案例分享：关闭 Oracle 审计时遇到的 Bug 排查与解决
作者 | JiekeXu
来源 | JiekeXu之路（ID: JiekeXu_IT）
转载请联系授权 | (微信ID：xxq1426321293)
大家好，我是 JiekeXu,很高兴又和大家见面了，今天分享下 关闭 Oracle 审计时遇到的 Bug 排查与解决。本文首发于微信公众号【JiekeXu之路】，欢迎点击上方蓝字关注我吧！
前 言
一重要的生产库长期以来就有各种问题，前段时间刚进行完 PSU190716 的更新，这两天查到发现审计功能对其性能有较大的影响，故客户要求关闭审计功能。我们便申请了三个小时的停机窗口，进行关闭审计的操作。心想改参数重启实例四十分钟就可以搞定的事，三个小时多多有余，因为数据量达五六十 T ，小伙伴都比较怕，只有我做了。以下涉及到实际的主机名、实例名均已替换为测试相关的，如不对应忽略即可。
正 文
一、先补充知识点 Oracle 审计
Oracle 审计(Audit)主要用于记录用户对数据库所做的操作，基于配置的不同，审计的结果会放在操作系统文件中或者系统表中。
默认情况下，使用管理员权限连接实例，开启及关闭数据库是会强制进行审计的，其它的基础的操作则没有进行审计。
在 Oracle 11g 中，一共有 4 种审计类型：
语句审计（Statement Auditing）：对特定的 SQL 语句进行审计，不指定具体对象；
权限审计（Privilege Auditing）：对特定的系统权限使用情况进行审计；
对象审计（Object Auditing）：对特定的模式对象上执行的特定语句进行审计；
网络审计（Network Auditing）：对网络协议错误与网络层内部错误进行审计。
Oracle 建议将审计跟踪写入到操作系统文件中，这是因为这种配置在源数据库系统上造成的开销较小。要启用数据库审计，应将初始化参数 AUDIT_TRAIL 设置为以下任一值：
| 参数值 | 含义 |
DB | 启用数据库审计并将所有审计记录指向数据库审计跟踪 (SYS.AUD$) 中，始终写入到操作系统审计跟踪的记录除外 |
DB,EXTENDED | 完成 AUDIT_TRAIL=DB 的全部操作并填充 SYS.AUD$ 表的 SQL 绑定和 SQL 文本列 |
XML | 启用数据库审计并将所有审计记录以 XML 格式指向一个操作系统文件 |
XML,EXTENDED | 完成 AUDIT_TRAIL=XML 的全部操作，添加 SQL 绑定和 SQL 文本列 |
OS（推荐） | 启用数据库审计并将所有审计记录指向一个操作系统文件 |
此外，还应设置以下数据库参数：
init.ora 参数：AUDIT_FILE_DEST — 指定操作系统审计跟踪位置的动态参数。Unix/Linux 上的默认位置为 $ORACLE_BASE/admin/$ORACLE_SID/adump。Windows 上默认为事件日志。为获得更好的性能，它应当引用磁盘上的一个目录，该目录在本地附加到运行 Oracle 实例的主机上。
init.ora 参数：AUDIT_SYS_OPERATIONS — 启用对用户 SYS 以及使用 SYSDBA、SYSOPER、SYSASM、SYSBACKUP、SYSKM 和 SYSDG 权限进行连接的用户发出的操作的审计。审计跟踪数据写入到操作系统审计跟踪中。该参数应当设为 true。
那么，为何要使用审计呢？官方给出如下解释：
对操作启用问责制。
基于该责任制，阻止用户采取不适当的行动。
调查可疑活动。
通知审核员未经授权的用户采取的措施。
检测授权或访问控制实施中的问题。
解决合规性的审核要求。
监视和收集有关特定数据库活动的数据。
有关 Oracle 数据库审计的更多信息和优秀实践，请阅读 Oracle Audit Vault OTN 页面上的优秀实践白皮书。有关数据库审计的详细信息，见介绍性的 Oracle 数据库两日速成和安全性指南以及 Oracle 数据库安全性指南。
https://docs.oracle.com/cd/E11882_01/server.112/e10575/tdpsg_auditing.htm#TDPSG50523
Database 2 Day + Security Guide ——> 7 Auditing Database Activity
https://www.oracle.com/technetwork/topics/security/index-085292-zhs.html
二、简单说明下生产环境系统版本和数据库版本及补丁
操作系统：AIX 6.1
数据库：11.2.0.4
PSU：190716
数据量：53T 左右
JiekeXu1:/app/oracle/diag/rdbms/testdbs/testdbs1/trace$cd $ORACLE_HOME/OPatchJiekeXu1:/app/product/11.2.0/db/OPatch$./opatch lspatches29497421;Database Patch Set Update : 11.2.0.4.190716 (29497421)29141201;OCW Patch Set Update : 11.2.0.4.190416 (29141201)20675347;OPatch succeeded.JiekeXu1:/app/product/11.2.0/db/OPatch$JiekeXu1:/app/oracle/diag/rdbms/testdbs/testdbs1/trace$oslevel6.1.0.0JiekeXu1:/app/product/11.2.0/db/OPatch$SQL*Plus: Release 11.2.0.4.0 Production on Tue Apr 28 22:29:52 2020Copyright (c) 1982, 2013, Oracle. All rights reserved.Connected to:Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit ProductionWith the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,Data Mining and Real Application Testing optionsSQL> set line 345col host_name for a30select inst_id,INSTANCE_NAME,HOST_name,status from gv$instance;SQL> SQL> INST_ID INSTANCE_NAME HOST_NAME STATUS---------- -------------------------------- ------------------------------ ------------------------ 1 testdbs1 JiekeXu1 OPEN 2 testdbs2 JiekeXu2 OPENsu - gridcrsctl status res -t--------------------------------------------------------------------------------NAME TARGET STATE SERVER STATE_DETAILS --------------------------------------------------------------------------------Local Resources--------------------------------------------------------------------------------ora.DATA.dg ONLINE ONLINE JiekeXu1 ONLINE ONLINE JiekeXu2 ora.ECIF_ARCH.dg ONLINE ONLINE JiekeXu1 ONLINE ONLINE JiekeXu2 ora.LISTENER.lsnr ONLINE ONLINE JiekeXu1 ONLINE ONLINE JiekeXu2 ora.OCR.dg ONLINE ONLINE JiekeXu1 ONLINE ONLINE JiekeXu2 ora.asm ONLINE ONLINE JiekeXu1 Started ONLINE ONLINE JiekeXu2 Started ora.gsd OFFLINE OFFLINE JiekeXu1 OFFLINE OFFLINE JiekeXu2 ora.net1.network ONLINE ONLINE JiekeXu1 ONLINE ONLINE JiekeXu2 ora.ons ONLINE ONLINE JiekeXu1 ONLINE ONLINE JiekeXu2 ora.registry.acfs ONLINE OFFLINE JiekeXu1 ONLINE ONLINE JiekeXu2 --------------------------------------------------------------------------------Cluster Resources--------------------------------------------------------------------------------ora.LISTENER_SCAN1.lsnr 1 ONLINE ONLINE JiekeXu2 ora.cvu 1 ONLINE ONLINE JiekeXu2 ora.testdbs.db 1 ONLINE ONLINE JiekeXu1 Open 2 ONLINE ONLINE JiekeXu2 Open ora.oc4j 1 ONLINE ONLINE JiekeXu2 ora.scan1.vip 1 ONLINE ONLINE JiekeXu2 ora.JiekeXu1.vip 1 ONLINE ONLINE JiekeXu1 ora.JiekeXu2.vip 1 ONLINE ONLINE JiekeXu2
--数据量查看 53TSQL> select sum(bytes)/1024/1024/1024 Total_GB from dba_segments; TOTAL_GB----------55135.5422三、关闭审计操作步骤
--节点 1 操作su - oraclesqlplus / as sysdbaSQL> show parameter audit_trailNAME TYPE VALUE------------------------------------ ---------------------- ------------------------------audit_trail string DBSQL> create pfile='/tmp/pfilebak.ora' from spfile;File created.SQL> alter database backup controlfile to trace as '/tmp/ctl.ctl' reuse; Database altered.SQL> alter system set audit_trail=none scope=spfile;--两节点 切归档、打检查点SQL> alter system switch logfile;System altered.SQL> alter system switch logfile;System altered.SQL> /System altered.SQL> alter system checkpoint;System altered.--节点2SQL> alter system switch logfile;System altered.SQL> alter system switch logfile;System altered.SQL> alter system switch logfile;System altered.SQL> alter system switch logfile;System altered.SQL> /System altered.SQL> alter system checkpoint;System altered.然后停止应用杀掉残余数据库连接，停止实例。
JiekeXu1:/home/oracle$ps -ef | grep LOCAL=NO | grep -v grep | awk '{print $2}' | wc -l 1688JiekeXu1:/home/oracle$ps -ef | grep LOCAL=NO | grep -v grep | awk '{print $2}' | xargs kill -9JiekeXu1:/home/oracle$srvctl stop database -d testdbs一切感觉都没问题，可就是等到半小时左右了还没有停止。平时这套库 20 多分钟就可以搞定的，这次居然快 40 分钟了还没有搞定。便去看两节点的 alert 日志，发现节点 2 已经停止完毕，节点 1 日志 如下：
Tue Apr 28 15:26:07 2020Thread 2 advanced to log sequence 858108 (internal thread disable)Tue Apr 28 15:26:37 2020Redo thread 2 internally disabled at seq 858108 (CKPT)Tue Apr 28 15:26:38 2020Archived Log entry 3504803 added for thread 2 sequence 858107 ID 0x5f6af75d dest 1:Tue Apr 28 15:26:39 2020ARC6: Standby redo logfile selected for thread 2 sequence 858107 for destination LOG_ARCHIVE_DEST_2Tue Apr 28 15:26:40 2020ARC5: Archiving disabled thread 2 sequence 858108Archived Log entry 3504805 added for thread 2 sequence 858108 ID 0x5f6af75d dest 1:ARC5: Archive log rejected (thread 2 sequence 858108) at host 'TESTDB'FAL[server, ARC5]: FAL archive failed, see trace file. ARCH: FAL archive failed. Archiver continuingORACLE Instance testdbs1 - Archival Error. Archiver continuing.Tue Apr 28 15:26:56 2020Decreasing number of real time LMS from 10 to 0
节点 1 后台日志一直卡在 “Decreasing number of real time LMS from 10 to 0”，没办法想直接 kill 掉 pmon 进程，同事说要不直接关闭集群，我想那也行，直接关闭集群很快也省事。所以就取消掉 srvctl 命令了，直接使用 crsctl stop crs 停集群，可是当停止了 listener、scan 等监听相关的进程后停止数据库又是卡住了，这样持续了半小时之多。返回去看又看了眼日志 “FAL[server, ARC5]: FAL archive failed, see trace file. ”
Tue Apr 28 15:26:40 2020ARC5: Archiving disabled thread 2 sequence 858108Archived Log entry 3504805 added for thread 2 sequence 858108 ID 0x5f6af75d dest 1:ARC5: Archive log rejected (thread 2 sequence 858108) at host 'TESTDB'FAL[server, ARC5]: FAL archive failed, see trace file. ARCH: FAL archive failed. Archiver continuingORACLE Instance testdbs1 - Archival Error. Archiver continuing.Tue Apr 28 15:26:56 2020Decreasing number of real time LMS from 10 to 0经查看 当时 trace file 为 testdbs1_lmhb_23396426.trc 这个，文件最后内容一直报错 LCK0 (ospid: 42140728) has not moved for 20 sec
--testdbs1_lmhb_23396426.trc 文件内容最后一直报错 LCK0 (ospid: 42140728) has not moved for 20 sec*** 2020-04-28 16:16:58.640==============================LCK0 (ospid: 42140728) has not moved for 20 sec (1588061818.1588061798)kjfmGCR_HBCheckAll: LCK0 (ospid: 42140728) has status 2 : waiting for event 'rdbms ipc message' for 0 secs with wait_id 171895692. ===[ Wait Chain ]=== Wait chain is empty.*** 2020-04-28 16:17:18.643==============================LCK0 (ospid: 42140728) has not moved for 20 sec (1588061838.1588061818)kjfmGCR_HBCheckAll: LCK0 (ospid: 42140728) has status 2 : waiting for event 'rdbms ipc message' for 0 secs with wait_id 171895756. ===[ Wait Chain ]=== Wait chain is empty.*** 2020-04-28 16:17:38.645==============================LCK0 (ospid: 42140728) has not moved for 20 sec (1588061858.1588061838)kjfmGCR_HBCheckAll: LCK0 (ospid: 42140728) has status 2 : waiting for event 'rdbms ipc message' for 0 secs with wait_id 171895820. ===[ Wait Chain ]===故去了解下 LCK0 进程相关的信息，官方文档解释如下：
LCK0Instance Enqueue Background ProcessManages global enqueue requests and cross-instance broadcastsThe process handles all requests for resources other than data blocks. For examples, LCK0 manages library and row cache requests.Database and ASM instances, Oracle RAC--下面是 LMHB 进程解释，LMHB 监视 LMON、LMD 和 LMSn 进程，以确保它们在没有阻塞或旋转的情况下正常运行。LMHBGlobal Cache/Enqueue Service Heartbeat MonitorMonitor the heartbeat of LMON, LMD, and LMSn processesLMHB monitors LMON, LMD, and LMSn processes to ensure they are running normally without blocking or spinning.Database and ASM instances, Oracle RAChttps://docs.oracle.com/cd/E11882_01/server.112/e40402/bgprocesses.htm
https://www.anbob.com/archives/2942.html
LCK: This lock process manages requests that are not cache-fusion requests. Requests like row cache requests and library cache requests. Only a single LCK process is allowed for each instance.
PMON is waiting for an LCK process to cleanup the lock context after a foreground process died while doing a global cache lock operation.
The shared pool is stressed and memory need to be freed for the new cursors. As a consequence, the dictionary cache is reduced in size by the LCK process causing a temporal hang of the instance since the LCK can’t do other activity during that time. Since the dictionary cache is a memory area protected clusterwide in RAC, the LCK is responsible to free it in collaboration with the dictionary cache users (the sessions using cursors referenced in the dictionary cache). This process can be time consuming when the dictionary cache is big.
因为在 RAC 环境中 LCK 进程负责释放持有 row cache 的用户进程协调工作及 Library cache 的请求， 如果 LCK 出现性能问题也就会导致 library cache object 无法请求和会话不 KILL 后的释放 row cache 堵塞。Pmon 进程也需要等待 LCK 进程清理 died 进程后才能清理锁上下文。
下面引用网络一篇文档中部分内容说有可能是 BUG，这个就暂时不讨论，放后面继续说明，先给出临时解决方案，既然实例已经卡住了，那就杀掉卡的进程 LCK0 或者直接 kill pmon 进程，但是有风险，生产环境又是大库，则采用了新开会话 shutdown abort。
当 shared pool 里的对象需要为新的对象释放空间时如 sql cursor, LCK 进程降低 Row Cache 大小期间使数据库临时 hang， 因为在 RAC 环境中 LCK 进程负责释放持有 row cache 的用户进程协调工作及Library cache 的请求， 如果LCK出现性能问题也就 会导致library cache object无法请求和会话补KILL后的释放row cache堵塞。Pmon 进程 也需要等待LCK进程清理died进程后才能清理锁上下文。而且如要row cache越大后期LCK进 程释放资源时就需要消耗更长的时间(每个instance 只有一个lck进程)。
该类现象相关的BUG：Bug 8215444 Many processes hang in RAC with wait event “DFS lock handle”Bug 16529874 Frequent “LCK(ospid: ****) has not moved for 20 sec” trace messagesBUG:8666117 – LCK0 PROCESS STUCK AT WAITING FOR “LATCH: ROW CACHE OBJECTS”Bug 18199537 – RAC database becomes almost hung when large amount of row cache are used in shared poolBug 13814739 Excessive KQR X PO” allocations in a RAC environment (can cause ORA-4031)实例直接 shutdown abort 后 alert 立即出现 terminating the instance ，刚才停不掉的 集群也可以正常停止了。
Tue Apr 28 16:40:47 2020License high water mark = 3645USER (ospid: 40109308): terminating the instanceInstance terminated by USER, pid = 40109308Tue Apr 28 16:47:55 2020Starting ORACLE instance (normal)LICENSE_MAX_SESSION = 0LICENSE_SESSIONS_WARNING = 0Initial number of CPU is 256Number of processor cores in the system is 64停止后担心的就是能不能正常启动的问题，因为节点2是正常停止的，故先将节点 2 正常启动了，没问题正常启动了节点 2 实例。实例 1 正常启动crsctl start crs 无报错，十分钟左右时间正常启动了。启动后检查状态正常，审计参数已经修改为 NONE 了。
sqlplus / as sysdbaSQL> set line 345col host_name for a30select inst_id,INSTANCE_NAME,HOST_name,status from gv$instance;SQL> INST_ID INSTANCE_NAME HOST_NAME STATUS---------- -------------------------------- ------------------------------ ------------------------ 1 testdbs1 JiekeXu1 OPEN 2 testdbs2 JiekeXu2 OPENSQL> show parameter audit_trailNAME TYPE VALUE------------------------------------ ---------------------- ------------------------------audit_trail string NONESQL> exit--顺便看了眼 LCK0 和 LMHB 这两个后台进程JiekeXu1:/app/oracle/diag/rdbms/testdbs/testdbs1/trace$ps -ef | grep ora_lck0 oracle 12386998 1 9 16:48:18 - 3:38 ora_lck0_testdbs1 oracle 12060336 35521284 0 20:56:14 pts/3 0:00 grep ora_lck0JiekeXu1:/app/oracle/diag/rdbms/testdbs/testdbs1/trace$ps -ef | grep ora_lmhb oracle 8323226 1 0 16:48:06 - 0:00 ora_lmhb_testdbs1 oracle 25560564 35521284 0 20:56:41 pts/3 0:00 grep ora_lmhb四、关闭审计后清空表 AUD$
数据库审计记录存放于系统表空间 SYSTEM 的 AUD$ 表中，需将其清空，如下所示，这样便算是完成了，本来半小时就可以搞定的问题硬是花了两小时。完事后打扫战场准备下班回家后查一下上文所说的 BUG。
SQL> col TABLESPACE_NAME for a20 SELECT a.tablespace_name,round(total/1024/1024/1024) "Total g",round(free/1024/1024/1024) "Free g",ROUND((total-free)/total,4)*100 "USED%"FROM (SELECT tablespace_name,SUM(bytes) free FROM DBA_FREE_SPACE GROUP BY tablespace_name ) a,(SELECT tablespace_name,SUM(bytes) total FROM DBA_DATA_FILESGROUP BY tablespace_name) b WHERE a.tablespace_name=b.tablespace_name ORDER BY 4;SQL> 2 3 TABLESPACE_NAME Total g Free g USED%-------------------- ---------- ---------- ----------UNDOTBS2 417 410 1.56UNDOTBS1 430 413 4.07SYSTEM 20 10 51.61USERS 150 58 61.62SYSAUX 8 2 70.8212 rows selected.
SQL> truncate table SYS.AUD$;
Table truncated.SQL> SELECT a.tablespace_name,round(total/1024/1024/1024) "Total g", 2 round(free/1024/1024/1024) "Free g",ROUND((total-free)/total,4)*100 "USED%" 3 FROM (SELECT tablespace_name,SUM(bytes) free FROMDBA_FREE_SPACEGROUP BY tablespace_name ) a,(SELECT tablespace_name,SUM(bytes) total FROM DBA_DATA_FILESGROUP BY tablespace_name) b 4 5 6 7 8 WHERE a.tablespace_name=b.tablespace_name and a.tablespace_name='SYSTEM' 9 ORDER BY 4;TABLESPACE_NAME Total g Free g USED%-------------------- ---------- ---------- ----------SYSTEM 20 17 15.27五、BUG 排查与确认
MOS 上有这一篇
Bug 16529874 - Frequent "LCK(ospid: ****) has not moved for 20 sec" trace messages (Doc ID 16529874.8) 果然就是 Bug，12.2 以下版本均会受影响，Bug 16529874 在 12c 中才修复了，文档中提到一参数 “ _lm_rcvr_hang_check_frequency” 这个以下划线开头的为隐含参数，需要修改此参数。
首先来了解下隐含参数，在 sqlplus 中使用 show parameter name 可以查看到 Oracle 定义的参数, 它是通过查询 v$parameter 获得的.另外 Oracle 中还有一些隐含的参数无法直接通过 show parameter 的方式查询.可见 11.2.0.4 里参数有 352 个，隐含参数 2914 个。
SYS@PROD3> set autotrace traceonly;
SYS@PROD3> select * from v$parameter;353 rows selected.Execution Plan----------------------------------------------------------Plan hash value: 1128103955------------------------------------------------------------------------------| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |------------------------------------------------------------------------------| 0 | SELECT STATEMENT | | 1 | 4414 | 0 (0)| 00:00:01 ||* 1 | HASH JOIN | | 1 | 4414 | 0 (0)| 00:00:01 ||* 2 | FIXED TABLE FULL| X$KSPPI | 1 | 249 | 0 (0)| 00:00:01 || 3 | FIXED TABLE FULL| X$KSPPCV | 100 | 406K| 0 (0)| 00:00:01 |------------------------------------------------------------------------------Predicate Information (identified by operation id):--------------------------------------------------- 1 - access("X"."INDX"="Y"."INDX") filter(TRANSLATE("KSPPINM",'_','#') NOT LIKE '#%' OR "KSPPSTDF"='FALSE' OR BITAND("KSPPSTVF",5)>0) 2 - filter("X"."INST_ID"=USERENV('INSTANCE') AND BITAND("KSPPIFLG",268435456)=0 AND TRANSLATE("KSPPINM",'_','#') NOT LIKE '##%')Statistics---------------------------------------------------------- 5 recursive calls 0 db block gets 8 consistent gets 0 physical reads 0 redo size 38903 bytes sent via SQL*Net to client 772 bytes received via SQL*Net from client 25 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 352 rows processedSYS@PROD3> set line 80SYS@PROD3> desc x$ksppiName Null? Type----------------------------------------- -------- ----------------------------ADDR RAW(8) --内存地址INDX NUMBER --序号，从0开始INST_ID NUMBER --instance numberKSPPINM VARCHAR2(80) --参数名称KSPPITY NUMBER --参数类型 1,'boolean' 2,'string', 3,'number',4,'fileKSPPDESC VARCHAR2(255) --描述KSPPIFLG NUMBER --标志字段（用来说明是isses_modifiable or issys_modifiableKSPPILRMFLG NUMBERKSPPIHASH NUMBERSYS@PROD3> desc x$ksppcvName Null? Type----------------------------------------- -------- ----------------------------ADDR RAW(8) --内存地址 INDX NUMBER --序号，从0开始INST_ID NUMBER --instance numberKSPPSTVL VARCHAR2(4000) --当前值KSPPSTDVL VARCHAR2(4000) KSPPSTDF VARCHAR2(9) --是否为缺省值KSPPSTVF NUMBER --标志字段，用来说明('Modified' or 'System Modified' or is_adjusted)KSPPSTCMNT VARCHAR2(255) --comment六、隐含参数修改
因为是生产环境，修改此参数需要变更窗口重启实例，故无法在正式环境修改，需要等待上报申请停机窗口。所以以下均是自己虚拟机测试环境修改的结果。隐含参数修改时需要加双引号“”不能有多余的空格，不过有的隐含参数可直接修改，有的需要修改 spfile。
SQL> set line 345SQL> col NAME for a35SQL> col VALUE for a20SQL> col DESCRIPTION for a60SQL> select a.ksppinm name, b.ksppstvl value,a.ksppdesc description from x$ksppi a, x$ksppcv b where a.indx = b.indx and a.ksppinm like '_lm_rcvr_hang_check_frequency';NAME VALUE DESCRIPTION----------------------------------- -------------------- ------------------------------------------------------------_lm_rcvr_hang_check_frequency 20 receiver hang check frequency in secondsSYS@PROD3> SYS@PROD3>SYS@PROD3> alter system set "_lm_rcvr_hang_check_frequency"=30;alter system set "_lm_rcvr_hang_check_frequency"=30 *ERROR at line 1:ORA-02095: specified initialization parameter cannot be modifiedSYS@PROD3> alter system set "_lm_rcvr_hang_check_frequency"=30 scope=spfile;System altered.SYS@PROD3> select a.ksppinm name, b.ksppstvl value,a.ksppdesc description from x$ksppi a, x$ksppcv b where a.indx = b.indx and a.ksppinm like '_lm_rcvr_hang_check_frequency';NAME VALUE DESCRIPTION----------------------------------- -------------------- ------------------------------------------------------------_lm_rcvr_hang_check_frequency 20 receiver hang check frequency in secondsSYS@PROD3>SYS@PROD3> shu immediateDatabase closed.Database dismounted.ORACLE instance shut down.SYS@PROD3> startupORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instanceORACLE instance started.Total System Global Area 835104768 bytesFixed Size 2257840 bytesVariable Size 499125328 bytesDatabase Buffers 327155712 bytesRedo Buffers 6565888 bytesDatabase mounted.Database opened.SYS@PROD3> select a.ksppinm name, b.ksppstvl value,a.ksppdesc description from x$ksppi a, x$ksppcv b where a.indx = b.indx and a.ksppinm like '_lm_rcvr_hang_check_frequency';NAME VALUE DESCRIPTION----------------------------------- -------------------- ------------------------------------------------------------_lm_rcvr_hang_check_frequency 30 receiver hang check frequency in seconds
好了就算告一段落了，整理一下分享给小伙伴们参考，如果此文对你有帮助，请支持点“在看”与转发，你的支持便是我最大的动力，让我们一起努力做更好的自己！如有其它不同见解，可扫描以下二维码添加微信交流探讨。
Oracle 11GR2 RAC 最新补丁 190416 安装指导
你该知道的 Oracle 认证那些事儿（送 OCP 题库）
三万字打造 91 道 MySQL 面试题【建议收藏】
六千字带你了解 Oracle 统计信息和执行计划
Oracle 软件包及补丁包免费下载及简单说明
Oracle 12C 最新补丁下载与安装操作指北
Oracle 12CR2 安装配置与基础学习
Windows 环境下安装 Oracle 19C
点亮在看，你最好看！