For many years, Oracle software quality has improved every year. Bugs were resolved and did not reappear. New bugs were rare and hard to find. However, it seems to me that they have regressed in the last few versions of Oracle. Some very simple errors have appeared in their software, in both the grid infrastructure and in the database software.
I have been in the process of putting together an Oracle 19c Cluster on VMware workstation for the purpose of a blog on Golden Gate. It has been a struggle. The first problem I ran into was in running the root.sh script:
2019/07/29 15:31:31 CLSRSC-4002: Successfully installed Oracle Trace File Analyzer (TFA) Collector.
2019/07/29 15:31:35 CLSRSC-594: Executing installation step 9 of 19: ‘ConfigOLR’.
2019/07/29 15:31:57 CLSRSC-594: Executing installation step 10 of 19: ‘ConfigCHMOS’.
2019/07/29 15:31:57 CLSRSC-594: Executing installation step 11 of 19: ‘CreateOHASD’.
2019/07/29 15:32:07 CLSRSC-594: Executing installation step 12 of 19: ‘ConfigOHASD’.
2019/07/29 15:32:08 CLSRSC-330: Adding Clusterware entries to file ‘oracle-ohasd.service’
2019/07/29 15:32:57 CLSRSC-594: Executing installation step 13 of 19: ‘InstallAFD’.
2019/07/29 15:33:10 CLSRSC-594: Executing installation step 14 of 19: ‘InstallACFS’.
2019/07/29 15:33:23 CLSRSC-594: Executing installation step 15 of 19: ‘InstallKA’.
2019/07/29 15:33:35 CLSRSC-594: Executing installation step 16 of 19: ‘InitConfig’.
2019/07/29 15:33:40 CLSRSC-119: Start of the exclusive mode cluster failed
Died at /u01/app/19.3.0/grid/crs/install/crsinstall.pm line 2439.
Died at line 2439. Really? No error message, nothing. It just died. This one took quite a bit of research, and finally I discovered the problem. My cluster name was ggclust1-cluster. See the problem? It took me a while too. The cluster name was 16 characters, and I entered the name in the installer conversation. But the maximum size of a cluster name is 15 characters.
Next, while running DBCA to create a new database, the DBCA process terminated with ‘Recovery manager failed to restore datafiles’. In the alert log of the database that was supposed to be created, there was this:
WARNING: failed to register ASMB with ASM instance
2019-07-30T18:42:30.735803-05:00
Errors in file /u01/app/oracle/diag/rdbms/ggdemo1/ggdemo11/trace/ggdemo11_asmb_98417.trc:
ORA-01017: invalid username/password; logon denied
DBCA had never prompted me for a password. This one took some research, but finally I found it. The problem was that Oracle was not in the oinstall group. If you installed the Oracle preinstall package, it should have put Oracle in the oinstall group, and if you run id oracle, it will show oracle in the oinstall group.
However, if you run the command ‘grep oracle /etc/group’:
oinstall:x:54321:==>
dba:x:54322:oracle
racdba:x:54330:oracle
oracle does not show up in the oinstall group. This looks like a problem with both DBCA and the Oracle preinstall package. The fix is to manually add oracle to the oinstall group. DBCA could also be modified to prompt for the ASM username/password, but that would require a change from Oracle.
usermod -g oinstall -G oinstall,dba oracle
These are two problems you are likely to run into on a fresh installation of Oracle 19c.
Andrew Kerber's Oracle DBA Weblog 
March 18, 2020 at 14:11 |
Andrew: Thanks for your posting. We got the same error (“failed to register ASMB with ASM instance” plus ORA-01017) in running dbua and your message is the only one found on the Internet or MOS. The solution is to explicitly add oracle to /etc/group on the line for oinstall as you suggested. Technically, this is not needed because Red Hat Enterprise or Oracle Linux uses the User Private Groups scheme, so a user’s primary group is in /etc/passwd but not in /etc/group; only supplementary groups should be added to /etc/group. (So it’s not right to say oracle is not in oinstall group.) But checking our servers set up by Oracle Support, i.e. those Exadata compute nodes, I see oracle is always in /etc/group on the line for oinstall. I think some tools, dbca, dbua and maybe some others, explicitly check the file /etc/group instead of using commands such as `id’ to check for groups oracle is in. That’s faulty logic, even more so in view of the fact that Oracle Linux also follows UPG.
April 29, 2020 at 18:00 |
Thanks I hit this same error.
June 15, 2020 at 12:19 |
Andrew: Thank you very much! I got the same issue and I spent lot of time time till finally see your post
August 13, 2020 at 07:27 |
I encountered the same issue on a standalone server with ASM and Linux o/s.
ASM was updated to 19c.
Installed 19c rdbms and patched with July 31326362 COMBO OF OJVM RU COMPONENT 19.8.0.0.200714 + DB RU 19.8.0.0.200714 .
When using dbca to create the 1st 19c database on the server, it indicated failed to start ASMB.
Here is the error message:
====================
Starting background process ASMB
2020-08-11T08:28:46.140586-05:00
ASMB started with pid=46, OS id=40048
2020-08-11T08:28:47.165219-05:00
WARNING: failed to start ASMB (connection failed) state=0x1 sid=’+ASM’
2020-08-11T08:28:47.165341-05:00
Errors in file /u01/app/oracle/diag/rdbms/jab/jab/trace/jab_asmb_40048.trc:
ORA-01017: invalid username/password; logon denied.
Create a MOS ticket and Oracle support recommended to add oracle user oinstall. oinstall:x:210:oracle
(run as root or sudo su – ) command: usermod -a -G oinstall oracle
I was able to create the 19c rdbms database using dbca after adding oracle to oinstall.
If Oracle support finds the root cause of my problem then I will post and update.
January 19, 2021 at 09:43 |
I got the same error as Jeff when upgrading to 19c using autoupgrade. this command resolved it so thanks for sharing.
(run as root or sudo su – ) command: usermod -a -G oinstall oracle