Hi all,
I'm experiencing a case which I'd like to share and seek for a solution. First I've successfully deployed both 12c and 18c DB on my 24Gb RAM /fast-CPU /NVME drive Centos 7.5 box.
After running HammerDB for a while, I decided the next step will be install ASM with Grid Infrastructure and see if it helps to improve the TCP-C results on my box.
I made probably all possible preparations according to the Grid Installation Guide, i.e. create both "grid" and "oracle" users, "oinstall", "dba","asmdba",... and other groups and also folders /u01/app/grid as ORACLE_BASE for "grid" user, and /u01/app/oracle for "oracle" user.
Then I installed Grid Infrastructure with "oracleasm" driver loaded and disk groups created beforehand, checked so far everything works fine:
[grid@larix sw]$ crsctl check has
CRS-4638: Oracle High Availability Services is online
[grid@larix sw]$ crsctl check evm
CRS-4533: Event Manager is online
[grid@larix sw]$ crsctl check css
CRS-4529: Cluster Synchronization Services is online
[grid@larix sw]$ srvctl status asm
ASM is running on larix
[grid@larix sw]$ asmca&
[1] 23604
[grid@larix sw]$ env | grep ORA
ORACLE_SID=+ASM
ORACLE_BASE=/u01/app/grid
ORACLE_HOME=/u01/app/grid/sw
The listener is active:
[oracle@larix ~]$ lsnrctl status
LSNRCTL for Linux: Version 18.0.0.0.0 - Production on 04-OCT-2018 13:17:51
Copyright (c) 1991, 2018, Oracle. All rights reserved.
Connecting to (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=1521))
STATUS of the LISTENER
------------------------
Alias LISTENER
Version TNSLSNR for Linux: Version 18.0.0.0.0 - Production
Start Date 04-OCT-2018 12:37:55
Uptime 0 days 0 hr. 39 min. 56 sec
Trace Level off
Security ON: Local OS Authentication
SNMP OFF
Listener Parameter File /u01/app/grid/sw/network/admin/listener.ora
Listener Log File /u01/app/grid/diag/tnslsnr/larix/listener/alert/log.xml
Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=larix)(PORT=1521)))
(DESCRIPTION=(ADDRESS=(PROTOCOL=ipc)(KEY=EXTPROC1521)))
Services Summary...
Service "+ASM" has 1 instance(s).
Instance "+ASM", status READY, has 1 handler(s) for this service...
Service "+ASM_DATA" has 1 instance(s).
Instance "+ASM", status READY, has 1 handler(s) for this service...
The command completed successfully
Now I xhost+ and su to "oracle" account and do step-by-step installation with configuring a new DB, and it runs well until DBCA is launched (which is the last step run after all software has been installed). Then it fails saying that "PMON didn't start".
No clue what happened in trace file, just says:
[root@larix ~]# cat /u01/app/oracle/admin/orcl/diag/diag/rdbms/orcl/orcl/trace/orcl_pmon_3917.tr
Trace file /u01/app/oracle/admin/orcl/diag/diag/rdbms/orcl/orcl/trace/orcl_pmon_3917.trc
Oracle Database 18c Standard Edition 2 Release 18.0.0.0.0 - Production
Version 18.3.0.0.0
Build label: RDBMS_18.1.0.0.0_LINUX.X64_180103.1
ORACLE_HOME: /u01/app/oracle/sw
System name: Linux
Node name: larix
Release: 3.10.0-862.6.3.el7.nvidia.x86_64
Version: #1 SMP Fri Jul 6 22:18:20 MSK 2018
Machine: x86_64
Instance name: orcl
Redo thread mounted by this instance: 0 <none>
Oracle process number: 0
Unix process pid: 3917, image:
*** 2018-10-04T13:12:16.944781+03:00
Oracle program name: oracle@larix (PMON)
-------------------------------------------------------------------------------
Trace Bucket Dump of current process skipped - empty bucket
------------------------------------------------------------------------------
I deinstall the failed package and re-run the installer without creating a new DB thus avoiding DBCA launch.
It's ok and I'm ready to proceed and make a new DB manually.
For connecting I'd use a simple initorcl.ora script - which has been tested and runs well without GI installed:
db_name='orcl'
memory_target=1G
processes = 150
audit_file_dest='/u01/app/oracle/admin/orcl/adump'
audit_trail ='db'
db_block_size=8192
db_domain=''
db_recovery_file_dest='/u01/app/oracle/admin/orcl/fast_recovery_area'
db_recovery_file_dest_size=2G
diagnostic_dest='/u01/app/oracle/admin/orcl/diag'
dispatchers='(PROTOCOL=TCP) (SERVICE=orcl)'
open_cursors=300
remote_login_passwordfile='EXCLUSIVE'
undo_tablespace='undo'
control_files = (ora_control1, ora_control2)
compatible ='12.2.0.1.0'
The result is as bad as before:
[oracle@larix ~]$ sqlplus / as sysdba
SQL*Plus: Release 18.0.0.0.0 - Production on Thu Oct 4 13:46:26 2018
Version 18.3.0.0.0
Copyright (c) 1982, 2018, Oracle. All rights reserved.
Connected to an idle instance.
SQL> startup nomount
ORA-00443: background process "PMON" did not start
SQL>
I tried both 12c and 18c versions of both software, the same negative result, both Enterprise and Standard versions of DB.
I googled the issue and found a description of a similar case:
.. but in my case the memory is high:
[root@larix ~]# df -h /dev/shm
Filesystem Size Used Avail Use% Mounted on
tmpfs 12G 693M 11G 6% /dev/shm
I tried to manipulate SGA_TARGET, MEMORY_TARGET in the initorcl.ora , but it doesn't help, PMON wouldn't start whatever memory is available.
I tried to install both 12c and 18c for both GI and DB - the same result, no difference.
So I cautiously guess the cause can be a faulty oraInventory folder, which is a mix of first GI setup and later DB setup. Without GI setup making the oraInventory folder first,
the DB makes it first and then runs well. After GI setup, even if you don't try to use ASM - and even after you'd deinstall GI altogether - , the DB wouldn't start because of "PMON is dead".
I hope someone has it solved already and would they please share the experience, thank you.