标签云
asm恢复 bbed bootstrap$ dul kcbzib_kcrsds_1 kccpb_sanity_check_2 kcratr_nab_less_than_odr MySQL恢复 obet ORA-00312 ORA-00704 ORA-00742 ORA-01110 ORA-01200 ORA-01555 ORA-01578 ORA-01595 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-600 kcratr_nab_less_than_odr 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 比特币加密文章分类
- MongoDB (1)
- MongoDB恢复 (1)
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (112)
- 数据库 (1,883)
- DB2 (22)
- MySQL (82)
- Oracle (1,708)
- Data Guard (53)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (168)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (72)
- Oracle Bug (8)
- Oracle RAC (56)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (29)
- Oracle备份恢复 (662)
- Oracle安装升级 (108)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (91)
- PostgreSQL (37)
- pdu工具 (7)
- PostgreSQL恢复 (13)
- SQL Server (34)
- SQL Server恢复 (14)
- TimesTen (7)
- 达梦数据库 (5)
- 达梦恢复 (3)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (51)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (34)
- MongoDB (1)
-
最近发表
- aix平台Oracle数据库由于断电无法启动故障处理
- 断电引起ORA-600 3005故障处理
- 记录一次云存储资源到期之后引起的数据库恢复
- Firebird 损坏数据库数据抢救工具—firebirdext
- Oracle 19c 202610补丁(RUs+OJVM)-19.33
- 由于con$.con#值达到极限,触发数据库增加约束报ORA-600 12807错误
- MongoDB 离线提取工具—mongoext
- .bres勒索病毒加密数据库dmp文件可恢复
- ORA-600 krsm_mrp_rebuild_lf_list.lno_mismatch
- 记录一次0丢失的ORA-00354: 损坏重做日志块标头故障恢复
- 不当数据库恢复操作导致一个月数据丢失
- obet快速修复oracle 位图损坏块
- 不太常见的10.2.0.1的oracle redo损坏恢复
- obet forcecopy功能抢救硬件故障中的数据文件
- kcratr_nab_less_than_odr和system坏块故障处理
- 通过obet 恢复system坏块,打开数据库
- obet dbv功能完整说明
- 分享一例运行在aix上的sap系统数据库恢复过程
- OBET-Oracle Block Editor Tool使用说明
- 几乎动用了所有手段的Oracle故障恢复
分类目录归档:数据库
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
.mkp和.Elbie勒索加密数据库可恢复
最近有朋友咨询了两种win机器文件加密的oracle数据库,通过判断均可修复然后正常open库
.DBF.[5D00A5FE].[Xats@privatemail.com].mkp,可以实现数据文件数据0丢失,和强制拉库效果一样

.DBF.id[10D73871-3400].[hero77@cock.li].Elbie,每个文件丢失数据小于1M

以上两种勒索加密都可以通过Oracle数据文件勒索加密恢复工具,快速open

对于类似这种被加密的勒索的数据文件(.[Xats@privatemail.com].mkp和.[hero77@cock.li].Elbie),我们可以实现比较好的恢复效果,如果此类的数据库(oracle,mysql,sql server)等被加密,需要专业恢复技术支持,请联系我们:
电话/微信:17813235971 Q Q:107644445
E-Mail:dba@xifenfei.com
系统安全防护措施建议:
1.多台机器,不要使用相同的账号和口令
2.登录口令要有足够的长度和复杂性,并定期更换登录口令
3.重要资料的共享文件夹应设置访问权限控制,并进行定期备份
4.定期检测系统和软件中的安全漏洞,及时打上补丁。
5.定期到服务器检查是否存在异常。
6.安装安全防护软件,并确保其正常运行。
7.从正规渠道下载安装软件。
8.对不熟悉的软件,如果已经被杀毒软件拦截查杀,不要添加信任继续运行。
9.保存良好的备份习惯,尽量做到每日备份,异地备份。
发表在 勒索恢复
标签为 .Elbie oracle恢复, .Elbie数据库恢复, .mkp oracle恢复, .mkp数据库恢复, hero77@cock.li, Xats@privatemail.com
评论关闭

加我微信(17813235971)
加我QQ(107644445)

