标签云
asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-00742 ORA-01110 ORA-01555 ORA-01578 ORA-01595 ORA-08103 ORA-600 2131 ORA-600 2662 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)
- 操作系统 (103)
- 数据库 (1,764)
- DB2 (22)
- MySQL (77)
- Oracle (1,605)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (166)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (69)
- Oracle Bug (8)
- Oracle RAC (54)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (28)
- Oracle备份恢复 (588)
- Oracle安装升级 (97)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (86)
- PostgreSQL (30)
- pdu工具 (6)
- PostgreSQL恢复 (9)
- SQL Server (32)
- SQL Server恢复 (13)
- TimesTen (7)
- 达梦数据库 (3)
- 达梦恢复 (1)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (39)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (22)
-
最近发表
- 文件系统格式化MySQL数据库恢复
- .sstop勒索加密数据库恢复
- 解决一次硬件恢复之后数据文件0kb的故障恢复case
- Error in invoking target ‘libasmclntsh19.ohso libasmperl19.ohso client_sharedlib’问题处理
- ORA-01171: datafile N going offline due to error advancing checkpoint
- linux环境oracle数据库被文件系统勒索加密为.babyk扩展名溯源
- ORA-600 ksvworkmsgalloc: bad reaper
- ORA-600 krccfl_chunk故障处理
- Oracle Recovery Tools恢复案例总结—202505
- ORA-600 kddummy_blkchk 数据库循环重启
- 记录一次asm disk加入到vg通过恢复直接open库的案例
- CHECKDB 发现了 N 个分配错误和 M 个一致性错误
- 达梦数据库dm.ctl文件异常恢复
- Oracle Recovery Tools修复ORA-00742、ORA-600 ktbair2: illegal inheritance故障
- 可能是 tempdb 空间用尽或某个系统表不一致故障处理
- 11.2.0.4库中遇到ORA-600 kcratr_nab_less_than_odr报错
- [MY-013183] [InnoDB] Assertion failure故障处理
- Oracle 19c 202504补丁(RUs+OJVM)-19.27
- Oracle Recovery Tools修复ORA-600 6101/kdxlin:psno out of range故障
- pdu完美支持金仓数据库恢复(KingbaseES)
年归档:2022
ORA-00257: archiver error的另外一种原因
今天遇到一个相对特殊的案例,拿出来和大家分享,数据库报错为不能归档ORA-00257
SQL> conn system/xxxxxx ERROR: ORA-00257: archiver error. Connect internal only, until freed. SQL> archive log list; Database log mode Archive Mode Automatic archival Enabled Archive destination /oracle/PRD/oraarch Oldest online log sequence 11479 Current log sequence 11481
alert日志报错
sapprddb1:oraprd 73> tail -f alert_prd.log Master archival failure: 19502 Master archival failure: 19502 Master archival failure: 19502 Master archival failure: 19502 Wed Oct 12 09:27:41 2022 Master archival failure: 19502 Master archival failure: 19502 Master archival failure: 19502 Wed Oct 12 09:27:41 2022 Master archival failure: 19502
该错误的含义
sapprddb1:oraprd 74>oerr ora 19502 19502, 00000, "write error on file \"%s\", block number %s (block size=%s)" // *Cause: write error on output file // *Action: check the file
从报错初步看是由于归档目录空间满了导致,查看发现归档空间剩余很多
sapprddb1:/oracle/PRD/sapdata1 # df -h Filesystem Size Used Avail Use% Mounted on /dev/sda1 99G 25G 70G 26% / udev 253G 240K 253G 1% /dev tmpfs 426G 72K 426G 1% /dev/shm /dev/sda3 388G 12G 357G 4% /backup /dev/mapper/SAPVG-oraclelv 197G 22G 165G 12% /oracle /dev/mapper/SAPVG-mirrlogA 20G 773M 18G 5% /oracle/PRD/mirrlogA /dev/mapper/SAPVG-mirrlogBlv 20G 773M 18G 5% /oracle/PRD/mirrlogB /dev/mapper/SAPVG-oraarchlv 180G 2.2G 169G 2% /oracle/PRD/oraarch <----剩余很多 /dev/mapper/SAPVG-origlogAlv 20G 894M 18G 5% /oracle/PRD/origlogA /dev/mapper/SAPVG-origlogBlv 20G 894M 18G 5% /oracle/PRD/origlogB /dev/mapper/SAPVG-sapdata1lv 591G 561G 0 100% /oracle/PRD/sapdata1 /dev/mapper/SAPVG-sapdata2lv 1.4T 1.4T 0 100% /oracle/PRD/sapdata2 /dev/mapper/SAPVG-sapdata3lv 788G 748G 0 100% /oracle/PRD/sapdata3 /dev/mapper/SAPVG-sapdata4lv 788G 748G 0 100% /oracle/PRD/sapdata4 sapprd:/sapmnt/PRD 30G 12G 17G 42% /sapmnt/PRD sapprd:/usr/sap/trans 105G 1005M 99G 1% /usr/sap/trans /dev/mapper/VGSAP2-lvsapdata5 1.5T 340G 1.1T 25% /oracle/PRD/sapdata5 /dev/mapper/VGSAP2-lvsapdata6 1.5T 706G 696G 51% /oracle/PRD/sapdata6
尝试人工归档
SQL> alter system archive log current 2 / alter system archive log current * ERROR at line 1: ORA-19502: write error on file "/oracle/PRD/sapdata1/cntrl/cntrlPRD.dbf", block number 4837 (block size=16384) ORA-27061: waiting for async I/Os failed Linux-x86_64 Error: 28: No space left on device Additional information: -1 Additional information: 442368
到这里基本上明确了,由于控制文件所在的分区磁盘使用100%,导致归档的时候无法写如记录到控制文件从而导致数据库报ORA-00257错误,对/oracle/PRD/sapdata1中的某个文件进行稍微收缩,数据库恢复正常
ORA-600 ktubko_1 恢复
oracle 12.2的rac库,pdb在open成功之后,没过多久会自动crash掉,主要报错ORA-600 ktubko_1
2022-10-08T16:00:17.874444+08:00 XFF(5):Endian type of dictionary set to little 2022-10-08T16:00:18.602483+08:00 XFF(5):[218515] Successfully onlined Undo Tablespace 26. XFF(5):Undo initialization finished serial:0 start:73483625 end:73484200 diff:575 ms (0.6 seconds) XFF(5):Database Characterset for XFF is ZHS16GBK 2022-10-08T16:00:19.340271+08:00 Buffer Cache Full DB Caching mode changing from FULL CACHING ENABLED to FULL CACHING DISABLED Full DB Caching disabled: DEFAULT_CACHE_SIZE should be at least 1394670 MBs bigger than current size. 2022-10-08T16:00:21.308122+08:00 XFF(5):Opening pdb with no Resource Manager plan active 2022-10-08T16:00:22.655433+08:00 Pluggable database XFF opened read write Completed: ALTER PLUGGABLE DATABASE ALL OPEN 2022-10-08T16:00:36.419719+08:00 XFF(5):Setting Resource Manager plan SCHEDULER[0x4AC8]:DEFAULT_MAINTENANCE_PLAN via scheduler window XFF(5):Setting Resource Manager plan DEFAULT_MAINTENANCE_PLAN via parameter 2022-10-08T16:00:57.054295+08:00 XFF(5):minact-scn: got error during useg scan e:1555 usn:57 XFF(5):minact-scn: useg scan erroring out with error e:1555 2022-10-08T16:01:41.527943+08:00 Errors in file /u01/app/db/diag/rdbms/orcl/orcl1/trace/orcl1_smon_218039.trc (incident=737693) (PDBNAME=XFF): ORA-00600: internal error code, arguments: [ktubko_1], [], [], [], [], [], [], [], [], [], [], [] XFF(5):Incident details in: /u01/app/db/diag/rdbms/orcl/orcl1/incident/incdir_737693/orcl1_smon_218039_i737693.trc XFF(5):Use ADRCI or Support Workbench to package the incident. See Note 411.1 at My Oracle Support for error and packaging details. 2022-10-08T16:01:41.530481+08:00 XFF(5):***************************************************************** XFF(5):An internal routine has requested a dump of selected redo. XFF(5):This usually happens following a specific internal error, when XFF(5):analysis of the redo logs will help Oracle Support with the XFF(5):diagnosis. XFF(5):It is recommended that you retain all the redo logs generated (by XFF(5):all the instances) during the past 12 hours, in case additional XFF(5):redo dumps are required to help with the diagnosis. XFF(5):***************************************************************** 2022-10-08T16:01:42.611317+08:00 XFF(5):***************************************************************** XFF(5):An internal routine has requested a dump of selected redo. XFF(5):This usually happens following a specific internal error, when XFF(5):analysis of the redo logs will help Oracle Support with the XFF(5):diagnosis. XFF(5):It is recommended that you retain all the redo logs generated (by XFF(5):all the instances) during the past 12 hours, in case additional XFF(5):redo dumps are required to help with the diagnosis. XFF(5):***************************************************************** XFF(5):ORACLE Instance orcl1 (pid = 44) - Error 600 encountered while recovering transaction (12, 1) on object 50. 2022-10-08T16:01:42.611961+08:00 XFF(5):Errors in file /u01/app/db/diag/rdbms/orcl/orcl1/trace/orcl1_smon_218039.trc: ORA-00600: internal error code, arguments: [ktubko_1], [], [], [], [], [], [], [], [], [], [], [] 2022-10-08T16:01:42.849438+08:00 Errors in file /u01/app/db/diag/rdbms/orcl/orcl1/trace/orcl1_smon_218039.trc (incident=737694) (PDBNAME=XFF): ORA-00600: internal error code, arguments: [ktubko_1], [], [], [], [], [], [], [], [], [], [], [] XFF(5):Incident details in: /u01/app/db/diag/rdbms/orcl/orcl1/incident/incdir_737694/orcl1_smon_218039_i737694.trc ………… 2022-10-08T16:01:55.212368+08:00 Instance Critical Process (pid: 44, ospid: 218039, SMON) died unexpectedly PMON (ospid: 217933): terminating the instance due to error 474 2022-10-08T16:01:55.379857+08:00 System state dump requested by (instance=1, osid=217933 (PMON)), summary=[abnormal instance termination]. System State dumped to trace file /u01/app/db/diag/rdbms/orcl/orcl1/trace/orcl1_diag_217966_20221008160155.trc 2022-10-08T16:01:56.417514+08:00 ORA-1092 : opitsk aborting process
因为有smon报的ORACLE Instance orcl1 (pid = 44) – Error 600 encountered while recovering transaction (12, 1) on object xxx这种比较明显错误,基本上可以定位是undo问题.对undo异常事务进行处理,数据库顺利open,并且稳定不再crash,然后对异常对象进行处理(当然也可以逻辑迁移)
在oracle 12.2到18.14的rac环境的cdb库中,如果节点sga大小不一致,而且有一个节点sga大于128G,就可能出现该问题,敬请注意

Bug 32347014: ORA-600[4506], ORA-600[KTUBKO_1] OCCUR AND INSTANCE CRASHES
一键修改Oracle SCN工具升级(patch scn)
前段时间开发了基于内存修改的patch scn小程序(修改oracle scn小工具(patch scn)),用来修改oracle数据库scn,实现快速调整oracle scn的功能(特别是在一些恢复的时候很有用),最近对其功能进一步完善,扩展了通过修改oracle controlfile实现调整scn功能,简单测试如下
数据库当前scn情况
C:\Users\XFF>sqlplus / as sysdba SQL*Plus: Release 11.2.0.4.0 Production on 星期四 10月 6 21:50:32 2022 Copyright (c) 1982, 2013, Oracle. All rights reserved. 连接到: Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production With the Partitioning, OLAP, Data Mining and Real Application Testing options SQL> set num 16 SQL> select checkpoint_change# from v$database; CHECKPOINT_CHANGE# ------------------ 141743308712 SQL> shutdown immediate; 数据库已经关闭。 已经卸载数据库。 ORACLE 例程已经关闭。
启动库查看修改之后scn值
SQL> startup mount; ORACLE 例程已经启动。 Total System Global Area 6413680640 bytes Fixed Size 2293216 bytes Variable Size 1275068960 bytes Database Buffers 5117050880 bytes Redo Buffers 19267584 bytes 数据库装载完毕。 SQL> set num 16 SQL> select checkpoint_change# from v$database; CHECKPOINT_CHANGE# ------------------ 141743339676 SQL> alter database open; 数据库已更改。 SQL> select checkpoint_change# from v$database; CHECKPOINT_CHANGE# ------------------ 151743339602
数据库启动过程中scn会被改变,在mount的时候未发生改变
Patch_SCN下载:Patch_SCN下载
Patch_SCN使用说明:Patch_SCN使用说明
OraRecovery下载:OraRecovery下载
OraRecovery使用说明:OraRecovery使用说明