2. 程式人生 > >中小型資料庫 RMAN CATALOG 備份恢復方案(三)

中小型資料庫 RMAN CATALOG 備份恢復方案(三)

阿新 • • 發佈：2019-01-29

      在前兩篇文章中描述了中小型資料庫使用RMAN catalog設計備份與恢復方案，並給出了所有相關的指令碼來從某種車程度上模擬Oracle Data Guard以減少硬體故障帶來Prod伺服器上資料庫損失。在這邊文章中主要描述Prod資料庫的變遷在Bak server端如何進行恢復。

1、恢復前提
     按照前兩篇文章的描述，我們制定了每天做一個level 0級備份並ftp整個備份集到Bak server。同時定時ftp Prod的歸檔日誌到Bak server。
     其次是每天會對Bak server端的資料庫做還原(restore)操作。因此對於Bak server實現資料恢復所要做的是應用歸檔日誌(含定時ftp的歸檔日誌)
     將資料庫重新整理到最新時刻。對於備份如恢復的間隔也可自行定義，如每2天做一次。下面是恢復的前提條件，否則需要手動備份或還原。
          使用RMAN備份指令碼已經完成RMAN備份，且備份被ftp到備份伺服器
          使用RMAN恢復指令碼已經在備份伺服器成功進行了還原

2、Prod DB上準備測試資料

SQL> select * from v$version where rownum<2;

BANNER
----------------------------------------------------------------
Oracle Database 10g Release 10.2.0.3.0 - 64bit Production

SQL> select instance_name,host_name from v$instance;

INSTANCE_NAME    HOST_NAME
---------------- ---------------------------------------------
Ak3210           N10db03p

--為prod新增tablespace
SQL> create tablespace tbs_tmp datafile '/u02/database/Ak3210/oradata/tbs_tmp.dbf' size 10m autoextend on;

--基於新的tablespace新增表物件
SQL> create table xy(seq varchar2(20),who varchar2(20),dt varchar2(20)) tablespace tbs_tmp;

--插入資料
SQL> insert into xy select 'FirstArch','Robinson',to_char(sysdate,'yyyymmdd hh24:mi:ss') from dual;

SQL> commit;

--對當前日誌歸檔
SQL> alter system archive log current;

--下面是生成的歸檔日誌
SQL> ho ls
arch_818416637_1_157.arc

--驗證剛剛插入的記錄是否存在於歸檔日誌
SQL> ho strings arch_818416637_1_157.arc | grep "FirstArch"
        FirstArch

--再次插入新的資料
SQL> insert into xy select 'SecnodArch','Jackson',to_char(sysdate,'yyyymmdd hh:mi:ss') from dual;

SQL> commit;

SQL> alter system archive log current;

SQL> ho ls
arch_818416637_1_157.arc  arch_818416637_1_158.arc

SQL> ho strings arch_818416637_1_158.arc | grep "SecnodArch"
SecnodArch

--Author : Robinson Cheng
--Blog   : http://blog.csdn.net/robinson_0612

--將歸檔日誌檔案複製到備份伺服器
SQL> ho scp *.arc 192.168.250.101:/u02/database/Ak3210/archive
arch_818416637_1_157.arc                                       100%   34MB  34.2MB/s   00:00
arch_818416637_1_158.arc                                       100%   12KB  12.0KB/s   00:00

--Prod資料庫的歸檔情況，當前Log sequence是159
SQL> archive log list;
Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            /u02/database/Ak3210/archive/
Oldest online log sequence     157
Next log sequence to archive   159
Current log sequence           159
SQL> col name format a60
SQL> set linesize 160
SQL> alter session set nls_date_format='yyyymmdd hh24:mi:ss';  -->查詢歸檔日誌
SQL> select name,sequence#,status,COMPLETION_TIME from v$archived_log where status='A';

NAME                                                          SEQUENCE# S COMPLETION_TIME
------------------------------------------------------------ ---------- - -----------------
/u02/database/Ak3210/archive/arch_818416637_1_157.arc               157 A 20130731 16:34:30
/u02/database/Ak3210/archive/arch_818416637_1_158.arc               158 A 20130731 16:35:42

SQL> select * from xy;

SEQ                  WHO                  DT
-------------------- -------------------- --------------------
FirstArch            Robinson             20130731 16:34:15
SecnodArch           Jackson              20130731 16:35:35

3、Bak Server上DB的恢復操作

[email protected]:~> export ORACLE_SID=Ak3210
[email protected]:~> rman target / catalog rman_user/[email protected]    --在備份伺服器上連線target DB 及catalog DB

Recovery Manager: Release 10.2.0.3.0 - Production on Wed Jul 31 16:39:45 2013

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

connected to target database (not started)
connected to recovery catalog database

RMAN> startup mount;                --->啟動資料庫到mount狀態
RMAN> restore archivelog all;       --->還原所有的歸檔日誌

Starting restore at 20130731 16:41:35
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=1090 devtype=DISK

channel ORA_DISK_1: starting archive log restore to default destination
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=156
channel ORA_DISK_1: reading from backup piece /u02/database/Ak3210/flash_recovery_area/Ak3210/backupset/
  2013_07_31/o1_mf_annnn_ARCHBK_8zkgnw5t_.bkp
channel ORA_DISK_1: restored backup piece 1
piece handle=/u02/database/Ak3210/flash_recovery_area/Ak3210/backupset/2013_07_31/o1_mf_annnn_ARCHBK_8zkgnw5t_.bkp tag=ARCHBK
channel ORA_DISK_1: restore complete, elapsed time: 00:00:02
channel ORA_DISK_1: starting archive log restore to default destination
channel ORA_DISK_1: restoring archive log
archive log thread=1 sequence=155
channel ORA_DISK_1: reading from backup piece /u02/database/Ak3210/flash_recovery_area/Ak3210/backupset/
  2013_07_31/o1_mf_annnn_ARCHBK_8zkgnw5l_.bkp
channel ORA_DISK_1: restored backup piece 1
piece handle=/u02/database/Ak3210/flash_recovery_area/Ak3210/backupset/2013_07_31/o1_mf_annnn_ARCHBK_8zkgnw5l_.bkp tag=ARCHBK
channel ORA_DISK_1: restore complete, elapsed time: 00:00:08
Finished restore at 20130731 16:41:46

RMAN> list copy;                    --->檢視剛剛還原出來的日誌檔案


List of Archived Log Copies
Key     Thrd Seq     S Low Time          Name
------- ---- ------- - ----------------- ----
34428   1    155     A 20130731 01:00:50 /u02/database/Ak3210/archive/arch_818416637_1_155.arc
34427   1    156     A 20130731 15:19:54 /u02/database/Ak3210/archive/arch_818416637_1_156.arc

RMAN> catalog archivelog '/u02/database/Ak3210/archive/arch_818416637_1_157.arc';  --->將新的歸檔日誌註冊到catalog

cataloged archive log
archive log filename=/u02/database/Ak3210/archive/arch_818416637_1_157.arc recid=148 stamp=822242629

RMAN> catalog archivelog '/u02/database/Ak3210/archive/arch_818416637_1_158.arc';

cataloged archive log
archive log filename=/u02/database/Ak3210/archive/arch_818416637_1_158.arc recid=149 stamp=822242639

RMAN> list copy;                   --->再次檢視時，所有的歸檔日誌已經位於歸檔目錄 


List of Archived Log Copies
Key     Thrd Seq     S Low Time          Name
------- ---- ------- - ----------------- ----
34428   1    155     A 20130731 01:00:50 /u02/database/Ak3210/archive/arch_818416637_1_155.arc
34427   1    156     A 20130731 15:19:54 /u02/database/Ak3210/archive/arch_818416637_1_156.arc
34495   1    157     A 20130731 15:19:55 /u02/database/Ak3210/archive/arch_818416637_1_157.arc
34534   1    158     A 20130731 16:34:30 /u02/database/Ak3210/archive/arch_818416637_1_158.arc


RMAN> run{                        --->使用until方式恢復資料庫，下面給出了錯誤提示
2> set until sequence 159;
3> recover database;}

executing command: SET until clause

Starting recover at 20130731 16:45:47
using channel ORA_DISK_1

starting media recovery

archive log thread 1 sequence 155 is already on disk as file /u02/database/Ak3210/archive/arch_818416637_1_155.arc
archive log thread 1 sequence 156 is already on disk as file /u02/database/Ak3210/archive/arch_818416637_1_156.arc
archive log thread 1 sequence 157 is already on disk as file /u02/database/Ak3210/archive/arch_818416637_1_157.arc
archive log thread 1 sequence 158 is already on disk as file /u02/database/Ak3210/archive/arch_818416637_1_158.arc
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 07/31/2013 16:45:51
RMAN-06053: unable to perform media recovery because of missing log
RMAN-06025: no backup of log thread 1 seq 94 lowscn 2457942 found to restore

RMAN> exit

Recovery Manager complete.

 
[email protected]:~> export ORACLE_SID=Ak3210
[email protected]:~> sqlplus / as sysdba              --->下面在sqlplus進行恢復

SQL> recover database using backup controlfile;    --->使用基於備份的控制檔案恢復資料庫  
ORA-00279: change 2654259 generated at 07/31/2013 15:19:26 needed for thread 1
ORA-00289: suggestion : /u02/database/Ak3210/archive/arch_818416637_1_155.arc
ORA-00280: change 2654259 for thread 1 is in sequence #155

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
auto                                               --->輸入auto，自動apply日誌檔案
ORA-00279: change 2654361 generated at 07/31/2013 15:19:54 needed for thread 1
ORA-00289: suggestion : /u02/database/Ak3210/archive/arch_818416637_1_156.arc
ORA-00280: change 2654361 for thread 1 is in sequence #156
ORA-00278: log file '/u02/database/Ak3210/archive/arch_818416637_1_155.arc' no
longer needed for this recovery

ORA-00279: change 2654372 generated at 07/31/2013 15:19:55 needed for thread 1
ORA-00289: suggestion : /u02/database/Ak3210/archive/arch_818416637_1_157.arc  
ORA-00280: change 2654372 for thread 1 is in sequence #157    --->日誌apply到157
ORA-00278: log file '/u02/database/Ak3210/archive/arch_818416637_1_156.arc' no
longer needed for this recovery

ORA-00283: recovery session canceled due to errors            --->下面提示出現了一個未知的資料檔案新增到控制檔案 
ORA-01244: unnamed datafile(s) added to control file by media recovery
ORA-01110: data file 26: '/u02/database/Ak3210/oradata/tbs_tmp.dbf'

ORA-01112: media recovery not started                         --->給出錯誤資訊，提示介質恢復沒有啟動

SQL> ho ls /u02/database/Ak3210/oradata/tbs_tmp.dbf           --->檢視相應的資料檔案，因為這個檔案在備份伺服器根本就不存在
ls: /u02/database/Ak3210/oradata/tbs_tmp.dbf: No such file or directory

--->使用下面的命令來重建資料檔案，為什麼可以這樣操作呢？這個是依賴於歸檔日誌記錄了這個資料檔案                                                 
SQL> alter database create datafile 26 as '/u02/database/Ak3210/oradata/tbs_tmp.dbf';

Database altered.

SQL> ho ls /u02/database/Ak3210/oradata/tbs_tmp.dbf           --->再次檢視資料檔案已經存在了
/u02/database/Ak3210/oradata/tbs_tmp.dbf

SQL> recover database using backup controlfile;               --->再次恢復資料庫
ORA-00279: change 2656873 generated at 07/31/2013 16:33:06 needed for thread 1
ORA-00289: suggestion : /u02/database/Ak3210/archive/arch_818416637_1_157.arc
ORA-00280: change 2656873 for thread 1 is in sequence #157

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
auto                                                          --->輸入auto
ORA-00279: change 2656938 generated at 07/31/2013 16:34:30 needed for thread 1
ORA-00289: suggestion : /u02/database/Ak3210/archive/arch_818416637_1_158.arc
ORA-00280: change 2656938 for thread 1 is in sequence #158
ORA-00278: log file '/u02/database/Ak3210/archive/arch_818416637_1_157.arc' no
longer needed for this recovery

ORA-00279: change 2656966 generated at 07/31/2013 16:35:42 needed for thread 1
ORA-00289: suggestion : /u02/database/Ak3210/archive/arch_818416637_1_159.arc
ORA-00280: change 2656966 for thread 1 is in sequence #159
ORA-00278: log file '/u02/database/Ak3210/archive/arch_818416637_1_158.arc' no
longer needed for this recovery

ORA-00308: cannot open archived log
'/u02/database/Ak3210/archive/arch_818416637_1_159.arc'  --->尋找sequence為159的，實際上它是不存在的，所以找不到
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3

SQL> recover database using backup controlfile until cancel;  --->再次恢復資料庫
ORA-00279: change 2656966 generated at 07/31/2013 16:35:42 needed for thread 1
ORA-00289: suggestion : /u02/database/Ak3210/archive/arch_818416637_1_159.arc
ORA-00280: change 2656966 for thread 1 is in sequence #159

Specify log: {<RET>=suggested | filename | AUTO | CANCEL}
cancel                                                       --->輸入cancel
Media recovery cancelled.
SQL> alter database open resetlogs;                          --->以resetlogs方式open資料庫

Database altered.

SQL> select * from xy;                                       --->驗證結果，資料庫恢復成功

SEQ                  WHO                  DT
-------------------- -------------------- --------------------
FirstArch            Robinson             20130731 16:34:15
SecnodArch           Jackson              20130731 16:35:35

SQL> shutdown immediate;                                     --->關閉資料庫

[email protected]:~> export ORACLE_SID=Ak3210
[email protected]:~> rman target / catalog rman_user/[email protected] --->再次連線到catalog
RMAN> startup mount;                                          --->啟動到mount狀態

Oracle instance started
database mounted
new incarnation of database registered in recovery catalog    --->可以看到新的incarnation被註冊到了catalog  
starting full resync of recovery catalog
full resync complete

RMAN> list incarnation;                                       --->列出當前資料庫的incarnation


List of Database Incarnations
DB Key  Inc Key DB Name  DB ID            STATUS  Reset SCN  Reset Time
------- ------- -------- ---------------- --- ---------- ----------
357     358     Ak3210   1008246269       PARENT  1          20130618 09:57:17
357     34690   Ak3210   1008246269       CURRENT 2656967    20130731 16:54:39

RMAN> reset database to incarnation 358;                      --->重置當前資料庫的incarnation

database reset to incarnation 358

RMAN> resync catalog;                                         --->同步的catalog
RMAN> shutdown abort;

對於在Prod段刪除表空間和資料檔案的處理比新增較為簡單，無需要單獨處理。直接執行restore以及recover就可了。但是其對應的物理資料檔案依舊
存在於OS系統之上，可以手動刪除即可。


Oracle&nbsp;牛鵬社

相關推薦

中小型資料庫 RMAN CATALOG 備份恢復方案(三)

      在前兩篇文章中描述了中小型資料庫使用RMAN catalog設計備份與恢復方案，並給出了所有相關的指令碼來從某種車程度上模擬Oracle Data Guard以減少硬體故障帶來Prod伺服器上資料庫損失。在這邊文章中主要描述Prod資料庫的變遷在Bak serve

某電商項目PostgreSQL數據庫備份恢復方案

postgresql、備份恢復某電商項目PostgreSQL數據庫備份恢復方案：下載地址：某電商項目PostgreSQL數據庫備份恢復方案本文出自 “雲計算與大數據” 博客，請務必保留此出處http://linuxzkq.blog.51cto.com/9379412/1967693某電商項目PostgreSQ

詳解mysql備份恢復的三種實現方式

一、Mysql備份策略： 完整備份： 完整備份就是指對某一個時間點上的所有資料或應用進行的一個完整拷貝，對資料量大的，備份時間較長，當然資料在恢復的時候快。 增量備份： 備份自上一次備份（包括完整備份，差異備份，增量備份）之後所有變化的資料進行備份。恢復的時候只需要一次完整的備份加上完整備份後的多

ORACLE 資料庫 rman 全備份

環境： 源庫 10.17.80.190 目標庫 10.17.80.189 uid：ictdb —-rman 異機備份過程——————————— 【源庫】 1、準備：開啟歸檔模式 1、SQLPLUS / AS SY

Elasticsearch系列---生產資料備份恢復方案

### 前言 生產環境中執行的元件，只要有資料儲存，定時備份、災難恢復是必修課，mysql資料庫的備份方案已經非常成熟，Elasticsearch也同樣有成熟的資料備份、恢復方案，我們來了解一下。 ### 概要 本篇介紹Elasticsearch生產叢集資料的資料備份、恢復和升級的常規操作。 ###

MySQL資料庫備份和恢復方案小結

這兩天在調研MySQL資料庫的備份和恢復方案，備份物件是對大量Innodb表，或者加上少量的MyISAM表。   InnoDB備份常見問題： 檔案一致性：資料檔案、快取、日誌檔案必須保持嚴格一致。加鎖的方法沒法保證一致性，因為InnoDB後臺重新整理資料是非同步進行的。

Oracle資料庫備份與恢復的三種方法

Oracle資料庫有三種標準的備份方法，它們分別是匯出／匯入（EXP/IMP）、熱備份和冷備份。匯出備件是一種邏輯備份，冷備份和熱備份是物理備份。 　　一、 匯出／匯入（Export／Import） 　　利用Export可將資料從資料庫中提取出來，利用Impor

通過RMAN備份恢復資料庫到其他伺服器

本節演示如何通過RMAN建立的備份集，將資料庫恢復到其他伺服器。本小節執行的操作較多，一定要有一個清醒的大腦，因此趕緊把腦袋裡那堆亂七八糟的東西清除清除，要不你一定會看暈的。 設定環境如下： 源庫192.168.100.100，SID：jssbook。 目錄庫192.168.

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

創建RMAN備份 恢復目錄數據庫

efault 只讀表空間 table oracl files 最好 本地 let rac 這是前段時間給客戶做的RMAN備份策略，今天有時間整理出來，希望對大家有些幫助，如有不對的地方歡迎大家給予指點，謝謝！ 創建成恢復目錄數據庫 如果不是在本地配置RMAN 恢復目錄，

MySQL備份，恢復方案，mysqlbinlog，mysqldump，主從，主主復制

庫存 讀寫 sel erro l數據庫 reat 當前 password ima DBMS數據庫管理系統的三層模型：物理層，邏輯層以及視圖層。 物理層：決定數據的存儲形式。 邏輯層：是一張有一張的表，一行行的數據記錄。 視圖層：讓用戶看起來更方便，可有可無。 存

使用mysqldump 備份 恢復從庫報錯解決方案（ERROR 1872）

tab 註意 targe 密碼 二進制 5.6 rec 可用 alter 版本：MySQL5.7.22一、報錯現象dba:(none)> start slave;ERROR 1872 (HY000): Slave failed to initialize relay

RDS資料庫全量恢復方案

一。全量恢復  恢復最近的快照，將快找之前的資料全量恢復 二。增量恢復 下載對應的binlog日誌匯入到資料庫 三。還沒有備份的binlog日誌獲取方法 首先連線 RDS for MySQL 後檢視當前的 binlog 檔案，可以通過下面命令： show binary

如何通過rman的增量備份恢復dataguard中standby端的資料

很多正在使用dataguard的客戶，都會遇到一個棘手的問題： 在備份端與主庫同步的過程中由於網路原因或磁碟問題導致一個或多個歸檔日誌丟失，進而dataguard同步無法繼續。很多客戶都選擇了重新全庫恢復，並重新搭建dataguard。 如果我們的源資料庫非常大（超過100G的資料量），其實可以選擇一種更簡便

ORACLE資料庫資料的備份與恢復

  原創作品，轉自請在文字開頭顯眼位置註明出處：https://www.cnblogs.com/sunshine5683/p/10052949.html 資料備份恢復在資料庫管理中至關重要，今天，總結一下資料庫備份與恢復需要注意的方面和實際操作！、 一、在備份之前首先應該執行commit語句，

RMAN備份恢復之不完全恢復

ORACLE不完全恢復 基於時間的不完全恢復 恢復要求：a、資料庫開啟歸檔切要有最近的有效rman全備。b、要有需要恢復到的準確時間點。 1、 做一個rman全備 RMAN>backup database; 2、 構建幾個狀態 在資料庫裡建立scott.t1並插入資料記錄狀態為a，記錄時間t1。 在資料

MySQL使用者管理，常用MySQL語句、MySQL資料庫備份恢復

12月6日任務 13.4 mysql使用者管理 13.5 常用sql語句 13.6 mysql資料庫備份恢復   13.4 mysql使用者管理 grant all on *.* to 'user1' identified by 'passw

設定更改root密碼、連線mysql、mysql常用命令、mysql使用者管理、常用sql語句、mysql資料庫備份恢復

一、設定更改root密碼 首次直接使用mysql會提示‘該命令不存在’，原因是還沒有將該命令加入環境變數，如果要使用該命令，需要使用其絕對路徑：/usr/local/mysql/bin/mysql，為了方便，先將其加入系統環境變數： [[email p

在遠端伺服器上備份/恢復資料庫（Oracle資料庫）

備份用exp命令： exp 使用者名稱/密碼@遠端伺服器ip：埠號/使用者名稱 file=儲存的路徑 其中使用者名稱是在遠端伺服器中你要備份的庫的使用者名稱 案列：exp fund02/[email protected]遠端伺服器ip(略)：1523/

MySQL常見備份與恢復方案

MySQL常見備份方案有以下三種： mysqldump + binlog lvm + binlog xtrabackup 本例為方便演示，資料庫裡面資料為空。下面開始動手 1 2 3 4 5 6 7 8