Skip to content

All posts by Guang Cai Li - 12. page

Oracle 每一个版本都发布的用于调查 ORA-1555 错误的脚本,二分切每一版本都有所不同。这些脚本只适用于自动 UNDO 管理 (AUM) 配置的环境。

脚本文件以本文档附件的形式提供。在mos上可以下载到,具体的脚本有如下列出的分类,下载地址参考此链接:http://www.ludatou.com/?page_id=2479

 

AUM 配置和 ORA-1555 全面分析

1. 配置:

UndoDatafiles.sql — spool 输出到位于默认目录位置的文件 undodatafiles.out 中。

UndoParameters.sql — spool 输出到位于默认目录位置的文件 undoparameters.out 中。

UndoUsage.sql — spool 输出到位于默认目录位置的文件 undousage.out 中。

2. 当前未提交的事务:

CurrentActivity.sql — spool 输出到位于默认目录位置的文件 undoactivity.out 中。

3. 历史 UNDO 信息:

UndoHistoryInfo.sql — spool 输出到位于默认目录位置的 undohistory.out 中。

UndoStatistics.sql — spool 输出到位于默认目录位置的 undostatistics.out 中。您可修改此报告以显示适当的分析时间范围。默认情况下,查看最后两天的 V$UNDOSTAT 数据。在 V$UNDOSTAT 视图中,数据会保留七天。

4. 等待/锁定分析:

UndoPressure.sql — spool 输出到位于默认目录位置的 undopressure.out 中。

5. 调查 LOB 问题:

LobData.sql — spool 输出到位于默认目录位置的 lobdata.out 中。

 

1.  配置

示例 undodatafiles.out

############## RUNTIME ##############

Run Time
—————–
05-Jul-2023 08:53

############## DATAFILES ##############

Aut
TBSP Name                   File #   Bytes Alloc (MB) Max Bytes Used (MB) (MB)     Ext
—————————— —— ————————- ———————————— ——
SMALLUNDO                  3                              200                                     200     YES

查看配置数据。AUTOEXTEND 是否打开?如果 UNDO 表空间配置为随着空间需求自动增长,这会对数据库造成影响,数据库可能不会重新使用超过Retention设置的过期 Undo extent,以减少发生 ORA-1555 的几率。表空间进而会随着新的需求增长。

示例 undoparameters.out

############## RUNTIME ##############

Run Time
—————–
05-Jul-2023 08:56

############## PARAMETERS ##############

Instance #  Parameter                              Session Value          Instance Value
————– ———————————– ————————- ————————-
1                 _smu_debug_mode                              33554432                  33554432
1                _undo_autotune                                         TRUE                        TRUE
1                undo_management                                    AUTO                       AUTO
1                undo_retention                                                900                             900
1                undo_tablespace                        SMALLUNDO          SMALLUNDO

查看影响 Undo Retention规则的参数设置。

‘_smu_debug_mode’=33554432 会强制让自动优化程序基于系统中运行时间最长的 SQL 的执行时间来计算自动的 undo retention。在默认情况下,自动调整后的保留时间会增长到很长的时间段,空间压力将成为 Undo 表空间中的重大问题。

‘_undo_autotune’=false 是一些 AUM bug 的权宜方法,但这会对分析产生重大影响。V$UNDOSTAT 中不会再进一步跟踪其他数据,显式指定的的 UNDO_RETENTION 设置是影响 undo Retention处理的关键。

示例 undousage.out

############## RUNTIME ##############

Run Time
————————–
05-JUL-2023 08:58

############## IN USE Undo Data ##############

PCT_INUSE
—————-
23.625

TABLESPACE_NAME    EXTENT_MAN    ALLOCATIO      SEGMEN      RETENTION
——————————— ———————— ———————- —————- —————–
SMALLUNDO                  LOCAL                    SYSTEM             MANUAL    NOGUARANTEE

Sum of Free
—————-
65,536

Total Bytes
—————-
209,715,200

############## UNDO SEGMENTS ##############

Status              Total Extents
—————— —————–
UNEXPIRED                    21
EXPIRED                        807
ACTIVE                          195
————-
sum                               1,023

Status               Total Segments
——————– ——————-
ONLINE                                  11
————-
sum                                          11

2. 当前未提交的事务

示例 undoactivity.out

############## RUNTIME ##############

Run Time
—————–
19-Jul-2023 09:43

############## Current Uncommitted Transactions ##############

Started    User     Undo Segment Name            File #       Block #       Status         KBytes     Rows
———— ——— ————————————- ———— ————– ————– ————- ———-
01/19/23 KEN      _SYSSMU8_1245875459$                  3            9735     ACTIVE       48,664   614,178
09:43:02

查看未提交的事务。该事务有多大?什么用户在处理该事务?随着时间的推移,其是否显示为未提交?这在预期之内吗?在此事务之前开始的任何长时间运行的查询、或在此事务之前使用闪回功能都必须创建此数据的旧“副本”。

3.  历史 UNDO 信息

示例 – undohistory.out

############## RUNTIME ##############

Run Time
—————–
05-Jul-2023 09:08

############## HISTORICAL DATA ##############

Max Concurrent
Last 7 Days
——————–
5

Max Concurrent
Since Startup
———————–
5

1555 Errors
—————
0

Undo Space Errors
————————-
0

############## CURRENT STATUS OF SEGMENTS ##############
############## SNAPSHOT IN TIME INFO ##############
##############(SHOWS CURRENT UNDO ACTIVITY)##############

Segment Name                      Active Bytes     Unexpired Bytes Expired Bytes
———————————– ——————— ———————- ——————–
_SYSSMU10_1245875459$                           0             1,114,112                 65,536
_SYSSMU1_1245875459$                             0             3,211,264          75,497,472
_SYSSMU2_1245875459$                             0                196,608                 65,536
_SYSSMU3_1245875459$                             0             1,507,328          55,115,776
_SYSSMU4_1245875459$             43,253,760                           0                          0
_SYSSMU5_1245875459$                             0             1,048,576          19,922,944
_SYSSMU6_1245875459$                             0                327,680                          0
_SYSSMU7_1245875459$                             0             1,114,112                 65,536
_SYSSMU8_1245875459$                             0                458,752            4,849,664
_SYSSMU9_1245875459$                             0             1,179,648                 65,536

10 rows selected.

############## UNDO SPACE USAGE ##############

Segment#      Shrinks     Avg Shrink Size
—————– ————- ———————–
0                0                              0
1                5                2,424,832
2                5                1,402,470
3                6                2,457,600
4                2                  425,984
5                4                1,638,400
6                4                1,523,712
7                2                1,048,576
8                5                2,031,616
9                1                2,621,440
10                2                1,114,112

11 rows selected.

了解并发性信息。有多少并发性事务相互重叠?如果不断看到高并发的未提交事务,是否自动调整的 retention 正在正确处理工作负载?

对于当前未提交的工作,还可以检查运行时的段活动情况。

同时查看 UNDO 改动的信息。这些段的工作负载是否平衡?收缩是否均匀地分布在段中?是否有任何段承受的压力大于其他段?

示例 undostatistics.out

############## RUNTIME ##############

Run Time
—————–
05-09:08

############## Historical V$UNDOSTAT (Last 2 Days) ##############

Query
Maximum                                               Undo     # of                                                     Tuned Ret
Date/Time Minutes   SqlID                 TBS        Blocks    Trans   # of Unexpired    # of Expired Minutes
————- ————- ——————– ———– ——— ———- ——————— —————- —————
03-09:15                 14 0rc4km05kgzb9           14          39       160                        312           25,024                  29
03-09:25                   4 0rc4km05kgzb9           14          36       220                        312           25,024                  43
03-09:35                 14 0rc4km05kgzb9           14         327      200                            8           25,024                  43
03-09:45                   4 0rc4km05kgzb9           14           20      202                        464           24,896                  29
. . .
05-08:37                   1 0rc4km05kgzb9           14           22      195                           80          25,344                  15
05-08:47                12 0rc4km05kgzb9            14           35      216                           48          25,376                  15
05-08:57                  2 0rc4km05kgzb9            14           33      183                           56          25,368                  15

284 rows selected.

############## RECENT MISSES FOR UNDO (Last 2 Days) ##############

no rows selected

no rows selected

############## AUTO-TUNING TUNE-DOWN DATA ##############
############## ROLLBACK DATA (Since Startup) ##############

Name                                                                                                        Counters
————————————————————————————- ————
user rollbacks                                                                                                 4,959
transaction tables consistent reads – undo records applied                          3
transaction tables consistent read rollbacks                                                    0
data blocks consistent reads – undo records applied                          300,730
rollbacks only – consistent read gets                                                       11,384
cleanouts and rollbacks – consistent read gets                                             39
rollback changes – undo records applied                                                18,529
transaction rollbacks                                                                                       190
total number of undo segments dropped                                                         0
tune down retentions in space pressure                                                           0
global undo segment hints helped                                                                     1
global undo segment hints were stale                                                               0
local undo segment hints helped                                                                       0
local undo segment hints were stale                                                                  0
undo segment header was pinned                                                             90,532
IMU CR rollbacks                                                                                           6,183
SMON posted for undo segment recovery                                                       0
SMON posted for undo segment shrink                                                            0

18 rows selected.

############## Long Running Query History ##############

Date                    SQL ID                Runaway SQL ID                          Space Issues
——————– ———————- —————————————– ————————————————
02-19:05              0rc4km05kgzb9                                                          Max Tuned Down – Not Auto-Tuning
02-19:15              0rc4km05kgzb9                                                          Reached Best Retention
02-19:25              0rc4km05kgzb9                                                          Reached Best Retention
02-19:35              0rc4km05kgzb9                                                          Reached Best Retention
02-19:45              0rc4km05kgzb9                                                          Reached Best Retention

############## Details on Long Run Queries ##############

SQL ID                 SQL Text                                                                                             Last Load                  Elapsed Days
———————- ——————————————————————————— ————————– ——————
0rc4km05kgzb9    select 1 from obj$ where name=’DBA_QUEUE_SCHEDULES’  2009-08-04/13:30:06                     19

查看报告中在设定时间内收集的关于 undo 活动的数据(默认为 2 天)。

第二部分将显示在 V$UNDOSTAT 中的七天或在实例生命周期中,查询持续时间大于调整后的Retention时间的情况。

是否有大量的“调低”相关活动?“调低”是自动调整 AUM 的一种功能,将会收缩保留时间以减少 UNDO 空间压力。这可指向尚未引发 ORA-30036 错误的空间问题。

最后调查长时运行查询数据。这些可能是我们预期内的,但也有助于指出意外的查询活动。

4. 等待/锁定分析

示例 undopressure.out

############## RUNTIME ##############

Run Time
—————–
05-08:58

############## WAITS FOR UNDO (Since Startup) ##############

Cummalitve
Instance# Enq Total Requests   Total Waits       Successes           Failures             Time
————- —— ——————– —————- ———————— ————— ——————
1                 HW                  2,104                     0                       2,104                    0                       0
1                  US                        58                     0                            58                    0                       0

############## LOCKS FOR UNDO ##############

no rows selected

############## TUNED RETENTION HISTORY (Last 2 Days) ##############
############## LOWEST AND HIGHEST DATA ##############

END_TIME TUNED_UNDORETENTION
—————– ————————————–
05-08:58                                                      900
05-08:57                                                      900
05-08:37                                                      900
05-07:17                                                      900
05-04:17                                                      900
05-03:57                                                      900
05-03:37                                                      900
05-02:57                                                      900
05-02:37                                                      900
05-02:17                                                      900
05-01:17                                                      900

11 rows selected.

END_TIME TUNED_UNDORETENTION
—————– ————————————-
04-17:57                                                   2227

############## CURRENT TRANSACTIONS ##############

START_DATE  START_SCN   STATUS            SQL Code
——————— —————— —————- —————————————-
05-08:58               53717782         ACTIVE       update abc_tmp set edition_name=”

CURRENT_SCN
———————
53734654

############## WHO’S STEALING WHAT? (Last 2 Days) ##############

UnexStolen ExStolen UnexReuse ExReuse
————— ———— ————— ———–
0              22                   0              0
0              12                   0              0

查看等待和锁定信息。高等待和性能问题可能与已知的 UNDO 性能 bug 匹配。同时查看高、低调整后的Retention信息。在此报告中,您是否发现被盗 extent 的证据?未过期 extent 是否被盗?

5. 调查 LOB 问题

示例 lobdata.out

Table               Column                                                Tablespace       PCTVersion %   Retention
—————— ———————————————- ——————– ——————– ————-
CTEST             DATA_OBJECT                                TB1                                                          900
PAA_TEST    RESPONDER_COMMENT              TB1                                                          900
EMP_O           PICTURE                                             USERS                                      10
EMP_O           RESUME                                             USERS                                      10
TEST               COMMENTS                                      TB1                                                          900

5 rows selected.

如果定期更新 LOB 数据,LOB 对象上发生 ORA-1555 就可能是预期内的。PCTVersion 默认为 10%,如果持续对 LOB 数据进行了更改,那么这个此值通常需要调高很多。有时 100%(保留所有更改)还不足以适应工作负载。常规的 ORA-1555 诊断/分析对与 LOB 相关的 ORA-1555 错误是没有用的。LOB 产生的 UNDO 不是使用 UNDO 表空间中的 extent,而是保留在 LOB 表空间中。

 

规范使用脚本用以诊断和分析 ORA-1555 错误(自动undo管理模式下的undo错误分析常用脚本)

有经验的DBA都知道SHUTDOWN ABORT 是关闭数据库的最快方式。

但是,以这种形式关闭数据库会使数据库处于不一致的状态(没有回滚),在这种情况下的备份在下次启动时需要恢复 。

在8.1.6以前的版本里,数据库是不推荐使用SHUTDOWN ABORT,因为在这么老的版本上这么做导致数据库损坏的概率很大。

 

在执行快速关闭之前,建议按照如下顺序来操作:

1.通过下面的查询判定干净的关闭数据库需要多少回滚(以字节计算)

select sum(used_ublk) * <undo / rollback segment 表空间的block size> from v$transaction;

2. SHUTDOWN ABORT

将不进行事务回滚,快速的中断所有进程 (客户端 和 后台)。

 

A SHUTDOWN IMMEDIATE时SMON会尝试中断所有客户端进程(SIGKILL),但是很多情况下SMON无法及时完成,这是使用SHUTDOWN ABORT的原因。

3.在下次启动时,SMON会回滚事务。

可以通过STARTUP RESTRICT启动

然后通过下面的查询语句查看回滚(块的个数)

select sum(distinct(ktuxesiz)) from x$ktuxe where ktuxecfl = ‘DEAD’;

6.当回滚完成 (当上次关闭数据库时候,活动事务不多的情况下,有可能启动后立刻就完成了), 执行 SHUTDOWN IMMEDIATE。
当完成此步骤后,数据库将干净的关闭

 

这里早前碰见过一个BUG,一个没有发布的SQLPLUS内部bug会阻止SQLPLUS会话被SMON中断,客户端进程的truss / pdump等会显示SQLPLUS会话在等待WAITPID

 

各版本Oracle数据库快速关闭的方式

之前发表过smon一些相关的文章,主要是讨论回滚方面的事宜,最近在项目上碰到pmon的相关问题,因此也学习了一些相关的知识,10g之前的版本跟踪方式主要局限于操作系统版本的命令跟踪,这里不做讨论

 

11g 跟踪命令

 

从 11.1.0.7 到 18.0, 可以使用下面的命令来启动 tracing:

alter system set events=’immediate trace name listener_registration level 3′;

当收集结束后,使用下面的命令来停止跟踪:

alter system set events=’immediate trace name listener_registration level 0′;

19c开始使用下面的命令

开启 Trace:
alter system set events ‘trace[LREG] disk highest’;
alter system set events = ‘immediate trace name LREG_STATE level 3’;

要关闭 Trace:
alter system set events ‘trace[LREG] disk disable’;
Trace的默认路径是:
$ORACLE_BASE/diag/rdbms/trace/
ls -l | grep -i lreg

这会将 PMON 的信息写入到名字包含 pmon 的 trace 文件中,存放在后台进程 trace 目录。Trace 文件会显示类似下面的信息:

Start Registration Information
——————————
Last update: 1188938571 (99 seconds ago)
Flag: 0x4, 0x0
State: succ=1, wait=0, fail=0
Listeners:
0 – (ADDRESS=(PROTOCOL=TCP)(HOST=)(PORT=1521)): <— 监听地址
state=1, err=0
nse[0]=0, nse[1]=0, nte[0]=0, nte[1]=0, nte[2]=0
ncre=0
Instance: <— 实例名
flg=0, upd=0
info=(HOST=) <– 主机名
node load=57, max=40960 <– 节点负载
inst load=1, max=170 <– 实例负载
Services:
0 – : <– 服务名
flg=4, upd=6
goodness=0, delta=1 <– Goodness 和 Delta 值
1 – _XPT:
flg=4, upd=0
goodness=0, delta=0
2 – XDB:
flg=5, upd=6
goodness=0, delta=1
Handlers:
0 – Dedicated
flg=80002002, upd=2
services=,_XPT
hdlr load=22, max=149
Dispatchers:
0 – D000:
addr=(ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=33099))
inf=DISPATCHER , pid: 10850>
flg=1004, upd=0
services=XDB
hdlr load=0, max=1022
CMON Handlers:
Listen Endpoints:
—————————-
End Registration Information
—————————-

注意:Oracle Net Server trace,TNS 监听 trace 和 event 10257 在 11g 仍然可用,之前的文章介绍过跟踪监听的方法。详见下面 12c 之前版本的介绍。

 

12c LREG 故障排除

 

从 12c 开始,引入了新的后台进程 ora_lreg_sid-name。
在之前的版本中,PMON 负责处理实例注册。12c 中,LREG(Listener REGistration)接管实例注册逻辑。

LREG:

将实例信息注册到监听。
是每个数据库实例的关键后台进程(如果被杀死,oracle 将宕机)。
接管旧版本中 PMON 的一些职责,并且在 listener.log 中更新 service_update,service_register,service_died 信息。

跟踪 LREG 的方法与跟踪 PMON 的方法相同:

开启 Oracle Net 服务器端 sqlnet trace 会从实例启动时开始跟踪 LREG。
旧的 PMON trace 现在跟踪 LREG:alter system set events = ‘10257 trace name context forever, level 5’;
监听注册信息也可以通过这种方式被转储到 ora_lreg trace 文件中:alter system set events = ‘immediate trace name listener_registration level 3’;
可以动态跟踪 LREG。

 

12c 之前版本,使用下面的方法跟踪 PMON 注册问题 A) Oracle Net server 和 listener traces 或者 B) PMON tracing

A) 搜集匹配的 Oracle Net Server trace 和 Listener Trace 文件

服务器端 TRACE:

1. 在文件 SQLNET.ORA 中添加下面的参数来开启 Oracle Net Server tracing:

DIAG_ADR_ENABLED=off # Disable ADR if database version 11g TRACE_LEVEL_SERVER = 16 # Enable level 16 trace
TRACE_DIRECTORY_SERVER = # Control trace file location

2. 使用特权用户通过 SQL*Plus 连接数据库:

SQL> connect / as sysdba
Connected.
SQL> select spid from V$process, V$session where audsid=userenv(‘SESSIONID’) and paddr=addr;

SPID
————
3940
生成的 trace 文件的名字,将包含上面的返回值。

3. 执行注册命令:

SQL > alter system register
SQL > exit
4. 关闭服务器端 trace:

如果需要禁用 trace,那么可以删除 SQLNET.ORA 中刚加入的参数。到 TRACE_DIRECTORY_SERVER 设置的路径下,找到名字包含 SPID 值的 trace 文件。文件中会包含 alter system register 命令:

Listener tracing:
1. 在 listener.ora 中添加下面的参数,然后 reload listener:

DIAG_ADR_ENABLED_ =off # 如果数据库版本是 11g,需要关闭 ADR。
TRACE_LEVEL_ = 16 # 启用 level 16 trace
TRACE_TIMESTAMP_ = ON # 设置 trace 文件中的时间戳
TRACE_DIRECTORY_ = # 设置 trace 文件路径

2. 执行‘alter system register’强制注册:

SQL> alter system register;
System altered.

listener trace 文件中会看到类似下面的信息:
(信息会由于版本不同或者单节点、RAC 等因素有细微差别)

nsglgrDoRegister: inst loads: ld1:17 mld1:10240 ld2:1 mld2:248
nsglgrDoRegister: instance flags – req:0 cur:16
nsglgrDoRegister: Creating new service: “XDB.*****.com”.
nsglgrDoRegister: service:..oracle.com flag:3 goodness:0 delta:1
nsglgrDoRegister: Creating new service: “..oracle.com”.
nsglgrDoRegister: service:..oracle.com flag:2 goodness:0 delta:1

B) 12c 之前的版本启用 PMON trace 的方法:
1. 找到 PMON 的进程 ID:

SQL> select SPID,PROGRAM from v$process;

SPID PROGRAM
———————— ————————————————
PSEUDO
10096 oracle@ (PMON)
10098 oracle@ (PSP0)
10100 oracle@ (VKTM)
10104 oracle@ (GEN0)
10106 oracle@ (DIAG)
10108 oracle@ (DBRM)
10110 oracle@ (DIA0)
10112 oracle@ (MMAN)
10114 oracle@ (DBW0)
10116 oracle@ (LGWR)

SPID PROGRAM
———————— ————————————————
10118 oracle@ (CKPT)
10120 oracle@ (SMON)
10122 oracle@ (RECO)
10124 oracle@ (MMON)
10126 oracle@ (MMNL)
10128 oracle@ (D000)
10130 oracle@ (S000)
10175 oracle@ (Q000)
10280 oracle@ (SMCO)
22191 oracle@ (TNS V1-V3)
10159 oracle@ (QMNC)

SPID PROGRAM
———————— ————————————————
10177 oracle@ (Q001)
10173 oracle@ (CJQ0)
22186 oracle@ (W000)

25 rows selected.

2. 对 PMON 做 oradebug:

SQL> oradebug setospid 10096
Oracle pid: 2, Unix process id: 10096, image: oracle@(PMON)

3. 对进程设置 event:

SQL> oradebug Event 10257 trace name context forever, level 16
Statement processed.
4. trace 文件的位置可以通过下面的命令查看:

SQL> oradebug tracefile_name
Trace file /app/oracle/diag/rdbms///trace/_pmon_10096.trc
5. 执行注册命令,或者等待 PMON 注册(默认轮询时间是60秒):

SQL> alter system register;
System altered.

6. 关闭 event:

SQL> oradebug Event 10257 trace name context OFF;
Statement processed.

到 trace 所在的目录下并上传 trace。
注册成功会显示类似下面的信息:

Trace file /app/oracle/diag/rdbms///trace/_pmon_10096.trc
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 – 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
ORACLE_HOME = /app/oracle/product/11.2.0/dbhome_1
System name: Linux
Node name:
Release: 2.6.18-238.19.1.0.1.el5
Version: #1 SMP Fri Jul 15 04:42:13 EDT 2011
Machine: x86_64
Instance name:
Redo thread mounted by this instance: 1
Oracle process number: 2
Unix process pid: 10096, image: oracle@ (PMON)

 

Received ORADEBUG command (#1) ‘Event 10257 trace name context forever, level 16’ from process ‘Unix process pid: 22065, image: ‘

Finished processing ORADEBUG command (#1) ‘Event 10257 trace name context forever, level 16’

err=-300 lbflgs=0x0 tbtime=0 tntime=0 etime=300 srvs=1 nreqs=0 sreqs=0 asrvs=1
error=-300 etime=300 control=0 integral=0 lasterr=-300 lastetm=300
kmmlrl: status: succ=1, wait=0, fail=0
kmmlrl: update for process drop delta: 3166 3166 25 28 149
kmmgdnu:
goodness=0, delta=1,
flags=0x5:unblocked/not overloaded, update=0x6:G/D/-
kmmgdnu:
goodness=0, delta=1,
flags=0x4:unblocked/not overloaded, update=0x6:G/D/-
kmmlrl: 25 processes
kmmlrl: instance load 1

 

Bug 5755010 Listener registration never completes
详细信息: 尽管并没有注册失败的错误,但是监听注册会失败
修复版本:10.2.0.4 and 11.1.0.6

Bug 8232287 PMON stops registering its services (ORA-12516 errors)
详细信息:pmon 停止注册到监听,会引发 ORA-12516 错误。
修复版本:10.2.0.5 and 11.2.0.1

Bug 7133740One Instance of Bug ( 2 – NODE RAC DATABASE) I Crashed Due To Ora-600
请参考:

Document 759083.1 Connections get TNS-12520 error on RAC & PMON is stuck on ‘ges cancel’ wait event

Document 779318.1 Repeating ‘* Service_died * 0′ Messages In The 9i R2 Listener.Log File

Document 419824.1RAC Instance Status Shows Ready Zero Handlers For The Service

Document 1130713.1 Pmon Spins While Cleaning Dead Process

诊断方法:

1.检查 Oracle net 名字解析方式是否正确。例如:SQLNET.ORA 文件中的 NAMES.DIRECTORY_PATH 。Oracle net 会尝试正确的名字解析方式。

2.确保使用了正确的网络管理文件:SQLNET.ORA 和 TNSNAMES.ORA。Note:464410.1 Search Order for TNS files – listener.ora, sqlnet.ora, tnsnames.ora ..etc.

3.检查在数据库启动之前是否设置了 TNS_ADMIN ,如果是 RAC 环境,是否使用 srvctl 设置了 TNS_ADMIN,TNS_ADMIN 可以 影响搜索顺序。数据库只在启动的时候读取环境变量。如果在启动数据库之后设置了 TNS_ADMIN,然后做了修改,修改后的值是不会被读取到的。

4.检查 LOCAL_LISTENER 或者 REMOTE_LISTENER 使用的网络服务名是否可以 tnsping 通。如果不通,重建条目或者参考第6步。

5.确保使用的主机名与 nslookup 返回的结果相同,并且返回的地址是预期的。

C:\>nslookup

Server:
Address: ….

Name:
Address:….

6.修改 LOCAL_LISTENER 或者 REMOTE_LISTENER 的值,确保不使用名字解释方式。不使用网络管理文件,确认是否问题出在网络管理文件或是没找到它们。
例如 LOCAL_LISTENER

sqlplus / as sysdba
SQL>alter system set LOCAL_LISTENER='(ADDRESS=(PROTOCOL=TCP)(HOST=)(PORT=1521));
例如两节点 RAC 中的 REMOTE_LISTENER

SQL>alter system set REMOTE_LISTENER=’ (ADDRESS_LIST =(ADDRESS = (PROTOCOL = TCP)(HOST = )(PORT = 1521))(ADDRESS = (PROTOCOL = TCP)(HOST = )(PORT = 1521)))’;

7.检查 HOST 到 ip 地址的转换是否允许注册。

8.使用 IPC 替代 TCP 完成 LOCAL_LISTENER 的注册,验证问题是否与 TCP 或主机名有关。

sqlplus / as sysdba
SQL>alter system set LOCAL_LISTENER='(ADDRESS=(PROTOCOL=IPC)(KEY=KEY1))’;
Key 值必须与 LISTENER.ORA 文件中的 IPC 地址一致。

在oracle 数据库运行时使用event跟踪 pmon进程动态注册

bug: MEMORY_TARGET not supported on this system
SQL> startup open;
ORA-00845: MEMORY_TARGET not supported on this system

解决方案:原因是/dev/shm 必须大于 MEMORY_TARGET。

$ df -h
Filesystem Size Used Avail Use% Mounted on
devtmpfs 1.8G 0 1.8G 0% /dev
tmpfs 1.9G 635M 1.2G 35% /dev/shm
tmpfs 1.9G 9.2M 1.8G 1% /run
tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup
/dev/mapper/ol-root 10G 3.9G 6.2G 39% /
/dev/sda1 397M 199M 198M 51% /boot
/dev/mapper/ol-home 3.0G 58M 3.0G 2% /home
/dev/mapper/ol-u01 30G 18G 13G 58% /u01
/dev/mapper/ol-tmp 3.0G 59M 3.0G 2% /tmp
vmhgfs-fuse 159G 133G 27G 84% /mnt/hgfs
tmpfs 370M 0 370M 0% /run/user/54322
tmpfs 370M 16K 370M 1% /run/user/42
tmpfs 370M 0 370M 0% /run/user/54321
tmpfs 370M 0 370M 0% /run/user/0

通过如下命令解决即可

mount -o size=2560m /dev/shm

 

Dataguard bug : MEMORY_TARGET not supported on this system ORA-00845

4月初对某银行可以使用dbua升级时候遭遇ORA-06512错误,导致升级中断

主要是在 调用 preupgrade 脚本时,报如下错误:

trace.log_20220405. 描述如下:

SEVERE: Apr 04, 2022 3:25:09 AM oracle.assistants.dbua.prereq.PreUpgradeDriverJob call
SEVERE: ERROR – Unable to run the preupgrade due to:ERROR – Unable to run preupgrade due to:
ORA-06512: at “SYS.UTL_FILE”, line 106
ORA-06512: at “SYS.UTL_FILE”, line 746
ORA-06512: at “SYS.DBMS_PREUP”, line 3264
ORA-06512: at “SYS.DBMS_PREUP”, line 9736
ORA-06512: at line 8

declare
*
ERROR at line 1:
ORA-29284: file read error
ORA-06512: at line 56

经检查

 

环境变量 ORA_NLS10 指向 18C HOME 下面的 data, 如下

ORA_NLS10=/oracle/app/18.0.0/nls/data

并且设置了其他的 NLS 环境变量。

 

解决方案

1) 清理环境变量 ORA_NLS10 和 NLS 环境变量
unset ORA_NLS10
unset NLS_SORT
unset NLS_LANG
unset NLS_NUMERIC_CHARACTERS

2) 重新运行 DBUA 升级.

ORA-06512: at “SYS.DBMS_PREUP” ,ORA-29284: file read error 报错 解决方法