标签云
asm 恢复 asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 kfed MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-01110 ORA-01555 ORA-01578 ORA-08103 ORA-600 2662 ORA-600 2663 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 ORACLE恢复 Oracle 恢复 ORACLE数据库恢复 oracle 比特币 OSD-04016 YOUR FILES ARE ENCRYPTED 勒索恢复 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (100)
- 数据库 (1,595)
- DB2 (22)
- MySQL (70)
- Oracle (1,462)
- Data Guard (49)
- EXADATA (7)
- GoldenGate (21)
- ORA-xxxxx (158)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (13)
- ORACLE 21C (3)
- Oracle ASM (65)
- Oracle Bug (7)
- Oracle RAC (47)
- Oracle 安全 (6)
- Oracle 开发 (27)
- Oracle 监听 (27)
- Oracle备份恢复 (530)
- Oracle安装升级 (83)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (75)
- PostgreSQL (16)
- PostgreSQL恢复 (4)
- SQL Server (27)
- SQL Server恢复 (8)
- TimesTen (7)
- 达梦数据库 (2)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (36)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (19)
-
最近发表
- PostgreSQL部分主要字典信息
- PostgreSQL恢复系列:pg_filedump恢复字典构造
- PostgreSQL 16 源码安装
- ORA-00742 ORA-00312 恢复
- 数据库open成功后报ORA-00353 ORA-00354错误引起的一系列问题(本质ntfs文件系统异常)
- ORA-600 ktsiseginfo1故障
- ORA-00600: internal error code, arguments: [16703], [1403], [4] 原因
- 最近遇到几起ORA-600 16703故障(tab$被清空),请引起重视
- ORA-600 2662快速恢复之Patch scn工具
- TNS-12518: TNS:listener could not hand off client connection
- ora.storage无法启动报ORA-12514故障处理
- 断电引起文件scn异常数据库恢复
- ORA-16188: LOG_ARCHIVE_CONFIG settings inconsistent with previously started instance
- .[hudsonL@cock.li].mkp勒索加密数据库完美恢复
- 模拟带库实现rman远程备份
- 又一例:ORA-600 kclchkblk_4和2662故障
- Oracle误删除数据文件恢复
- Oracle 19C 备库DML重定向—DML Redirection
- ORA-01595/ORA-600 4194处理
- 从ORA-00283 ORA-16433报错开始恢复
月归档:十一月 2018
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脚本检查数据库结果
通过这里可以看出来,数据库需要的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
在虚拟化环境中的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故障说明
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 1 FUNCTIONALITY: Kernel Cache layer Control file component.