ORACLE11G 將dataguard的rman備份恢復到測試環境的單機oracle中的詳細過程
1，從生產庫上copy好全備份檔案
1.1，檢視引數檔案資訊
RMAN> list backup of spfile;
從一大推list資訊找出最近的備份資訊
/pddata2/oracle/backup/data/ctl_auto/c-3391761643-20150820-01
1.2檢視控制檔案資訊：
RMAN> list backup of controlfile;
找出裡面的控制檔案
/pddata2/oracle/backup/data/ctl_auto/c-3391761643-20150820-01
1.3 檢視資料庫資訊：
RMAN> list backup of database;
1.4 檢視歸檔日誌資訊：
RMAN> list backup of archivelog all;
BS Key Type LV Size Device TypeElapsed Time Completion Time
------- ---- -- ---------- ----------------------- ---------------
4110 Full 18.36M DISK 00:00:01 20-AUG-15
BP Key: 4110 Status: AVAILABLE Compressed: NO Tag: TAG20150820T032017
Piece Name:/pddata2/oracle/backup/data/ctl_auto/c-3391761643-20150820-01
Control File Included: Ckp SCN: 11412370967 Ckp time: 20-AUG-15
將引數檔案控制檔案copy到測試環境到測試環境/data/impdp/
cd /pddata2/oracle/backup/data/ctl_auto/
scp c-3391761643-20150820-01c-3391761643-20150820-01 192.168.180.60:/data/impdp/
2、開始恢復引數檔案控制檔案：
SQL> select dbid from v$database;
2.1 設定DBID：
注意：在rman下即使沒有引數檔案，預設也會啟動一個DUMMY例項，以便能夠恢復引數檔案。
set dbid 3391761643
2.2 恢復spfile檔案
startup到open狀態，先檢視spfile檔案位置：
SQL> show parameter spfile;
/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/spfilepowerdes.ora
shutdown後，再startup 到 nomount狀態
去生產環境查詢
RMAN> show all;
......
CONFIGURE SNAPSHOT CONTROLFILE NAME TO'/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/snapcf_powerdes.f'; # default
找到之後copy到測試環境：
scp/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/snapcf_powerdes.f192.168.180.60:/data/impdp/
開始進行恢復
restore spfile to'/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/spfilepowerdes.ora' from '/data/impdp/snapcf_powerdes.f';
startup nomount再恢復
恢復報錯如下：
RMAN> restore spfile to'/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/spfilepowerdes.ora' from '/data/impdp/c-3391761643-20150820-01';
RMAN> restore spfile to'/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/spfilepowerdes.ora' from '/data/impdp/c-3391761643-20150820-01';
Starting restore at 20-AUG-15
using channel ORA_DISK_1
channel ORA_DISK_1: restoring spfile fromAUTOBACKUP /data/impdp/c-3391761643-20150820-01
RMAN-00571:===========================================================
RMAN-00569: =============== ERROR MESSAGESTACK FOLLOWS ===============
RMAN-00571:===========================================================
RMAN-03002: failure of restore command at08/20/2015 18:25:14
ORA-32011: cannot restore SPFILE tolocation already being used by the instance
RMAN>
所以從pd線上重新拉一個引數檔案出來，copy到測試環境
SQL> create pfile='/oracle/pfile01.ora'from spfile;
File created.
SQL>
然後根據複製來的引數檔案再在測試庫上建立spfile
create spfile frompfile='/data/pfile01.ora';
SQL> create spfile frompfile='/data/impdp/pfile01.ora';
File created.
SQL>
然後將測試庫啟動到nomount
SQL> startup nomount
ORA-00845: MEMORY_TARGET not supported onthis system
SQL>
看到報記憶體錯誤了，然後修改/etc/fstab檔案設定好記憶體標示配置
vi/etc/fstab
tmpfs /dev/shm tmpfs defaults,size=11G 0 0
執行生效
mount -t tmpfs shmfs -o size=11g /dev/shm
SQL> startup mount;
ORA-01078: failure in processing systemparameters
LRM-00109: could not open parameter file'/oracle/app/oracle/product/11.2.0/dbhome_1/dbs/initpowerdes.ora'
SQL>
restore
2.3 在測試環境恢復控制檔案：
restore controlfile to'/data/oracle/powerdes/control01.ctl' from'/data/impdp/c-3391761643-20150820-01';
RMAN> restore controlfile to'/data/oracle/powerdes/control01.ctl' from'/data/impdp/c-3391761643-20150820-01'
restore controlfile to'/home/oradata/powerdes/control01.ctl' from'/data/impdp/c-3391761643-20150820-01';
2> ;
之後需要啟動到mount才能進行restore和recover操作，但是啟動失敗
RMAN> alter database mount
2> ;
RMAN-00571:===========================================================
RMAN-00569: =============== ERROR MESSAGESTACK FOLLOWS ===============
RMAN-00571:===========================================================
RMAN-03002: failure of alter db command at08/21/2015 11:12:13
ORA-00205: error in identifying controlfile, check alert log for more info
RMAN>
看到是因為控制檔案不識別，去看下alert日誌資訊，
[[email protected] /]# tail -f/oracle/app/oracle/diag/rdbms/pdunq/powerdes/trace/alert_powerdes.log
Checker run found 1 new persistent datafailures
Fri Aug 21 11:13:51 2015
alter database mount
Fri Aug 21 11:13:51 2015
ORA-00210: cannot open the specifiedcontrol file
ORA-00202: control file:'/home/oradata/powerdes/control01.ctl'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file ordirectory
Additional information: 3
ORA-205 signalled during: alter databasemount...
從alert日誌可以看出控制檔案已經變成了生產環境的路徑了，原因是spfile是從生產環境copy出來的，生產環境的spfile裡面記錄的控制檔案路徑和測試環境不同，所以這裡為了快速恢復，要重新指定和生產環境一樣路徑的，重新生成新路徑的控制檔案。
控制檔案
RMAN> restore controlfile to'/home/oradata/powerdes/control01.ctl' from'/data/impdp/c-3391761643-20150820-01';
Starting restore at 21-AUG-15
using channel ORA_DISK_1
channel ORA_DISK_1: restoring controlfile
channel ORA_DISK_1: restore complete,elapsed time: 00:00:01
Finished restore at 21-AUG-15
OK，看到控制檔案restore成功了，接下來直接將資料庫狀態改成mount
RMAN> alter database mount;
database mounted
released channel: ORA_DISK_1
RMAN>
然後就可以開始restore整個庫
2.4, 在新控制檔案中註冊資料檔案備份和歸檔備份
要將db狀態改成mount才行
catalog start with'/data/impdp/2015-08-20/';
RMAN> alter database mount
2> ;
using target database control file insteadof recovery catalog
database mounted
RMAN> catalog start with'/data/impdp/2015-08-20/';
Starting implicit crosscheck backup at20-AUG-15
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=129 devicetype=DISK
Crosschecked 98 objects
Finished implicit crosscheck backup at20-AUG-15
Starting implicit crosscheck copy at20-AUG-15
using channel ORA_DISK_1
Finished implicit crosscheck copy at20-AUG-15
searching for all files in the recoveryarea
cataloging files...
no files cataloged
searching for all files that match thepattern /data/impdp/2015-08-20/
List of Files Unknown to the Database
=====================================
File Name:/data/impdp/2015-08-20/arch_POWERDES_20150820_4420.bak
File Name:/data/impdp/2015-08-20/rman_backup.log
File Name:/data/impdp/2015-08-20/arch_POWERDES_20150820_4418.bak
File Name:/data/impdp/2015-08-20/full_POWERDES_20150820_4419.bak
Do you really want to catalog the abovefiles (enter YES or NO)? YES
cataloging files...
cataloging done
List of Cataloged Files
=======================
File Name:/data/impdp/2015-08-20/arch_POWERDES_20150820_4420.bak
File Name:/data/impdp/2015-08-20/arch_POWERDES_20150820_4418.bak
File Name:/data/impdp/2015-08-20/full_POWERDES_20150820_4419.bak
List of Files Which Where Not Cataloged
=======================================
File Name:/data/impdp/2015-08-20/rman_backup.log
RMAN-07517: Reason: The file header is corrupted
RMAN>
2.5，開始恢復整個庫
因為前面恢復了整個spfile已經controlfile，所以接下來恢復所有庫的話，就不用帶引數，直接恢復restore database就可以 ;
RMAN> restore database;
RMAN> restore database;
Starting restore at 20-AUG-15
using channel ORA_DISK_1
channel ORA_DISK_1: starting datafilebackup set restore
channel ORA_DISK_1: specifying datafile(s)to restore from backup set
channel ORA_DISK_1: restoring datafile00001 to /home/oradata/powerdes/system01.dbf
channel ORA_DISK_1: restoring datafile00002 to /home/oradata/powerdes/sysaux01.dbf
channel ORA_DISK_1: restoring datafile00003 to /home/oradata/powerdes/undotbs01.dbf
channel ORA_DISK_1: restoring datafile00004 to /home/oradata/powerdes/users01.dbf
channel ORA_DISK_1: restoring datafile00005 to /home/oradata/powerdes/powerdesk01.dbf
channel ORA_DISK_1: restoring datafile00006 to /home/oradata/powerdes/plas01.dbf
channel ORA_DISK_1: restoring datafile00007 to /home/oradata/powerdes/pl01.dbf
channel ORA_DISK_1: restoring datafile00008 to /home/oradata/powerdes/help01.dbf
channel ORA_DISK_1: restoring datafile00009 to /home/oradata/powerdes/adobelc01.dbf
channel ORA_DISK_1: restoring datafile00010 to /home/oradata/powerdes/sms01.dbf
channel ORA_DISK_1: restoring datafile00011 to /home/oradata/powerdes/plcrm01.dbf
channel ORA_DISK_1: restoring datafile00012 to /home/oradata/powerdes/powerdesk02.dbf
channel ORA_DISK_1: reading from backuppiece /data/impdp/2015-08-20/full_POWERDES_20150820_4419.bak
channel ORA_DISK_1: piecehandle=/data/impdp/2015-08-20/full_POWERDES_20150820_4419.baktag=TAG20150820T030008
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete,elapsed time: 00:17:35
Finished restore at 20-AUG-15
RMAN>
2.6 然後recover修復資料庫
RMAN> recover database;
Starting recover at 20-AUG-15
using channel ORA_DISK_1
starting media recovery
channel ORA_DISK_1: starting archived logrestore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=36277
channel ORA_DISK_1: reading from backuppiece /data/impdp/2015-08-20/arch_POWERDES_20150820_4420.bak
channel ORA_DISK_1: piecehandle=/data/impdp/2015-08-20/arch_POWERDES_20150820_4420.baktag=TAG20150820T032015
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete,elapsed time: 00:00:01
archived log filename=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/2015_08_20/o1_mf_1_36277_bxcjyzbg_.arcthread=1 sequence=36277
channel default: deleting archivedlog(s)
archived log file name=/oracle/app/oracle/flash_recovery_area/POWERDES/archivelog/2015_08_20/o1_mf_1_36277_bxcjyzbg_.arcRECID=71395 STAMP=888264671
unable to find archived log
archived log thread=1 sequence=36278
RMAN-00571:===========================================================
RMAN-00569: =============== ERROR MESSAGESTACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at08/20/2015 20:11:13
RMAN-06054: media recovery requestingunknown archived log for thread 1 with sequence 36278 and starting SCN of11412370952
RMAN>
後臺alet日誌報錯資訊為：
Fri Aug 21 11:47:07 2015
alter database recover datafile list clear
Completed: alter database recover datafilelist clear
alter database recover datafile list
1 ,2 , 3 , 4 , 5 , 6 , 7 , 8 , 9 , 10 , 11 , 12
Completed: alter database recover datafilelist
1 ,2 , 3 , 4 , 5 , 6 , 7 , 8 , 9 , 10 , 11 , 12
alter database recover if needed
start until cancel using backup controlfile
Media Recovery Start
started logmerger process
Parallel Media Recovery started with 4slaves
ORA-279 signalled during: alter databaserecover if needed
start until cancel using backup controlfile
...
alter database recover logfile'/oracle/app/oracle/flash_recovery_area/archivelog1_36277_821708334.dbf'
Media Recovery Log/oracle/app/oracle/flash_recovery_area/archivelog1_36277_821708334.dbf
ORA-279 signalled during: alter databaserecover logfile'/oracle/app/oracle/flash_recovery_area/archivelog1_36277_821708334.dbf'...
alter database recover cancel
Media Recovery Canceled
Completed: alter database recover cancel
Fri Aug 21 11:47:09 2015
Checker run found 1 new persistent datafailures
可見，出先此錯誤的原因是恢復需要的歸檔日誌記錄在控制檔案或恢復目錄中找不到。解決方法分兩種情況：
1.如果相關的日誌存在且可用的話，就將此日誌記錄新增到控制檔案或恢復目錄中。
2.如果相關的日誌已經被刪除了或不可用了，那麼就按照錯誤的提示scn將資料庫恢復到此scn，這裡是11412370952。也就是說此時資料庫只能進行不完全恢復了，在開啟資料庫時得使用resetlogs開啟。
recover database until scn 11412370952;
RMAN> recover database until scn11412370952;
Starting recover at 20-AUG-15
using channel ORA_DISK_1
starting media recovery
media recovery complete, elapsed time:00:00:00
Finished recover at 20-AUG-15
RMAN>
然後開啟資料庫
RMAN> alter database openresetlogs;
database opened
RMAN>
3，一些除錯過程中的意外報錯
然後開啟報錯
RMAN> alter database open resetlogs;
RMAN-00571:===========================================================
RMAN-00569: =============== ERROR MESSAGESTACK FOLLOWS ===============
RMAN-00571:===========================================================
RMAN-03002: failure of alter db command at08/20/2015 20:31:07；
ORA-03113: end-of-file on communicationchannel
Process ID: 30584
Session ID: 192 Serial number: 19
RMAN-00571:===========================================================
RMAN-00569: =============== ERROR MESSAGESTACK FOLLOWS ===============
RMAN-00571:===========================================================
ORA-03114: not connected to ORACLE
RMAN-00571:===========================================================
RMAN-00569: =============== ERROR MESSAGESTACK FOLLOWS ===============
RMAN-00571:===========================================================
RMAN-03002: failure of alter db command at08/20/2015 20:31:07
ORA-03113: end-of-file on communicationchannel
Process ID: 30584
Session ID: 192 Serial number: 19
[[email protected] dbs]$
重新進去開啟
RMAN> alter database open resetlogs;
using target database control file insteadof recovery catalog
RMAN-00571:===========================================================
RMAN-00569: =============== ERROR MESSAGESTACK FOLLOWS ===============
RMAN-00571:===========================================================
RMAN-03002: failure of alter db command at08/20/2015 20:35:44
RMAN-06403: could not obtain a fullyauthorized session
ORA-01034: ORACLE not available
ORA-27101: shared memory realm does notexist
Linux-x86_64 Error: 2: No such file ordirectory
RMAN>
嘗試去sqlplus模式下啟動
SQL> startup
ORACLE instance started.
Total System Global Area 5010685952 bytes
Fixed Size 2212936 bytes
Variable Size 2751466424 bytes
Database Buffers 2214592512 bytes
Redo Buffers 42414080 bytes
Database mounted.
ORA-03113: end-of-file on communicationchannel
Process ID: 10504
Session ID: 191 Serial number: 3
SQL>
這裡打不開的原因是，引數檔案恢復失效後，跳過引數檔案恢復這一步驟，然後進行控制檔案恢復後restore庫recover庫引發的問題。解決方案：就是重新恢復引數檔案後再進行下述步驟就完全OK。
相關推薦
ORACLE11G 將dataguard的rman備份恢復到測試環境的單機oracle中的詳細過程
1，從生產庫上copy好全備份檔案1.1，檢視引數檔案資訊RMAN> list backup of spfile;從一大推list資訊找出最近的備份資訊/pddata2/oracle/backup/data/ctl_auto/c-3391761643-20150820-
基於Apollo實現.NET Core微服務統一配置(測試環境-單機) .NET Core微服務之基於Apollo實現統一配置中心
一、前言 注：此篇只是為測試環境下的快速入門。後續會給大家帶來生產環境下得實戰開發。 具體的大家可以去看官方推薦。非常的簡單明瞭。以下介紹引用官方內容： Apollo（阿波羅）是攜程框架部門研發的分散式配置中心，能夠集中化管理應用不同環境、不同叢集的配置，配置修改後能夠實時推送到應用端，並且具
利用ansible-playbook從測試環境獲取tomcat中java項目新版本發布到生產環境
java 還在 ack 類型 pro http ignore entry 最新 一、環境描述 安裝有ansible的服務器：192.168.13.45 測試環境服務器：192.168.13.49 /home/app/api-tomcat/webapps/api.war為測試
下載git2.2.1並將git添加到環境變量中
install bash string ring bic hub -html nsh cal ># wget https://github.com/git/git/archive/v2.2.1.tar.gz > # tar zxvf v2.2.1.tar.gz
Appium+Python移動端（Android）自動化測試環境搭建（經典詳細）
據說，appium+python環境的搭建90%的人在痛苦中掙扎，在掙扎中放棄，在放棄後重新開始，只有10%的人，人品極好，極具正能量，能夠很快並順利的搭建成功（此時你在想什麼？......） 一、安裝JDK 下載好jdk安裝包後直接下一步直至安裝完成即可，安裝完JD
RMAN備份恢復系列1： Oracle 10g rac asm資料庫恢復到10g單例項資料庫
RMAN> recover database; Starting recover at 11-MAR-13 using channel ORA_DISK_1 starting media recovery channel ORA_DISK_1: starting archive log restore
Selenium+TestNG Web自動化測試環境搭建6_selenium中的等待
Web頁面是一個逐步載入的過程。當元素沒有載入完時，我們對其操作將會失敗。 因此，要保證web測試的穩定性，等待處理必不可少。 Selenium的等待可以分為兩類：顯示等待（Explicit Waits）和隱式等待（Implicit Waits）。 1）顯式等待： 在執行
MySQL 使用mysqld_multi部署單機多例項詳細過程
序言：多例項？Why？隨著硬體層面的發展，linux系統多核已經是普通趨勢，而mysql是單程序多執行緒，所以先天上對多程序的利用不是很高，雖然5.6版本已經在這方面改進很多，但是也沒有達到100%，所以為了充分的利用系統資源，mysql有自己的補充，那就是可以部署多例項，一
記一次測試環境Hbase數據備份恢復以及恢復後部分表無法刪除的問題處理
localhost mkdir folder max 一個表 任務 spa file config 一、Hbase數據備份恢復說明：因為測試環境要修改hadoop配置文件hdfs-site.xml的參數hdfs.rootdir修改前的配置 <property>
SQL Server中使用數據庫快照的方式來完成測試環境中數據庫的輕量級備份還原操作
otf tempdb 不支持 ces har font 技術分享 ace clas 原文:SQL Server中使用數據庫快照的方式來完成測試環境中數據庫的輕量級備份還原操作 在開發或者測試環境的數據庫中，經常會發現有開發或者測試人員誤刪除表或者數據的情況，對於開發或者
RMAN備份介質的移動與再恢復測試 [ catalog start with ‘dir’ ]
https://www.cnblogs.com/jackhub/p/3331673.html 由於目前生產環境中沒有集中的備份條件,所以備份要考慮到可以移動再恢復性.這裡要測試的就是,RMAN全部備份的介質,我關注是否可以定期的移動到其他儲存介質中,到要恢復的時候再拿過來.
持續整合之將程式碼自動部署至測試環境
將程式碼自動部署至測試環境 一：本文在上一篇文章的基礎之上繼續進行操作，上一篇實現了從git獲取程式碼並進行程式碼測試，本文將在上一篇的基礎之上實現將程式碼部署至測試環境。1.1：新建一個專案叫web-demo-deploy用於程式碼釋出，上一個專案web-demo可用於程式碼測試，當測試階段出現問題的
[轉帖]PG的簡單備份恢復 找時間進行測試
轉帖PG的簡單使用 https://blog.csdn.net/lk_db/article/details/77971634 一： 純檔案格式的指令碼： 示例：1. 只匯出postgres資料庫的資料，不包括模式 -s pg_dump -U postgres -f /po
ORACLE11G資料備份恢復注意事項
資料庫在資訊爆發的當前正扮演者越來越重要的角色，因為資料庫一旦停止執行，整個應用基本就處於停用狀態，所以保證資料庫的穩定可靠是應用執行的最基本最核心的問題。所以正確做好資料庫的備份及恢復非常重要，那麼我們就來講講資料庫的一些特徵。 1，orac
【比原鏈】比原鏈如何在單機solonet測試環境下挖到礦
比原專案倉庫：https://github.com/Bytom/bytom好多人學習和研究比原，但苦於在主網環境不敢實際操作怕帶來損失，在單機solo環境又挖不出代幣無法進行測試。本人在 學習過程中也遇到了類似的問題，簡單研究了一下寫了如下方法。提前做好檔案和錢包的備份。提前
DB2 備份 恢復 詳細測試
本文測試環境：Windows XP、IBM DB2 Express V9.5、 DB2 Quest Center V9.5 在這裡舉個應用場景以說明資料庫恢復備份的思路：那麼假設我們週一晚上做了一個數據庫的備份，週二中午12 點資料庫儲存介質出現了故障。如何能夠實
oracle rman 增量備份完整恢復測試
RMAN備份 sql*plus與作業系統命令列切換 linux：用！符號 window：sql>到c:>用host命令，c:>到sql>用exit。 RMAN備份模式：全備、增量備份、冷備、熱備。 RMAN備份的檔案型別：表空間、資料檔案、控制檔案
Window環境下配置MySQL 5.6的主從復制、備份恢復
end inf content 復制 grant -h 正常的 mysql 5.6 出現 原文:Window環境下配置MySQL 5.6的主從復制、備份恢復1、環境準備 Windows 7 64位 MySQL 5.6 主庫：192.168.103.
mongodb安裝、連線，mongodb使用者管理、建立集合、資料管理、備份恢復，副本集介紹、搭建、測試，分片介紹、搭建、測試，php的mongodb擴充套件、mongo擴充套件
21.26 mongodb介紹 21.27 mongodb安裝 21.28 連線mongodb
apiAutoTest: 介面自動化測試的資料清洗(備份/恢復)處理方案
# 介面自動化測試之資料清洗/隔離/備份/恢復 > 在得到QQ:1301559180 得程式碼貢獻之後，想到了通過ssh連線上伺服器，然後進行資料庫備份，資料庫恢復， 主要使用了 `paramiko`庫 # 最終效果 1. 測試開始前會進行資料備份，並在下面2個路徑儲存對應的資料庫備份(目前備份的資料庫