ORA-00322 ORA-00312 恢复

联系:手机/微信(+86 17813235971) QQ(107644445)

标题:ORA-00322 ORA-00312 恢复

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

数据库mount报ORA-00214错误

C:\Users\Administrator>sqlplus / as sysdba
SQL*Plus: Release 11.2.0.4.0 Production on 星期二 11月 27 14:41:15 2018
Copyright (c) 1982, 2013, Oracle.  All rights reserved.
连接到:
XIFENFEIle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> select open_mode from v$database;
select open_mode from v$database
                      *
第 1 行出现错误:
ORA-01507: ??????
SQL> alter database mount;
alter database mount
*
第 1 行出现错误:
ORA-00214: ???? ''D:\APP\ADMINISTRATOR\ORADATA\XIFENFEI\CONTROL01.CTL'' ?? 14709
??? ''D:\APP\ADMINISTRATOR\FAST_RECOVERY_AREA\XIFENFEI\CONTROL02.CTL'' ?? 14681 ???

使用其中一个控制文件启动数据库报ORA-00322 ORA-00312错误

SQL> startup mount;
XIFENFEILE 例程已经启动。
Total System Global Area 5127602176 bytes
Fixed Size                  2290120 bytes
Variable Size            1056968248 bytes
Database Buffers         4060086272 bytes
Redo Buffers                8257536 bytes
数据库装载完毕。
SQL> recover database;
ORA-00283: recovery session canceled due to errors
ORA-00322: log 1 of thread 1 is not current copy
ORA-00312: online log 1 thread 1:
'D:\APP\ADMINISTRATOR\ORADATA\XIFENFEI\REDO01.LOG'

alert日志报ORA-00322 ORA-00312 ORA-00314 等错

Tue Nov 27 14:42:44 2018
ALTER DATABASE RECOVER  database
Media Recovery Start
 started logmerger process
Parallel Media Recovery started with 24 slaves
Tue Nov 27 14:42:45 2018
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\XIFENFEI\XIFENFEI\trace\XIFENFEI_pr00_4168.trc:
ORA-00322: log 1 of thread 1 is not current copy
ORA-00312: online log 1 thread 1: 'D:\APP\ADMINISTRATOR\ORADATA\XIFENFEI\REDO01.LOG'
Tue Nov 27 14:42:45 2018
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\XIFENFEI\XIFENFEI\trace\XIFENFEI_m000_3876.trc:
ORA-00322: log 1 of thread 1 is not current copy
ORA-00312: online log 1 thread 1: 'D:\APP\ADMINISTRATOR\ORADATA\XIFENFEI\REDO01.LOG'
Media Recovery failed with error 322
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\XIFENFEI\XIFENFEI\trace\XIFENFEI_pr00_4168.trc:
ORA-00283: recovery session canceled due to errors
ORA-00322: log 1 of thread 1 is not current copy
ORA-00312: online log 1 thread 1: 'D:\APP\ADMINISTRATOR\ORADATA\XIFENFEI\REDO01.LOG'
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\XIFENFEI\XIFENFEI\trace\XIFENFEI_m000_3876.trc:
ORA-00314: log 2 of thread 1, expected sequence# 722 doesn't match 719
ORA-00312: online log 2 thread 1: 'D:\APP\ADMINISTRATOR\ORADATA\XIFENFEI\REDO02.LOG'
Checker run found 4 new persistent data failures
ORA-283 signalled during: ALTER DATABASE RECOVER  database  ...

通过Oracle Database Recovery Check脚本检查数据库结果
datafile-header
logfile


通过这里可以看出来,数据库需要的redo确实是721,但是recover无法应用成功,出现该问题的原因是由于控制文件信息不对导致

使用备份控制文件恢复

D:\>sqlplus / as sysdba
SQL*Plus: Release 11.2.0.4.0 Production on 星期二 11月 27 14:44:00 2018
Copyright (c) 1982, 2013, Oracle.  All rights reserved.
连接到:
XIFENFEIle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options
SQL> recover database using backup controlfile;
ORA-00279: 更改 4034899 (在 11/27/2018 10:37:04 生成) 对于线程 1 是必需的
ORA-00289: 建议:
D:\APP\ADMINISTRATOR\FAST_RECOVERY_AREA\XIFENFEI\ARCHIVELOG\2018_11_27\O1_MF_1_721_%U_.ARC
ORA-00280: 更改 4034899 (用于线程 1) 在序列 #721 中
指定日志: {<RET>=suggested | filename | AUTO | CANCEL}
D:\APP\ADMINISTRATOR\ORADATA\XIFENFEI\REDO02.LOG
ORA-00310: archived log contains sequence 719; sequence 721 required
ORA-00334: archived log: 'D:\APP\ADMINISTRATOR\ORADATA\XIFENFEI\REDO02.LOG'
SQL> recover database using backup controlfile;
ORA-00279: 更改 4034899 (在 11/27/2018 10:37:04 生成) 对于线程 1 是必需的
ORA-00289: 建议:
D:\APP\ADMINISTRATOR\FAST_RECOVERY_AREA\XIFENFEI\ARCHIVELOG\2018_11_27\O1_MF_1_721_%U_.ARC
ORA-00280: 更改 4034899 (用于线程 1) 在序列 #721 中
指定日志: {<RET>=suggested | filename | AUTO | CANCEL}
D:\APP\ADMINISTRATOR\ORADATA\XIFENFEI\REDO02.LOG
ORA-00310: archived log contains sequence 719; sequence 721 required
ORA-00334: archived log: 'D:\APP\ADMINISTRATOR\ORADATA\XIFENFEI\REDO02.LOG'
SQL> D:\APP\ADMINISTRATOR\ORADATA\XIFENFEI\REDO02.LOG
SP2-0734: 未知的命令开头 "D:\APP\ADM..." - 忽略了剩余的行。
SQL> recover database using backup controlfile;
ORA-00279: 更改 4034899 (在 11/27/2018 10:37:04 生成) 对于线程 1 是必需的
ORA-00289: 建议:
D:\APP\ADMINISTRATOR\FAST_RECOVERY_AREA\XIFENFEI\ARCHIVELOG\2018_11_27\O1_MF_1_721_%U_.ARC
ORA-00280: 更改 4034899 (用于线程 1) 在序列 #721 中
指定日志: {<RET>=suggested | filename | AUTO | CANCEL}
D:\APP\ADMINISTRATOR\ORADATA\XIFENFEI\REDO01.LOG
已应用的日志。
完成介质恢复。
SQL> alter database open resetlogs;
数据库已更改。

实现数据0丢失恢复,数据库open之后可以直接使用

下调虚拟化资源导致ORA-00494

联系:手机/微信(+86 17813235971) QQ(107644445)

标题:下调虚拟化资源导致ORA-00494

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

在虚拟化环境中的Oracle数据库近期报大量ORA-00494: 入队 [CF] 被持有的时间过长 (more than 900 seconds) 错误,每次客户重启一段时间之后又不行

Mon Nov 26 14:04:39 中国标准时间 2018
Thread 1 advanced to log sequence 97327 (LGWR switch)
  Current log# 1 seq# 97327 mem# 0: D:\ORADATA\xifenfei\REDO01.LOG
Mon Nov 26 14:20:02 中国标准时间 2018
Errors in file c:\oracle\product\10.2.0\admin\xifenfei\bdump\xifenfei_arc1_1860.trc:
ORA-00494: 入队 [CF] 被持有的时间过长 (more than 900 seconds) (由 'inst 1, osid 3264')
Mon Nov 26 14:20:03 中国标准时间 2018
Errors in file c:\oracle\product\10.2.0\admin\xifenfei\bdump\xifenfei_arc4_1872.trc:
ORA-00494: 入队 [CF] 被持有的时间过长 (more than 900 seconds) (由 'inst 1, osid 3264')
Mon Nov 26 14:20:03 中国标准时间 2018
Errors in file c:\oracle\product\10.2.0\admin\xifenfei\bdump\xifenfei_arc3_1868.trc:
ORA-00494: 入队 [CF] 被持有的时间过长 (more than 900 seconds) (由 'inst 1, osid 3264')
Mon Nov 26 14:20:03 中国标准时间 2018
Errors in file c:\oracle\product\10.2.0\admin\xifenfei\bdump\xifenfei_arc0_1856.trc:
ORA-00494: 入队 [CF] 被持有的时间过长 (more than 900 seconds) (由 'inst 1, osid 3264')

因为这个系统有一段历史,以前是客户的核心生产库,虚拟化资源给的比较多128G,后来核心生产迁移到其他系统,该系统跑一些边缘小业务,所以怀疑客户有可能下调了虚拟化的资源(cpu和内存),检查机器硬件资源

C:\Users\Administrator>systeminfo
主机名:           HIS-VM
OS 名称:          Microsoft Windows Server 2008 R2 Enterprise
OS 版本:          6.1.7601 Service Pack 1 Build 7601
OS 制造商:        Microsoft Corporation
OS 配置:          独立服务器
OS 构件类型:      Multiprocessor Free
注册的所有人:     Windows 用户
注册的组织:
产品 ID:          00486-OEM-8400691-20006
初始安装日期:     2013/4/19, 12:22:44
系统启动时间:     2018/11/27, 8:06:00
系统制造商:       VMware, Inc.
系统型号:         VMware Virtual Platform
系统类型:         x64-based PC
处理器:           安装了 2 个处理器。
                  [01]: Intel64 Family 6 Model 45 Stepping 2 GenuineIntel
Mhz
                  [02]: Intel64 Family 6 Model 45 Stepping 2 GenuineIntel
Mhz
BIOS 版本:        Phoenix Technologies LTD 6.00, 2014/4/14
Windows 目录:     C:\Windows
系统目录:         C:\Windows\system32
启动设备:         \Device\HarddiskVolume1
系统区域设置:     zh-cn;中文(中国)
输入法区域设置:   zh-cn;中文(中国)
时区:             (UTC+08:00) 北京,重庆,香港特别行政区,乌鲁木齐
物理内存总量:     32,767 MB
可用的物理内存:   22,740 MB
虚拟内存: 最大值: 95,047 MB
虚拟内存: 可用:   10,426 MB
虚拟内存: 使用中: 84,621 MB
页面文件位置:     C:\pagefile.sys
域:               WORKGROUP

果然系统内存从128G下调到了32G,但是数据库sga估计没有对应降低

SQL> show parameter sga;
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------
lock_sga                             boolean     FALSE
pre_page_sga                         boolean     FALSE
sga_max_size                         big integer 80G
sga_target                           big integer 80G

基本上就是由于虚拟机内存下调,但是数据库sga配置过大导致该问题.

ORA-600 2131故障说明

联系:手机/微信(+86 17813235971) QQ(107644445)

标题:ORA-600 2131故障说明

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

oracle 12c数据库启动报ORA-600 2131错误

Mon Nov 26 09:43:57 2018
starting up 1 dispatcher(s) for network address '(ADDRESS=(PARTIAL=YES)(PROTOCOL=TCP))'...
starting up 1 shared server(s) ...
ORACLE_BASE from environment = D:\app\Administrator
alter database mount exclusive
Mon Nov 26 09:44:00 2018
Using default pga_aggregate_limit of 2048 MB
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\orcl12c\orcl12c\trace\orcl12c_ora_3040.trc  (incident=375524):
ORA-00600: ??????, ??: [2131], [9], [8], [], [], [], [], [], [], [], [], []
Incident details in: D:\APP\ADMINISTRATOR\diag\rdbms\orcl12c\orcl12c\incident\incdir_375524\orcl12c_ora_3040_i375524.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
ORA-600 signalled during: alter database mount exclusive...

这个日志比较明显,数据库无法mount,在mount操作的时候报ORA-600 2131错误.
trace文件报错

Error: kccpb_sanity_check_2
Control file sequence number mismatch!
fhcsq: 497844 bhcsq: 497849 cfn 0 rpbn 16
----- Call Stack Trace -----
calling              call     entry                argument values in hex
location             type     point                (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedst1()+92         CALL???  skdstdst()           000000001 000004000 000030000
                                                   016301338
kccpb_sanity_check(  CALL???  ksedst1()            1492761E0 0000798B4 0000798B9
)+834                                              000000000
kccbmp_get()+275     CALL???  kccpb_sanity_check(  000000000 000000000 000000000
                              )                    000004000
kccsed_rbl()+174     CALL???  kccbmp_get()         000017E28 015A67E14 015592200
                                                   000000001
kccocx()+1399        CALL???  kccsed_rbl()         100000010 100000001 0000354D8
                                                   000035508
kccocf()+167         CALL???  kccocx()+528         016303990 000000000
                                                   7FF00000001 000000000
kcfcmb()+1254        CALL???  kccocf()             000000000 000000000 000000000
                                                   000000000
kcfmdb()+69          CALL???  kcfcmb()             000000000 7FF59FFF856
                                                   000000007 7FE00000000
adbdrv_options()+43  CALL???  kcfmdb()             0163083E0 14903FF2C 000000005
724                                                000000000
adbdrv()+149         CALL???  adbdrv_options()     000000000 000000000 0163084A0
                                                   851F2CC90B75
opiexe()+22668       CALL???  adbdrv()             7FF00000023 000000003
                                                   000000000 016309380
opiosq0()+6009       CALL???  opiexe()             000000000 000000000 016309990
                                                   000000000
kpooprx()+410        CALL???  opiosq0()            000000003 000000000 000000000
                                                   0000000A4
kpoal8()+994         CALL???  kpooprx()            0146A57FC 000000001 0146A5820
                                                   000000001
opiodr()+1601        CALL???  kpoal8()             000000000 015523288 015523270
                                                   0159FCDD0
ttcpip()+1223        CALL???  opiodr()             7FE0000005E 00000001F
                                                   01630DA20 7FE00000000
opitsk()+2160        CALL???  ttcpip()             0146C0690 000000000 000000000
                                                   000000000
opiino()+1079        CALL???  opitsk()             000000007 000000000 01630F200
                                                   01630E970
opiodr()+1601        CALL???  opiino()             00000003C 000000000 01630F470
                                                   000000000
opidrv()+842         CALL???  opiodr()             00000003C 000000004 01630F470
                                                   000000000
sou2o()+94           CALL???  opidrv()+156         10000003C 7FE00000004
                                                   01630F470 0154E6A30
opimai_real()+276    CALL???  sou2o()              1D4851F4C467583 00A9D55E0
                                                   8001A000B07E2 1004B0039001E
opimai()+170         CALL???  opimai_real()        000000000 851F2CB1B179
                                                   00A9D55E0 01630F628
OracleThreadStart()  CALL???  opimai()             000000000 149031F90 000000050
+713                                               0000005C8
00000000775259CD     CALL???  OracleThreadStart()  000000000 000000000 000000000
                                                   000000000
000000007765A561     CALL???  00000000775259C0     000000000 000000000 000000000
                                                   000000000
--------------------- Binary Stack Dump ---------------------

这个错误和以往版本中的kccpb_sanity_check_2比较类似,由于数据库异常关闭导致ctl写丢失导致
ORA-600 2131/kccpb_sanity_check_2解释

DESCRIPTION:
  This internal error is raised when the sequence number (seq#) of the
  current block of the controlfile is greater than the seq# in the controlfile header.
  The header value should always be equal to, or greater than the value
  held in the control file block(s).
  This extra check was introduced in Oracle 10gR2 to detect lost writes
  or stale reads to the header.
ARGUMENTS:
  Arg [a] seq# in control block header.
  Arg [b] seq# in the control file header.
  Arg 
FUNCTIONALITY:
  Kernel Cache layer Control file component.

文件系统损坏导致数据文件异常恢复

联系:手机/微信(+86 17813235971) QQ(107644445)

标题:文件系统损坏导致数据文件异常恢复

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

今天接到一个客户的服务请求,由于服务器被强制重启,数据库无法启动
ORA-1200报错
ora-1200


这是一个常见的ORA-1200错误,但是文件大小相差的有离谱实际大小729600个block,但是现在只有149760个block.不像是一般主机重启导致的数据库异常.通过再次咨询客户实际是什么情况,客户那边如实描述:三个磁盘的raid 5由于两个盘掉线,后来使用最后一个好的盘和最后掉线的盘,强制拉起raid,系统启动通过长时间的自检之后,就是出现这样的情况.通过进一步检查发现,发现大多数数据文件异常.
文件系统中数据文件截图
dbf-fs


通过查询数据库确定文件大小情况
df_header_check


对比文件系统中的文件和数据库查询结果,可以发现绿色框中的文件全部大于文件系统中文件,蓝色框中的文件在文件系统中丢失.对于这样的情况,由于被强制online的磁盘中有坏道,导致文件系统损坏,从而出现大量文件大小异常甚至文件丢失;或者是由于选择错了上线的磁盘出现该问题(通过分析存在的文件,判断确定上线的盘没有问题),那就是文件系统故障导致.
底层重组恢复
解决该问题的方法是通过底层block恢复,重组oracle数据文件,并且检查恢复文件坏块情况.参考:Oracle 数据文件大小为0kb或者文件丢失恢复
scan-disk


分析文件坏块原因
block-had


由于文件所在block被覆盖或者磁盘坏道导致这部分block直接被空块填充.
这个客户比较幸运,直接open数据库成功,坏坏块进行分析判断业务表空间数据文件的坏块全部为index,业务数据0丢失.

ogg导致v$logfile查询频繁

联系:手机/微信(+86 17813235971) QQ(107644445)

标题:ogg导致v$logfile查询频繁

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

在某些版本的ogg中发现ogg抽取进程对v$logfile视图查询影响比较大
20181116220104


对应的sql语句为:SELECT 1 FROM V$LOGFILE WHERE(STATUS NOT IN (‘STALE’, ‘INVALID’) OR STATUS IS NULL) AND MEMBER <> :log_name AND EXISTS ( SELECT 1 FROM V$LOG WHERE GROUP# = V$LOGFILE.GROUP# AND THREAD# = :ora_thread AND SEQUENCE# = :ora_seq_no ) AND ROWNUM = 1
查询mos发现相关问题描述:Query On V$logfile Running Excessive Number Of Times After upgrading ogg to 11.2.1.0.32 or 12.1.2.1.5 or later (Doc ID 2116395.1)和Bug 22650790 : CE 12.1.2.1.9: Query on v$logfile running excessive number of times
2116395.1


根据mos描述在ogg对应版本中设置:TRANLOGOPTIONS _ENABLESTREAMLINEDDBLOGREADER

Oracle 11.2升级到18C

联系:手机/微信(+86 17813235971) QQ(107644445)

标题:Oracle 11.2升级到18C

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

Oracle 18c是12.2的后续版本,不管是从稳定性还是企业级用户的对数据库使用习惯(一般不使用初始版)都是一个可以考虑的选择.另外从11.2的标准服务期限将在2018年底到
DBRoadmap


还有一些客户可能需要使用到一些新功能必须imdb,far sync dg等,考虑把11.2的数据库升级到oracle 18c,结合oracle官方升级文档,这里提供一个手工升级11.2到18c的参考文档:Oracle 18C Non-CDB手工升级文档
主要参考官方文档:Oracle DB 18c – Complete Checklist for Manual Upgrades to Non-CDB Oracle Database 18c(Doc ID 2418045.1)

Oracle Database Server 'TNS Listener'远程数据投毒漏洞(CVE-2012-1675)的解决方案

联系:手机/微信(+86 17813235971) QQ(107644445)

标题:Oracle Database Server 'TNS Listener'远程数据投毒漏洞(CVE-2012-1675)的解决方案

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

根据oracle mos官方描述,该问题需要打patch和配置同步进行,这篇主要提供单机Oracle Database Server ‘TNS Listener’远程数据投毒漏洞(CVE-2012-1675)的解决方案,参考文档Using Class of Secure Transport (COST) to Restrict Instance Registration (Doc ID 1453883.1),因为文档本身描述比较繁琐,这里对其进行简单总结:
数据库版本要求
包含12880299补丁,最低版本要求(高于以下版本即可)
12880299


通过$ORACL_HOME/OPatch/opatch lsinventory 命令获取版本信息,大于等于上述文档版本即可,具体版本对应关系参考:数据库补丁对应关系
listener.ora文件配置

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = localhost.localdomain)(PORT = 1521))
     # (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))  --注释掉,一般不会使用ipc,绝大部分应用使用tcp连接数据库
    )
  )
ADR_BASE_LISTENER = /home/u01/app/oracle
SECURE_REGISTER_LISTENER = (TCP)  --增加该参数

重启监听

lsnrctl stop
lsnrctl start

验证配置生效

1.查看数据库监听日志
$ORACLE_BASE/diag/tnslsnr/主机名/listener/trace/listener.log
2.在局域网中找一台数据库服务器(单机环境),登录数据库
Sqlplus / as sysdba
Show parameter remote_listener;--记录该值(一般是空)
alter system set remote_listener='(ADDRESS=(PROTOCOL=TCP)(HOST=ip)(PORT=1521))' scope=memory;
IP为修改为上述监听的数据库服务器地址
3.再次查看监听日志,会发现类似记录(亦可在数据库中之执行alter system register观察)
02-NOV-2018 20:37:53 * service_register_NSGR * 1194
TNS-01194: The listener command did not arrive in a secure transport
02-NOV-2018 20:37:56 * service_register_NSGR * 1194
TNS-01194: The listener command did not arrive in a secure transport
观察一会儿,表明我们的监听配置生效,数据库拒绝远程监听,修复该漏洞.
如果没有出现类似记录,请核查数据库版本补丁是否满足要求,listener.ora参数配置是否正确
4.还原remote_listener参数以前值
sqlplus / as sysdba
alter system set remote_listener='2中查询记录的值' scope=memory;

对于rac环境,配置比较复杂,参考mos文档:Using Class of Secure Transport (COST) to Restrict Instance Registration in Oracle RAC (Doc ID 1340831.1)