分类目录归档：非常规恢复

asm磁盘加入vg恢复

发表于 2023 年 6 月 25 日 由 惜分飞

又一个客户把asm disk做成pv,加到vg中,并且对lv进行了扩展(ext4的文件系统)
asm-disk-pv

这个客户做了上述操作之后,没有对lv进行写入其他数据,所以破坏较少(主要的破坏就是ext4的每个一段就会置空一部分block预留给文件系统写入元数据使用),通过winhex查看被破坏磁盘发现lvm信息
lvm
对于这种情况,通过对文件头进行修复,结合工具直接拷贝出来数据文件（个别文件元数据损坏通过基于block的方式恢复dbf）
asm-dbf
然后直接恢复dbf中数据文件（对于异常的主要是segment header被置空的tab使用dul单独扫描处理）,实现客户数据的最大限度恢复
以前类似文章:
asm disk被加入vg恢复
asm disk被分区,格式化为ext4恢复
pvcreate asm disk导致asm磁盘组异常恢复
再一起asm disk被格式化成ext3文件系统故障恢复
一次完美的asm disk被格式化ntfs恢复
oracle asm disk格式化恢复—格式化为ext4文件系统

发表在 Oracle ASM, 非常规恢复 | 标签为 , , , , | 评论关闭

再一例asm disk被误加入vg并且扩容lv恢复

发表于 2023 年 2 月 17 日 由 惜分飞

又一客户把三块asm disk磁盘加入到vg里面(两个节点的root vg中),并且还进行了扩容
sdj-asmdisk

加入之后,还对该lv里面进行了expdp数据导出(导出一半失败了,数据库挂了),进而引起了大量的asm磁盘中数据块被文件系统中的expdp导出的dmp复写
20230217200348
通过对损坏磁盘进行kfed分析大概判断损坏到90GB位置
20230217200625
对于这种asm磁盘损坏比较多的情况,常规kfed无法进行修复,只能采用底层基于block层面的扫描恢复,参考:
asm disk header 彻底损坏恢复
通过底层处理恢复出来数据文件:
datafile
然后通过可以有的2天之前的备份,结合dul工具,恢复出来最近数据,业务层面进行整合,完成本次数据恢复
有过类似的恢复案例:
asm disk被加入vg恢复
又一例asm disk 加入vg故障

发表在 非常规恢复 | 标签为 , , , , | 评论关闭

重建control遗漏数据文件,reseltogs报ORA-1555错误处理

发表于 2023 年 2 月 12 日 由 惜分飞

又一客户,误删除oracle redo导致数据库无法正常启动,自己尝试重建ctl,结果遗漏部分oracle数据文件并且尝试过resetlogs,导致部分文件resetlogs scn不一致.导致重建ctl失败

Fri Feb 10 12:41:20 2023
CREATE CONTROLFILE REUSE DATABASE "orcl" RESETLOGS  NOARCHIVELOG
    MAXLOGFILES 50
    MAXLOGMEMBERS 5
    MAXDATAFILES 100
    MAXINSTANCES 8
    MAXLOGHISTORY 226
LOGFILE
  GROUP 1 'H:\BaiduNetdisk\couga/redo01.log'  SIZE 50M,
  GROUP 2 'H:\BaiduNetdisk\couga/redo02.log'  SIZE 50M,
  GROUP 3 'H:\BaiduNetdisk\couga/redo03.log'  SIZE 50M
DATAFILE
'H:\BaiduNetdisk\couga\system01.dbf',
'H:\BaiduNetdisk\couga\cougaerp.DBF',
'H:\BaiduNetdisk\couga\cougajh.DBF',
'H:\BaiduNetdisk\couga\example01.dbf',
'H:\BaiduNetdisk\couga\sysaux01.dbf',
'H:\BaiduNetdisk\couga\undotbs01.dbf',
'H:\BaiduNetdisk\couga\users01.dbf'
CHARACTER SET zhs16gbk
WARNING: Default Temporary Tablespace not specified in CREATE DATABASE command
Default Temporary Tablespace will be necessary for a locally managed database in future release
Errors in file c:\app\xff\diag\rdbms\orcl\orcl11\trace\orcl11_ora_4132.trc:
ORA-01189: ????????????? RESETLOGS
ORA-01110: ???? 6: 'H:\BaiduNetdisk\couga\cougajh.DBF'

通过OraRecovery工具修改相关异常文件头resetlogs scn之后,重建ctl成功
20230212201432

尝试resetlogs 数据库报ORA-00704 ORA-00604 ORA-01555错误
ORA-704-ORA-604-ORA-01555
Fri Feb 10 12:46:04 2023
SMON: enabling cache recovery
ORA-01555 caused by SQL statement below (SQL ID: 4krwuz0ctqxdt, SCN: 0x0000.09dab82d):
select ctime, mtime, stime from obj$ where obj# = :1
Errors in file c:\app\xff\diag\rdbms\orcl\orcl11\trace\orcl11_ora_7088.trc:
ORA-00704: 引导程序进程失败
ORA-00704: 引导程序进程失败
ORA-00604: 递归 SQL 级别 1 出现错误
ORA-01555: 快照过旧: 回退段号 5 (名称为 "_SYSSMU5_1527469038$") 过小
Errors in file c:\app\xff\diag\rdbms\orcl\orcl11\trace\orcl11_ora_7088.trc:
ORA-00704: 引导程序进程失败
ORA-00704: 引导程序进程失败
ORA-00604: 递归 SQL 级别 1 出现错误
ORA-01555: 快照过旧: 回退段号 5 (名称为 "_SYSSMU5_1527469038$") 过小
Error 704 happened during db open, shutting down database
USER (ospid: 7088): terminating the instance due to error 704

通过类似方法处理:
在数据库open过程中常遇到ORA-01555汇总
数据库open过程遭遇ORA-1555对应sql语句补充
顺利open数据库，并且逻辑方式导出数据,完成恢复

发表在 非常规恢复 | 评论关闭