Hello Tom! Recently we have encountered a problem when trying to shutdown our database. The Qnnn process remains active and keeps the database hanging for a long time before it can be finally closed. We have a set of nearly identical test databases and to confirm that it is not an isolated case, we tested closing all those databases and expectingly, all of them are stuck on waiting for Qnnn process to logout. We haven't used Advancing Queuing in our application development so I'm not sure the root cause of this problem. Can you help me out please? The alert log and trace file for relevant process is attached below.
2022-04-09T10:20:33.369532+08:00
alter pluggable database product_main1 close immediate
ORA-1155 signalled during: alter pluggable database product_main1 close immediate...
TABLE AUDSYS.AUD$UNIFIED: ADDED INTERVAL PARTITION SYS_P237 (94) VALUES LESS THAN (TIMESTAMP' 2022-05-01 00:00:00')
2022-04-09T10:20:55.623272+08:00
alter pluggable database product_main1 close abort
2022-04-09T10:20:55.729306+08:00
PRODUCT_MAIN1(3):KILL SESSION for sid=(1105, 24893):
PRODUCT_MAIN1(3): Reason = PDB close abort - oper lock blocker
PRODUCT_MAIN1(3): Mode = KILL HARD FORCE -/-/-
PRODUCT_MAIN1(3): Requestor = USER (orapid = 90, ospid = 6928, inst = 1)
PRODUCT_MAIN1(3): Owner = Process: USER (orapid = 89, ospid = 8592)
PRODUCT_MAIN1(3): Result = ORA-0
PRODUCT_MAIN1(3):KILL SESSION for sid=(1105, 24893):
PRODUCT_MAIN1(3): Reason = PDB close abort - oper lock blocker
PRODUCT_MAIN1(3): Mode = KILL HARD FORCE -/-/-
PRODUCT_MAIN1(3): Requestor = USER (orapid = 90, ospid = 6928, inst = 1)
PRODUCT_MAIN1(3): Owner = Process: USER (orapid = 89, ospid = 8592)
PRODUCT_MAIN1(3): Result = ORA-0
PRODUCT_MAIN1(3):JIT: pid 3984 requesting stop
PRODUCT_MAIN1(3):KILL SESSION for sid=(1468, 20341):
PRODUCT_MAIN1(3): Reason = PDB close abort
PRODUCT_MAIN1(3): Mode = KILL HARD FORCE -/-/-
PRODUCT_MAIN1(3): Requestor = USER (orapid = 90, ospid = 6928, inst = 1)
PRODUCT_MAIN1(3): Owner = Process: Q00B (orapid = 28, ospid = 9820)
PRODUCT_MAIN1(3): Result = ORA-0
2022-04-09T10:25:55.948873+08:00
PRODUCT_MAIN1(3):Active process 7420 user 'OracleServicePRODUCT1' program 'ORACLE.EXE (Q009)', not in a wait
PRODUCT_MAIN1(3):SHUTDOWN: waiting for logins to complete.
2022-04-09T11:20:56.603495+08:00
PRODUCT_MAIN1(3):Active process 1204 user 'OracleServicePRODUCT1' program 'ORACLE.EXE (Q001)', not in a wait
PRODUCT_MAIN1(3):SHUTDOWN: Active sessions prevent database close operation
Shutdown did not complete in 60 minutes
2022-04-09T11:20:56.612495+08:00
PRODUCT_MAIN1(3):PDB Close Abort marking the Control File to indicate pdb 3 as aborted for tno 1
PRODUCT_MAIN1(3):Buffer Cach invalidation for PDB 3 started
PRODUCT_MAIN1(3):Buffer Cache invalidation for PDB 3 complete
2022-04-09T11:20:57.029207+08:00
PRODUCT_MAIN1(3):While transitioning the pdb 3 to clean state, clearing all its abort bits in the control file.
Pluggable database PRODUCT_MAIN1 closed
Completed: alter pluggable database product_main1 close abort
2022-04-09T11:20:58.333491+08:00
Buffer Cache Full DB Caching mode changing from FULL CACHING DISABLED to FULL CACHING ENABLED *** 2022-04-08T20:16:06.291293+08:00 (CDB$ROOT(1))
Required IPC RDMAV_FORK_SAFE environment not set
Required IPC RDMAV_HUGEPAGES_SAFE environment not set
Trace file D:\APP\ADMINISTRATOR\diag\rdbms\product1\product1\trace\product1_q001_1204.trc
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.3.0.0.0
Build label: RDBMS_19.3.0.0.0DBRU_WINDOWS.X64_190528
Windows NT Version V6.2
ORACLE_HOME = D:\WINDOWS.X64_193000_db_home
Node name : TYZH-SZV-APP1-3
CPU : 16 - type 866416 physical cores
Process Affinity : 0x0000000000000000
Memory (Avail/Total): Ph:14639M/32767M, Ph+PgF:18975M/37631M
VM name : VMWare Version (6)
Instance name: product1
Redo thread mounted by this instance: 1
Oracle process number: 0
Windows thread id: 1204, image:
For hangs and similar, you really need to talk to Support for that one.
But personally, I've never really been a fan of "shutdown immediate" because you're in effect "asking" sessions to exit. If those sessions (Qxxx or otherwise) are in any kind of hung state or tight loop, there is always that risk. My preference for stop/start of a database is:
shutdown abort
startup
If I need the database closed and in a clean state, I would do:
shutdown abort
startup restrict
shutdown
to ensure that the instance recovery has been done.
I've always opted for this approach to ensure that shutdown times are predictable.