标签云
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,767)
- DB2 (22)
- MySQL (77)
- Oracle (1,608)
- 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 监听 (29)
- Oracle备份恢复 (590)
- 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)
-
最近发表
- ORA-00756 ORA-10567故障数据0丢失恢复
- 数据库文件变成32k故障恢复
- tcp连接过多导致监听TNS-12532 TNS-12560 TNS-00502错误
- 文件系统格式化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故障处理
月归档:三月 2018
恢复没有控制文件备份的rman数据文件备份
最近有朋友咨询,只有rman备份数据文件,无控制文件备份的问题,这里进行分析验证
只有数据文件的rman备份
这里只有数据文件的备份,没有任何控制文件的备份
C:\Documents and Settings\Administrator>e: E:\>dir 驱动器 E 中的卷是 新加卷 卷的序列号是 68FB-8527 E:\ 的目录 2018-03-29 10:53 6,163,873,792 FULL_20180329_01SV08N2_1_1.RMAN 2018-03-29 10:54 1,050,558,464 FULL_20180329_02SV0918_1_1.RMAN 2018-03-29 10:56 2,167,414,784 FULL_20180329_03SV092B_1_1.RMAN 2018-03-29 11:07 1,034,625,024 FULL_20180329_05SV09QQ_1_1.RMAN 2018-03-29 11:07 1,376,256 FULL_20180329_06SV09RJ_1_1.RMAN 2018-03-29 11:08 3,104,768 FULL_20180329_07SV09TP_1_1.RMAN
还原system01.dbf
SQL> startup nomount ORACLE 例程已经启动。 Total System Global Area 2137886720 bytes Fixed Size 2177456 bytes Variable Size 1224738384 bytes Database Buffers 905969664 bytes Redo Buffers 5001216 bytes SQL> @restore_datafile.sql system01.dbf Trying : E:/FULL_20180329_02SV0918_1_1.RMAN From : DISK Data File : Found ------------------------ RESTORED Data File To: D:\oradata\orcl\system01.dbf PL/SQL 过程已成功完成。
重建控制文件
SQL> startup nomount pfile=e:/pfile.txt ORACLE 例程已经启动。 Total System Global Area 2137886720 bytes Fixed Size 2177456 bytes Variable Size 1224738384 bytes Database Buffers 905969664 bytes Redo Buffers 5001216 bytes SQL> CREATE CONTROLFILE REUSE DATABASE "ORCL" RESETLOGS NOARCHIVELOG 2 MAXLOGFILES 50 3 MAXLOGMEMBERS 5 4 MAXDATAFILES 100 5 MAXINSTANCES 1 6 MAXLOGHISTORY 226 7 LOGFILE 8 GROUP 1 'D:\oradata\orcl\redo01.log' SIZE 100M, 9 GROUP 2 'D:\oradata\orcl\redo02.log' SIZE 100M, 10 GROUP 3 'D:\oradata\orcl\redo03.log' SIZE 100M 11 DATAFILE 12 'D:\oradata\orcl\system01.dbf' 13 CHARACTER SET ZHS16GBK 14 ; 控制文件已创建。
注册备份集
E:\>rman target / 恢复管理器: Release 11.2.0.1.0 - Production on 星期四 3月 29 15:46:17 2018 Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved. 已连接到目标数据库: ORCL (DBID=1449113534, 未打开) RMAN> catalog start with 'e:/*.rman'; 使用目标数据库控制文件替代恢复目录 搜索与样式 e:/*.rman 匹配的所有文件 数据库未知文件的列表 ===================================== 文件名: E:\FULL_20180329_01SV08N2_1_1.RMAN 文件名: E:\FULL_20180329_02SV0918_1_1.RMAN 文件名: E:\FULL_20180329_03SV092B_1_1.RMAN 文件名: E:\FULL_20180329_05SV09QQ_1_1.RMAN 文件名: E:\FULL_20180329_06SV09RJ_1_1.RMAN 文件名: E:\FULL_20180329_07SV09TP_1_1.RMAN 是否确实要将上述文件列入目录 (输入 YES 或 NO)? yes 正在编制文件目录... 目录编制完毕 已列入目录的文件的列表 ======================= 文件名: E:\FULL_20180329_01SV08N2_1_1.RMAN 文件名: E:\FULL_20180329_02SV0918_1_1.RMAN 文件名: E:\FULL_20180329_03SV092B_1_1.RMAN 文件名: E:\FULL_20180329_05SV09QQ_1_1.RMAN 文件名: E:\FULL_20180329_06SV09RJ_1_1.RMAN 文件名: E:\FULL_20180329_07SV09TP_1_1.RMAN RMAN> list backup; 备份集列表 =================== BS 关键字 类型 LV 大小 设备类型 经过时间 完成时间 ------- ---- -- ---------- ----------- ------------ ---------- 1 Full 5.74G DISK 00:00:00 29-3月 -18 BP 关键字: 1 状态: AVAILABLE 已压缩: NO 标记: TAG20180329T104802 段名:E:\FULL_20180329_01SV08N2_1_1.RMAN 备份集 1 中的数据文件列表 文件 LV 类型 Ckp SCN Ckp 时间 名称 ---- -- ---- ---------- ---------- ---- 5 Full 96384627 29-3月 -18 BS 关键字 类型 LV 大小 设备类型 经过时间 完成时间 ------- ---- -- ---------- ----------- ------------ ---------- 2 Full 1001.88M DISK 00:00:00 29-3月 -18 BP 关键字: 2 状态: AVAILABLE 已压缩: NO 标记: TAG20180329T104802 段名:E:\FULL_20180329_02SV0918_1_1.RMAN 备份集 2 中的数据文件列表 文件 LV 类型 Ckp SCN Ckp 时间 名称 ---- -- ---- ---------- ---------- ---- 1 Full 96384627 29-3月 -18 D:\ORADATA\ORCL\SYSTEM01.DBF BS 关键字 类型 LV 大小 设备类型 经过时间 完成时间 ------- ---- -- ---------- ----------- ------------ ---------- 3 Full 2.02G DISK 00:00:00 29-3月 -18 BP 关键字: 3 状态: AVAILABLE 已压缩: NO 标记: TAG20180329T104802 段名:E:\FULL_20180329_03SV092B_1_1.RMAN 备份集 3 中的数据文件列表 文件 LV 类型 Ckp SCN Ckp 时间 名称 ---- -- ---- ---------- ---------- ---- 6 Full 96384627 29-3月 -18 BS 关键字 类型 LV 大小 设备类型 经过时间 完成时间 ------- ---- -- ---------- ----------- ------------ ---------- 4 Full 986.69M DISK 00:00:00 29-3月 -18 BP 关键字: 4 状态: AVAILABLE 已压缩: NO 标记: TAG20180329T110706 段名:E:\FULL_20180329_05SV09QQ_1_1.RMAN 备份集 4 中的数据文件列表 文件 LV 类型 Ckp SCN Ckp 时间 名称 ---- -- ---- ---------- ---------- ---- 2 Full 96384627 29-3月 -18 BS 关键字 类型 LV 大小 设备类型 经过时间 完成时间 ------- ---- -- ---------- ----------- ------------ ---------- 5 Full 1.30M DISK 00:00:00 29-3月 -18 BP 关键字: 5 状态: AVAILABLE 已压缩: NO 标记: TAG20180329T110706 段名:E:\FULL_20180329_06SV09RJ_1_1.RMAN 备份集 5 中的数据文件列表 文件 LV 类型 Ckp SCN Ckp 时间 名称 ---- -- ---- ---------- ---------- ---- 4 Full 96384627 29-3月 -18 BS 关键字 类型 LV 大小 设备类型 经过时间 完成时间 ------- ---- -- ---------- ----------- ------------ ---------- 6 Full 2.95M DISK 00:00:00 29-3月 -18 BP 关键字: 6 状态: AVAILABLE 已压缩: NO 标记: TAG20180329T110841 段名:E:\FULL_20180329_07SV09TP_1_1.RMAN 备份集 6 中的数据文件列表 文件 LV 类型 Ckp SCN Ckp 时间 名称 ---- -- ---- ---------- ---------- ---- 3 Full 96384627 29-3月 -18
还原所有数据文件
SQL> @restore_datafile all_file Restoring All Data Files : -------------------------- Attempting To Restore :D:\oradata\orcl\1.dbf ------------------------ Trying : E:/FULL_20180329_01SV08N2_1_1.RMAN From : DISK Data File: Not Found ------------------------ Trying : E:/FULL_20180329_02SV0918_1_1.RMAN From : DISK Data File : Found ------------------------ RESTORED Data File To: D:\oradata\orcl\1.dbf Attempting To Restore :D:\oradata\orcl\2.dbf ------------------------ Trying : E:/FULL_20180329_01SV08N2_1_1.RMAN From : DISK Data File: Not Found ------------------------ Trying : E:/FULL_20180329_02SV0918_1_1.RMAN From : DISK Data File: Not Found ------------------------ Trying : E:/FULL_20180329_03SV092B_1_1.RMAN From : DISK Data File: Not Found ------------------------ Trying : E:/FULL_20180329_05SV09QQ_1_1.RMAN From : DISK Data File : Found ------------------------ RESTORED Data File To: D:\oradata\orcl\2.dbf Attempting To Restore :D:\oradata\orcl\3.dbf ------------------------ Trying : E:/FULL_20180329_01SV08N2_1_1.RMAN From : DISK Data File: Not Found ------------------------ Trying : E:/FULL_20180329_02SV0918_1_1.RMAN From : DISK Data File: Not Found ------------------------ Trying : E:/FULL_20180329_03SV092B_1_1.RMAN From : DISK Data File: Not Found ------------------------ Trying : E:/FULL_20180329_05SV09QQ_1_1.RMAN From : DISK Data File: Not Found ------------------------ Trying : E:/FULL_20180329_06SV09RJ_1_1.RMAN From : DISK Data File: Not Found ------------------------ Trying : E:/FULL_20180329_07SV09TP_1_1.RMAN From : DISK Data File : Found ------------------------ RESTORED Data File To: D:\oradata\orcl\3.dbf Attempting To Restore :D:\oradata\orcl\4.dbf ------------------------ Trying : E:/FULL_20180329_01SV08N2_1_1.RMAN From : DISK Data File: Not Found ------------------------ Trying : E:/FULL_20180329_02SV0918_1_1.RMAN From : DISK Data File: Not Found ------------------------ Trying : E:/FULL_20180329_03SV092B_1_1.RMAN From : DISK Data File: Not Found ------------------------ Trying : E:/FULL_20180329_05SV09QQ_1_1.RMAN From : DISK Data File: Not Found ------------------------ Trying : E:/FULL_20180329_06SV09RJ_1_1.RMAN From : DISK Data File : Found ------------------------ RESTORED Data File To: D:\oradata\orcl\4.dbf Attempting To Restore :D:\oradata\orcl\5.dbf ------------------------ Trying : E:/FULL_20180329_01SV08N2_1_1.RMAN From : DISK Data File : Found ------------------------ RESTORED Data File To: D:\oradata\orcl\5.dbf Attempting To Restore :D:\oradata\orcl\6.dbf ------------------------ Trying : E:/FULL_20180329_01SV08N2_1_1.RMAN From : DISK Data File: Not Found ------------------------ Trying : E:/FULL_20180329_02SV0918_1_1.RMAN From : DISK Data File: Not Found ------------------------ Trying : E:/FULL_20180329_03SV092B_1_1.RMAN From : DISK Data File : Found ------------------------ RESTORED Data File To: D:\oradata\orcl\6.dbf PL/SQL 过程已成功完成。
重建控制文件并open数据库
SQL> CREATE CONTROLFILE REUSE DATABASE "ORCL" RESETLOGS NOARCHIVELOG 2 MAXLOGFILES 50 3 MAXLOGMEMBERS 5 4 MAXDATAFILES 100 5 MAXINSTANCES 1 6 MAXLOGHISTORY 226 7 LOGFILE 8 GROUP 1 'D:\oradata\orcl\redo01.log' SIZE 100M, 9 GROUP 2 'D:\oradata\orcl\redo02.log' SIZE 100M, 10 GROUP 3 'D:\oradata\orcl\redo03.log' SIZE 100M 11 DATAFILE 12 'D:\oradata\orcl\1.dbf', 13 'D:\oradata\orcl\2.dbf', 14 'D:\oradata\orcl\3.dbf', 15 'D:\oradata\orcl\4.dbf', 16 'D:\oradata\orcl\5.dbf', 17 'D:\oradata\orcl\6.dbf' 18 CHARACTER SET ZHS16GBK 19 ; 控制文件已创建。 SQL> alter database open resetlogs; 数据库已更改。
这里本质就是通过oracle内部包,直接还原数据文件,这个模拟的是基础的情况,在实际的恢复中,由于只有数据文件的备份,可能文件不一致,还需要通过一些非常规方法对数据库进行强制打开
发表在 rman备份/恢复
评论关闭
dataguard配合flashback实现主备任意切换(failover和switchover)
有客户使用本地和公有云通过vpn搭建数据库容灾,其中有一个需求,当本地环境出现问题云端容灾库接管业务,当本地环境恢复之后,本地继续做为主库,云端作为备库.我这里使用oracle dataguard结合flashback模拟实现客户需求(也可以在failover之后通过重新搭建dg实现类似需求,具体需要看客户的实际场景:数据量,带宽,恢复时间,技术能力等)
正常dg同步的主备环境
这里ora11g主机是主库,ora10g主机是备库
--数据库版本 SQL> select * from v$version; BANNER -------------------------------------------------------------------------------- Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production PL/SQL Release 11.2.0.4.0 - Production CORE 11.2.0.4.0 Production TNS for Linux: Version 11.2.0.4.0 - Production NLSRTL Version 11.2.0.4.0 - Production ---主库(ora11g) SQL> select open_mode,database_role,(select HOST_NAME from v$instance) HOST_NAME,flashback_on from v$database; OPEN_MODE DATABASE_ROLE HOST_NAME FLASHBACK_ ------------------------------ ------------------------------ ------------------------------ ---------- READ WRITE PRIMARY ora11g YES SQL> create table xff.t_xifenfei as select * from dba_objects; Table created. SQL> select count(*) from xff.t_xifenfei; COUNT(*) ---------- 86348 ---备库(ora10g) SQL> select open_mode,database_role,(select HOST_NAME from v$instance) HOST_NAME,flashback_on from v$database; OPEN_MODE DATABASE_ROLE HOST_NAME FLASHBACK_ ------------------------------ ------------------------------ ------------------------------ ---------- READ ONLY WITH APPLY PHYSICAL STANDBY ora10g YES SQL> select count(*) from xff.t_xifenfei; COUNT(*) ---------- 86348
模拟主库(ora11g)故障,直接激活备库(ora10g)
模拟dg备库(ora10g)直接failover操作
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL; Database altered. SQL> ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE; Database altered.
Sat Mar 24 16:05:40 2017 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL MRP0: Background Media Recovery cancelled with status 16037 Errors in file /u01/app/oracle/diag/rdbms/ora11g/ora11g/trace/ora11g_pr00_13428.trc: ORA-16037: user requested cancel of managed recovery operation Managed Standby Recovery not using Real Time Apply Recovery interrupted! Recovered data files to a consistent state at change 1470499 Sat Mar 24 16:05:40 2017 MRP0: Background Media Recovery process shutdown (ora11g) Managed Standby Recovery Canceled (ora11g) Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL Sat Mar 24 16:05:50 2017 ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE ALTER DATABASE ACTIVATE [PHYSICAL] STANDBY DATABASE (ora11g) All dispatchers and shared servers shutdown CLOSE: killing server sessions. CLOSE: all sessions shutdown successfully. Sat Mar 24 16:05:50 2017 SMON: disabling cache recovery Killing 3 processes with pids 13372,13393,13388 (all RFS) in order to disallow current and future RFS connections. Requested by OS process 13350 Begin: Standby Redo Logfile archival End: Standby Redo Logfile archival RESETLOGS after incomplete recovery UNTIL CHANGE 1470499 Archived Log entry 9 added for thread 1 sequence 14 ID 0xfd5a5fc1 dest 1: Resetting resetlogs activation ID 4250558401 (0xfd5a5fc1) Online log /u01/app/oracle/oradata/ora11g/redo01.log: Thread 1 Group 1 was previously cleared Online log /u01/app/oracle/oradata/ora11g/redo02.log: Thread 1 Group 2 was previously cleared Online log /u01/app/oracle/oradata/ora11g/redo03.log: Thread 1 Group 3 was previously cleared Standby became primary SCN: 1470497 Sat Mar 24 16:05:52 2017 Setting recovery target incarnation to 4 ACTIVATE STANDBY: Complete - Database mounted as primary Completed: ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE
模拟新主库(ora10g)业务操作
SQL> select open_mode,database_role,(select HOST_NAME from v$instance) HOST_NAME,flashback_on from v$database; OPEN_MODE DATABASE_ROLE HOST_NAME FLASHBACK_ ------------------------------ ------------------------------ ------------------------------ ---------- MOUNTED PRIMARY ora10g YES SQL> alter database open; Database altered. SQL> select open_mode,database_role,(select HOST_NAME from v$instance) HOST_NAME,flashback_on from v$database; OPEN_MODE DATABASE_ROLE HOST_NAME FLASHBACK_ ------------------------------ ------------------------------ ------------------------------ ---------- READ WRITE PRIMARY ora10g YES SQL> alter system switch logfile; System altered. SQL> / System altered. SQL> / / System altered. SQL> System altered. SQL> SQL> archive log list; Database log mode Archive Mode Automatic archival Enabled Archive destination USE_DB_RECOVERY_FILE_DEST Oldest online log sequence 5 Next log sequence to archive 7 Current log sequence 7 SQL> delete from xff.t_xifenfei; 86348 rows deleted. SQL> commit; Commit complete. SQL> select count(*) from xff.t_xifenfei; COUNT(*) ---------- 0
原主库(ora11g)配置为新备库
---原主库(ora10g) SQL> shutdown immediate; Database closed. Database dismounted. ORACLE instance shut down. SQL> startup mount ORACLE instance started. Total System Global Area 3056513024 bytes Fixed Size 2257152 bytes Variable Size 704646912 bytes Database Buffers 2332033024 bytes Redo Buffers 17575936 bytes Database mounted. SQL> Flashback database to scn 1470490; Flashback complete. SQL> select open_mode,database_role,(select HOST_NAME from v$instance) HOST_NAME,flashback_on from v$database; OPEN_MODE DATABASE_ROLE HOST_NAME FLASHBACK_ ------------------------------ ------------------------------ ------------------------------ ---------- MOUNTED PRIMARY ora11g YES --现在主库(ora10g) SQL> alter database create standby controlfile as '/tmp/ctl.3'; Database altered. [oracle@ora10g ~]$ scp /tmp/ctl.3 192.168.222.11:/u01/app/oracle/oradata/ora11g/control01.ctl oracle@192.168.222.11's password: ctl.3 ---也可以直接在老主库上执行ALTER DATABASE CONVERT TO PHYSICAL STANDBY; 转换为standby 角色,然后直接启动同步 --现在备库(ora11g) SQL> shutdown abort ORACLE instance shut down. SQL> startup mount ORACLE instance started. Total System Global Area 3056513024 bytes Fixed Size 2257152 bytes Variable Size 704646912 bytes Database Buffers 2332033024 bytes Redo Buffers 17575936 bytes Database mounted. SQL> col open_mode for a30 SQL> col database_role for a30 SQL> col HOST_NAME for a30 SQL> col flashback_on for a10 SQL> set lines 150 SQL> select open_mode,database_role,(select HOST_NAME from v$instance) HOST_NAME,flashback_on from v$database; OPEN_MODE DATABASE_ROLE HOST_NAME FLASHBACK_ ------------------------------ ------------------------------ ------------------------------ ---------- MOUNTED PHYSICAL STANDBY ora11g NO SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION; Database altered.
Sat Mar 24 16:10:09 2017 ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION Attempt to start background Managed Standby Recovery process (ora11g) Sat Mar 24 16:10:09 2017 MRP0 started with pid=27, OS id=27086 MRP0: Background Managed Standby Recovery process started (ora11g) started logmerger process Sat Mar 24 16:10:14 2017 Managed Standby Recovery starting Real Time Apply Parallel Media Recovery started with 4 slaves Media Recovery start incarnation depth : 1, target inc# : 4, irscn : 1470499 Waiting for all non-current ORLs to be archived... All non-current ORLs have been archived. Clearing online redo logfile 1 /u01/app/oracle/oradata/ora11g/redo01.log Clearing online log 1 of thread 1 sequence number 7 Clearing online redo logfile 1 complete Clearing online redo logfile 2 /u01/app/oracle/oradata/ora11g/redo02.log Clearing online log 2 of thread 1 sequence number 8 Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION Clearing online redo logfile 2 complete Clearing online redo logfile 3 /u01/app/oracle/oradata/ora11g/redo03.log Clearing online log 3 of thread 1 sequence number 9 Clearing online redo logfile 3 complete Media Recovery Waiting for thread 1 sequence 13 branch(resetlogs_id) 854379205 Sat Mar 24 16:10:16 2017 RFS[3]: Assigned to RFS process 27098 RFS[3]: Opened log for thread 1 sequence 13 dbid 48871109 branch 854379205 Archived Log entry 2 added for thread 1 sequence 13 rlc 854379205 ID 0xfd5a5fc1 dest 2: Sat Mar 24 16:10:16 2017 RFS[4]: Assigned to RFS process 27100 RFS[4]: Opened log for thread 1 sequence 14 dbid 48871109 branch 854379205 Archived Log entry 3 added for thread 1 sequence 14 rlc 854379205 ID 0xfd5a5fc1 dest 2: RFS[3]: Opened log for thread 1 sequence 1 dbid 48871109 branch 947798452 RFS[4]: Opened log for thread 1 sequence 3 dbid 48871109 branch 947798452 Sat Mar 24 16:10:16 2017 RFS[5]: Assigned to RFS process 27070 RFS[5]: Opened log for thread 1 sequence 2 dbid 48871109 branch 947798452 Archived Log entry 4 added for thread 1 sequence 1 rlc 947798452 ID 0x2ec1ed0 dest 2: Archived Log entry 5 added for thread 1 sequence 3 rlc 947798452 ID 0x2ec1ed0 dest 2: RFS[3]: Opened log for thread 1 sequence 4 dbid 48871109 branch 947798452 RFS[4]: Opened log for thread 1 sequence 5 dbid 48871109 branch 947798452 Archived Log entry 6 added for thread 1 sequence 5 rlc 947798452 ID 0x2ec1ed0 dest 2: Archived Log entry 7 added for thread 1 sequence 4 rlc 947798452 ID 0x2ec1ed0 dest 2: Archived Log entry 8 added for thread 1 sequence 2 rlc 947798452 ID 0x2ec1ed0 dest 2: RFS[4]: Opened log for thread 1 sequence 6 dbid 48871109 branch 947798452 Archived Log entry 9 added for thread 1 sequence 6 rlc 947798452 ID 0x2ec1ed0 dest 2: RFS[3]: Opened log for thread 1 sequence 7 dbid 48871109 branch 947798452 Archived Log entry 10 added for thread 1 sequence 7 rlc 947798452 ID 0x2ec1ed0 dest 2: Media Recovery Log /u01/app/oracle/fast_recovery_area/ORA11GDG/archivelog/2017_03_24/o1_mf_1_13_9xmyh8cs_.arc Media Recovery Log /u01/app/oracle/fast_recovery_area/ORA11GDG/archivelog/2017_03_24/o1_mf_1_14_9xmyh8dr_.arc Media Recovery Log /u01/app/oracle/fast_recovery_area/ORA11GDG/archivelog/2017_03_24/o1_mf_1_1_9xmyh8fk_.arc Media Recovery Log /u01/app/oracle/fast_recovery_area/ORA11GDG/archivelog/2017_03_24/o1_mf_1_2_9xmyh8fo_.arc Media Recovery Log /u01/app/oracle/fast_recovery_area/ORA11GDG/archivelog/2017_03_24/o1_mf_1_3_9xmyh8fm_.arc Media Recovery Log /u01/app/oracle/fast_recovery_area/ORA11GDG/archivelog/2017_03_24/o1_mf_1_4_9xmyh8g3_.arc Media Recovery Log /u01/app/oracle/fast_recovery_area/ORA11GDG/archivelog/2017_03_24/o1_mf_1_5_9xmyh8g4_.arc Media Recovery Log /u01/app/oracle/fast_recovery_area/ORA11GDG/archivelog/2017_03_24/o1_mf_1_6_9xmyh8gs_.arc Media Recovery Log /u01/app/oracle/fast_recovery_area/ORA11GDG/archivelog/2017_03_24/o1_mf_1_7_9xmyh8hl_.arc Media Recovery Log /u01/app/oracle/fast_recovery_area/ORA11GDG/archivelog/2017_03_24/o1_mf_1_8_9xmy5d3f_.arc Media Recovery Waiting for thread 1 sequence 9 (in transit) Recovery of Online Redo Log: Thread 1 Group 4 Seq 9 Reading mem 0 Mem# 0: /u01/app/oracle/oradata/ora11g/std_redo10.log
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE cancel; Database altered. SQL> alter database open; Database altered. SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION; Database altered. SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE cancel; Database altered. SQL> alter database flashback on; Database altered. SQL> select open_mode,database_role,(select HOST_NAME from v$instance) HOST_NAME,flashback_on from v$database; OPEN_MODE DATABASE_ROLE HOST_NAME FLASHBACK_ ------------------------------ ------------------------------ ------------------------------ ---------- READ ONLY PHYSICAL STANDBY ora11g YES SQL> select count(*) from xff.t_xifenfei; COUNT(*) ---------- 0 --现在主库 SQL> drop table xff.t_xifenfei ; Table dropped. SQL> select count(*) from xff.t_xifenfei; select count(*) from xff.t_xifenfei * ERROR at line 1: ORA-00942: table or view does not exist --现在备库 SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION; Database altered. SQL> select open_mode,database_role,(select HOST_NAME from v$instance) HOST_NAME,flashback_on from v$database; OPEN_MODE DATABASE_ROLE HOST_NAME FLASHBACK_ ------------------------------ ------------------------------ ------------------------------ ---------- READ ONLY WITH APPLY PHYSICAL STANDBY ora11g YES SQL> select count(*) from xff.t_xifenfei; select count(*) from xff.t_xifenfei * ERROR at line 1: ORA-00942: table or view does not exist
通过上述一系列操作,以前假设故障的主库,现在变成了被failover激活的主库的备库,也就是说数据库主备关系由ora11g主库—>ora10g备库变成了ora10g主库—>ora11g备库
switchover实现主备库互换
---现在主库(ora10g) SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO STANDBY WITH SESSION SHUTDOWN; Database altered. --现在备库(ora11g) SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN; Database altered. SQL> select open_mode,database_role,(select HOST_NAME from v$instance) HOST_NAME,flashback_on from v$database; OPEN_MODE DATABASE_ROLE HOST_NAME FLASHBACK_ ------------------------------ ------------------------------ ------------------------------ ---------- MOUNTED PRIMARY ora11g YES SQL> alter database open; Database altered. SQL> select open_mode,database_role,(select HOST_NAME from v$instance) HOST_NAME,flashback_on from v$database; OPEN_MODE DATABASE_ROLE HOST_NAME FLASHBACK_ ------------------------------ ------------------------------ ------------------------------ ---------- READ WRITE PRIMARY ora11g YES --最新备库(ora10g) SQL> startup ORACLE instance started. Total System Global Area 3056513024 bytes Fixed Size 2257152 bytes Variable Size 687869696 bytes Database Buffers 2348810240 bytes Redo Buffers 17575936 bytes Database mounted. Database opened. SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION; Database altered. SQL> select open_mode,database_role,(select HOST_NAME from v$instance) HOST_NAME,flashback_on from v$database; OPEN_MODE DATABASE_ROLE HOST_NAME FLASHBACK_ ------------------------------ ------------------------------ ------------------------------ ---------- READ ONLY WITH APPLY PHYSICAL STANDBY ora10g YES --最新主库(ora11g) SQL> alter system switch logfile; System altered. SQL> create table t_xifenfei as select * from dba_objects; Table created. SQL> select count(*) from t_xifenfei; COUNT(*) ---------- 86347 --最新备库(ora10g) SQL> select count(*) from t_xifenfei; COUNT(*) ---------- 86347
通过switchover主备库再次互换由ora10g主库—>ora11g备库变成了ora11g主库—>ora10g备库,再次恢复到最初的状态.这个不是唯一的方法,可以通过重建dg,也能够实现类似需求.
比特币加密勒索间隔加密
最近我们在一个客户的oracle恢复case中发现比特币文件系统勒索加密比较特殊,和大家做一个分享
文件加密后缀名为:.$ILICONE
文件加密特点分析
DUL> dump datafile 5 block 1 Block Header: block type=0x0b (file header) block format=0xa2 (oracle 10) block rdba=0x01400001 (file#=5, block#=1) scn=0x0000.00000000, seq=1, tail=0x00000b01 block checksum value=0x6e7d=28285, flag=4 File Header: Db Id=0xe1891cca=3783859402, Db Name=XIFENFEI, Root Dba=0x0 Software vsn=0x0, Compatibility Vsn=0xa200300, File Size=0x3ffffe=4194302 Blocks File Type=0x3 (data file), File Number=5, Block Size=8192 Tablespace #7 - OA rel_fn:5 DUL> dump datafile 5 block 2 Block Header: block type=0x63 (unknown) block format=0x57 (unknown) block rdba=0xc6538298 (file#=793, block#=1278616) scn=0xe0ab.fdc4d8d0, seq=225, tail=0xa7b5cab5 block checksum value=0xfaa1=64161, flag=165 corrupted block. DUL> dump datafile 5 block 3 Block Header: block type=0x1e (LMT space map block) block format=0xa2 (oracle 10) block rdba=0x01400003 (file#=5, block#=3) scn=0x0000.00246fbe, seq=1, tail=0x6fbe1e01 block checksum value=0xe495=58517, flag=4 DUL> dump datafile 5 block 4 Block Header: block type=0x83 (unknown) block format=0xa3 (unknown) block rdba=0x17e4c9e4 (file#=95, block#=2410980) scn=0xe3b2.fc505eea, seq=101, tail=0x6e2f1004 block checksum value=0x7f2e=32558, flag=196 corrupted block. DUL> dump datafile 5 block 5 Block Header: block type=0x1e (LMT space map block) block format=0xa2 (oracle 10) block rdba=0x01400005 (file#=5, block#=5) scn=0x0000.00264875, seq=1, tail=0x48751e01 block checksum value=0xb25e=45662, flag=4 DUL> dump datafile 5 block 6 Block Header: block type=0x68 (unknown) block format=0x35 (unknown) block rdba=0x7011e0e3 (file#=448, block#=1171683) scn=0x47bf.9f2df54a, seq=207, tail=0x69ae0a91 block checksum value=0x49f8=18936, flag=174 corrupted block.
通过这里初步分析,确认加密是间隔方式加密,在数据库中表现明显的是每相隔8k进行加密,而且这里是偶数block被加密
确认加密文件结束位置
DUL> dump datafile 5 block 962818 header Block Header: block type=0x4d (unknown) block format=0xde (unknown) block rdba=0x0bab780d (file#=46, block#=2848781) scn=0x056b.2c695f6b, seq=223, tail=0x2399e0cb block checksum value=0x9706=38662, flag=212 corrupted block. DUL> dump datafile 5 block 962820 header Block Header: block type=0x00 (blank block) block format=0xa2 (oracle 10) block rdba=0x014eb104 (file#=5, block#=962820) scn=0x0000.00000000, seq=1, tail=0x00000001 block checksum value=0x174a=5962, flag=5
通过这里可以发现,对于一个32G的文件,一直被加密到block 962818,也就是7.34G(962818*8k),这里间隔加密,而且加密深度特别深,在以往的比特币文件系统加密中比较少见.
再次提醒
1. 不要把数据库暴露在外网
2. 相对linux而言,win更容易受到黑客的攻击
3. 数据库一定要做好备份,条件允许的情况下,配置数据实时同步到其他机器还是有必要的