Skip to content

All posts by Guang Cai Li

  1.  DB版本生命周期支持策略

 

PS(Primier Support)是自软件发布之日起为期5年的维护和支持服务,超过这个时间就需要购买3年的Extended Support或者不确定时间的Sustaining Support。
Oracle Database 10gR2以及Oracle Database 11gR1都已结束Paid Extended Support进入Sustaining Support阶段,11gR2开始Extended Support包含Waived Extended Support和Paid Extended Support两种:Waived Extended Support不需要单独购买扩展服务包,而Paid Extended Support将在原来的PS服务费用基础上,第一年加收10%的费用提供支持,第二年加收20%的费用提供支持,第三年也是加收20%的费用提供支持, Extended Support主要目的是客户版本升级缓冲期,在该阶段客户将仍能获得“软件更新、修订和安全预警”。

12.2: 新的发行版本会每年发行,版本号是年份的后两位。原来计划发布的12.2.0.2是18c,原来计划发布的12.2.0.3会是19c。18c和19c被认为和12.2的终身支持政策一致。
19c是一个“长期支持”版本(至少4年PS服务,3年扩展支持服务),也是12.2的最后一个版本, 同时也是Oracle Autonomous database优化的一个基础。

 

 

升级到19c的直接升级路径

具体参考:Oracle 19c – Complete Checklist for Manual Upgrades to Non-CDB Oracle Database 19c (Doc ID 2539778.1)

Source Database Target Database
11.2.0.4 19c
12.1.0.212.2.0.1 19c
18c 19c

 

升级到19c的的间接升级路径

Source Database Intermediate upgrade path Target Database
12.1.0.1 12.1.0.2 19c
更早版本 11.2.0.1 / 11.2.0.2/11.2.0.3 11.2.0.4 19c
11.1.0.6 / 11.1.0.7 11.2.0.4 19c
10.2.0.2/10.2.0.3/10.2.0.4/10.2.0.5 11.2.0.4/12.1.0.2 19c
10.1.0.5 11.2.0.4/12.1.0.2 19c
7.3.3.0.0 (or lower)  7.3.4.x –> 9.2.0.8 9.2.0.8 11.2.0.4 19c
8.0.5.0.0 (or lower) 8.0.6.x –> 9.2.0.8
8.1.7.0.0 (or lower) 8.1.7.4 –> 9.2.0.8
9.0.1.3.0 (or lower) 9.0.1.4 –> 9.2.0.8

 

升级到19c的升级技术方法

升级/迁移Oracle数据库19c的方法,不论是上Oracle Cloud还是本地环境都一样 下面是根据操作系统、字节序、版本、数据库大小、停机时间要求等的不同而采用的常用方法

 

具体参考: Transportable Tablespace (TTS) Restrictions and Limitations: Details, Reference, and Version Where Applicable [Document 1454872.1] Best Practices for Using Transportable Tablespaces (TTS) [Document 1457876.1]

方法 说明
Export / Import  适用所有版本和平台,要使用Data Pump需要10.1.0.2或更高版本,停机时间长
       Transportable Tablespaces  Sets(TTS)

       Cross-Platform Transportable Tablespace Sets(XTTS)

8i及以后:TTS(从8i开始),XTTS(10g开始,支持跨平台)

相同的字符集和国家字符集,如果跨字节序(10g+),需要配合RMAN’s convert 

RMAN’s convert function for Transportable Tablespaces 10g及以后版本,可以跨endianness,字符集要兼容

转换动作可以在SoureTarget完成,需要额外的临时工作空间,不支持SYSTEM/SYSAUX

Transportable DatabaseData Pump Full Transportable 11.2.0.3及以后版本,字符集要兼容,12c开始RMAN支持跨字节序转换
XTTS with RMAN Cross Platform Incremental Backups new 11.2.0.4及以后版本,字符集要兼容
Create Table As Select (CTAS)SQL*LoaderCopy 需注意表属性、约束、数据类型的限制
Dataguard Heterogeneous Primary and Physical Standbys Data Guard异构的限制
Oracle GoldenGate 无法支持的异构或停机时间极小的场景

 

 

 

 

关于升级到oracle 19c的一些需要知道的事情

之前发表过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 报错 解决方法

最近在某出版客户升级数据库到 19c 时,源库 pfile / spfile 中设置的 event 被删除。

查询metalink匹配bug为 BUG 30193505 – SOURCE EVENTS REMOVED BY DBUA IN UPGRADING TO 19C.

 

解决办法如下:

从以下链接下载并应用 Patch 30193505:

https://updates.oracle.com/download/30193505.html

在打完 Patch 后,可以使用 DBUA 的 –keepEvents 参数来保留 event

 

参考文章:DBUA does not retain database events after Oracle 19c upgrade (Doc ID 2618457.1)

19c 数据库使用DBCA升级小版本时候遭遇bug未保留之前设置的 events 的解决办法