- 1深入理解 uni-app 页面生命周期（一）：onLoad vs onShow_uni-app onload
- 2Bash编程：readonly命令_bash-3.2 command readonly
- 3现代游戏引擎架构
- 4【愚公系列】2023年12月 HarmonyOS教学课程 062-ArkTS语言基础类库（XML）_arkts xml
- 5获取docker镜像内文件_docker镜像提取文件
- 6Kafka文件存储机制详解_简述kafka的存储方式
- 7解决虚拟机桥接模式无法上网的问题_虚拟机桥接模式连不上网
- 8Plugin [id: ‘com.android.application‘, version: ‘7.*.*‘, apply: false] was not found 的解决办法_plugin [id: 'com.android.application', version: '7
- 9Exception in thread “main“ java.lang.NoClassDefFoundError: org/apache/flink/api/common/typeinfo/Type_"exception in thread \"main\" java.lang.noclassdef
- 10计算机网络（谢希仁）— 第三章-数据链路层（三）_三个广播域的拓扑
19c datagarud roll forward
赞
踩
NOTE: In the images and/or the document content below, the user information and environment data used represents fictitious data from the
Oracle sample schema(s), Public Documentation delivered with an Oracle database product or other training material. Any similarity to actual
environments, actual persons, living or dead, is purely coincidental and not intended in any manner.
For the purposes of this document, the following fictitious environment is used as an example to describe the procedure:
Standby Name: SBY180
Primary Name: PRM180
Directory Name: /u01/app/oracle and all sub-directories
Note, this procedure is version dependent. The procedure described in this note is for Oracle 18c and higher.
For 11g see the following procedure:
11g Steps to perform for Rolling Forward a Physical Standby Database using RMAN Incremental Backup. (Doc ID 836986.1)
For 12.1 and 12.2, see the following procedure:
12c How to Roll Forward a Standby Database Using Recover Database From Service (Doc ID 2850185.1)
Typically, when rolling forward a physical standby database using primary incremental backup, multiple steps are required:
- Identify the Start SCN on Standby for performing incremental backup on primary
- Perform incremental backup on primary with FROM SCN clause
- Move the backup-pieces from primary to standby
- Catalog the backup-piece on Standby
- Perform recovery on standby using recover database noredo
- Refresh standby controlfile again from primary
Starting from 12.1, we could use "RECOVER DATABASE FROM SERVICE"command which will automate a few steps like performing incremental backup on primary, transfer the backup-pieces to standby over network and perform recovery on standby. However, we still had to manually refresh the standby controlfile and manually restore newly-added datafiles. These steps required manual efforts and are error prone especially when standby files are physically located in a path different to that of primary.
Starting with 18.1, we can use a single command to refresh the standby with changes made on primary:
RMAN> RECOVER STANDBY DATABASE FROM SERVICE primary_connect_identifier;
This command will internally keep track of standby file locations, refresh standby controlfile from primary, update the new standby controlfile with standby file names, perform incremental backup on primary, transfer the backup-pieces over network to standby and perform recovery on standby
SOLUTION
1. To refresh the standby, ensure that managed recovery is stopped on standby:
SQL> recover managed standby database cancel;
NOTE: If you do not stop managed recovery, you will get RMAN-05150 error during execution:
RMAN> RECOVER STANDBY DATABASE FROM SERVICE PRM180; RMAN-03090: Starting recover at 03-AUG-18 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of recover command at 08/03/2018 12:33:05 RMAN-05150: Managed Recovery Process must be disabled before running RECOVER STANDBY DATABASE.
NOTE: If using dataguard broker, ensure to stop recovery using broker:
DGMGRL> EDIT DATABASE '<standby_db>' SET STATE='APPLY-OFF';
2.If the standby is RAC with more than one instance, make sure only the instance from which recover standby command will be executed is mounted and all other instances are shutdown to avoid RMAN-05157
Starting recover at 22-FEB-21 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of recover command at 02/22/2021 15:18:54 RMAN-05157: The database must not be mounted on any other instance for RECOVER STANDBY DATABASE command.
Starting recover at 22-FEB-21 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of recover command at 02/22/2021 15:18:54 RMAN-05157: The database must not be mounted on any other instance for RECOVER STANDBY DATABASE command.
3.Ensure that Oracle Net connectivity is established between the physical standby database and the primary database by adding an entry corresponding to the primary database in the tnsnames.ora file of the physical standby database. In below example, PRM180 is the connect identifier for primary.
4. Connect RMAN to standby as target and run "RECOVER STANDBY DATABASE FROM SERVICE" command. Find below an example run for the command:
$ export ORACLE_SID=SBY180
$ rman target /
RMAN> RECOVER STANDBY DATABASE FROM SERVICE PRM180;
RMAN-03090: Starting recover at 03-AUG-18
RMAN-06009: using target database control file instead of recovery catalog
RMAN-06196: Oracle instance started
Total System Global Area 671086904 bytes
Fixed Size 8661304 bytes
Variable Size 188743680 bytes
Database Buffers 465567744 bytes
Redo Buffers 8114176 bytes
RMAN-08161: contents of Memory Script:
{
restore standby controlfile from service 'PRM180';
alter database mount standby database;
}
RMAN-08162: executing Memory Script
RMAN-03090: Starting restore at 03-AUG-18
RMAN-08030: allocated channel: ORA_DISK_1
RMAN-08500: channel ORA_DISK_1: SID=141 device type=DISK
RMAN-08016: channel ORA_DISK_1: starting datafile backup set restore
RMAN-08169: channel ORA_DISK_1: using network backup set from service PRM180
RMAN-08021: channel ORA_DISK_1: restoring control file
RMAN-08180: channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
RMAN-08505: output file name=/u01/app/oracle/oradata/SBY180/control01.ctl
RMAN-03091: Finished restore at 03-AUG-18
RMAN-08031: released channel: ORA_DISK_1
RMAN-06986: Statement processed
RMAN-06958: Executing: alter system set standby_file_management=manual
RMAN-08161: contents of Memory Script:
{
recover database from service 'PRM180';
}
RMAN-08162: executing Memory Script
RMAN-03090: Starting recover at 03-AUG-18
RMAN-08030: allocated channel: ORA_DISK_1
RMAN-08500: channel ORA_DISK_1: SID=149 device type=DISK
RMAN-06179: datafile 4 not processed because file is read-only
RMAN-08039: channel ORA_DISK_1: starting incremental datafile backup set restore
RMAN-08169: channel ORA_DISK_1: using network backup set from service PRM180
RMAN-08509: destination for restore of datafile 00001: /u01/app/oracle/oradata/SBY180/system01.dbf
RMAN-08180: channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
RMAN-08039: channel ORA_DISK_1: starting incremental datafile backup set restore
RMAN-08169: channel ORA_DISK_1: using network backup set from service PRM180
RMAN-08509: destination for restore of datafile 00002: /u01/app/oracle/oradata/SBY180/sysaux01.dbf
RMAN-08180: channel ORA_DISK_1: restore complete, elapsed time: 00:00:07
RMAN-08039: channel ORA_DISK_1: starting incremental datafile backup set restore
RMAN-08169: channel ORA_DISK_1: using network backup set from service PRM180
RMAN-08509: destination for restore of datafile 00003: /u01/app/oracle/oradata/SBY180/undotbs01.dbf
RMAN-08180: channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
RMAN-08054: starting media recovery
RMAN-08181: media recovery complete, elapsed time: 00:00:00
RMAN-03091: Finished recover at 03-AUG-18
RMAN-06958: Executing: alter system set standby_file_management=auto
RMAN-03091: Finished recover at 03-AUG-18
NOTE:
If you face errors about SBT channels during the process, ensure that below is set on Primary (since the controlfile is automatically refreshed from Primary)
RMAN> CONFIGURE DEFAULT DEVICE TYPE TO DISK;
RMAN> CONFIGURE CHANNEL DEVICE TYPE SBT CLEAR;
If your disk channels on primary are configured with CONNECT clause, then, the disk channel allocation won't work on standby. In that case, we need to clear the configuration of DISK channels also on Primary:
RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK CLEAR;
---------------------------19c 以下
Oracle Database - Enterprise Edition - Version 12.1.0.1 to 12.2.0.1 [Release 12.1 to 12.2]
Information in this document applies to any platform.
GOAL
Note, this procedure is version dependent. The procedure described in this note is for Oracle 12.1 and 12.2.
For 11g see the following procedure:
11g Steps to perform for Rolling Forward a Physical Standby Database using RMAN Incremental Backup. (Doc ID 836986.1)
For 18c and higher, see the following procedure:
Roll Forward Physical Standby Using RMAN Incremental Backup in Single Command (Doc ID 2431311.1)
Utilize RECOVER DATABASE FROM SERVICE to skip over a large gap in redo or a gap in redo which is unresolvable(missing logs).
SOLUTION
In cases where there is a large redo gap between the primary and standby or when there is an unresolvable gap of missing logs, the standby database can be 'rolled forward' using the RECOVER DATABASE FROM SERVICE command introduced in 12c. This process recovers blocks from the primary to the standby which have changed since the standby database SCN. This is more efficient in catching up the standby rather than applying every individual change to the database as is done with managed recovery.
Follow the steps to roll forward a standby database using RECOVER DATABASE FROM SERVICE.
NOTE: Cleaning up any backups from orphaned incarnations (e.g. snapshot standby incarnations) on the standby before executing this process is recommended.
Stop Managed Recovery and Redo Transport
via Data Guard Broker connected to any database in the configuration:
DGMGRL> edit database <primary> set state=TRANSPORT-OFF;
Succeeded.
DGMGRL> edit database <standby> set state=APPLY-OFF;
Succeeded.
OR
via SQLPLUS (if Data Guard Broker is not configured):
From the Primary database:
SQL> alter system set LOG_ARCHIVE_DEST_STATE_<#>=DEFER;
System altered.
SQL> alter system archive log current;
From the Standby database:
SQL> recover managed standby database cancel;
Media recovery complete.
Save Existing Logfile Names
This roll forward process will create new online redo logs and standby redo logs, leaving the existing logs as orphans using up space. Save the logfile names with the following query to be removed later in the process.
SQL> set heading off linesize 999 pagesize 0 feedback off trimspool on
SQL> spool /tmp/delete_logfiles.log
SQL> select member from v$logfile;
SQL> spool off
Refresh Standby Control File From Primary
The standby database control file must be refreshed to advance the control file SCN. This new standby control file will contain information about any new files added to the database since the current standby SCN. Additional steps are described to update the locations of the standby files in the control file and restore any of those newly added files.
Document the Current SCN for the Standby
Run the command in the example below on the standby database and save the SCN for later use.
RMAN> select current_scn from v$database;
CURRENT_SCN#
------------------
644203931
Save Current RMAN Configuration Settings
Refreshing the standby control file from the primary control file overwrites the RMAN configuration items specific to the standby database.
Create a script to restore the current RMAN configuration settings. This will be used after the control file is restored from the primary.
NOTE: This step is when using target database control file instead of recovery catalog
On the standby:
$ $ rman target / nocatalog log=/tmp/RMAN_settings.log <<EOF
show all;
EOF
To remove the unnecessary commands output and the RETENTION POLICY command, which cannot be executed on a standby, run the following:
$ grep ^CONFIGURE /tmp/RMAN_settings.log | grep -v 'RETENTION POLICY' >/tmp/RMAN_settings.rman
$ rm /tmp/RMAN_settings.log
Refresh the Standby Control File
Start one instance in nomount and restore the control file from the primary database.
$ srvctl stop database -d <db> -o immediate
$ rman target / nocatalog
RMAN> startup nomount
RMAN> restore standby controlfile from service <tns alias for primary database>;
Starting restore at <date>
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=2824 instance=<standby instance> device type=DISK
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: using network backup set from service <primary service>
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:10
output file name=<standby control file>
Finished restore at <date>
Replace RMAN Configuration Settings and Remove Orphaned Online and Standby Redo Log Files
Mount the database and replace the RMAN configuration with the saved script
RMAN> alter database mount;
released channel: ORA_DISK_1
Statement processed
RMAN> @/tmp/RMAN_settings.rman
<output from CONFIGURE commands in the script>
RMAN> exit
$ rm /tmp/RMAN_settings.rman
Then remove the orphaned log files saved in /tmp/delete_logfiles.log and delete the /tmp/delete_logfiles.log file
Catalog Standby Database Files to the Refreshed Control File
At this point, the refreshed control file has file locations and metadata from the primary database. Use the RMAN CATALOG command to update the control file with standby database file locations.
RMAN> catalog start with '<DATA DISKGROUP>/<standby db_unique_name/';
Starting implicit crosscheck backup at 24-FEB-22
<...listing of files found...>
Do you really want to catalog the above files (enter YES or NO)? YES
cataloging files...
[There may be error reported for files which cannot be cataloged. These can be ignored.]
RMAN> catalog start with '<RECO DISKGROUP>/<standby db_unique_name>/';
searching for all files that match the pattern <RECO DISKGROUP>/<standby db_unique_name>
no files found to be unknown to the database <-- often times there are no files found on RECO
NOTE: If the standby was used as a snapshot standby check that the standby controlfile incarnation matches that of the primary. It is possible that the incarnation was not set correctly during the catalog command, especially if backups were taken during the snapshot database and not deleted.
Use RMAN> LIST INCARNATION on each database to compare incarnations and RMAN> RESET DATABASE INCARNATION TO x to set the standby database incarnation if necessary. Cleaning up any backups from orphaned incarnations before executing this process is recommended.
Restore Any Missing Files
Files would be missing if they were created between the SCN of the standby and the SCN of the refreshed control file.
Using the SCN documented in step 'Document the Current SCN for the Standby', identify any missing files and restore them.
RMAN> select file# from v$datafile where creation_change# >= 644203931;
-
If files are returned by the query, files must be restored from the primary and the existing files.
Restore Missing Datatfiles
RMAN> run {
allocate channel c1 type disk;
allocate channel c2 type disk;
allocate channel c3 type disk;
allocate channel c4 type disk;
allocate channel c5 type disk;
allocate channel c6 type disk;
allocate channel c7 type disk;
allocate channel c8 type disk;
set newname for database to NEW;
restore datafile <comma separate list of files> from service <tns alias for primary database> section size <section size>;
}
NOTE: For SECTION SIZE, query the primary database datafile sizes for those files being restored.
If the largest file is
- <15TB use section size of 64GB
- >15TB and <30TB used section size of 128G
- >30TB and <60TB used section size of 256G
- >60TB use section size of 512G
NOTE: For cases where the primary database is not encrypted and the standby in encrypted, the files should be restored using the AS ENCRYPTED clause. This clause is not valid on RESTORE DATAFILE so the tablespace(s) of the missing datafile(s) must be restored using RESTORE TABLESPACE instead and incorporate the 'AS ENCRYPTED' clause.
For example: RESTORE TABLESPACE <tablespace name> FROM SERVICE <tns alias for primary database> SECTION SIZE <section size> AS ENCRYPTED;
Switch Database to Copy
To make the restored and pre-existing standby datafile locations permanent in the controlfile, switch to the cataloged copies of the datafiles.
RMAN> switch database to copy;
Clean Up Orphaned Files
In the event that any file was deleted between the SCN of the standby and the SCN of the refreshed control file it will remain a datafilecopy in RMAN. Remove any datafilecopy to remove the unneeded file.
RMAN> list datafilecopy all;
using target database control file instead of recovery catalog
List of Datafile Copies
=======================
Key File S Completion Time Ckp SCN Ckp Time Sparse
------- ---- - --------------- ---------- --------------- ------
<#> <#> A <date> <#> <date> NO
Name: <orphaned datafilecopy name>
RMAN> delete datafilecopy all;
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=2620 instance=<instance name> device type=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: SID=1737 instance=<instance name> device type=DISK
List of Datafile Copies
=======================
Key File S Completion Time Ckp SCN Ckp Time Sparse
------- ---- - --------------- ---------- --------------- ------
<#> <#> A <date> <#> <date> NO
Name: <orphaned datafilecopy name>
Do you really want to delete the above objects (enter YES or NO)? YES
deleted datafile copy
datafile copy file name=<orphaned datafilecopy name> RECID=<#> STAMP=<#>
Deleted 1 objects
Clear Online Redo Logs and Standby Redo Logs
Execute the following query in SQL*PLUS on the standby to create new logfiles.
SQL> begin
for log_cur in ( select group# group_no from v$log )
loop
execute immediate 'alter database clear logfile group '||log_cur.group_no;
end loop;
end;
/
SQL> begin
for log_cur in ( select group# group_no from v$standby_log )
loop
execute immediate 'alter database clear logfile group '||log_cur.group_no;
end loop;
end;
/
Roll the Standby Database Forward
The standby database is now prepared to execute the recover from service incremental roll forward.
Restart All Instances to Mount
All instances can be used during the recovery. restart the database mounting all instances.
$ srvctl stop database -db <dbname> -o immediate
$ srvctl start database -db <dbname> -o mount
Re-Enable Redo Transport
Archived logs created during the roll forward will be needed to make the database consistent. It is more efficient to let the primary ship the redo to the standby while the roll forward is running than to wait for those logs to be transported at the end of the roll forward.
via Data Guard Broker from either database:
DGMGRL> edit database <primary> set state=TRANSPORT-ON;
Succeeded.
via SQLPLUS From the Primary database:
SQL> alter system set LOG_ARCHIVE_DEST_STATE_<#>=ENABLE;
System altered.
NOTE: Do NOT start managed recovery at this point.
Determine Section Size to be Used
On the primary, query the largest datafile size to determine the section size to be used for the recover command.
SQL> select max(bytes)/1073741824 GB from v$datafile;
If the largest file is:
- <15TB use section size of 64GB
- >15TB and <30TB used section size of 128G
- >30TB and <60TB used section size of 256G
- >60TB use section size of 512G
Run Recover From Service
The recover command can utilize all instances of the standby during recovery. This approach spreads the resource utilization across hardware and potentially increases parallelization and throughput for the process as a whole. The example below utilizes this method but parallelization where all channels run on one instance can also be used.
$ rman target sys/<password> <- It is necessary to connect with the password
RMAN > run {
allocate channel c1 type disk connect '/@<standby instance 1 SID_NAME>';
allocate channel c2 type disk connect '/@<standby instance 1 SID_NAME>';
allocate channel c3 type disk connect '/@<standby instance 1 SID_NAME>';
allocate channel c4 type disk connect '/@<standby instance 1 SID_NAME>';
allocate channel c5 type disk connect '/@<standby instance 2 SID_NAME>';
allocate channel c6 type disk connect '/@<standby instance 2 SID_NAME>';
allocate channel c7 type disk connect '/@<standby instance 2 SID_NAME>';
allocate channel c8 type disk connect '/@<standby instance 2 SID_NAME>';
recover database from service '<primary unique name>' section size <section size>;
}
NOTE: Additional channels can be allocated per instance or on additional instances.
Estimating the time which the recover will take is difficult due to the number of variables however, once started, progress and estimates can be monitored with GV$SESSION_LONGOPS on the primary database.
select INST_ID,SID,SERIAL#,OPNAME, (sofar/totalwork)*100 as "%complete", ELAPSED_SECONDS, TIME_REMAINING
from gv$session_longops
where sofar<>totalwork
and totalwork<>0
and SID||SERIAL# in (select SID||SERIAL# from v$session);
INST_ID SID SERIAL# OPNAME %complete ELAPSED_SECONDS TIME_REMAINING
---------- ---------- ---------- ---------------------------------------------------------------- ---------- --------------- --------------
1 1177 56089 RMAN: incremental datafile backup 2.36167908 55 2274
1 2415 52071 RMAN: incremental datafile backup 12.9760623 394 2642
1 2541 26066 RMAN: incremental datafile backup .274372101 22 7996
1 2808 18883 RMAN: incremental datafile backup .262057781 21 7992
1 2670 65170 RMAN: incremental datafile backup 8.32093954 386 4253
1 1900 48392 RMAN: incremental datafile backup 5.93750477 197 3121
Recover Until Consistent
At the completion of the recover database from service command, in order to re-enable flashback database and open the standby read-only more recovery is required to make the database consistent, meaning the control file and all datafiles are at the same SCN. The amount of recovery required will be a function of how long the initial recovery took and how active the primary was during that time.
First switch a log on the primary database to archive the last of the redo during the recover command.
From the primary:
SQL> alter system archive log current;
Then from SQL*PLUS on the standby issue the command below. The UNTIL CONSISTENT clause cannot be used in RMAN.
SQL> recover automatic standby database until consistent;
Media recovery complete.
NOTE: If the recover until consistent results in the error below, all required logs are not present at the standby.
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01152: file 1 was not restored from a sufficiently old backup
Monitor the standby alert logs and as logs arrive at the standby, reissue the recover until consistent until it complete successfully as indicated by 'Media recovery complete.'
Re-Enable Flashback Database
Restoring the standby control file automatically disables flashback. Once the database is in a consistent state, flashback can be re-enabled.
SQL> alter database flashback on;
Database altered.
Restart the Standby and Managed Recovery
Once the standby database is consistent, it can be opened read-only. Restart the database to open all instances read-only.
$ srvctl stop database -db <dbname> -o immediate
$ srvctl start database -db <dbname> -o 'read only'
Then restart managed recovery
via Data Guard Broker from either database:
DGMGRL> edit database <standby> set state=APPLY-ON;
Succeeded.
OR
via SQLPLUS (if Data Guard Broker is not configured):
From the Standby database:
SQL> recover managed standby database disconnect;
Take a New Backup (If Needed)
After the roll forward, if the standby database is being backed up, a new backup is suggested.
请注意，此过程取决于版本。本说明中描述的过程适用于 Oracle 12.1 和 12.2。
对于 11g，请参阅以下步骤：
11g Steps to perform for Rolling Forward a Physical Standby Database using RMAN Incremental Backup. (Doc ID 836986.1)
对于 18c 及更高版本，请参阅以下步骤：
Roll Forward Physical Standby Using RMAN Incremental Backup in Single Command (Doc ID 2431311.1)
这是利用 RECOVER DATABASE FROM SERVICE 来跳过 REDO 中的大的差距 (GAP) 或 REDO 中无法解决的差距 (GAP)（缺少日志）。
解决方案
如果主库和备库之间存在较大的 redo 差距，或者因缺少日志存在无法解决的差距，则可以使用 12c 中引入的 RECOVER DATABASE FROM SERVICE 命令 " 前滚 (roll forward) " 备库。此过程将自备库当前 SCN 以后已更改的块从主库恢复到备库。这在赶上主库方面，比像管理恢复 (managed recovery) 那样将每个单独的更改应用于数据库要更有效。
按照以下步骤使用 RECOVER DATABASE FROM SERVICE 前滚备库。
注意：建议在执行此过程之前清除备库上的孤立化身 (orphaned incarnation) (例如快照备库化身) 的任何备份。
停止管理恢复 (managed recovery) 和 redo 传输
通过 Data Guard Broker 连接到配置中的任一数据库：
DGMGRL> edit database <primary> set state=TRANSPORT-OFF;
Succeeded.
DGMGRL> edit database <standby> set state=APPLY-OFF;
Succeeded.
或者
通过 SQLPLUS (如果未配置 Data Guard Broker)：
在主库执行：
SQL> alter system set LOG_ARCHIVE_DEST_STATE_<#>=DEFER;
System altered.
SQL> alter system archive log current;
在备库执行：
SQL> recover managed standby database cancel;
Media recovery complete.
保存现有日志文件名称
此前滚过程将创建新的在线重做日志 (online redo log) 和备库重做日志 (standby redo log) ，会使得现有日志成为孤立日志，占用空间。 使用以下查询保存日志文件名称，以便稍后在此过程中删除它们。
SQL> set heading off linesize 999 pagesize 0 feedback off trimspool on
SQL> spool /tmp/delete_logfiles.log
SQL> select member from v$logfile;
SQL> spool off
从主库刷新备库控制文件
必须刷新备库控制文件才能推进控制文件 SCN。此新的备库控制文件将包含有关自当前备库的 SCN 以来添加到数据库的任何新文件的信息。下面介绍了更新控制文件中备库的文件位置并还原任何新添加的文件的的附加步骤。
记录备库的当前 SCN
在备库上运行以下示例中的命令，并保存 SCN 以供以后使用。
RMAN> select current_scn from v$database;
CURRENT_SCN#
------------------
644203931
保存当前 RMAN 配置的设置
从主库控制文件刷新备库控制文件会覆盖特定于备库的 RMAN 配置项目。
创建一个脚本以恢复当前的 RMAN 配置设置。这将在从主库恢复控制文件后被使用。
注意：此步骤是在使用目标数据库控制文件 (target database control file) 而不是使用恢复目录 (recovery catalog) 时执行的
在备库：
$ $ rman target / nocatalog log=/tmp/RMAN_settings.log <<EOF
show all;
EOF
要删除不必要的命令输出和 RETENTION POLICY 命令 (无法在备库上执行) ，请运行以下命令：
$ grep ^CONFIGURE /tmp/RMAN_settings.log | grep -v 'RETENTION POLICY' >/tmp/RMAN_settings.rman
$ rm /tmp/RMAN_settings.log
刷新备库控制文件
以 nomount 方式启动一个实例，然后从主库还原控制文件。
$ srvctl stop database -d <db> -o immediate
$ rman target / nocatalog
RMAN> startup nomount
RMAN> restore standby controlfile from service <tns alias for primary database>;
---不需要备份后copy
Starting restore at <date>
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=2824 instance=<standby instance> device type=DISK
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: using network backup set from service <primary service>
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:10
output file name=<standby control file>
Finished restore at <date>
替换 RMAN 配置设置并删除孤立的在线重做日志文件 ( Online Redo Log ) 和备库重做日志文件 ( Standby Redo Log )
调整数据库到 mount 状态并利用此前保存的脚本替换 RMAN 配置
RMAN> alter database mount;
released channel: ORA_DISK_1
Statement processed
RMAN> @/tmp/RMAN_settings.rman
<output from CONFIGURE commands in the script>
RMAN> exit
$ rm /tmp/RMAN_settings.rman
然后删除保存在 /tmp/delete_logfiles.log 中的孤立日志文件并删除 /tmp/delete_logfiles.log 文件
将备库数据文件编录到刷新的控制文件
此时，刷新的控制文件中具有主库中的文件位置和元数据。 使用 RMAN CATALOG 命令使用备库文件位置更新控制文件。
-----主备库的文件位置不同的
RMAN> catalog start with '<DATA DISKGROUP>/<standby db_unique_name/';
Starting implicit crosscheck backup at 24-FEB-22
<...listing of files found...>
Do you really want to catalog the above files (enter YES or NO)? YES
cataloging files...
[There may be error reported for files which cannot be cataloged. These can be ignored.]
RMAN> catalog start with '<RECO DISKGROUP>/<standby db_unique_name>/';
searching for all files that match the pattern <RECO DISKGROUP>/<standby db_unique_name>
no files found to be unknown to the database <-- often times there are no files found on RECO
注意：如果备库用作快照备库，请检查备库控制文件化身是否与主库的控制文件化身匹配。 在 catalog 命令期间，化身可能未正确设置，尤其是在快照数据库期间进行备份且未删除的情况下更是如此。
对每个数据库使用 RMAN> LIST INCARNATION 来比较化身，并使用 RMAN> RESET DATABASE INCARNATION TO x 来设置备库的化身（如有必要）。 建议在执行此过程之前清除孤立化身中的任何备份。
恢复任何丢失的文件
如果文件是在备库的 SCN 和刷新的控制文件的 SCN 之间创建的，则文件将丢失。
使用步骤 " 记录备库的当前 SCN " 中记录的 SCN，识别任何丢失的文件并还原它们。
RMAN> select file# from v$datafile where creation_change# >= 644203931;-----第一句SQL查询
-
如果查询返回文件，则必须从主库和其现有文件来还原文件。
还原缺失的数据文件
RMAN> run {
allocate channel c1 type disk;
allocate channel c2 type disk;
allocate channel c3 type disk;
allocate channel c4 type disk;
allocate channel c5 type disk;
allocate channel c6 type disk;
allocate channel c7 type disk;
allocate channel c8 type disk;
set newname for database to NEW;
restore datafile <comma separate list of files> from service <tns alias for primary database> section size <section size>;
}
注意：对于 SECTION SIZE 的使用，通过查询要还原的数据文件在主库中的大小来确定。
如果最大的文件是
- <15TB 则使用 64GB 的 section size
- >15TB 并且 <30TB 则使用 128G 的 section size
- >30TB 并且 <60TB 则使用 256G 的 section size
- >60TB 则使用 512G 的 section size
注意：如果主库未加密，备库处于加密状态，则应使用 AS ENCRYPTED 子句还原文件。此子句在 RESTORE DATAFILE 上无效，因此必须改用 RESTORE TABLESPACE 来恢复缺失数据文件的表空间，并合并 "AS ENCRYPTED" 子句。
例如： RESTORE TABLESPACE <tablespace name> FROM SERVICE <tns alias for primary database> SECTION SIZE <section size> AS ENCRYPTED;
将数据库切换到复制 (copy)
要使已恢复和预先存在的备库数据文件位置永久存在于控制文件中，请执行切换数据文件副本的操作。
RMAN> switch database to copy;
清理孤立文件
如果在备库的 SCN 和刷新的控制文件的 SCN 之间删除了任何文件，它将在 RMAN 中保留下数据文件副本。 删除任何 datafilecopy 以除去不需要的文件。
RMAN> list datafilecopy all;
using target database control file instead of recovery catalog
List of Datafile Copies
=======================
Key File S Completion Time Ckp SCN Ckp Time Sparse
------- ---- - --------------- ---------- --------------- ------
<#> <#> A <date> <#> <date> NO
Name: <orphaned datafilecopy name>
RMAN> delete datafilecopy all;
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=2620 instance=<instance name> device type=DISK
allocated channel: ORA_DISK_2
channel ORA_DISK_2: SID=1737 instance=<instance name> device type=DISK
List of Datafile Copies
=======================
Key File S Completion Time Ckp SCN Ckp Time Sparse
------- ---- - --------------- ---------- --------------- ------
<#> <#> A <date> <#> <date> NO
Name: <orphaned datafilecopy name>
Do you really want to delete the above objects (enter YES or NO)? YES
deleted datafile copy
datafile copy file name=<orphaned datafilecopy name> RECID=<#> STAMP=<#>
Deleted 1 objects
清除在线重做日志 (online redo log) 和备库重做日志 (standby redo log)
在备库的 SQL*PLUS 中执行以下查询以创建新的日志文件。
SQL> begin
for log_cur in ( select group# group_no from v$log )
loop
execute immediate 'alter database clear logfile group '||log_cur.group_no;
end loop;
end;
/
SQL> begin
for log_cur in ( select group# group_no from v$standby_log )
loop
execute immediate 'alter database clear logfile group '||log_cur.group_no;
end loop;
end;
/
前滚备库
备库现在已准备好执行从服务中恢复来完成前滚。
将所有实例启动到 Mount
恢复期间可以使用所有实例。 重新启动以使得数据库的所有实例处于 mount 状态。
$ srvctl stop database -db <dbname> -o immediate
$ srvctl start database -db <dbname> -o mount
重新启用 redo 传输
需要前滚期间创建的存档日志以使数据库保持一致。 在前滚运行时让主库将 redo 传输到备库的方式比在前滚结束时等待这些日志被传输过来的方式更有效。
通过任一数据库中的 Data Guard Broker：
DGMGRL> edit database <primary> set state=TRANSPORT-ON;
Succeeded.
通过主库的 SQLPLUS：
SQL> alter system set LOG_ARCHIVE_DEST_STATE_<#>=ENABLE;
System altered.
注意：此时不要启动管理恢复 (managed recovery) 。
确定要使用的 section size
在主库，查询最大数据文件大小以确定要用于 recover 命令的 section size 大小。
SQL> select max(bytes)/1073741824 GB from v$datafile;
如果最大的文件是：
- <15TB 则使用 64GB 的 section size
- >15TB 并且 <30TB 则使用 128G 的 section size
- >30TB 并且 <60TB 则使用 256G 的 section size
- >60TB 则使用 512G 的 section size
执行 Recover From Service
recover 命令可以在恢复期间利用备库的所有实例。 这种方法将资源利用分散到硬件上，并可能提高整个流程的并行化和吞吐量。 下面的示例使用此方法，但也可以使用在一个实例上的所有通道来并行化运行。
$ rman target sys/<password> <- 需要使用口令进行连接
RMAN > run {
allocate channel c1 type disk connect '/@<standby instance 1 SID_NAME>';
allocate channel c2 type disk connect '/@<standby instance 1 SID_NAME>';
allocate channel c3 type disk connect '/@<standby instance 1 SID_NAME>';
allocate channel c4 type disk connect '/@<standby instance 1 SID_NAME>';
allocate channel c5 type disk connect '/@<standby instance 2 SID_NAME>';
allocate channel c6 type disk connect '/@<standby instance 2 SID_NAME>';
allocate channel c7 type disk connect '/@<standby instance 2 SID_NAME>';
allocate channel c8 type disk connect '/@<standby instance 2 SID_NAME>';
recover database from service '<primary unique name>' section size <section size>;
}
注意：可以为每个实例或在其他实例上分配其他通道。
由于受到多个因素的影响，估计恢复所需的时间是很困难的，但是，一旦开始，就可以在主库上使用 GV$SESSION_LONGOPS 来监控进度和估计所需时间。
select INST_ID,SID,SERIAL#,OPNAME, (sofar/totalwork)*100 as "%complete", ELAPSED_SECONDS, TIME_REMAINING
from gv$session_longops
where sofar<>totalwork
and totalwork<>0
and SID||SERIAL# in (select SID||SERIAL# from v$session);
INST_ID SID SERIAL# OPNAME %complete ELAPSED_SECONDS TIME_REMAINING
---------- ---------- ---------- ---------------------------------------------------------------- ---------- --------------- --------------
1 1177 56089 RMAN: incremental datafile backup 2.36167908 55 2274
1 2415 52071 RMAN: incremental datafile backup 12.9760623 394 2642
1 2541 26066 RMAN: incremental datafile backup .274372101 22 7996
1 2808 18883 RMAN: incremental datafile backup .262057781 21 7992
1 2670 65170 RMAN: incremental datafile backup 8.32093954 386 4253
1 1900 48392 RMAN: incremental datafile backup 5.93750477 197 3121
持续恢复直到达到一致性状态
在完成 recover database from service 命令后，为了重新启用闪回数据库并以只读方式打开备库，需要进行更多恢复以使数据库保持一致，这意味着控制文件和所有数据文件需要都位于同一 SCN。所需的恢复量将取决于初始恢复所花费的时间以及主库在这段时间内的活跃程度。
首先，在主库上切换日志，以在 recover 命令期间归档最后一次 redo。
从主库执行：
SQL> alter system archive log current;
然后从备库的 SQL*PLUS 执行如下命令。 UNTIL CONSISTENT 字句是不能在 RMAN 中使用的。
SQL> recover automatic standby database until consistent;
Media recovery complete.
注意：如果执行 recover until cancel 导致以下错误，则说明备库上并不存在所有的必需的日志。
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01152: file 1 was not restored from a sufficiently old backup
监视备库告警日志，当日志到达备库时，重新执行 recover until cancel，重复这一过程直到返回 "Media recovery complete" 说明已执行成功。
重新启用数据库 Flashback
恢复备库控制文件会自动禁用闪回功能。 一旦数据库处于一致状态，就可以重新启用闪回功能。
SQL> alter database flashback on;
Database altered.
重启备库和管理模式恢复 (managed recovery)
当备库达到一致性状态后，可以用只读方式来打开它。 重新启动数据库并以只读方式打开所有实例。
$ srvctl stop database -db <dbname> -o immediate
$ srvctl start database -db <dbname> -o 'read only'
然后重启管理恢复
通过任一数据库中的 Data Guard Broker：
DGMGRL> edit database <standby> set state=APPLY-ON;
Succeeded.
或者
通过 SQLPLUS（如果未配置 Data Guard Broker）：
从备库：
SQL> recover managed standby database disconnect;
创建一份新备份 ( 如果需要 )
前滚后，如果要备库正在被创建备份，则建议重新开始创建一份新的备份。
