标签云
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 2131 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)
- 操作系统 (102)
- 数据库 (1,671)
- DB2 (22)
- MySQL (73)
- Oracle (1,533)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (21)
- ORA-xxxxx (159)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (14)
- ORACLE 21C (3)
- Oracle 23ai (7)
- Oracle ASM (65)
- Oracle Bug (8)
- Oracle RAC (52)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (28)
- Oracle备份恢复 (560)
- Oracle安装升级 (92)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (78)
- PostgreSQL (18)
- PostgreSQL恢复 (6)
- SQL Server (27)
- SQL Server恢复 (8)
- TimesTen (7)
- 达梦数据库 (2)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (37)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (20)
-
最近发表
- Kylin Linux 安装19c
- ORA-600 krse_arc_complete.4
- Oracle 19c 202410补丁(RUs+OJVM)
- ntfs MFT损坏(ntfs文件系统故障)导致oracle异常恢复
- .mkp扩展名oracle数据文件加密恢复
- 清空redo,导致ORA-27048: skgfifi: file header information is invalid
- A_H_README_TO_RECOVER勒索恢复
- 通过alert日志分析客户自行对一个数据库恢复的来龙去脉和点评
- ORA-12514: TNS: 监听进程不能解析在连接描述符中给出的SERVICE_NAME
- ORA-01092 ORA-00604 ORA-01558故障处理
- ORA-65088: database open should be retried
- Oracle 19c异常恢复—ORA-01209/ORA-65088
- ORA-600 16703故障再现
- 数据库启动报ORA-27102 OSD-00026 O/S-Error: (OS 1455)
- .[metro777@cock.li].Elbie勒索病毒加密数据库恢复
- 应用连接错误,初始化mysql数据库恢复
- RAC默认服务配置优先节点
- Oracle 19c RAC 替换私网操作
- 监听报TNS-12541 TNS-12560 TNS-00511错误
- drop tablespace xxx including contents恢复
分类目录归档:Oracle
rm -rf误删Oracle数据库恢复
有客户把虚拟化环境中装有oracle数据库的linux操作系统,由于操作失误在/下面执行了rm -rf *,导致所有文件被删除,系统无法启动.客户希望要求恢复出其中的Oracle数据库.由于是虚拟化环境,然后客户直接从虚拟化平台下载下来磁盘文件,通过工具加载和分析确认是一个xfs的文件系统
使用工具进一步扫描分析,找到部分数据文件
这里可以获取到两个信息:
1. 尝试恢复oracle的control01.ctl文件,然后通过该文件尝试分析其他数据文件位置,运气不错该文件恢复出来是好的,直接加载到新库查询v$datafile,分析出来所有数据文件信息
2. 这里有一个非常不幸的信息,oracle最核心的system01.dbf文件大小明显异常,进一步分析该文件信息,结论是该文件无法通过反删除方式进行恢复
先把可以os层面可以恢复的数据恢复出来,并且检查坏块情况
对于异常的system文件,有两个处理方法:
1. 通过阅览被删除的文件,发现客户有5月14日1点左右的rman备份,通过恢复软件中完整度提示,大概率应该没有什么问题,但是分析发现部分归档日志损坏无法完整恢复
2. 通过对磁盘做碎片,恢复出来该数据文件,参考以往文章:
dbca删除库和rm删库恢复
Oracle 数据文件大小为0kb或者文件丢失恢复
通过这个方法运气不错,恢复出来该库的system01.dbf文件非常完整0丢失
[oracle@localhost oradata]$ dbv file=system01.dbf DBVERIFY: Release 19.0.0.0.0 - Production on Thu May 15 23:26:57 2024 Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved. DBVERIFY - Verification starting : FILE = /u01/oradata/system01.dbf DBVERIFY - Verification complete Total Pages Examined : 199680 Total Pages Processed (Data) : 113988 Total Pages Failing (Data) : 0 Total Pages Processed (Index): 26869 Total Pages Failing (Index): 0 Total Pages Processed (Other): 40253 Total Pages Processed (Seg) : 1 Total Pages Failing (Seg) : 0 Total Pages Empty : 18570 Total Pages Marked Corrupt : 0 Total Pages Influx : 0 Total Pages Encrypted : 0 Highest block SCN : 658228557 (0.658228557)
完成上述恢复工作之后,目前确认只有sysaux01.dbf有8026个block损坏,但是该表空间不涉及业务数据,尝试在新的系统中直接修改路径并open库
SQL> recover database; ORA-00283: recovery session canceled due to errors ORA-38760: This database instance failed to turn on flashback database SQL> alter database flashback off; Database altered. SQL> recover database; Media recovery complete. SQL> alter database open; Database altered.
运气不错,数据库直接open成功,现在处理sysaux01.dbf中的损坏文件:
1. 确认该文件具体坏块开始位置:
2. 由于坏块在文件中比较靠后,分析实际存储数据最后的位置
SQL> select max(block_id+blocks) from dba_extents where file_id=3; MAX(BLOCK_ID+BLOCKS) -------------------- 3493120
最后存储数据的位置小于坏块的位置,证明坏块部分是没有存储数据的,直接resize掉坏块部分
SQL> alter database datafile '/u01/oradata/sysaux01.dbf' resize 27290m; Database altered.
然后dbv该数据文件,确认没有任何问题
[oracle@localhost trace]$ dbv file=/u01/oradata/sysaux01.dbf DBVERIFY: Release 19.0.0.0.0 - Production on Wed May 15 22:43:00 2024 Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved. DBVERIFY - Verification starting : FILE = /u01/oradata/sysaux01.dbf DBVERIFY - Verification complete Total Pages Examined : 3493120 Total Pages Processed (Data) : 1516833 Total Pages Failing (Data) : 0 Total Pages Processed (Index): 1868832 Total Pages Failing (Index): 0 Total Pages Processed (Lob) : 56577 Total Pages Failing (Lob) : 0 Total Pages Processed (Other): 32107 Total Pages Processed (Seg) : 0 Total Pages Failing (Seg) : 0 Total Pages Empty : 18771 Total Pages Marked Corrupt : 0 Total Pages Influx : 0 Total Pages Encrypted : 0 Highest block SCN : 658223915 (0.658223915)
使用rman检测全库,也确定没有任何问题
[oracle@localhost trace]$ rman target / Recovery Manager: Release 19.0.0.0.0 - Production on Wed May 15 22:43:58 2024 Version 19.15.0.0.0 Copyright (c) 1982, 2019, Oracle and/or its affiliates. All rights reserved. connected to target database: XIFENFEI (DBID=2912535091) RMAN> RMAN> RMAN> backup validate check logical database skip inaccessible; Starting backup at 15-MAY-24 using target database control file instead of recovery catalog allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=43 device type=DISK allocated channel: ORA_DISK_2 channel ORA_DISK_2: SID=278 device type=DISK channel ORA_DISK_1: starting full datafile backup set channel ORA_DISK_1: specifying datafile(s) in backup set ……………… File Status Marked Corrupt Empty Blocks Blocks Examined High SCN ---- ------ -------------- ------------ --------------- ---------- 32 OK 0 6273 6400 370625094 File Name: /u01/oradata/xff_com.dbf Block Type Blocks Failing Blocks Processed ---------- -------------- ---------------- Data 0 0 Index 0 0 Other 0 127 File Status Marked Corrupt Empty Blocks Blocks Examined High SCN ---- ------ -------------- ------------ --------------- ---------- 33 OK 0 163752 832000 627920639 File Name: /u01/oradata/XFF_DATA_202312231.dbf Block Type Blocks Failing Blocks Processed ---------- -------------- ---------------- Data 0 374296 Index 0 285002 Other 0 8950 Finished backup at 15-MAY-24 [oracle@localhost trace]$ sqlplus / as sysdba SQL*Plus: Release 19.0.0.0.0 - Production on Wed May 15 22:47:44 2024 Version 19.15.0.0.0 Copyright (c) 1982, 2022, Oracle. All rights reserved. Connected to: Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production Version 19.15.0.0.0 SQL> select * from v$database_block_corruption ; no rows selected SQL>
至此对于这次rm -rf /*的故障实现了Oracle数据库完美恢复,数据0丢失.
分布式存储故障导致数据库无法启动故障处理
国内xx医院使用了国外医疗行业龙头的pacs系统,由于是一个历史库,存放在分布式存储中,由于存储同时多个节点故障,导致数据库多个文件异常,数据库无法启动,三方维护人员尝试通通过rman归档进行应用日志,结果发现日志有损坏报ORA-00354 ORA-00353,无法记录恢复,希望我们给予支持
Mon Apr 29 13:28:40 2024 Media Recovery failed with error 354 Mon Apr 29 13:28:40 2024 Errors in file F:\XXXXXX_DB\ORACLE\ADMIN\diag\rdbms\xxx\msxxx1\trace\xxx_pr00_4568.trc: ORA-00283: recovery session canceled due to errors ORA-00354: corrupt redo log block header ORA-00353: log corruption near block 487424 change 8737273868 time 04/01/2024 01:38:25 ORA-00334: archived log: 'F:\XXXXXX_DB\ORADATA\XXX\LOGARC0000052184_0922116268.0001' ORA-283 signalled during: alter database recover logfile 'F:\XXXXXX_DB\ORADATA\XXX\LOGARC0000052184_0922116268.0001'...
接手故障之后,通过尝试恢复发现除该错误之外,还有ORA-600 4552之类错误
跳过这些异常文件恢复,最终确认异常文件有如下部分
这些文件由于日志无法正常应用(有日志损坏无法应用,有日志和数据文件block不匹配导致无法应用),这样的情况直接通过自研的Oracle Recovery Tools小工具直接修改文件头信息
然后尝试OPEN数据库结果报ORA-1207
对于这个故障可以通过rectl或者using backup ctl方式处理,然后open数据库成功
由于该系统是历史库,不会有新业务写入,通过对异常表和索引进行处理之后,客户测试业务可以正常访问,完成本次恢复
WINDOWS 下用dg broker搭建ADG(单机to单机)
环境
#主备库 C:\Windows\System32\drivers\etc\hosts 文件 192.168.11.10 dg1 192.168.11.11 dg2 #环境 主库主机名:dg1 现有实例orcl 备库主机名:dg2 只安装软件
一,主库配置
–主库设置强制日志,保证所有的操作都记录到日志文件
–查看当前force\_logging的设置
#主库如果已开启归档,不需要停机 sqlplus / as sysdba select force_logging from v$database; select flashback_on from v$database; alter database force logging; -- 开启强制日志模式 ####################################################### #如果没开归档 sqlplus / as sysdba shudown immediate; startup mount; alter database archivelog; -- 开启归档模式 alter database force logging; -- 开启强制日志模式 #alter database flashback on; -- 开启闪回,不是必须,推荐开启 ####################################################### #主库添加standby日志组 #查看日志文件大小 select bytes/1024/1024 from v$log;这里是50M alter database add standby logfile group 10 ('D:\app\Administrator\oradata\orcl\standby_redo01.log') size 50m; alter database add standby logfile group 11 ('D:\app\Administrator\oradata\orcl\standby_redo02.log') size 50m; alter database add standby logfile group 12 ('D:\app\Administrator\oradata\orcl\standby_redo03.log') size 50m; alter database add standby logfile group 13 ('D:\app\Administrator\oradata\orcl\standby_redo04.log') size 50m; ######################################################## #设置文件管理自动 alter system set standby_file_management=auto;
二、主备库网络设置
#主库listener.ora SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (GLOBAL_DBNAME = orcl) (ORACLE_HOME = D:\APP\ADMINISTRATOR\PRODUCT\11.2.0\DBHOME_1) (SID_NAME = orcl) ) (SID_DESC = (GLOBAL_DBNAME = orcl_DGMGRL) #用于dg broker的静态监听 (ORACLE_HOME = D:\APP\ADMINISTRATOR\PRODUCT\11.2.0\DBHOME_1) (SID_NAME = orcl) ) ) LISTENER = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = dg1)(PORT = 1521)) (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521)) ) #主库tnsnames.ora ORCL_STBY = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = dg2)(PORT = 1521)) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = orcl) ) ) ORCL = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = dg1)(PORT = 1521)) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = orcl) ) ) #备库listener.ora SID_LIST_LISTENER = (SID_LIST = (SID_DESC = (GLOBAL_DBNAME = orcl) (ORACLE_HOME = D:\APP\ADMINISTRATOR\PRODUCT\11.2.0\DBHOME_1) (SID_NAME = orcl) ) (SID_DESC = (GLOBAL_DBNAME = orcl_stby_DGMGRL) #用于dg broker的静态监听 (ORACLE_HOME = D:\APP\ADMINISTRATOR\PRODUCT\11.2.0\DBHOME_1) (SID_NAME = orcl) ) ) LISTENER = (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = dg2)(PORT = 1521)) (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521)) ) #备库tnsnames.ora ORCL_STBY = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = dg2)(PORT = 1521)) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = orcl) ) ) ORCL = (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = dg1)(PORT = 1521)) ) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = orcl) ) ) #主库监听reload lsnrctl reload #备库启动监听 lsnrctl start
三、备库配置
#创建一个临时参数文件如d:\pfile.txt内容如下 *.db_name='orcl' #创建密码文件,或者从主库拷贝一个 orapwd file=D:\APP\ADMINISTRATOR\PRODUCT\11.2.0\DBHOME_1\database\PWDorcl.ora password=oracle entries=10 #创建备库所需目录 mkdir D:\app\Administrator\oradata\orcl\ mkdir D:\app\Administrator\admin\orcl\adump\ mkdir D:\app\Administrator\fast_recovery_area\orcl\ #用ORADIM创建实例 oradim -new -sid orcl #用临时参数文件启动 sqlplus / as sysdba starup nomount pfile='d:\pfile.txt';
四、RMAN duplicate创建备库
#tnsping测试互通性 tnsping orcl tnsping orcl_stby #主库连接备库 sqlplus sys/oracle@stddb as sysdba #备库连接主库 sqlplus sys/oracle@orcl as sysdba ######################################################### #备库执行,连接主备库 rman target sys/oracle@orcl auxilary sys/oracle@orcl_stby #创建dg备库,这里假设主备库路径相同 duplicate target database for standby from active database dorecover spfile set db_unique_name='orcl_stby' nofilenamecheck; ######################################################### #如果主备库路径不同 duplicate target database for standby from active database dorecover spfile set db_unique_name='orcl_stby' set db_file_name_convert='orcl','orcl_stby' set log_file_name_convert='orcl','orcl_stby' set job_queue_processes='0' nofilenamecheck; #开启ADG sqlplus / as sysdba alter database open read only; alter database recover managed standby database disconnect from session;
五、配置DG BROKER
#主备库两边执行 alter system set dg_broker_start=true; #主库连接dgmgrl dgmgrl sys/oracle@orcl #创建dg broker配置 create configuration dg_config as primary database is orcl connect identifier is orcl; #添加备库到配置文件 add database orcl_stby as connect identifier is orcl_stby; #启用配置 enable configuration; ############################################################################ #显示DG配置信息 show configuration show configuration verbose #显示主备库信息 show database orcl show database orcl_stby show database verbose orcl show database verbose orcl_stby
六、一些测试
#测试Database Switchover dgmgrl sys/oracle@orcl switchover to orcl_stby; show configuration #切换回来 switchover to orcl; show configuration ########################################################################### #测试Database Failover,此时dg关系已经打破 dgmgrl sys/oracle@orcl failover to orcl_stby; #如果主库开启了flashback,执行以下语句自动重建主库 reinstate database orcl; #如果没有开启flashback,删除重建主库,重新建立dg关系 ############################################################################ #测试快照备库 dgmgrl sys/oracle@orcl convert database orcl_stby to snapshot standby; show configuration; #快照转成正常备库 convert database orcl_stby to physical standby; show configuration;
七、总结
优点在于除监听设置外主备库都不需要做过多的设置,备库临时参数文件只需要一个dbname,其余dg有关的参数dg broker会自动设置。
八、参考资料
ORACLE-BASE – Data Guard Physical Standby Setup Using the Data Guard Broker in Oracle Database 11g Release 2
发表在 Data Guard
评论关闭