##sample 0 不完全恢復之后,open resetlogs之前,怎么快速的檢查數據庫是否處於一致性的狀態?
https://blog.csdn.net/msdnchina/article/details/55515313
How to quickly check that Database is consistent after incomplete recovery (Point in Time Recovery) before OPEN RESETLOGS (Doc ID 1354256.1)
（主要思想是檢查數據庫是否同步，文件是否是fuzzy）
通過從物理datafile中讀取 datafile header來查詢datafile的當前狀態和PIT(Point In Time up to which the datafiles have been recovered)
SQL> select fuzzy, status, error, recover, checkpoint_change#, checkpoint_time, count(*)
from v$datafile_header
group by fuzzy, status, error, recover, checkpoint_change#, checkpoint_time ;
For Unix:
% export NLS_DATE_FORMAT='dd-mon-rr hh24:mi:ss'
% rman target /
For Windows:
> set nls_date_format=dd-mon-rr:hh24:mi:ss
> rman target /
找到備份的命令:
RMAN> LIST BACKUP OF DATABASE COMPLETED AFTER '<date>';
or
RMAN> LIST BACKUP OF DATABASE COMPLETED AFTER 'sysdate -n';
設置<date> 來限制backup命令的輸出,以便定位到你想要的backup的輸出,注意完成時間,
對於一個multi-piece的backup,請注意最后一個被創建的backuppiece的完成時間.
在本文中,運行SQL查詢語句時,你應該在session級別設置NLS_DATE_FORMAT,如下:
SQL> alter session set nls_date_format='DD-MON-YYYY HH24:MI:SS';
檢查項 1:Checkpoint Time and Fuzziness
目標:驗證被恢復(recovered)到想要的時間點(point in time--PIT)的datafiles,這些數據文件是一致的(FUZZY=NO)
通過從物理datafile中讀取 datafile header來查詢datafile的當前狀態和PIT(Point In Time up to which the datafiles have been recovered)
SQL> select fuzzy, status, error, recover, checkpoint_change#, checkpoint_time, count(*)
from v$datafile_header
group by fuzzy, status, error, recover, checkpoint_change#, checkpoint_time ;
FUZ STATUS ERROR REC CHECKPOINT_CHANGE# CHECKPOINT_TIME COUNT(*)
--- ------- --------------- --- ------------------ -------------------- ----------
NO ONLINE 5311260 31-AUG-2011 23:10:14 6
YES ONLINE 5311260 31-AUG-2011 23:10:14 1
a)驗證 checkpoint_time/checkpoint_change# 符合你想要的 UNTIL TIME/SCN,如果不符合,繼續recover database,若是你有更多的archived log的話
b)如果有些datafile的FUZZY=YES,這意味着需要更多的recovery.
如果這些歸檔日志被丟失了,定位這些datafile並決定我們是否可以將這些datafile置於offline(譯者注:當然可以用bbed進行修改,只不過風險自當,責任自負)
警告:如果把datafile置為offline,我們會丟失這些datafile中的數據.
如果這些datafile屬於system or undo 表空間,沒有合適的分析,我們決不能把這些文件置為offline狀態.請聯系Oracle Support以獲取進一步的action.
SQL> select file#, substr(name, 1, 50), substr(tablespace_name, 1, 15), undo_opt_current_change# from v$datafile_header where fuzzy='YES' ;
FILE# SUBSTR(NAME,1,50) SUBSTR(TABLESPA UNDO_OPT_CURRENT_CHANGE#
---------- -------------------------------------------------- --------------- ------------------------
3 /u01/app/oracle/oradata/prod111/undotbs01.dbf
###參考Step by Step method to create Primary/Standby Database from Standby Backup (文檔 ID 1604251.1)
Note:
Only from 11g, backup of controlfile which is taken as " Backup current controlfile" can be restored at standby database as
(a) current controlfile ( restore controlfile from '<>.BKP'; )
(b) standby controlfie ( restore standby controlfile from <>.bkp')
Step a1:
init ( minimum required parameter )
>>>
DB_NAME=MASTERDB # Database name of standby/primary
DB_UNIQUE_NAME="MASTERDBSNGS" # can be set for differentiation
control_files='/<path><>.CTL'
log_file_name_convert = '<your current standby REDO location >,< your new host location >' ( # optional )
<<<
Step a2:
$ export ORACLE_SID=MASTERDBSNGS
$ sqlplus / as sysdba
sql> startup nomount;
Step a3:
In another session
$ export ORACLE_SID=MASTERDBSNGS
$ rman target /
RMAN> restore controlfile from '<backup location/ctl.BKP'; for ( case a)
RMAN> alter database mount;
RMAN> catalog start with '< backup piece location>';
RMAN
run {
allocate channel t1 type disk;
allocate channel t2 type disk;
set newname for datafile 1 to '< new location/ DF name> ';
set newname for datafile 2 to '< new location/ DF name> ';
...
set until sequence 212; # this is to set as per your requirement
restore database;
switch datafile all;
recover database;
}
Step a4: alter database open resetlogs.
@ mount stage
SQL> alter database rename file '<old file location and name>' to '<new location and name>';
a4.1 Option (1) alter database open resetlogs;
a4.2 Option (b) Activate the Standby
SQL> Alter database activate physical standby database ;
SQL> Alter database open;
n 11.2.0.4 , you can follow below workaround if patch 18455956 NOT applied.
Since controlfile type would be 'STANDBY step (a4) will fail at 'Alter database open resetlogs'
With any of below option you can open the database as Primary role
Option (a) Create trace file of controlfile
recreate the controlfile from trace
recover database using backup controlfile until cancel # Cancel the recovery
alter database open resetlogs
Option (b) Activate the Standby
SQL> Alter database activate physical standby database ;
SQL> Alter database open;
##sample 1 如何對10g容災庫進行一個一致性備份
How to take consistent backups at standby site (文檔 ID 1292126.1)
-》1.備庫上停下MRP
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
備庫上執行
RMAN> backup database plus archivelog ;
##10G 主庫上執行
RMAN> backup current controlfile;
（Note: In 10g, you will need to backup the controlfile from the primary site.
The above will result in a consistent, self-contained backup.）
3) 備份重啟MRP restart managed recovery:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNETED FROM SESSION;
3) 使用備份恢復 restart managed recovery:
To restore from this backup:
RMAN> startup nomount;
RMAN> restore controlfile from 'controlfile backuppiece name and location';
RMAN> alter database mount;
RMAN> restore database;
RMAN> recover database noredo;
##sample 2 如何在11g ADG環境備份一個一致性的備份；
Howto make a consistent RMAN backup in an Standby database in Active DataGuard mode (文檔 ID 1419923.1)
1.如果在11.2.0.4 主庫上備份，只要執行這條命令即可完成一致性備份。
Consistent means, that the backup is having the datafiles and the related archived redologs, so that it can be opened with this backup. This done on the Primary database by using :
RMAN> backup database plus archivelog;
This will execute the following :
Backup the existing archived redologs
Backup the datafiles
Switch a logfile
Backup all the archives again, but this time it will include all the archived redologs created during and just after the datafile backup. This are the archives which are required to make the datafile backup consistent.
2.如果在11.2.0.4 上standby db ADG上執行,就需要顯性在主庫上執行如下命令，對當前日志進行歸檔，
因為在恢復模式下對備用數據庫進行的備份也不會得到所有歸檔日志，除非在主日志上執行切換並進行第二次存檔日志備份, 否則需要第二次備份存檔日志。
-》1.備庫上准備遠程切換主庫的歸檔日志的腳本
shell script : /usr/local/bin/logswitch.sh
#!/bin/ksh
#
# Change <passwd>
# <primary_db>
#
sqlplus -s "sys/<passwd>@<primary_db> as sysdba" <<EOF
alter system archive log current;
exit
EOF
% chmod 755 /usr/local/bin/logswitch.sh
-》2 備庫上執行如下命令，歸檔進行二次備份。
Example of RMAN backup script on the Active Dataguard Standby database
% rman target / catalog <un/pw@catalog_db>
Rman> Configure controlfile autobackup on ;--------------> This would ensure Controlfile auto backup
RMAN> backup database plus archivelog delete input;
host "/usr/local/bin/logswitch.sh";
backup archivelog all delete input;
注意：
（A backup taken of a MOUNTED standby database in recovery mode will also not get all of the archived logs required unless a switch is performed on the primary and a second archived log backup is taken.
）
（The missing 'Log Switch' by making an explicit 'Log Switch' on the Primary.
also does apply to the BASIC DATA GUARD case as well where the database is MOUNTED and in
managed recovery mode (MRP).
A backup taken of a MOUNTED standby database in recovery mode will also not get all of the archived logs required unless a switch is performed on the primary and a second archived log backup is taken.
）
通過在主服務器上創建顯式 "日志切換" 來丟失 "日志切換"。
也適用於基本數據保護表的情況下, 以及在其中的數據庫是移動和在托管恢復模式 (MRP)。
在恢復模式下對備用數據庫進行的備份也不會得到所有歸檔日志，除非在主日志上執行切換並進行第二次存檔日志備份, 否則需要存檔日志。