DBASK问答集萃第三期

32次阅读

共计 6093 个字符,预计需要花费 16 分钟才能阅读完成。

引言
近期我们在 DBASK 小程序增加了众多专栏,其中包括盖国强、杨廷琨、罗海雄、张乐奕、黄廷忠、崔华、熊军、李真旭、何剑敏等专家栏目,还有 2019 年 6 月 SCN 兼容性问题、XTTS、备份恢复等技术专栏,另外蚂蚁金服 OceanBase 入驻小程序。欢迎大家阅读分享小程序中的专题栏目。

问答集萃
接下来,我们分享本期整理出的问题和诊断总结,供大家参考学习,详细的诊断分析过程可以通过标题链接跳转到小程序中查看。

问题一、RMAN-20039: format requires %c when duplexing

备份时报错:

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: failure of backup command
RMAN-20039: format requires %c when duplexing

备份数据文件不加 %C 就会报错,加 %C 有两份一样的?

---- 备份脚本
run{ 
allocate channel c1 device type disk;
allocate channel c2 device type disk;
allocate channel c3 device type disk;
allocate channel c4 device type disk;
crosscheck backup;
sql 'alter system archive log current';
backup spfile format '/bak/backup/spfile_%T_%s_%p_%c';
#backup database format '/bak/backup/dbbk_0_%d_%t_%u_%s_%p';
backup as compressed backupset incremental level 0 database format '/bak/backup/dbbk_0_%d_%t_%u_%s_%p';
sql 'alter system archive log current';
backup archivelog all format '/bak/backup/arc_%T_%s_%p_%c' delete all input;
backup current controlfile format '/bak/backup/cntrl_%T_%s_%p_%c';
crosscheck archivelog all;
delete noprompt expired backup;
delete noprompt obsolete;

release channel c1;
release channel c2;
release channel c3;
release channel c4;
}

诊断结论:如果设置不冗余就不需要加 c%,否则就会出现你的报错。如果设置了冗余必须加 %c,那么也就会产生相应的备份片。

问题二、RAC 实例无法启动 ORA-01157 ORA-01110 ORA-27041 OSD-04002

服务器未知原因故障恢复后,启动数据库实例报错,错误信息如下:

ALTER DATABASE OPEN /* db agent *//* {2:38813:23181} */
This instance was first to open
Errors in file D:\APP\...\orcl2_ora_7780.trc:
ORA-01157: ????/?????? 11 - ??? DBWR ????
ORA-01110: ???? 11: 'D:\APP\...\NXPT.DBF'
ORA-1157 signalled during: ALTER DATABASE OPEN /* db agent *//* {2:38813:23181} */...
Fri Mar 01 10:00:59 2019
Shutting down instance (abort)
License high water mark = 2
USER (ospid: 13460): terminating the instance
Instance terminated by USER, pid = 13460
Fri Mar 01 10:01:16 2019
Instance shutdown complete
Fri Mar 01 10:34:34 2019

诊断结论:从报错看,这个是一个本地数据文件

'D:\APP\ADMINISTRATOR\PRODUCT\11.2.0\DBHOME_1\DATABASE\NTBS.DBF'

应该是将 RAC 中的数据库文件误建到本地磁盘,所以其他实例无法启动,导致错误。

问题三、Oracle 12.2 expdp 非常慢

我有一个 12.2.0.1 的库,非容器单实例。使用 expdp 导出,导出文件总共不到 4G,但要花将近 6 个小时。alert 没有任何报错。新库基本都是空的分区表。

诊断结论:请先尝试收集系统、数据字典统计信息。另外可以尝试如下方法:
1、最小配置 stream_pool_size 最小到 256M,可能的话设置 512M 或者 1GB;
2、加大 expdp 的并行度,如果 CPU 压力不大,可以设置为 CPU 核数的 1 半或更多;
3、EXCLUDE=GRANT exclude = statistic
4、METRICS=YES
5、如果导出停留在 TABLE_DATA 阶段,并且上述处理无效,可以打补丁 Bug 28100495

问题四、RAC CTSS 状态观察模式,时间不同步

2 节点 RAC,其中一台物理故障。修复后 RAC 报 CTSS 状态为观察模式,时间不同步

Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production 0

PL/SQL Release 12.2.0.1.0 - Production 0
CORE 12.2.0.1.0 Production 0
TNS for Linux: Version 12.2.0.1.0 - Production 0
NLSRTL Version 12.2.0.1.0 - Production 0
CPUs:56 Cores:28 Sockets:2
内存 188.26G

诊断结论:CTSS 状态为观察模式通常是因为本地的 NTP 服务启动了。所以可以先检查一下新修复的那台服务器上是不是默认启动了 NTP。如果是,禁用掉通常就可以了。

问题五、OGG-00665 OCI Error (status = 3114-ORA-03114)

OGG 同步序列,进程 ABENDING,重启进程问题仍然存在,数据库正常,其他 ogg 的进程正常,且排除掉该序列的同步后进程可以正常启动

2019-03-07 17:06:39  ERROR   OGG-00665 Oracle GoldenGate Delivery for Oracle, rptsqe.prm:  OCI Error describe for query
(status = 3114-ORA-03114: not connected to ORACLE), SQL<select status, deferrable from dba_constraints where owner =UPPER('BOSDATA') and table_name='TASK_SEQ' and constraint_type = 'P' >.
2019-03-07 17:06:39  ERROR   OGG-01668 Oracle GoldenGate Delivery for Oracle, rptsqe.prm:  PROCESS ABENDING.

诊断结论:
1、我昨天查了很多资料,有一个同样的报错,RAC 环境,OGG 版本也是 11.2,不过是抽取进程,说是重启集群后问题消失,所以以后再遇到 SEQ 同步报错了,可以尝试下。
2、有可能是复制进程中的这个参数引起,或者未知 BUG
DBOPTIONS _NOAUTOMATICSEQUENCEFLUSH
3、一般情况下目标端不会使用 sequence,所以可以考虑排除所有 SEQ 的同步
4、升级 OGG 版本,至少 12

问题六、数据库大量僵尸进程未自动清理

数据库出现客户端连接不上,查看 alert 日志

Wed Mar 13 09:21:50 2019
ORA-00020: No more process state objects available
ORA-20 errors will not be written to the alert log for
 the next minute. Please look at trace files to see all
 the ORA-20 errors.
Process J002 submission failed with error = 20
kkjcre1p: unable to spawn jobq slave process
Errors in file /export/home/u01/app/oracle/diag/rdbms///trace/_cjq0_25517.trc:

此时查看 v$process 为 738 个进程,参数 process 进程数设置为 800. 以下语句查询结果为 380

select count(*) from v$process where addr not in (select paddr from v$session);

杀掉这些进程,客户端可以正常连接。总体进程维持在 400 左右。
问题点:1、pmon 为何没有清理掉这 380 个没有会话的进程。2、是否有参数设置 pmon 清除僵尸进程的条件,比如空闲时间之类的。
诊断结论:一般 kill session 后会出现这种情况,但是不会出现几百个的情况。首先请检查是否存在频繁 kill session 的操作,和应用建立连接、断开连接的方式是否规范;其次,临时将数据库的 process 参数调高,避免应用出错。最后,提供一个自动清理僵尸 process 的脚本。

问题七、oracle 10gR2 expdp 报错 ORA-00376

expdp 导出报错

Connected to: Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - 64bit Production

With the Partitioning, OLAP and Data Mining options

ORA-39001: invalid argument value
ORA-00376: file 53 cannot be read at this time
ORA-01110: data file 53: '/oracle/oracle/oradata/xxx/xxx.dbf'

53 号数据文件由于硬件故障导致文件损坏,无法修复。库为非归当模式,所以将 53 号数据文件 offline drop, 将库强制启起来了。现在备份的时候报错了,导出命令如下;

expdp user/passwd parfile=cfg_except_tables.cfg

cat  cfg_except_tables.cfg
EXCLUDE=TABLE
COMPRESSION=METADATA_ONLY
DIRECTORY=DPUMP_DIR1
DUMPFILE=auto_backup.dmp
LOGFILE=auto_backup.log

通过如下 SQL 查为空,我把 53 号数据文件已经清空了,但还是报上面的错

select * from dba_extents where file_id=53 

诊断结论:ASSM 管理模式下 dba_extents 是存放在数据文件中的,脱机文件是看不到对象的。因为你这种报错说明 53 号文件还是有对象存在的,原则上是可以跳过这些对象导出正常的对象的,要确认 53 号的对象需要使用如下 SQL。

问题八、oracle 10G 建立 dblink 访问 9i 的远程库执行 sql 很慢

oracle 10G 建立了 dblink 连接 9i 数据库 执行了 select from table –table 中只有两条记录 耗时 20s 两台服务器间网络正常 再 9i 直接执行 sql 很快 还可能是什么原因呢?查看等待事件为 SQLNet message from dblink
诊断结论:是因为 10g 的服务器操作系统版本是 windows server 2012 从 windows server 2008 以后 增加了 接收窗口自动调谐级别 功能导致,调整接收窗口自动调谐级别解决。

问题九、安装 rac,IO 有什么要求?
安装 rac,IO 有什么要求么?参考过 rac 安装有最佳实践, 但是官方并没有指出 IO 具体参考范围(IOPS)。所以,想咨询下,贵司有没有针对 RAC 安装对 IO 的要求或 IO 范围参考值?我想对比下自己的存储 IO 性能,看是否达标。
诊断结论:是因为 10g 的服务器操作系统版本是 windows server 2012 从 windows server 2008 以后 增加了 接收窗口自动调谐级别 功能导致,调整接收窗口自动调谐级别解决。

问题十、双机切换后 TNS-12537 ORA-609
数据库是 Oracle,操作系统是 Windows,高可用是 rose 双机。把主服务器切换到备用服务器时,会出现程序连接不上,报错如下:

但是切回来以后就正常了,经过查看日志,发现如下报错:

Fatal NI connect error 12537, connecting to:
 (LOCAL=NO)
  VERSION INFORMATION:
TNS for 64-bit Windows: Version 11.2.0.1.0 - Production
Oracle Bequeath NT Protocol Adapter for 64-bit Windows: Version 11.2.0.1.0 - Production
Windows NT TCP/IP NT Protocol Adapter for 64-bit Windows: Version 11.2.0.1.0 - Production
 Time: 12- 3 月 -2019 20:15:08
 Tracing not turned on.
 Tns error struct:
    ns main err code: 12537

TNS-12537: TNS: 连接关闭
    ns secondary err code: 12560
    nt main err code: 0
    nt secondary err code: 0
    nt OS err code: 0
opiodr aborting process unknown ospid (10796) as a result of ORA-609
Tue Mar 12 20:15:28 2019

请问是什么原因导致的呢?怎么去解决这个问题呢
诊断结论:检查双机各自监听日志,发现节点监听日志 4G,清空问题节点监听日志问题解决。

问题十一、oracle 导入数据报 ORA-39242 错误
提示由于表属性原因,无法导入入成功

ORA-39242: Unable to export/import TABLE_DATA: … due to table attributes.

诊断结论:检查表上面索引的状态是否正常,如果不是 VALID 就做下 rebuild 再导入

正文完
 0