- 浏览: 4410873 次
- 性别:
- 来自: 厦门
-
文章分类
- 全部博客 (634)
- Oracle日常管理 (142)
- Oracle体系架构 (45)
- Oracle Tuning (52)
- Oracle故障诊断 (35)
- RAC/DG/OGG (64)
- Oracle11g New Features (48)
- DataWarehouse (15)
- SQL, PL/SQL (14)
- DB2日常管理 (9)
- Weblogic (11)
- Shell (19)
- AIX (12)
- Linux/Unix高可用性 (11)
- Linux/Unix日常管理 (66)
- Linux桌面应用 (37)
- Windows (2)
- 生活和工作 (13)
- 私人记事 (0)
- Python (9)
- CBO (15)
- Cognos (2)
- ORACLE 12c New Feature (2)
- PL/SQL (2)
- SQL (1)
- C++ (2)
- Hadoop大数据 (5)
- 机器学习 (3)
- 非技术 (1)
最新评论
-
di1984HIT：
xuexilee!!!
Oracle 11g R2 RAC高可用连接特性 – SCAN详解 -
aneyes123：
谢谢非常有用那
PL/SQL的存储过程和函数(原创) -
jcjcjc：
写的很详细
Oracle中Hint深入理解(原创) -
di1984HIT：
学习了，学习了
Linux NTP配置详解 (Network Time Protocol) -
avalonzst：
大写的赞..
AIX内存概述(原创)
中午刚去吃饭，就接到同事电话说急着要恢复生产库上的归档日志。系统环境是10.2.0.5，RAC，归档日志在node1上建立了nfs共享，而node2上没有建立nfs共享。另有一套查询库，通过DSG的同步软件将数据从生产库上同步到查询库上。软件原理是通过传说分析归档日志然后加以应用，总体感觉有点像DG。由于生产库上使用的是增量备份，每天都进行备份。且备份完后会自动删除归档日志。恢复生产库的归档日志的原因是，同步到查询库时失败(采用DSG的备份软件时，当遇到大量DML操作时经常遇到同步失败的情况)，需要重新同步，但归档日志已经被删除，故需要还原归档日志。查询库昨日17:00后的数据同步失败，故需要还原从昨日至今的归档日志。系统环境交代到这，下面是具体的实施步骤。
在node1上进行操作
$ pwd
/arch_log/restore
root@fjlt_zgsc_db01:/#mount
node mounted mounted over vfs date options
-------- --------------- --------------- ------ ------------ ---------------
/dev/hd4 / jfs2 Apr 21 19:42 rw,log=/dev/hd8
/dev/hd2 /usr jfs2 Apr 21 19:42 rw,log=/dev/hd8
/dev/hd9var /var jfs2 Apr 21 19:42 rw,log=/dev/hd8
/dev/hd3 /tmp jfs2 Apr 21 19:42 rw,log=/dev/hd8
/dev/hd1 /home jfs2 Apr 21 19:43 rw,log=/dev/hd8
/dev/hd11admin /admin jfs2 Apr 21 19:43 rw,log=/dev/hd8
/proc /proc procfs Apr 21 19:43 rw
/dev/hd10opt /opt jfs2 Apr 21 19:43 rw,log=/dev/hd8
/dev/livedump /var/adm/ras/livedump jfs2 Apr 21 19:43 rw,log=/dev/hd8
/dev/lv_oracle10g /oracle10g jfs2 Apr 21 19:43 rw,log=/dev/hd8
/dev/lv_zs_arch_01 /arch_log jfs2 Apr 21 19:43 rw,log=/dev/loglv01
/dev/lv_zs_db2bk_01 /rman_db2_bk jfs2 Apr 21 19:43 rw,log=/dev/loglv01
/dev/lv_zs_bck_01 /rman_data jfs2 Apr 21 19:43 rw,log=/dev/loglv00
/dev/lv_cdump /oracle10g/app/oracle/admin/zgscdb/cdump jfs2 Nov 16 12:05 rw,log=/dev/loglv02
/dev/lv_dsg1 /dsg1 jfs2 Nov 16 12:10 rw,log=/dev/loglv02
fjlt_zgsc_db02 /arch_log/zgsc_db02_arch /arch_log/zgsc_db02_arch nfs3 Jan 16 16:26
$ df -g
Filesystem GB blocks Free %Used Iused %Iused Mounted on
/dev/hd4 10.00 9.56 5% 12767 1% /
/dev/hd2 10.00 6.75 33% 62385 4% /usr
/dev/hd9var 10.00 9.23 8% 13956 1% /var
/dev/hd3 10.00 9.09 10% 3512 1% /tmp
/dev/hd1 10.00 8.99 11% 8013 1% /home
/dev/hd11admin 0.25 0.25 1% 5 1% /admin
/proc - - - - - /proc
/dev/hd10opt 10.00 9.73 3% 10356 1% /opt
/dev/livedump 0.25 0.25 1% 8 1% /var/adm/ras/livedump
/dev/lv_oracle10g 30.00 11.84 61% 215252 7% /oracle10g
/dev/lv_zs_arch_01 997.00 989.75 1% 32 1% /arch_log
/dev/lv_zs_db2bk_01 998.00 432.63 57% 167 1% /rman_db2_bk
/dev/lv_zs_bck_01 2992.00 1836.57 39% 224 1% /rman_data
/dev/lv_cdump 200.00 199.97 1% 15 1% /oracle10g/app/oracle/admin/zgscdb/cdump
/dev/lv_dsg1 49.75 43.97 12% 8831 1% /dsg1
fjlt_zgsc_db02:/arch_log/zgsc_db02_arch 997.00 971.00 3% 34 1% /arch_log/zgsc_db02_arch
/arch_log挂载点下空余空间接近1T，目标将归档日志还原到/arch_log/restore下
第一反应，通过v$archived_log找到17:00以后的归档日志序列号
select sequence#,completion_time from v$archived_log where completion_time > to_date('2012-02-15','hh24:mi:ss');
查询得出从sequence#为16147开始的归档日志为2012-02-17 17:00以后的归档日志
执行
$ rman target /
Recovery Manager: Release 10.2.0.5.0 - Production on Thu Feb 16 13:07:12 2012
Copyright (c) 1982, 2007, Oracle. All rights reserved.
connected to target database: ZGSCDB (DBID=3629726729)
RMAN> run{
2> allocate channel c1 type disk;
3> allocate channel c2 type disk;
4> allocate channel c3 type disk;
5> allocate channel c4 type disk;
6> set archivelog destination to '/arch_log/restore';
7> restore archivelog from logseq 16147;
8> release channel c1 ;ype disk
9> release channel c2;
10> release channel c3;
11> release channel c4;
12> }
using target database control file instead of recovery catalog
allocated channel: c1
channel c1: sid=4834 instance=zgscdb1 devtype=DISK
allocated channel: c2
channel c2: sid=5333 instance=zgscdb1 devtype=DISK
allocated channel: c3
channel c3: sid=4879 instance=zgscdb1 devtype=DISK
allocated channel: c4
channel c4: sid=5317 instance=zgscdb1 devtype=DISK
executing command: SET ARCHIVELOG DESTINATION
Starting restore at 16-FEB-12
released channel: c1
released channel: c2
released channel: c3
released channel: c4
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 02/16/2012 13:10:53
RMAN-20242: specification does not match any archive log in the recovery catalog
RMAN> list archivelog from logseq 16147;
没有任何输出，郁闷。。。。。。。。。
RMAN> list backup of archivelog all;
List of Backup Sets
===================
BS Key Size Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
5115 169.62M DISK 00:00:09 12-FEB-12
BP Key: 12219 Status: AVAILABLE Compressed: NO Tag: TAG20120212T014331
Piece Name: /rman_data/zgscdb_rman/ZGSCDB_arch_20120212_0tn33hqa_s5149_p1_C1
List of Archived Logs in backup set 5115
Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- --------- ---------- ---------
1 13769 12663219622525 11-FEB-12 12663220068092 11-FEB-12
1 13770 12663220068092 11-FEB-12 12663220426071 11-FEB-12
1 13771 12663220426071 11-FEB-12 12663220887716 11-FEB-12
1 13772 12663220887716 11-FEB-12 12663222831310 12-FEB-12
省略部分输出
List of Archived Logs in backup set 5197
Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- --------- ---------- ---------
2 16176 12670019198216 15-FEB-12 12670023192712 15-FEB-12
2 16177 12670023192712 15-FEB-12 12670025565356 16-FEB-12
2 16178 12670025565356 16-FEB-12 12670026143737 16-FEB-12
2 16179 12670026143737 16-FEB-12 12670026897385 16-FEB-12
2 16180 12670026897385 16-FEB-12 12670027305649 16-FEB-12
2 16181 12670027305649 16-FEB-12 12670027693987 16-FEB-12
BS Key Size Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
5198 13.00G DISK 00:01:07 16-FEB-12
List of Archived Logs in backup set 5193
Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- --------- ---------- ---------
2 16148 12670010177819 15-FEB-12 12670011207570 15-FEB-12
2 16149 12670011207570 15-FEB-12 12670012283915 15-FEB-12
2 16150 12670012283915 15-FEB-12 12670012754302 15-FEB-12
2 16151 12670012754302 15-FEB-12 12670012969887 15-FEB-12
2 16152 12670012969887 15-FEB-12 12670013212670 15-FEB-12
2 16153 12670013212670 15-FEB-12 12670013780868 15-FEB-12
2 16154 12670013780868 15-FEB-12 12670013976009 15-FEB-12
2 16155 12670013976009 15-FEB-12 12670015183858 15-FEB-12
2 16156 12670015183858 15-FEB-12 12670015441965 15-FEB-12
2 16157 12670015441965 15-FEB-12 12670015599451 15-FEB-12
2 16158 12670015599451 15-FEB-12 12670015722094 15-FEB-12
2 16159 12670015722094 15-FEB-12 12670015785593 15-FEB-12
2 16160 12670015785593 15-FEB-12 12670015847887 15-FEB-12
2 16161 12670015847887 15-FEB-12 12670016000750 15-FEB-12
Backup Set Copy #1 of backup set 5193
Device Type Elapsed Time Completion Time Compressed Tag
----------- ------------ --------------- ---------- ---
DISK 00:03:55 16-FEB-12 NO TAG20120216T010430
List of Backup Pieces for backup set 5193 Copy #1
BP Key Pc# Status Piece Name
------- --- ----------- ----------
12560 1 AVAILABLE /rman_data/zgscdb_rman/ZGSCDB_arch_20120216_39n3e111_s5225_p1_C1
12561 2 AVAILABLE /rman_data/zgscdb_rman/ZGSCDB_arch_20120216_39n3e111_s5225_p2_C1
12562 3 AVAILABLE /rman_data/zgscdb_rman/ZGSCDB_arch_20120216_39n3e111_s5225_p3_C1
List of Archived Logs in backup set 5198
Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- --------- ---------- ---------
2 16134 12668052207072 15-FEB-12 12668052339209 15-FEB-12
2 16135 12668052339209 15-FEB-12 12668052456743 15-FEB-12
2 16136 12668052456743 15-FEB-12 12668052579080 15-FEB-12
2 16137 12668052579080 15-FEB-12 12668052695760 15-FEB-12
2 16138 12668052695760 15-FEB-12 12668056672468 15-FEB-12
2 16139 12668056672468 15-FEB-12 12668060445745 15-FEB-12
2 16140 12668060445745 15-FEB-12 12668062444755 15-FEB-12
2 16141 12668062444755 15-FEB-12 12668660576479 15-FEB-12
2 16142 12668660576479 15-FEB-12 12668660718987 15-FEB-12
2 16143 12668660718987 15-FEB-12 12668660871830 15-FEB-12
2 16144 12668660871830 15-FEB-12 12668661303733 15-FEB-12
2 16145 12668661303733 15-FEB-12 12668661585953 15-FEB-12
2 16146 12668661585953 15-FEB-12 12668662079217 15-FEB-12
2 16147 12668662079217 15-FEB-12 12670010177819 15-FEB-12
Backup Set Copy #1 of backup set 5198
Device Type Elapsed Time Completion Time Compressed Tag
----------- ------------ --------------- ---------- ---
DISK 00:01:07 16-FEB-12 NO TAG20120216T010430
List of Backup Pieces for backup set 5198 Copy #1
BP Key Pc# Status Piece Name
------- --- ----------- ----------
12573 1 AVAILABLE /rman_data/zgscdb_rman/ZGSCDB_arch_20120216_3an3e18j_s5226_p1_C1
12574 2 AVAILABLE /rman_data/zgscdb_rman/ZGSCDB_arch_20120216_3an3e18j_s5226_p2_C1
12575 3 AVAILABLE /rman_data/zgscdb_rman/ZGSCDB_arch_20120216_3an3e18j_s5226_p3_C1
List of Archived Logs in backup set 5195
Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- --------- ---------- ---------
2 16162 12670016000750 15-FEB-12 12670016088204 15-FEB-12
2 16163 12670016088204 15-FEB-12 12670016308969 15-FEB-12
2 16164 12670016308969 15-FEB-12 12670016653192 15-FEB-12
2 16165 12670016653192 15-FEB-12 12670017027396 15-FEB-12
2 16166 12670017027396 15-FEB-12 12670017225549 15-FEB-12
2 16167 12670017225549 15-FEB-12 12670017317060 15-FEB-12
2 16168 12670017317060 15-FEB-12 12670017393441 15-FEB-12
2 16169 12670017393441 15-FEB-12 12670017462567 15-FEB-12
2 16170 12670017462567 15-FEB-12 12670017541021 15-FEB-12
2 16171 12670017541021 15-FEB-12 12670017654244 15-FEB-12
2 16172 12670017654244 15-FEB-12 12670017735163 15-FEB-12
2 16173 12670017735163 15-FEB-12 12670017811611 15-FEB-12
2 16174 12670017811611 15-FEB-12 12670017888323 15-FEB-12
2 16175 12670017888323 15-FEB-12 12670019198216 15-FEB-12
Backup Set Copy #1 of backup set 5195
Device Type Elapsed Time Completion Time Compressed Tag
----------- ------------ --------------- ---------- ---
DISK 00:03:56 16-FEB-12 NO TAG20120216T010430
List of Backup Pieces for backup set 5195 Copy #1
BP Key Pc# Status Piece Name
------- --- ----------- ----------
12566 1 AVAILABLE /rman_data/zgscdb_rman/ZGSCDB_arch_20120216_38n3e111_s5224_p1_C1
12567 2 AVAILABLE /rman_data/zgscdb_rman/ZGSCDB_arch_20120216_38n3e111_s5224_p2_C1
12568 3 AVAILABLE /rman_data/zgscdb_rman/ZGSCDB_arch_20120216_38n3e111_s5224_p3_C1
可以看到从日志序列号为16147到16181的归档日志备份全部存。那为什么执行list backup of archivelog from logseq 16147;时没有输出呢？
查了下rman的list语法，执行如下命令
RMAN>list backup of archivelog from time "to_date('2012-02-15 17:00:00','yyyy-mm-dd hh24:mi:ss')";
List of Backup Sets
===================
BS Key Size Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
5189 287.12M DISK 00:00:04 16-FEB-12
BP Key: 12552 Status: AVAILABLE Compressed: NO Tag: TAG20120216T010430
Piece Name: /rman_data/zgscdb_rman/ZGSCDB_arch_20120216_37n3e111_s5223_p1_C1
List of Archived Logs in backup set 5189
Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- --------- ---------- ---------
1 14153 12670027303388 16-FEB-12 12670027694268 16-FEB-12
BS Key Size Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
5190 9.98G DISK 00:02:45 16-FEB-12
List of Archived Logs in backup set 5190
Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- --------- ---------- ---------
1 14131 12668662080221 15-FEB-12 12670012207947 15-FEB-12
1 14132 12670012207947 15-FEB-12 12670012971251 15-FEB-12
1 14133 12670012971251 15-FEB-12 12670013978444 15-FEB-12
1 14134 12670013978444 15-FEB-12 12670015440149 15-FEB-12
1 14135 12670015440149 15-FEB-12 12670015722540 15-FEB-12
1 14136 12670015722540 15-FEB-12 12670016001416 15-FEB-12
Backup Set Copy #1 of backup set 5190
Device Type Elapsed Time Completion Time Compressed Tag
----------- ------------ --------------- ---------- ---
DISK 00:02:45 16-FEB-12 NO TAG20120216T010430
List of Backup Pieces for backup set 5190 Copy #1
BP Key Pc# Status Piece Name
------- --- ----------- ----------
12553 1 AVAILABLE /rman_data/zgscdb_rman/ZGSCDB_arch_20120216_35n3e111_s5221_p1_C1
12554 2 AVAILABLE /rman_data/zgscdb_rman/ZGSCDB_arch_20120216_35n3e111_s5221_p2_C1
BS Key Size Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
5192 12.30G DISK 00:03:09 16-FEB-12
List of Archived Logs in backup set 5192
Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- --------- ---------- ---------
1 14137 12670016001416 15-FEB-12 12670016653312 15-FEB-12
1 14138 12670016653312 15-FEB-12 12670017030219 15-FEB-12
1 14139 12670017030219 15-FEB-12 12670017394454 15-FEB-12
1 14140 12670017394454 15-FEB-12 12670017657280 15-FEB-12
1 14141 12670017657280 15-FEB-12 12670017890908 15-FEB-12
1 14142 12670017890908 15-FEB-12 12670018260012 15-FEB-12
1 14143 12670018260012 15-FEB-12 12670020257257 15-FEB-12
1 14144 12670020257257 15-FEB-12 12670022421290 15-FEB-12
1 14145 12670022421290 15-FEB-12 12670023190650 15-FEB-12
1 14146 12670023190650 15-FEB-12 12670024544870 15-FEB-12
1 14147 12670024544870 15-FEB-12 12670026609312 16-FEB-12
1 14148 12670026609312 16-FEB-12 12670026743414 16-FEB-12
1 14149 12670026743414 16-FEB-12 12670026894479 16-FEB-12
1 14150 12670026894479 16-FEB-12 12670027048502 16-FEB-12
1 14151 12670027048502 16-FEB-12 12670027176883 16-FEB-12
1 14152 12670027176883 16-FEB-12 12670027303388 16-FEB-12
Backup Set Copy #1 of backup set 5192
Device Type Elapsed Time Completion Time Compressed Tag
----------- ------------ --------------- ---------- ---
DISK 00:03:09 16-FEB-12 NO TAG20120216T010430
List of Backup Pieces for backup set 5192 Copy #1
BP Key Pc# Status Piece Name
------- --- ----------- ----------
12557 1 AVAILABLE /rman_data/zgscdb_rman/ZGSCDB_arch_20120216_32n3e111_s5218_p1_C1
12558 2 AVAILABLE /rman_data/zgscdb_rman/ZGSCDB_arch_20120216_32n3e111_s5218_p2_C1
12559 3 AVAILABLE /rman_data/zgscdb_rman/ZGSCDB_arch_20120216_32n3e111_s5218_p3_C1
BS Key Size Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
5193 13.27G DISK 00:03:55 16-FEB-12
List of Archived Logs in backup set 5193
Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- --------- ---------- ---------
2 16148 12670010177819 15-FEB-12 12670011207570 15-FEB-12
2 16149 12670011207570 15-FEB-12 12670012283915 15-FEB-12
2 16150 12670012283915 15-FEB-12 12670012754302 15-FEB-12
2 16151 12670012754302 15-FEB-12 12670012969887 15-FEB-12
2 16152 12670012969887 15-FEB-12 12670013212670 15-FEB-12
2 16153 12670013212670 15-FEB-12 12670013780868 15-FEB-12
2 16154 12670013780868 15-FEB-12 12670013976009 15-FEB-12
2 16155 12670013976009 15-FEB-12 12670015183858 15-FEB-12
2 16156 12670015183858 15-FEB-12 12670015441965 15-FEB-12
2 16157 12670015441965 15-FEB-12 12670015599451 15-FEB-12
2 16158 12670015599451 15-FEB-12 12670015722094 15-FEB-12
2 16159 12670015722094 15-FEB-12 12670015785593 15-FEB-12
2 16160 12670015785593 15-FEB-12 12670015847887 15-FEB-12
2 16161 12670015847887 15-FEB-12 12670016000750 15-FEB-12
Backup Set Copy #1 of backup set 5193
Device Type Elapsed Time Completion Time Compressed Tag
----------- ------------ --------------- ---------- ---
DISK 00:03:55 16-FEB-12 NO TAG20120216T010430
List of Backup Pieces for backup set 5193 Copy #1
BP Key Pc# Status Piece Name
------- --- ----------- ----------
12560 1 AVAILABLE /rman_data/zgscdb_rman/ZGSCDB_arch_20120216_39n3e111_s5225_p1_C1
12561 2 AVAILABLE /rman_data/zgscdb_rman/ZGSCDB_arch_20120216_39n3e111_s5225_p2_C1
12562 3 AVAILABLE /rman_data/zgscdb_rman/ZGSCDB_arch_20120216_39n3e111_s5225_p3_C1
BS Key Size Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
5195 13.28G DISK 00:03:56 16-FEB-12
List of Archived Logs in backup set 5195
Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- --------- ---------- ---------
2 16162 12670016000750 15-FEB-12 12670016088204 15-FEB-12
2 16163 12670016088204 15-FEB-12 12670016308969 15-FEB-12
2 16164 12670016308969 15-FEB-12 12670016653192 15-FEB-12
2 16165 12670016653192 15-FEB-12 12670017027396 15-FEB-12
2 16166 12670017027396 15-FEB-12 12670017225549 15-FEB-12
2 16167 12670017225549 15-FEB-12 12670017317060 15-FEB-12
2 16168 12670017317060 15-FEB-12 12670017393441 15-FEB-12
2 16169 12670017393441 15-FEB-12 12670017462567 15-FEB-12
2 16170 12670017462567 15-FEB-12 12670017541021 15-FEB-12
2 16171 12670017541021 15-FEB-12 12670017654244 15-FEB-12
2 16172 12670017654244 15-FEB-12 12670017735163 15-FEB-12
2 16173 12670017735163 15-FEB-12 12670017811611 15-FEB-12
2 16174 12670017811611 15-FEB-12 12670017888323 15-FEB-12
2 16175 12670017888323 15-FEB-12 12670019198216 15-FEB-12
Backup Set Copy #1 of backup set 5195
Device Type Elapsed Time Completion Time Compressed Tag
----------- ------------ --------------- ---------- ---
DISK 00:03:56 16-FEB-12 NO TAG20120216T010430
List of Backup Pieces for backup set 5195 Copy #1
BP Key Pc# Status Piece Name
------- --- ----------- ----------
12566 1 AVAILABLE /rman_data/zgscdb_rman/ZGSCDB_arch_20120216_38n3e111_s5224_p1_C1
12567 2 AVAILABLE /rman_data/zgscdb_rman/ZGSCDB_arch_20120216_38n3e111_s5224_p2_C1
12568 3 AVAILABLE /rman_data/zgscdb_rman/ZGSCDB_arch_20120216_38n3e111_s5224_p3_C1
BS Key Size Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
5197 3.02G DISK 00:00:26 16-FEB-12
BP Key: 12572 Status: AVAILABLE Compressed: NO Tag: TAG20120216T010430
Piece Name: /rman_data/zgscdb_rman/ZGSCDB_arch_20120216_3bn3e18n_s5227_p1_C1
List of Archived Logs in backup set 5197
Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- --------- ---------- ---------
2 16176 12670019198216 15-FEB-12 12670023192712 15-FEB-12
2 16177 12670023192712 15-FEB-12 12670025565356 16-FEB-12
2 16178 12670025565356 16-FEB-12 12670026143737 16-FEB-12
2 16179 12670026143737 16-FEB-12 12670026897385 16-FEB-12
2 16180 12670026897385 16-FEB-12 12670027305649 16-FEB-12
2 16181 12670027305649 16-FEB-12 12670027693987 16-FEB-12
看到都需要的归档日志都包含进去了，满心欢喜的执行如下命令
RMAN> run{
2> allocate channel c1 type disk;
3> allocate channel c2 type disk;
4> allocate channel c3 type disk;
5> allocate channel c4 type disk;
6> set archivelog destination to '/arch_log/restore';
7> restore archivelog from time "to_date('2012-02-15 17:00:00','yyyy-mm-dd hh24:mi:ss')";
8> release channel c1;
9> release channel c2;
10> release channel c3;
11> release channel c4;
12> }
using target database control file instead of recovery catalog
allocated channel: c1
channel c1: sid=4849 instance=zgscdb1 devtype=DISK
allocated channel: c2
channel c2: sid=5326 instance=zgscdb1 devtype=DISK
allocated channel: c3
channel c3: sid=4946 instance=zgscdb1 devtype=DISK
allocated channel: c4
channel c4: sid=4879 instance=zgscdb1 devtype=DISK
executing command: SET ARCHIVELOG DESTINATION
Starting restore at 16-FEB-12
archive log thread 1 sequence 14155 is already on disk as file /arch_log/zgsc_db01_arch/1_14155_743864713.dbf
archive log thread 1 sequence 14156 is already on disk as file /arch_log/zgsc_db01_arch/1_14156_743864713.dbf
archive log thread 1 sequence 14157 is already on disk as file /arch_log/zgsc_db01_arch/1_14157_743864713.dbf
archive log thread 1 sequence 14158 is already on disk as file /arch_log/zgsc_db01_arch/1_14158_743864713.dbf
archive log thread 1 sequence 14159 is already on disk as file /arch_log/zgsc_db01_arch/1_14159_743864713.dbf
archive log thread 1 sequence 14160 is already on disk as file /arch_log/zgsc_db01_arch/1_14160_743864713.dbf
archive log thread 1 sequence 14161 is already on disk as file /arch_log/zgsc_db01_arch/1_14161_743864713.dbf
archive log thread 1 sequence 14162 is already on disk as file /arch_log/zgsc_db01_arch/1_14162_743864713.dbf
archive log thread 1 sequence 14163 is already on disk as file /arch_log/zgsc_db01_arch/1_14163_743864713.dbf
archive log thread 1 sequence 14164 is already on disk as file /arch_log/zgsc_db01_arch/1_14164_743864713.dbf
archive log thread 1 sequence 14165 is already on disk as file /arch_log/zgsc_db01_arch/1_14165_743864713.dbf
released channel: c1
released channel: c2
released channel: c3
released channel: c4
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 02/16/2012 13:47:51
RMAN-06026: some targets not found - aborting restore
RMAN-06025: no backup of log thread 2 seq 16209 lowscn 12670043591603 found to restore
RMAN-06025: no backup of log thread 2 seq 16208 lowscn 12670043181908 found to restore
RMAN-06025: no backup of log thread 2 seq 16207 lowscn 12670043081120 found to restore
RMAN-06025: no backup of log thread 2 seq 16206 lowscn 12670042973201 found to restore
RMAN-06025: no backup of log thread 2 seq 16205 lowscn 12670042654302 found to restore
RMAN-06025: no backup of log thread 2 seq 16204 lowscn 12670041610965 found to restore
RMAN-06025: no backup of log thread 2 seq 16203 lowscn 12670040751853 found to restore
RMAN-06025: no backup of log thread 2 seq 16202 lowscn 12670040584982 found to restore
RMAN-06025: no backup of log thread 2 seq 16201 lowscn 12670040305341 found to restore
RMAN-06025: no backup of log thread 2 seq 16200 lowscn 12670039987074 found to restore
RMAN-06025: no backup of log thread 2 seq 16199 lowscn 12670039745774 found to restore
RMAN-06025: no backup of log thread 2 seq 16198 lowscn 12670039250107 found to restore
RMAN-06025: no backup of log thread 2 seq 16197 lowscn 12670038751777 found to restore
RMAN-06025: no backup of log thread 2 seq 16196 lowscn 12670038122926 found to restore
RMAN-06025: no backup of log thread 2 seq 16195 lowscn 12670037110291 found to restore
RMAN-06025: no backup of log thread 2 seq 16194 lowscn 12670036384317 found to restore
RMAN-06025: no backup of log thread 2 seq 16193 lowscn 12670036130529 found to restore
RMAN-06025: no backup of log thread 2 seq 16192 lowscn 12670035930022 found to restore
RMAN-06025: no backup of log thread 2 seq 16191 lowscn 12670035736951 found to restore
RMAN-06025: no backup of log thread 2 seq 16190 lowscn 12670034378583 found to restore
RMAN-06025: no backup of log thread 2 seq 16189 lowscn 12670033507562 found to restore
RMAN-06025: no backup of log thread 2 seq 16188 lowscn 12670032888750 found to restore
RMAN-06025: no backup of log thread 2 seq 16187 lowscn 12670031934562 found to restore
RMAN-06025: no backup of log thread 2 seq 16186 lowscn 12670031295273 found to restore
RMAN-06025: no backup of log thread 2 seq 16185 lowscn 12670029669200 found to restore
RMAN-06025: no backup of log thread 2 seq 16184 lowscn 12670029122812 found to restore
RMAN-06025: no backup of log thread 2 seq 16183 lowscn 12670027774997 found to restore
RMAN-06025: no backup of log thread 2 seq 16182 lowscn 12670027693987 found to restore
报错，郁闷，超级郁闷
$ ls /arch_log/zgsc_01_arch
1_14155_743864713.dbf 1_14158_743864713.dbf 1_14161_743864713.dbf 1_14164_743864713.dbf 1_14167_743864713.dbf
1_14156_743864713.dbf 1_14159_743864713.dbf 1_14162_743864713.dbf 1_14165_743864713.dbf
1_14157_743864713.dbf 1_14160_743864713.dbf 1_14163_743864713.dbf 1_14166_743864713.dbf
观察报错发现没有找到的备份信息主要都是thread 2的备份信息，结合上面ls命令的输出分析得出，线程为1日志序列号从14155至14166的归档日志虽然为2012-02-15 17:00之后的归档日志，但却仍再使用。使用restore archivelog from time "to_date('2012-02-15 17:00:00','yyyy-mm-dd hh24:mi:ss')";命令恢复时会提示already on disk。
结合list backup of archivelog from time "to_date('2012-02-15 17:00:00','yyyy-mm-dd hh24:mi:ss')";
和
node1
$ ls /rman_data/zgscdb_rman/ZGSCDB_arch_20120216_39n3e111_s5225_p1_C1
ls: 0653-341 The file /rman_data/zgscdb_rman/ZGSCDB_arch_20120216_39n3e111_s5225_p1_C1 does not exist
node2
$ ls /rman_data/zgscdb_rman/ZGSCDB_arch_20120216_35n3e111_s5221_p1_C1
ls: 0653-341 The file /rman_data/zgscdb_rman/ZGSCDB_arch_20120216_35n3e111_s5221_p1_C1 does not exist.
发现双节点都只有各自的备份文件，备份文件没有进行存储共享的配置(出于安全考虑，确实不应该把备份配置成共享的，不过设置成nfs挂载应该是没问题)。呵呵，犯了个低级错误。
经过以上分析得出，restore archivelog from time "to_date('2012-02-15 17:00:00','yyyy-mm-dd hh24:mi:ss')";命令会自动查找所需的备份文件进行还原，但是由于双节点无法同时访问所有需要备份文件，故需在特定节点还原指定的日志序列号，进行逐个还原，即
需要在相应的实例上还原相应thread对应的归档日志。
thread的意义： RAC环境下，多台主机同时访问位于共有的磁盘阵列的共同的数据库结构。每台主机上的数据库例程分别写自己的日志文件，不同的例程通过thread来区分。
于是根据list backup of archivelog from time "to_date('2012-02-15 17:00:00','yyyy-mm-dd hh24:mi:ss')"
命令得出的归档日志和备份信息，执行如下命令恢复
在RAC节点node 1上执行
run{
allocate channel c1 type disk;
allocate channel c2 type disk;
allocate channel c3 type disk;
allocate channel c4 type disk;
set archivelog destination to '/arch_log/restore';
restore archivelog from logseq 14131 until logseq 14153 thread 1;
release channel c1;
release channel c2;
release channel c3;
release channel c4;
}
在RAC节点node 2上执行
run{
allocate channel c1 type disk;
allocate channel c2 type disk;
allocate channel c3 type disk;
allocate channel c4 type disk;
set archivelog destination to '/arch_log/restore';
restore archivelog from logseq 16148 until logseq 16181 thread 2;
release channel c1;
release channel c2;
release channel c3;
release channel c4;
}
还原成功。
这里顺带说一句，如果需要进行数据库恢复，那么必须在能够访问所有归档日志的节点上进行，这里是node1
感谢惜分飞，边城，杨帅君，select.简单的指导
本文原创，转载请注明出处、作者
如有错误，欢迎指正
邮箱:czmcj@163.com
顶
踩
发表评论
-
AIX平台下磁盘的PVID对ASM磁盘的破坏
2014-03-19 20:53 2738这篇文章将通过两篇MOS文章来讨论AIX平台下为磁盘分配 ... -
Bug 9020054,ORA-8103 BEING HIT DURING GATHERING OF STATISTICS ON TABLE PARTITION
2013-12-01 09:22 1882Bug 9020054 : ORA-8103 ... -
oracle数据库hanganalyze(原创)
2013-06-23 14:11 8329为什么要使用hanganalyzeOracle 数据库“真 ... -
Oracle:并行操作为什么无法执行(老白)
2013-06-23 10:30 5739在一次系统割接的时候，我们碰到一个十分奇怪的现象。由于进行 ... -
补写的2小节DBA日记
2013-06-05 21:52 13886月8日 ITL等待引发的RAC性能问题 从这几天的情况 ... -
ORA-27054故障排除
2013-03-08 17:57 12961在数据备份过程中，由于目标是使用NFS文件系统，因此在导入 ... -
长时间latch free等待——记一次系统异常的诊断过程
2013-01-09 19:17 3736今天发现一个报表数据库中SQL运行异常，简单记录一下问题的诊断 ... -
ORA-15063: ASM discovered an insufficient number of disks for diskgroup(原创)
2012-11-25 16:59 13087ORA-15063: ASM discovered an in ... -
libpthread.so.0: cannot open shared object file解决方法(原创)
2012-11-24 17:33 17760在linux 5上装10G RAC时，常常会碰到“libpth ... -
ora-02020故障诊断详解(原创)
2012-07-16 12:54 3206ORA-2020错发生在一个分布式事务使用的dblink数超过 ... -
Oracle数据库CPU 100%故障诊断实例(原创)
2012-07-05 13:55 16916前言 这两天一只对外提供查询的数据库CPU使用率 ... -
DBA手记:System State转储分析之问题定位
2012-04-19 22:20 2110在 Oracle 数据库的运行过程中，可能会因为一些异常遇 ... -
ORA-02050故障诊断一例
2012-04-05 17:20 8577昨天客户反映说在下午某时间段有几个事务失败了，让我查下当时数据 ... -
ORA-00308: cannot open archived log(原创)
2012-03-23 09:36 16258笔者在为客户配置DG时发现主备库日志无法正常传输，经仔细检查后 ... -
ORA-00600: internal error code, arguments: [kcblasm_1], [103]原创
2012-03-23 09:36 3111故障报错 Mon Mar 19 11:30:03 GMT ... -
ORA-00600: internal error code, arguments: [kglhdda-bad-free](原创)
2012-03-22 09:16 2963故障报错如下 Thu Mar 15 09:51:29 G ... -
ORA-27300,ORA-27301,ORA-27302: failure occurred at: skgpalive1(原创)
2012-03-22 08:58 3347故障报错如下 Wed Mar 07 16:4 ... -
ora-07445错误相关内容
2012-03-01 17:14 1823本文档主要介绍ora-07445 错误相关内容，并给出了对这 ... -
SMON: Parallel transaction recovery tried 引发的问题
2012-01-04 11:26 2399SMON: Parallel transaction rec ... -
ORA-00444，ORA-07446故障排查
2011-12-14 16:58 4650phenomenon startup ORA-00 ...
相关推荐
6. **切换回归档模式**：为了提高数据安全性，建议将数据库切换到归档模式，这样每次日志切换都会创建归档日志，从而提供额外的数据保护。 实验表明，这种非归档模式下的重做日志恢复方法能够在没有备份的情况下...
### Oracle备份与还原数据库知识点详解 #### 一、Oracle数据库备份方法概述 Oracle数据库提供了三种标准的备份方式：导出/导入（EXP/IMP）、热备份（Hot Backup）和冷备份（Cold Backup）。这些方法根据不同的场景...
在生产环境中我们应该使用归档模式，它会产生归档日志，可以使用多种备份和还原方案，对与Oracle管理员来说应该更改模式是必然的选择。 首先查看数据库现有模式可使用以下语句 select name，log_mode from v$...
RMAN（Recovery Manager）是 Oracle 服务器软件中随附的一种工具软件，可以用来备份和恢复数据库文件、归档日志和控制文件。RMAN 的主要优点是可以跳过未使用的数据块，从而提高备份速度和效率。 二、使用 RMAN ...
2. **日志文件备份**：日志文件通常自动备份到归档模式，通过设置参数`LOG_ARCHIVE_FORMAT`来定义归档日志的存放位置。 3. **恢复操作**：如果控制文件或日志文件丢失，可以利用备份进行恢复。恢复控制文件通常使用`...
Oracle数据库提供了一系列工具，如RMAN（Recovery Manager）来管理和执行归档日志的备份和恢复。 理解Oracle日志文件的管理策略也是提高数据库性能的关键。适当的日志文件大小和数量应根据数据库的事务量和I/O性能...
这涉及到Oracle的时间点恢复，需要RMAN和归档日志的参与，C#程序需要调用RMAN命令，并解析返回结果。 3. **C#中的实现细节**： - 使用`OracleCommand`执行SQL脚本进行备份和恢复操作，如创建备份表、导出数据等。 ...
归档日志模式允许在完成一次完全数据库备份后，通过归档日志进行增量备份，从而实现更细粒度的数据恢复。 2. **RAID5存储配置**：文中提到使用RAID5作为存储解决方案，RAID5提供数据冗余和性能提升，可以防止因单块...
### Oracle RAC恢复到单机方案—仅有一个全备 #### 概述 在Oracle Real Application Clusters (RAC)环境中，当面临只有历史全备（热备）且无增量备份和归档备份的情况下，若需要将数据恢复到单机环境，会面临一定...
Oracle日志分析 ...在使用Oracle日志来还原数据库的时候，必须使用数据字典，因为在数据字典中记录了数据库中的一些信息，比如表的字段在日志中是一个编号，在恢复数据库时，需要使用这些信息来还原数据库。
3. **归档日志模式**：在Oracle中，启用归档日志模式可以实现更精细的恢复，因为所有的更改都会被记录在归档日志中。这使得数据库能够进行前向恢复，即恢复到任何已归档的日志存在的时点。 4. **闪回技术**：Oracle...
除了上述方法，Oracle 10g还提供了归档日志和闪回技术来增强恢复能力。归档日志记录了数据库的所有更改，使得在发生问题后可以通过redo log进行前滚恢复。闪回功能则允许用户在特定时间点恢复整个数据库或单个表，...
全库备份包括所有数据文件、控制文件和归档日志，确保在灾难时能完全恢复数据库。增量备份仅备份自上次备份以来发生更改的数据块，节省存储空间。表空间备份则针对特定用户或应用需求。 还原过程中，RMAN同样扮演...
Oracle的恢复机制主要包括还原和归档日志应用两部分。还原是将备份的文件恢复到新的位置，而应用归档日志则是为了完成从备份点到当前时间的数据恢复。在实际操作中，可能需要使用到SQL*Plus命令行工具或者RMAN进行...
2. 了解数据库的归档日志模式和非归档日志模式，以及它们对恢复的影响。 3. 掌握闪回技术和时间点恢复的概念，以便在特定场景下快速恢复数据。 4. 理解Oracle Data Guard和GoldenGate等高可用性解决方案，以及如何...
5. **保留策略**：保留最近两次全备和归档日志备份，以及至少保留最近一个月的EXP文件，确保数据的可恢复性。 #### 实施细节 在Windows 2000环境下，针对Oracle 8i/9i数据库，备份可以通过RMAN(Recovery Manager)...
- **物理备份**：通过备份数据文件、控制文件和归档日志来实现数据库的完整恢复。适用于需要完全恢复的情况，但对存储空间需求较大，且要求数据库处于归档模式。 - **逻辑备份**：利用Oracle提供的`EXPDP`和`IMPDP...
Oracle数据库中的归档日志（Archive Log）是数据库在运行过程中产生的一种重要数据记录，它存储了数据库事务的完整历史，对于数据保护、故障恢复和多版本并发控制（MVCC）有着至关重要的作用。这篇学习笔记将深入...
6. **恢复第一次增量备份后到第二次此增量备份完成这段时间的归档日志。** 7. **再次执行恢复数据库。** 8. **执行备份检查。** 9. **再次执行恢复数据库。** 10. **打开数据库验证数据。** 11. **恢复测试小结。** ...
- **db_recovery_file_dest**: 库恢复还原用文件存放目录，用于存放备份 control files、online redo logs、归档日志、flashback logs 和 RMAN 备份。 - **db_recovery_file_dest_size**: 限定恢复还原用文件占用的...