作者 | JiekeXu
来源 | JiekeXu之路（ID: JiekeXu_IT）
转载请联系授权 | (微信ID：xxq1426321293)
大家好，我是 JiekuXu,很高兴又和大家见面了，今天分享下 关闭 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/OPatch
JiekeXu1:/app/product/11.2.0/db/OPatch$./opatch lspatches
29497421;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$oslevel
6.1.0.0
JiekeXu1:/app/product/11.2.0/db/OPatch$
SQL*Plus: Release 11.2.0.4.0 Production on Tue Apr 28 22:29:52 2020
Copyright (c) 1982, 2013, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP,
Data Mining and Real Application Testing options
SQL> set line 345
col host_name for a30
select 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 OPEN
su - grid
crsctl 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
--数据量查看 53T
SQL> select sum(bytes)/1024/1024/1024 Total_GB from dba_segments;
TOTAL_GB
----------
55135.5422
三、关闭审计操作步骤
--节点 1 操作
su - oracle
sqlplus / as sysdba
SQL> show parameter audit_trail
NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
audit_trail string DB
SQL> 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.
--节点2
SQL> 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
1688
JiekeXu1:/home/oracle$ps -ef | grep LOCAL=NO | grep -v grep | awk '{print $2}' | xargs kill -9
JiekeXu1:/home/oracle$srvctl stop database -d testdbs
一切感觉都没问题，可就是等到半小时左右了还没有停止。平时这套库 20 多分钟就可以搞定的，这次居然快 40 分钟了还没有搞定。便去看两节点的 alert 日志，发现节点 2 已经停止完毕，节点 1 日志 如下：
Tue Apr 28 15:26:07 2020
Thread 2 advanced to log sequence 858108 (internal thread disable)
Tue Apr 28 15:26:37 2020
Redo thread 2 internally disabled at seq 858108 (CKPT)
Tue Apr 28 15:26:38 2020
Archived Log entry 3504803 added for thread 2 sequence 858107 ID 0x5f6af75d dest 1:
Tue Apr 28 15:26:39 2020
ARC6: Standby redo logfile selected for thread 2 sequence 858107 for destination LOG_ARCHIVE_DEST_2
Tue Apr 28 15:26:40 2020
ARC5: Archiving disabled thread 2 sequence 858108
Archived 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 continuing
ORACLE Instance testdbs1 - Archival Error. Archiver continuing.
Tue Apr 28 15:26:56 2020
Decreasing 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 2020
ARC5: Archiving disabled thread 2 sequence 858108
Archived 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 continuing
ORACLE Instance testdbs1 - Archival Error. Archiver continuing.
Tue Apr 28 15:26:56 2020
Decreasing 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 进程相关的信息，官方文档解释如下：
LCK0
Instance Enqueue Background Process
Manages global enqueue requests and cross-instance broadcasts
The 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 进程，以确保它们在没有阻塞或旋转的情况下正常运行。
LMHB
Global Cache/Enqueue Service Heartbeat Monitor
Monitor the heartbeat of LMON, LMD, and LMSn processes
LMHB monitors LMON, LMD, and LMSn processes to ensure they are running normally without blocking or spinning.
Database and ASM instances, Oracle RAC
https://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 messages
BUG: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 pool
Bug 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 2020
License high water mark = 3645
USER (ospid: 40109308): terminating the instance
Instance terminated by USER, pid = 40109308
Tue Apr 28 16:47:55 2020
Starting ORACLE instance (normal)
LICENSE_MAX_SESSION = 0
LICENSE_SESSIONS_WARNING = 0
Initial number of CPU is 256
Number of processor cores in the system is 64
停止后担心的就是能不能正常启动的问题，因为节点2是正常停止的，故先将节点 2 正常启动了，没问题正常启动了节点 2 实例。实例 1 正常启动crsctl start crs 无报错，十分钟左右时间正常启动了。启动后检查状态正常，审计参数已经修改为 NONE 了。
sqlplus / as sysdba
SQL> set line 345
col host_name for a30
select 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 OPEN
SQL> show parameter audit_trail
NAME TYPE VALUE
------------------------------------ ---------------------- ------------------------------
audit_trail string NONE
SQL> 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_lck0
JiekeXu1:/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_FILES
GROUP 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.56
UNDOTBS1 430 413 4.07
SYSTEM 20 10 51.61
USERS 150 58 61.62
SYSAUX 8 2 70.82
12 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 FROM
DBA_FREE_SPACE
GROUP BY tablespace_name ) a,
(SELECT tablespace_name,SUM(bytes) total FROM DBA_DATA_FILES
GROUP 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 processed
SYS@PROD3> set line 80
SYS@PROD3> desc x$ksppi
Name Null? Type
----------------------------------------- -------- ----------------------------
ADDR RAW(8) --内存地址
INDX NUMBER --序号，从0开始
INST_ID NUMBER --instance number
KSPPINM VARCHAR2(80) --参数名称
KSPPITY NUMBER --参数类型 1,'boolean' 2,'string', 3,'number',4,'file
KSPPDESC VARCHAR2(255) --描述
KSPPIFLG NUMBER --标志字段（用来说明是isses_modifiable or issys_modifiable
KSPPILRMFLG NUMBER
KSPPIHASH NUMBER
SYS@PROD3> desc x$ksppcv
Name Null? Type
----------------------------------------- -------- ----------------------------
ADDR RAW(8) --内存地址
INDX NUMBER --序号，从0开始
INST_ID NUMBER --instance number
KSPPSTVL 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 345
SQL> col NAME for a35
SQL> col VALUE for a20
SQL> col DESCRIPTION for a60
SQL> 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 seconds
SYS@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 modified
SYS@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 seconds
SYS@PROD3>
SYS@PROD3> shu immediate
Database closed.
Database dismounted.
ORACLE instance shut down.
SYS@PROD3> startup
ORA-32004: obsolete or deprecated parameter(s) specified for RDBMS instance
ORACLE instance started.
Total System Global Area 835104768 bytes
Fixed Size 2257840 bytes
Variable Size 499125328 bytes
Database Buffers 327155712 bytes
Redo Buffers 6565888 bytes
Database 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
点亮在看，你最好看！