在標準的 RMAN 備份還原指令中，不外乎會指定(I)Target database：指定被備份或還原的資料庫。(II)Catalog database 或 controlfile：儲存歷史備份資訊與參數的 repository，但其中還有一個比較不常見但相當實用，被稱為 Auxiliary database 的語法。Auxiliary database 是指 duplicate(複製)一個與 Target database 完全相同的資料庫，另外也可以被使用來作為 Data Guard 中 Physical standby 資料庫的建立。此方法大大的簡化了複製資料庫或是建立 Physical standby 資料庫所需的程序與時間，也是 Oracle 官方主要建議的建置方法之一。
本文將實作透過 RMAN 的 Auxiliary 語法來複製名稱、結構與資料完全相同的資料庫。
預計目標：
將 Pri 主機上的 demo2 資料庫透過 RMAN 完整複製成 Std 主機上的 demo2 資料庫。
環境說明：
DB 版本:10gR2
主機:Pri 資料庫:demo2(Target DB)
主機:Std 資料庫:demo1(Catalog DB)、demo2(Auxiliary DB)
前置作業:
* 使用 RMAN 產生 Pri 上 demo2 的 incremental level 0 backupset
* 將 incremental level 0 backupset 由 Pri 複製至 Std 上,並確保存放路徑完全相同
* 在 Std 上建立與 Pri 檔案路徑完全相符的目錄，包含 datafile，redo log files 與 control files
* 將 Std 上 demo2 參數 log_file_name_convert 路徑設定為與 Pri 上放置 redo logs 的路徑相符，避免複製過程中 DB 找不到參數而直接將 redo logs 放置到 flash_recovery_area 路徑下
* 在 Std 上建立一個名稱為 demo2 的 instance，並將其啟動至 nomount 狀態
執行步驟
Step1：
[oracle@Std db_1]$ export ORACLE_SID=demo2
Step2：
[oracle@Std db_1]$ rman target sys/password@pdemo2 catalog rman_user/password@demo1 auxiliary /
若連線成功，會出現類似以下的訊息：
connected to target database: DEMO2 (DBID=3656776519)
connected to recovery catalog database
connected to auxiliary database: DEMO2 (not mounted)
Step3：
RMAN> RUN {
DUPLICATE TARGET DATABASE TO DEMO2
NOFILENAMECHECK;
}
待指令完成後，Std 上的 demo2 會被自動帶至 open 的狀態，即可進行連線測試。
2009年4月16日 星期四
2009年4月11日 星期六
備份還原概論 - 3
資料庫的重建通常包含了兩個階段：1.從備份的檔案中取得所需的 Datafile。 2.套用備份時間點之後的 archived 和 online redo logs。這兩個步驟一般也被稱為 Restore 與 Recovery。
Restore 代表將 datafile 或 control file 由備份的 tape(磁帶)、disk(硬碟)或是其他 media 取回至硬碟上。
Recovery 是令 restore 完成的 datafile 去套用 archived redo logs 來將資料庫還原至備份時間點後的某特定 SCN(System Change Number)/時間。
以上圖為例，資料庫在 SCN 100 時執行了一次包含 Datafile 的備份，而且 SCN 100 之後所有的 redo logs 皆有被 archving。隨後資料庫在SCN 500 時因為硬體故障而需要還原，這時候便須要 restore 在 SCN 100 時所備份的 datafile，然後 recover 在 SCN 100 之後所備份的 archived redo logs。(亦可將SCN想像為某一特定時間點)
另外 Complete Recovery（完整回復）與 Incomplete/Point-In-Time recovery（不完整／時間點回復）在備份還原策略中也是經常被提及的兩種型態。
Complete recovery 是指將資料庫回復至離現在最近的一個時間點，已完成的交易資料不會有所損失。一般所指的回復通常就是 Complete recovery。
然而，也會有將資料庫回復至過去某特定時間點的需求。舉例來說，還原一些使用者造成的錯誤，像是誤刪資料或表格的情況。這種案例的話，則是需要將資料庫回復至誤刪動作發生前。這種回復方式就被稱為 Incomplete/Point-In-Time recovery。另外這種還原方式也是當 archived redo logs 有不連續或損毀情況下的唯一解決方法。
Restore 代表將 datafile 或 control file 由備份的 tape(磁帶)、disk(硬碟)或是其他 media 取回至硬碟上。
Recovery 是令 restore 完成的 datafile 去套用 archived redo logs 來將資料庫還原至備份時間點後的某特定 SCN(System Change Number)/時間。
以上圖為例，資料庫在 SCN 100 時執行了一次包含 Datafile 的備份，而且 SCN 100 之後所有的 redo logs 皆有被 archving。隨後資料庫在SCN 500 時因為硬體故障而需要還原，這時候便須要 restore 在 SCN 100 時所備份的 datafile，然後 recover 在 SCN 100 之後所備份的 archived redo logs。(亦可將SCN想像為某一特定時間點)
另外 Complete Recovery（完整回復）與 Incomplete/Point-In-Time recovery（不完整／時間點回復）在備份還原策略中也是經常被提及的兩種型態。
Complete recovery 是指將資料庫回復至離現在最近的一個時間點，已完成的交易資料不會有所損失。一般所指的回復通常就是 Complete recovery。
然而，也會有將資料庫回復至過去某特定時間點的需求。舉例來說，還原一些使用者造成的錯誤，像是誤刪資料或表格的情況。這種案例的話，則是需要將資料庫回復至誤刪動作發生前。這種回復方式就被稱為 Incomplete/Point-In-Time recovery。另外這種還原方式也是當 archived redo logs 有不連續或損毀情況下的唯一解決方法。
2009年4月5日 星期日
備份還原概論 - 2
Physical backup 通常是指備份供資料庫儲存的實體檔案，因此透過了解 physical database structure(資料庫實體結構)將有助於整體性策略的擬定與執行。本文將就與備份還原相關的資料庫實體結構來進行討論，其中包含了：Datafiles and Data Blocks，Redo Logs，Control Files.
* Datafiles and Data Blocks:資料庫通常是由一個/多個被稱為tablespace space(表格空間)的 logical storage units(邏輯存儲單元)所組成。而每個 tablespace 則是由一個/多個OS層中 physical files 所構成,一般稱為 datafiles。在 Datafiles 中是使用 Data Blocks 來作為存放資料的 smallest units of storage(最小儲存單元)。因此 Datafiles and Data Blocks 是備份還原中是一個很重要的部分。
* Redo Logs:Redo logs 紀錄資料庫中 data files 異動的資訊。也就是說當資料有所異動時，資料庫會將其變動的部份先紀錄在 redo logs，然後再寫入到 datafiles。Redo logs 儲存變動資料的特性在資料庫備份中也扮演了一個很重要的腳色。舉例來說，在某特定時間點備份的 datafiles,可使用在該時間點後備份的 redo logs 來將資料還原至 datafiles 備份時間點後的任一時間。
但由於 redo logs 本身是被循環使用,因此保存 redo logs 是亦是備份的一大要素。在 Oracle 中是透過 archiving 的程序來備份存有資料的 redo logs,亦被稱為 archived redo log files。
* Control Files:包含了資料庫實體結構與狀態的資訊，而這些資訊正是資料庫還原程序所不可或缺的，例如 database checkpoint，current redo log file，datafile header checkpoint。缺少 control file 將會讓整個資料庫還原變的相當困難。
接下來的主題將討論基礎的備份還原程序。
* Datafiles and Data Blocks:資料庫通常是由一個/多個被稱為tablespace space(表格空間)的 logical storage units(邏輯存儲單元)所組成。而每個 tablespace 則是由一個/多個OS層中 physical files 所構成,一般稱為 datafiles。在 Datafiles 中是使用 Data Blocks 來作為存放資料的 smallest units of storage(最小儲存單元)。因此 Datafiles and Data Blocks 是備份還原中是一個很重要的部分。
* Redo Logs:Redo logs 紀錄資料庫中 data files 異動的資訊。也就是說當資料有所異動時，資料庫會將其變動的部份先紀錄在 redo logs，然後再寫入到 datafiles。Redo logs 儲存變動資料的特性在資料庫備份中也扮演了一個很重要的腳色。舉例來說，在某特定時間點備份的 datafiles,可使用在該時間點後備份的 redo logs 來將資料還原至 datafiles 備份時間點後的任一時間。
但由於 redo logs 本身是被循環使用,因此保存 redo logs 是亦是備份的一大要素。在 Oracle 中是透過 archiving 的程序來備份存有資料的 redo logs,亦被稱為 archived redo log files。
* Control Files:包含了資料庫實體結構與狀態的資訊，而這些資訊正是資料庫還原程序所不可或缺的，例如 database checkpoint，current redo log file，datafile header checkpoint。缺少 control file 將會讓整個資料庫還原變的相當困難。
接下來的主題將討論基礎的備份還原程序。
2009年4月1日 星期三
備份還原概論 - 1
一般來講，備份還原意指多種不同保護資料庫的策略與程序，避免資料遺失(Data Loss)以及任何資料遺失後的資料庫重建(Database Reconstructing)。
備份又可被區分為 physical backup(物理備份)與 logical backup(邏輯備份)。
Physical backup 通常是指備份供資料庫儲存與還原的實體檔案，例如 datafile，controlfile 和 archived redo logs。
Logical backup 一般是使用 Oracle export utility 將 logical data(例如:table，index 或是 stored procedures)匯出為 binary 檔案的動作。
通常當我們提到備份還原策略時，主要是以 physical backup 為主,logical backup 為輔。因此在本文內提到的 backup，皆是指 physical backup。
Physical backups 主要又可被區分為兩種:
* Recovery Manager(RMAN):Oracle 提供的整合性備份工具，除了提供備份與還原的功能外，還可以維護歷史性的備份。
* User-Managed Backup:使用者直接使用系統指令(OS commands)與 SQL*Plus 的功能來進行備份還原。相關文章
雖然 Oracle 提供這兩種備份還原方法，但官方建議採用 RMAN 來作為主要方案。因為 RMAN 除了使用上較 User-Managed Backup 容易外,還可建構不同系統間的備份還原以及其他相關應用.
但不論最終是採用 RMAN 或 User-Managed Backup，也應該將 data export 這種 logical backup 做為一種互補性的應用，納入整體的備份策略中。
備份又可被區分為 physical backup(物理備份)與 logical backup(邏輯備份)。
Physical backup 通常是指備份供資料庫儲存與還原的實體檔案，例如 datafile，controlfile 和 archived redo logs。
Logical backup 一般是使用 Oracle export utility 將 logical data(例如:table，index 或是 stored procedures)匯出為 binary 檔案的動作。
通常當我們提到備份還原策略時，主要是以 physical backup 為主,logical backup 為輔。因此在本文內提到的 backup，皆是指 physical backup。
Physical backups 主要又可被區分為兩種:
* Recovery Manager(RMAN):Oracle 提供的整合性備份工具，除了提供備份與還原的功能外，還可以維護歷史性的備份。
* User-Managed Backup:使用者直接使用系統指令(OS commands)與 SQL*Plus 的功能來進行備份還原。相關文章
雖然 Oracle 提供這兩種備份還原方法，但官方建議採用 RMAN 來作為主要方案。因為 RMAN 除了使用上較 User-Managed Backup 容易外,還可建構不同系統間的備份還原以及其他相關應用.
但不論最終是採用 RMAN 或 User-Managed Backup，也應該將 data export 這種 logical backup 做為一種互補性的應用，納入整體的備份策略中。
2009年3月14日 星期六
Cold Backup n Recovery (冷備份 n 還原)
Oracle DB提供了多種備份還原機制(Backup n Recovery Mechanism)來因應不同層級的備份需求. 其中主要可分為 Cold Backup(冷備份)與 Hot Backup(熱備份). Cold Backup 需在資料庫關閉的情況下進行, Hot Backup 則可在資料庫運行時備份. 這兩種備份機制各有其優缺點,端看組織需求來決定採用何種備份機制.
基於成本考量,並非所有組織都有額外的測試機來執行備份還原演練,但這卻是資安演練中不可獲缺的一環. 因此這個案例要在不影響 Production 的運作前提下,將每日 Production 的 Cold Backup 檔案,使用不同的 SID 與檔案目錄還原至同一台 Production 主機上,驗證該 Cold Backup 的有效性.
步驟:
1. 將每日備份的 cold backup files,完整複製(不包含 control files)至新目錄下.
2. 由 Production 的 spfile 來產生新 pfile,並修改相關參數至對應的 SID 與新目錄路徑.
SQL> create pfile from spfile;
3. 由 Production 的 crontol file 來建立一個文字型態的新 control file.
SQL> alter database backup controlfile to trace;
4. 編輯該 crontol file,複製由 CREATE CONTROLFILE SET DATABASE 開頭至 CHARACTER SET ZHT16MSWIN950 結尾的段落至新檔案 new_control.sql. 調整檔案內容至新的路徑與 DBNAME,並將 REUSE 改為 SET,NORESETLOG 改為 RESETLOG.
5. 修改 OS oracle user profile 的相關參數(ex:ORACLE_SID)
6. 使用修改過的 pfile 來啟動新 DB 至 NOMOUNT 狀態
SQL> startup nomount pfile='/u02/app/oracle/pfile';
7. 執行調整過的 new_control
SQL> @new_control.sql;
8. 將 DB 啟動至 OPEN 狀態
SQL> alter database open resetlogs;
最後可透過 select v$instance 與 v$recovery_log 來確定新 DB 已經開啟至正確狀態.
基於成本考量,並非所有組織都有額外的測試機來執行備份還原演練,但這卻是資安演練中不可獲缺的一環. 因此這個案例要在不影響 Production 的運作前提下,將每日 Production 的 Cold Backup 檔案,使用不同的 SID 與檔案目錄還原至同一台 Production 主機上,驗證該 Cold Backup 的有效性.
步驟:
1. 將每日備份的 cold backup files,完整複製(不包含 control files)至新目錄下.
2. 由 Production 的 spfile 來產生新 pfile,並修改相關參數至對應的 SID 與新目錄路徑.
SQL> create pfile from spfile;
3. 由 Production 的 crontol file 來建立一個文字型態的新 control file.
SQL> alter database backup controlfile to trace;
4. 編輯該 crontol file,複製由 CREATE CONTROLFILE SET DATABASE 開頭至 CHARACTER SET ZHT16MSWIN950 結尾的段落至新檔案 new_control.sql. 調整檔案內容至新的路徑與 DBNAME,並將 REUSE 改為 SET,NORESETLOG 改為 RESETLOG.
5. 修改 OS oracle user profile 的相關參數(ex:ORACLE_SID)
6. 使用修改過的 pfile 來啟動新 DB 至 NOMOUNT 狀態
SQL> startup nomount pfile='/u02/app/oracle/pfile';
7. 執行調整過的 new_control
SQL> @new_control.sql;
8. 將 DB 啟動至 OPEN 狀態
SQL> alter database open resetlogs;
最後可透過 select v$instance 與 v$recovery_log 來確定新 DB 已經開啟至正確狀態.
訂閱：
文章 (Atom)