概要：
第三部分：快照standby数据库
第四部分: 物理备库转换为逻辑备库
第五部分: 管理physical dataguard
内容：
l 第三部分：快照standby数据库
快照备库的作用：
可以暂时将物理备用数据库转换为可更新的数据库，称为快照备用数据库 (Snapshot Standby Database)。在这一模式中，可以运行您的应用程序（它可能会更改许多表），然后再分析其影响。评估影响后，您可以将数据库转换为备用数据库，然后进行常规恢复。您可以在数据库中创建一个恢复点来完成这一过程，使用 Flashback 数据库特性“闪回”至该点，恢复所有的更改。、
转换快照备库的步骤：
1. 在备库启动恢复进程。
SQL> alter database recover managed standby database disconnect;
数据库已更改。
2. 终止恢复进程。
SQL> select open_mode from v$database;
OPEN_MODE
--------------------
READ ONLY WITH APPLY
SQL> alter database recover managed standby database cancel;
数据库已更改。
3. 转换为快照备用数据库。
SQL> select open_mode from v$database;
OPEN_MODE
--------------------
READ ONLY
SQL> alter database convert to snapshot standby;
数据库已更改。
Alter日志内容：
alter database convert to snapshot standby
Starting background process RVWR
Thu Jun 23 17:07:55 2011
RVWR started with pid=30, OS id=13133
Allocated 7814440 bytes in shared pool for flashback generation buffer
Created guaranteed restore point SNAPSHOT_STANDBY_REQUIRED_06/23/2011 17:07:53
krsv_proc_kill: Killing 4 processes (all RFS)
Thu Jun 23 17:08:04 2011
CLOSE: killing server sessions.
CLOSE: all sessions shutdown successfully.
Thu Jun 23 17:08:05 2011
SMON: disabling cache recovery
Begin: Standby Redo Logfile archival
End: Standby Redo Logfile archival
RESETLOGS after incomplete recovery UNTIL CHANGE 5788110
Resetting resetlogs activation ID 962622994 (0x39607612)
Online log /u01/app/ora11g/oradata/PRIDB1/onlinelog/o1_mf_1_6mf7b92o_.log: Thread 1 Group 1 was previously cleared
Online log /u01/app/ora11g/fla/PRIDB1/onlinelog/o1_mf_1_6mf7bbdv_.log: Thread 1 Group 1 was previously cleared
Online log /u01/app/ora11g/oradata/PRIDB1/onlinelog/o1_mf_2_6mf7bds9_.log: Thread 1 Group 2 was previously cleared
Online log /u01/app/ora11g/fla/PRIDB1/onlinelog/o1_mf_2_6mf7bfp2_.log: Thread 1 Group 2 was previously cleared
Online log /u01/app/ora11g/oradata/PRIDB1/onlinelog/o1_mf_3_6mf7bhsx_.log: Thread 1 Group 3 was previously cleared
Online log /u01/app/ora11g/fla/PRIDB1/onlinelog/o1_mf_3_6mf7bjrt_.log: Thread 1 Group 3 was previously cleared
Standby became primary SCN: 5788108
Thu Jun 23 17:08:09 2011
Setting recovery target incarnation to 3
CONVERT TO SNAPSHOT STANDBY: Complete - Database mounted as snapshot standby
Completed: alter database convert to snapshot standby
注意：
在上面的转换快照步骤，它启用了闪回日志，因此，如果您没有配置闪回恢复区，
将出现以下消息：
ORA-38784: Cannot create restore point 'SNAPSHOT_STANDBY_REQUIRED_01/12/2008
00:23:14'.
ORA-38786: Flash recovery area is not enabled.
为了避免出现这种情况，您应先创建闪回恢复区。如果没有，需要马上创建它：
SQL> alter system set db_recovery_file_dest_size = 4G;
System altered.
SQL> alter system set db_recovery_file_dest= '/db_recov';
System altered.
4. 重新利用数据库。
SQL> shutdown immediate
ORA-01109: 数据库未打开
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> startup
ORACLE 例程已经启动。
Total System Global Area 3190132736 bytes
Fixed Size 2230720 bytes
Variable Size 1879049792 bytes
Database Buffers 1291845632 bytes
Redo Buffers 17006592 bytes
数据库装载完毕。
数据库已经打开。
SQL> select open_mode,database_role,flashback_on from v$database;
OPEN_MODE DATABASE_ROLE FLASHBACK_ON
-------------------- ---------------- ------------------
READ WRITE SNAPSHOT STANDBY RESTORE POINT ONLY
5. 对快照数据库进行读写测试。
SQL> select * from lcz_test.test1;
ID C1
---------- ----------
1 333.01
2 333.01
SQL> insert into lcz_test.test1 select 911,2000.1 from dual;
已创建 1 行。
SQL> commit;
提交完成。
SQL> insert into lcz_test.test1 select 912,3000.2 from dual;
已创建 1 行。
SQL> commit;
提交完成。
SQL> select * from lcz_test.test1;
ID C1
---------- ----------
1 333.01
2 333.01
911 2000.1
912 3000.2
6. 完成测试后，快照数据库转换为普通物理备库
SQL> shutdown immediate
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> startup mount
ORACLE 例程已经启动。
Total System Global Area 3190132736 bytes
Fixed Size 2230720 bytes
Variable Size 1879049792 bytes
Database Buffers 1291845632 bytes
Redo Buffers 17006592 bytes
数据库装载完毕。
SQL> alter database convert to physical standby;
数据库已更改。
Alert日志如下：
alter database convert to physical standby
ALTER DATABASE CONVERT TO PHYSICAL STANDBY (pridb2)
krsv_proc_kill: Killing 4 processes (all RFS)
Flashback Restore Start
Flashback Restore Complete
Drop guaranteed restore point
Stopping background process RVWR
Deleted Oracle managed file /u01/app/ora11g/fla/PRIDB1/flashback/o1_mf_7060mccr_.flb
Deleted Oracle managed file /u01/app/ora11g/fla/PRIDB1/flashback/o1_mf_7060mkpg_.flb
Guaranteed restore point dropped
Clearing standby activation ID 964610552 (0x397ec9f8)
The primary database controlfile was created using the
'MAXLOGFILES 16' clause.
There is space for up to 13 standby redo logfiles
Use the following SQL commands on the standby database to create
standby redo logfiles that match the primary database:
ALTER DATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl2.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl3.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl4.f' SIZE 52428800;
Thu Jun 23 17:49:04 2011
Completed: alter database convert to physical standby
7. 重启挂载数据库，启动管理恢复
SQL> alter database recover managed standby database using current logfile disconnect from session;
alter database recover managed standby database using current logfile disconnect from session
*
第 1 行出现错误:
ORA-01153: 激活了不兼容的介质恢复
SQL> alter database open;
数据库已更改。
SQL> select open_mode,database_role from v$database;
OPEN_MODE DATABASE_ROLE
-------------------- ----------------
READ ONLY WITH APPLY PHYSICAL STANDBY
注意：上面的ORA-01153报错，可能是因为备库没把主库的日志同步过来，过会之后可以直接open数据库。
8. 最后再次测试数据库。
SQL> select * from lcz_test.test1;
ID C1
---------- ----------
1 333.01
2 333.01
可以看到数据库已经还原到了切换快照数据库前的状态。
l 第四部分: 物理备库转换为逻辑备库
步骤如下：
１. 在主库构建数据字典
备用数据库需要从某一位置获取数据字典信息。字典信息应当置于来自于主数据库中的重做流中。
因此，在主数据库上，执行以下命令构建字典的 LogMiner 表：
SQL>
begin
dbms_logstdby.build;
end;
/
２. 在备用数据库上，停止管理恢复进程：
SQL> alter database recover managed standby database cancel;
Database altered.
３. 在备用数据库中执行以下命令以将它转换为逻辑数据库
SQL> alter database recover to logical standby pro11sb;
Database altered.
如果您没有执行步骤 1，以上命令将处于等待状态，因为没有发现字典信息。不要担心，只需执行
步骤 1 即可。如果启用了 RTA(实时应用)，信息将立即显示在备用数据库上。
４. 在主数据库上执行几个日志切换操作，确保创建归档日志并将它们发送至备用数据库：
SQL> alter system switch logfile;
System altered.
５. 在备用数据库侧，在一段时间后您可以看到更改数据库命令已经完成。现在备用数据库已经变成逻
辑数据库。在警报日志中您可以看到以下内容：
RFS[12]: Identified database type as 'logical standby'
６. 重新利用数据库：
SQL> shutdown
ORA-01507: database not mounted
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Total System Global Area 1071333376 bytes
...
Database mounted.
SQL> alter database open resetlogs;
Database altered.
７. 现在这已经是一个逻辑备用数据库，您应当启用 SQL Apply 进程
SQL> alter database start logical standby apply immediate;
将物理备用数据库转换为逻辑备用数据库后，若要将其转换回物理数据
库，您需要使用一个特别子句 ("keep identity")。
l 第五部分: 管理physical dataguard
一、 角色转换
主备角色转换的时间估算：
在备库查询V$DATAGUARD_STATS视图，此视图主要说明如果所有可用的日志数据被应用，主备切换可能需要的时间。
SQL> COLUMN NAME FORMAT A24
SQL> COLUMN VALUE FORMAT A16
SQL> COLUMN DATUM_TIME FORMAT A24
SQL> COLUMN UNIT FORMAT A30
SQL> SELECT NAME, VALUE,UNIT, DATUM_TIME FROM V$DATAGUARD_STATS;
NAME VALUE UNIT DATUM_TIME
------------------------ ---------------- ------------------------------ ------------------------
transport lag +00 00:00:00 day(2) to second(0) interval 05/31/2011 09:38:43
apply lag +00 00:00:00 day(2) to second(0) interval 05/31/2011 09:38:43
apply finish time +00 00:00:00.000 day(2) to second(3) interval
estimated startup time 65 second
apply lag 和 transport lag是记录主备之间如果出现通讯故障等问题，日志的传输和应用出现滞后时间的统计。
estimated startup time 主备切换可以需要的时间。
1.Switchovers转换操作：
Switchover操作用于在计划内维护时减少主库的down机的时间，如system和硬件升级、数据库软件和补丁滚动升级。Switchover分为两步，第一步是primary转换成为standby角色，第二步是standby转换为primary角色。
切换前的准备：
（1）检查参数是否正确，如LOG_ARCHIVE_DEST_n 和 LOG_ARCHIVE_DEST_STATE_n
（2）检查主库的standby log是否存在、备库的temporary files是否存存，并和主库一致
（3）检查备库的归档状态，是否和主库一致，已经完全归档并一致。
SQL> SELECT STATUS, GAP_STATUS FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;
STATUS GAP_STATUS
--------- ------------------------
VALID NO GAP
确保STATUS为 VALID 和GAP_STATUS为NOGAP.
切换步骤：
(1).验证primary是否能被切换成standby角色,在primary执行
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
--------------------
TO STANDBY
注：当结果是TO STANDBY或SESSIONS ACTIVE时，主库才可以切换成standby角色。
(2).在主库执行切换为standby操作
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;
注：如果上步中结果是TO STANDBY，可以省略WITH SESSION SHUTDOWN子句。
(3).关闭之前的主库并启动到mount状态
SQL> SHUTDOWN ABORT;
SQL> STARTUP MOUNT;
(4).验证standby是否能被切换成primary角色,在standby执行
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
-----------------
TO_PRIMARY
1 row selected
注：当结果是TO_PRIMARY 或SESSIONS ACTIVE时，主库才可以切换成standby角色。
(5).在目标备库执行切换为primay操作
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;
注：如果上步中结果是TO_PRIMARY，可以省略WITH SESSION SHUTDOWN子句。
(6).打开新的主库。
SQL> ALTER DATABASE OPEN;
(7).在新的备库开启redo日志应用
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
(8).如果其它的standby备库日志应用已经停则重新启动应用。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
另外，要确保新主库的log_archive_dest_n参数设置正确，要同时配置了有发送各standby节点log_archive_dest_n参数,否则当主备切换后，新的将主库无法传送日志给standby点，导致Standby点不能同步主库的数据。但如果如果使用broker图形切换，主备log_archive_dest_n会自动更改主，不需要手工修改主库的log_archive_dest_n参数。
2.Failover转换操作：
Failover仅当主库不可用时，并且在短时间内无法恢复时使用。
(1). 在主库Flush没有传送完成的redo log到备库
如果在主库可以mount状态下，主库也许能够flush那些没有传送的归档或redolog到备库。如果不操作成功，可能就不会有数据丢失，即使DG在非数据丢失的保护的模式下。
首先要确保备库的日志应用是开启的状态。
要确保主库能够启动到mount状态，如果主库不能mount，直接执行下面(2)的操作。
SQL> ALTER SYSTEM FLUSH REDO TO target_db_name;
注：target_db_name为standby库的DB_UNIQUE_NAME
如果语句执行成功，直接到第(5)步操作；如果执行有错或是你不能再等候很长的时间完成此操作，你可继续执行第(2)步.
(2).在目标备库验证最近的主库的归档日志
SQL> SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#) OVER (PARTITION BY thread#) AS LAST from V$ARCHIVED_LOG;
THREAD LAST
---------- ----------
1 100
如果可能，可以从主库copy最近备库缺失的归档日志文件到备库服务器，然后在备库注册归档日志，如下：
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';
(3).检查并解决目标备库没有缺失的归档日志
SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
---------- ------------- --------------
1 90 92
如上步说明一样：
如果可能，可以从主库copy最近备库缺失的归档日志文件到备库服务器，然后在备库注册归档日志，如下：
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';
(4).重复步骤(3)直到缺失的日志解决完成。
(5).在目标备库停止日志应用
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
(6).在目标备库完成应用所有收到的日志
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
如果上面的语句执行成功，直接到第(7)步。
如果有报错，尝试解决错误后然后再试执行上面的语句。
如果在第(3),(4)没有成功解决缺失归档的问题，在这步也会报错。
如果报错不能解决，failover可能造成数据丢失，然后执行下面的语句：
SQL> ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE;
注：执行完此ACTIVATE语句后，直接执行第(9)步。
(7).验证standby是否能被切换成primary角色.
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
-----------------
TO_PRIMARY
1 row selected
注：当结果是TO_PRIMARY 或SESSIONS ACTIVE时，主库才可以切换成standby角色。
(8).在目标备库执行切换为primay操作
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;
注：如果上步中结果是TO_PRIMARY，可以省略WITH SESSION SHUTDOWN子句。
(9).打开新的主库。
SQL> ALTER DATABASE OPEN;
(10).备份新的primary库
执行primary库的全库备份。
(11).如果其它的standby备库日志应用已经停则重新启动应用。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
(12).还原失败的primary数据库（可选）
在failover后，之前的primary库可以重配置建为新primary库的standby库。
二、角色转换后闪回数据库
在角色转换后，你可以随意的使用FLASHBACK DATABASE命令恢复数据库到一个时间点或是角色转换之前的SCN处（前提是闪回数据库功能要在角色转换之前就被开启）。如果是闪回的是primary库，则必需同时闪回所有的standby备到同样(或更早)的时间点或SCN处。
1. 在switchover之后使用闪回。
实例:
2. 在failover之后使用闪回
在failover发生之后，原始的主库将不在是dataguard的一部分，要对它重新配置或修复。你可以使用flashback功能把原始的主库恢复到failover发生之前的某个时间点。这样你能把原始的主库转换成一个新的物理备库或是逻辑备库。
注意：前提是数据库必需是之前开了flashback功能。
下面的步骤是将旧的主库转换成备库：
实例:
三、实时查询模式管理
1. 打开物理DG时查询功能(active dataguard)。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
SQL> ALTER DATABASE OPEN;
SQL> select open_mode from v$database;
OPEN_MODE
--------------------
READ ONLY
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT;
SQL> select open_mode from v$database;
OPEN_MODE
--------------------
READ ONLY WITH APPLY
按官方的说法：
n 如果购买了ADG选项的license，当物理备库是open的时候，日志应用能被激活，这样允许备能查询和主库一样的内容，即active datagaurd实时查询的特性。
n 如果没有购买ADG选项的license，当物理备库的日志被激活时，物理备库不能open，所以我们可以观察到下面的规则：(1)在物理备open之前，日志应用必需被停止；(2)如果一个或更多的备库实例openj时，在开启日志应用之前，这些实例必需被停止或重启到mount状态。
上面就意思就是说active datagaurd功能选项是收费的，否则物理DG的功能和10g的相同。
注意：日志应用和DB打开的顺序
实验1：
--开启日志应用之后再打开数据库，数据库为READ ONLY模式，日志应用关闭。
SQL> shutdown immediate
SQL> startup mount
SQL> alter database recover managed standby database using current logfile disconnect from session;
数据库已更改。
SQL> alter database open;
数据库已更改。
SQL> select open_mode from v$database;
OPEN_MODE
--------------------
READ ONLY
--然后再次开启日志应用，此时数据库为READ ONLY WITH APPLY模式
SQL> alter database recover managed standby database using current logfile disconnect from session;
数据库已更改。
SQL> select open_mode from v$database;
OPEN_MODE
--------------------
READ ONLY WITH APPLY
实验2：
--取消日志应用后打开数据库，数据库同样为READ ONLY模式
SQL> shutdown immediate。
SQL> startup mount
SQL> alter database recover managed standby database using current logfile disconnect from session;
数据库已更改。
SQL> alter database recover managed standby database cancel;
数据库已更改。
SQL> alter database open;
数据库已更改。
SQL> select open_mode from v$database;
OPEN_MODE
--------------------
READ ONLY
--然后再次开启日志应用，此时数据库为READ ONLY WITH APPLY模式
SQL> alter database recover managed standby database using current logfile disconnect from session;
数据库已更改。
SQL> select open_mode from v$database;
OPEN_MODE
--------------------
READ ONLY WITH APPLY
实验3：
在另一个节点物理备库，在启动日志应用时出现了下面的错误，但是再次查看数据库状态却依然发生了变化，虽然报错，但是语句还是同样执行成功。
SQL> shutdown immediate
SQL> startup
SQL> select open_mode from v$database;
OPEN_MODE
--------------------
READ ONLY
SQL> alter database recover managed standby database using current logfile disconnect from session;
alter database recover managed standby database using current logfile disconnect from session
*
第 1 行出现错误:
ORA-01153: 激活了不兼容的介质恢复
SQL> select open_mode from v$database;
OPEN_MODE
--------------------
READ ONLY WITH APPLY
2. 监控应用滞后情况
SQL> SELECT name, value, datum_time, time_computed FROM V$DATAGUARD_STATS WHERE name like 'apply lag';
NAME VALUE DATUM_TIME TIME_COMPUTED
------------ ------------- -------------------- -------------------
apply lag +00 00:00:00 05/31/2011 17:20:17 05/31/2011 17:20:18
查看自从实例启动以来apply lag的柱状图：
SQL> SELECT * FROM V$STANDBY_EVENT_HISTOGRAM WHERE NAME = 'apply lag' AND COUNT > 0;
----------- ---------- ---------------- ---------- ------------
apply lag 57 minutes 59 05/30/2011 23:03:51
apply lag 58 minutes 59 05/30/2011 23:04:50
apply lag 59 minutes 60 05/30/2011 23:05:52
apply lag 1 hours 58 05/30/2011 23:06:51
apply lag 2 hours 3531 05/31/2011 00:06:50
apply lag 3 hours 3523 05/31/2011 01:06:50
apply lag 4 hours 3516 05/31/2011 02:06:51
apply lag 5 hours 3505 05/31/2011 03:06:50
3. 配置应用滞后可容忍的时间。
设置STANDBY_MAX_DATA_DELAY会话参数，它指定一个可接受的延迟时间（单位：秒），如果数据因超时变得无效，Oracle 11g R2会简单地拒绝执行查询，直接抛出一个异常（ORA-03172）。
STANDBY_MAX_DATA_DELAY参数值默认为NONE,备库此时不将不考虑应用滞后情况
STANDBY_MAX_DATA_DELAY设为0时，备库查询确保返回和主库同样的结果。如果备库正在处于应用滞后状态，它将返回ORA-03172错误。
SQL> ALTER SESSION SET STANDBY_MAX_DATA_DELAY=2;
4. 强制日志应用同步
在逻辑备库执行下面的语句，确保从主库接收到的日志被应用。
SQL> ALTER SESSION SYNC WITH PRIMARY;
在备库的所有日志应用未完成之前，执行此语句将处于等待状态。如果在备库日志传输状态处于非SYNCHRONIZED状态或是处于日志应用未启动状态，执行此语句会出现ORA-3173错误。
在备库创建下面的tigger,在指定的用户登录后强制执行日志应用同步操作。
CREATE TRIGGER adg_logon_sync_trigger
AFTER LOGON ON user.schema
begin
if (SYS_CONTEXT('USERENV', 'DATABASE_ROLE') IN ('PHYSICAL STANDBY')) then
execute immediate 'alter session sync with primary';
end if;
end;
5. 块修复功能
自动块修复：
当备库处于实时查询模式时，如果在主库查询时发现有数据块损坏，主库会自动地使用那些在备库没有损坏的块替换主库损坏的块，但前提是主备是同步的状态；如果损坏的块在备库发现，服务器会自动地从主库获得那些没有损坏的数据库的拷贝进行修复，主数据库，前提是备库的LOG_ARCHIVE_CONFIG、LOG_ARCHIVE_DEST_n和FAL_SERVER参数配置正确。
手动块修复：
使用RMAN RECOVER BLOCK命令进行手动块修复。
四、当主库改变需要手动介入的情况
1． 添加数据文件或创建表空间，当STANDBY_FILE_MANAGEMENT= MANUAL时。
STANDBY_FILE_MANAGEMENT参数控制在主库添加数据文件是否自动地传播到备库。
n 如果在备库STANDBY_FILE_MANAGEMENT=AUTO,在主库添加任何的数据库文件都会自动地传播到备库。
n 如果在备库STANDBY_FILE_MANAGEMENT=MANUAL，在主库添加任何的数据文件后，要手动的copy到备份。
注意：如果从其它的数据库copy一个数据文件到主库，不管备份的STANDBY_FILE_MANAGEMENT参数值为何值，都必须同样copy数据文件库到备库，并且要重建备库的控制文件。
1) . STANDBY_FILE_MANAGEMENT参数在祼设备上使用
注意：如果主备库的祼设备(raw)的路径名不同，可以使用DB_FILE_NAME_CONVERT参数转换祼设备路径名。
如果主备库使用raw，STANDBY_FILE_MANAGEMENT=AUTO是仍然启作用的，但是有一点就是要确保备在主库添的数据文件使用的raw，在备库有同样的raw。
例子：
--在主库创建使用raw的数据文件
SQL> CREATE TABLESPACE MTS2 DATAFILE '/dev/raw/raw100' size 1m;
Tablespace created.
SQL> ALTER SYSTEM SWITCH LOGFILE;
System altered.
--因为备机上的有存在同样的raw,所以在备库会自动添加上数据文件。
--备库日志如下：
Fri Apr 8 09:49:31 2005
Media Recovery Log /u01/MILLER/flash_recovery_area/MTS_STBY/archivelog/2005_04_
08/o1_mf_1_7_15ffgt0z_.arc
Recovery created file /dev/raw/raw100
Successfully added datafile 6 to media recovery
Datafile #6: '/dev/raw/raw100'
Media Recovery Waiting for thread 1 sequence 8 (in transit
--但是如果备机没有同样的raw，备库的日志应用将会停止。
--例如下面的主库操作：
SQL> CREATE TABLESPACE MTS3 DATAFILE '/dev/raw/raw101' size 1m;
Tablespace created.
SQL> ALTER SYSTEM SWITCH LOGFILE;
System altered.
--因为在备库没有同样raw,备库在恢复归档时，日志出现如下报错信息：
Fri Apr 8 10:00:22 2005
Media Recovery Log /u01/MILLER/flash_recovery_area/MTS_STBY/archivelog/2005_04_
08/o1_mf_1_8_15ffjrov_.arc
File #7 added to control file as 'UNNAMED00007'.
Originally created as:
'/dev/raw/raw101'
Recovery was unable to create the file as:
'/dev/raw/raw101'
MRP0: Background Media Recovery terminated with error 1274
Fri Apr 8 10:00:22 2005
Errors in file /u01/MILLER/MTS/dump/mts_mrp0_21851.trc:
ORA-01274: cannot add datafile '/dev/raw/raw101' - file could not be created
ORA-01119: error in creating database file '/dev/raw/raw101'
ORA-27041: unable to open file
Linux Error: 13: Permission denied
Additional information: 1
Some recovered datafiles maybe left media fuzzy
Media recovery may continue but open resetlogs may fail
Fri Apr 8 10:00:22 2005
Errors in file /u01/MILLER/MTS/dump/mts_mrp0_21851.trc:
ORA-01274: cannot add datafile '/dev/raw/raw101' - file could not be created
ORA-01119: error in creating database file '/dev/raw/raw101'
ORA-27041: unable to open file
Linux Error: 13: Permission denied
Additional information: 1
Fri Apr 8 10:00:22 2005
MTS; MRP0: Background Media Recovery process)
2) .恢复错误
可以使用下面的方法纠正上面的问题，步骤如下：
--创建祼设备在备机上，然后分配给oracle 用户权限。
--查询备库V$DATAFILE：
SQL> SELECT NAME FROM V$DATAFILE;
NAME
-------------------------------------------------------------------------------
/u01/MILLER/MTS/system01.dbf
/u01/MILLER/MTS/undotbs01.dbf
/u01/MILLER/MTS/sysaux01.dbf
/u01/MILLER/MTS/users01.dbf
/u01/MILLER/MTS/mts.dbf
/dev/raw/raw100
/u01/app/oracle/product/10.1.0/dbs/UNNAMED00007
SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=MANUAL;
SQL> ALTER DATABASE CREATE DATAFILE -
> '/u01/app/oracle/product/10.1.0/dbs/UNNAMED00007' -
> AS -
> '/dev/raw/raw101';
--在备库会出现下面类似的信息:
Fri Apr 8 10:09:30 2005
alter database create datafile
'/dev/raw/raw101' as '/dev/raw/raw101'
Fri Apr 8 10:09:30 2005
Completed: alter database create datafile
'/dev/raw/raw101' a
--在备库设置 STANDBY_FILE_MANAGEMENT=AUTO，然后重启
Redo Apply:
SQL> ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=AUTO;
SQL> RECOVER MANAGED STANDBY DATABASE DISCONNECT;
此时日志应用使用这个raw设备继续进行恢复了
2． Drop or delete数据文件和表空间时。
方法1:
使用DROP TABLESPACE tbs，需要手介入
--在主库删除表空间
SQL> DROP TABLESPACE tbs_4;
SQL> ALTER SYSTEM SWITCH LOGFILE;
--在主库v$datafile视图验证表空间已经被删除。
--在备库v$datafile视图验证表空间也同样已经被删除
--在确保主库的操作已经应用到备库以后，然后手动删除备机上的物理数据文件。
$rm /disk1/oracle/oradata/payroll/s2tbs_4.dbf
--在确保主库的操作已经应用到备库以后，最后手动删除主库上的物理数据文件。
$rm /disk1/oracle/oradata/payroll/tbs_4.dbf
方法2：
使用DROP TABLESPACE tbs INCLUDING CONTENTS AND DATAFILES语法时，不需要手动介入。
但前提是STANDBY_FILE_MANAGEMENT参数值必需为AUTO，操作如下：
SQL> DROP TABLESPACE INCLUDING CONTENTS AND DATAFILES tbs_4;
SQL> ALTER SYSTEM SWITCH LOGFILE;
3． 使用传输表空间时。
当使用传输表空间移动一个表空间到主库时，用下面的步骤：
1) .从源数据库创建一个传输表空间集。
--把要传输的表空间设为只读
SQL> alter tablespace tbs_test read only;
Tablespace altered
--导出表空间结构
$ expdp system/oracle dumpfile=tbs.dmp directory=exp_dir transport_tablespaces=tbs_test
2) .把数据文件和导出文件copy到主库
[oracle@OEL03 datafile]$ pwd
/u01/app/ora11g/oradata/PRIDB2/datafile
[oracle@OEL03 datafile]$ ls tbs*
tbs.dmp tbs_test01.dbf
3) .把数据文件copy到备库。
[oracle@OEL01 datafile]$ pwd
/u01/app/ora11g/oradata/PRIDB/datafile
[oracle@OEL01 datafile]$ ls tbs*
tbs_test01.dbf
4) .用impdp工具导入表空间
在导入时有几点需要注意：
a. 主库的数据文件路径必需与备相同，除非在备库配置了DB_FILE_NAME_CONVERT参数。
b. 如果DB_FILE_NAME_CONVERT参数没有配置，而且主备库数据文件的路径也不相同，那么在主库进行impdp导入时备库的应用会停止。此时，需要在备库先设STANDBY_FILE_MANAGEMENT=MANUAL，然后用ALTER DATABASE RENAME FILE语句重命名备库的数据文件，这样，再启动日志应用主库备就可以同步了。
b示例：
--在主库成功导入传输表空间数据
[oracle@OEL03 ~]$ impdp system/oracle DUMPFILE=tbs.dmp DIRECTORY=imp_dir TRANSPORT_DATAFILES=/u01/app/ora11g/oradata/PRIDB2/datafile/tbs_test01.dbf
… …
作业 "SYSTEM"."SYS_IMPORT_TRANSPORTABLE_01" 已于 18:10:02 成功完成
--在备库日志如下：
Mon Jul 04 17:15:12 2011
Errors in file /u01/app/ora11g/diag/rdbms/pridb/pridb/trace/pridb_dbw0_12957.trc:
ORA-01157: cannot identify/lock data file 6 - see DBWR trace file
ORA-01110: data file 6: '/u01/app/ora11g/oradata/PRIDB2/datafile/tbs_test01.dbf'
ORA-27037: unable to obtain file status
Linux-x86_64 Error: 2: No such file or directory
Additional information: 3
Errors in file /u01/app/ora11g/diag/rdbms/pridb/pridb/trace/pridb_dbw0_12957.trc:
ORA-01186: file 6 failed verification tests
ORA-01157: cannot identify/lock data file 6 - see DBWR trace file
ORA-01110: data file 6: '/u01/app/ora11g/oradata/PRIDB2/datafile/tbs_test01.dbf'
File 6 not verified due to error ORA-01157
Mon Jul 04 17:15:12 2011
MRP0: Background Media Recovery terminated with error 1157
Errors in file /u01/app/ora11g/diag/rdbms/pridb/pridb/trace/pridb_pr00_13472.trc:
ORA-01157: cannot identify/lock data file 6 - see DBWR trace file
ORA-01110: data file 6: '/u01/app/ora11g/oradata/PRIDB2/datafile/tbs_test01.dbf'
Managed Standby Recovery not using Real Time Apply
Recovery interrupted!
Recovered data files to a consistent state at change 44543313990
Mon Jul 04 17:15:15 2011
MRP0: Background Media Recovery process shutdown (pridb)
--可以看到日志用户此时停止
SQL> select open_mode from v$database;
OPEN_MODE
--------------------
READ ONLY
SQL> select name from v$tablespace;
NAME
------------------------------
TBS_TEST
……
SQL> alter system set STANDBY_FILE_MANAGEMENT=manual;
系统已更改。
SQL> shutdown immediate
数据库已经关闭。
已经卸载数据库。
ORACLE 例程已经关闭。
SQL> startup
ORACLE 例程已经启动。
Total System Global Area 3190132736 bytes
Fixed Size 2230720 bytes
Variable Size 2231371328 bytes
Database Buffers 939524096 bytes
Redo Buffers 17006592 bytes
数据库装载完毕。
ORA-10458: standby database requires recovery
ORA-01157: 无法标识/锁定数据文件 6 - 请参阅 DBWR 跟踪文件
ORA-01110: 数据文件 6: '/u01/app/ora11g/oradata/PRIDB2/datafile/tbs_test01.dbf'
SQL> select name from v$datafile;
NAME
--------------------------------------------------------------------------------
/u01/app/ora11g/oradata/PRIDB/datafile/o1_mf_system_6mf4bydf_.dbf
/u01/app/ora11g/oradata/PRIDB/datafile/o1_mf_sysaux_6mf4bz52_.dbf
/u01/app/ora11g/oradata/PRIDB/datafile/o1_mf_undotbs1_6mf4bzcv_.dbf
/u01/app/ora11g/oradata/PRIDB/datafile/o1_mf_users_6mf4bzl7_.dbf
/u01/app/ora11g/oradata/PRIDB/datafile/o1_mf_far_near_700moksy_.dbf
/u01/app/ora11g/oradata/PRIDB2/datafile/tbs_test01.dbf
已选择6行。
SQL> alter database rename file '/u01/app/ora11g/oradata/PRIDB2/datafile/tbs_test01.dbf' to '/u01/app/ora11g/oradata/PRIDB//datafile/tbs_test01.dbf';
数据库已更改。
SQL> alter database open;
数据库已更改。
SQL> alter database recover managed standby database using current logfile disconnect from session;
数据库已更改。
SQL> select open_mode from v$database;
OPEN_MODE
--------------------
READ ONLY WITH APPLY
4． Rename 数据文件时。
如果在主库重命名数据文件，则必需在备手动执行相同的操作，即使STANDBY_FILE_MANAGEMENT=auto,其原理和方法和上面类似
示例如下：
The following steps describe how to rename a datafile in the primary database and
manually propagate the changes to the standby database.
1). To rename the datafile in the primary database, take the tablespace offline:
SQL> ALTER TABLESPACE tbs_4 OFFLINE;
2). Exit from the SQL prompt and issue an operating system command, such as the
following UNIX mv command, to rename the datafile on the primary system:
$ mv /disk1/oracle/oradata/payroll/tbs_4.dbf /disk1/oracle/oradata/payroll/tbs_x.dbf
3). Rename the datafile in the primary database and bring the tablespace back online:
SQL> ALTER TABLESPACE tbs_4 RENAME DATAFILE -
> '/disk1/oracle/oradata/payroll/tbs_4.dbf' -
> TO '/disk1/oracle/oradata/payroll/tbs_x.dbf';
SQL> ALTER TABLESPACE tbs_4 ONLINE;
4). Connect to the standby database and stop Redo Apply:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
5). Shut down the standby database:
SQL> SHUTDOWN;
6). Rename the datafile at the standby site using an operating system command, suchas the UNIX mv command:
$ mv /disk1/oracle/oradata/payroll/tbs_4.dbf /disk1/oracle/oradata/payroll/tbs_x.dbf
7). Start and mount the standby database:
SQL> STARTUP MOUNT;
8). Rename the datafile in the standby control file.
Note that the STANDBY_FILE_MANAGEMENT database initialization parameter must be set to MANUAL in order torename a datafile. This parameter can be reset to its previous value after renaming a datafile.
SQL> ALTER DATABASE RENAME FILE '/disk1/oracle/oradata/payroll/tbs_4.dbf' -
> TO '/disk1/oracle/oradata/payroll/tbs_x.dbf';
9). On the standby database, restart Redo Apply:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;
If you do not rename the corresponding datafile at the standby system, and then try to
refresh the standby database control file, the standby database will attempt to use the
renamed datafile, but it will not find it. Consequently, you will see error messages
similar to the following in the alert log:
ORA-00283: recovery session canceled due to errors
ORA-01157: cannot identify/lock datafile 4 - see DBWR trace file
ORA-01110: datafile 4: '/Disk1/oracle/oradata/payroll/tbs_x.dbf'
注意：其实通过上面的实例可以看到，主库数据文件名的更改不会影响到备库，所以当主库的某表空间的数据文件名改变后，备库数据相应的文件名可以不用去改，或者也不必改成和主库数据文件名一样，主备同样可以正常同步。从这里可以看出物理DG也不是完成结构相同，可以说是某部分是逻辑上相同，结构也是不同的。
5． 添加或删除日志文件组时。
The configuration of the redo log and standby redo log on a physical standby databaseshould be reevaluated and adjusted as necessary after adding or dropping a log filegroup on the primary database.Take the following steps to add or drop a log file group or standby log file group on aphysical standby database:
1). Stop Redo Apply.
2). If the STANDBY_FILE_MANAGEMENT initialization parameter is set to AUTO,
change the value to MANUAL.
3). Add or drop a log file group.
Note: An online logfile group must always be manually cleared before it can be dropped from a physical standby database. For example:
ALTER DATABASE CLEAR LOGFILE GROUP 3;
An online logfile group that has a status of CURRENT or CLEARING_CURRENT cannot be dropped from a physical standby database. Anonline logfile group that has this status can be dropped after a roletransition.
4). Restore the STANDBY_FILE_MANAGEMENT initialization parameter and the Redo
Apply options to their original states.
5). Restart Redo Apply.
6． 使用NOLOGGING或UNRECOVERABLE子句执行DML或DDL操作时。
当使用带有NOLOGGING或UNRECOVERABLE子句的DML或DDL语句时，备库会变成无效，然后需要DBA去做修复数据库。可以指定一个带有FORCELOGGING的ALTER DATABASE、ALTER TABLESPACE的SQL子句覆盖NOLOGGING的设置。但是，这个语句将不能在一个失效的数据中修复。
7． Grant 或revoke 管理用户权限时，或改变管理用户密码时。
n 如果REMOTE_LOGIN_PASSWORDFILE参数设为SHARED 或 EXCLUSIVE，在赋予或撤销的事管理员用户权限后，备的密码文件必需重新从主库进行copy
n 在备库如果恢复密码文件失败，可能会导致日志传输会话的认证或作为SYSDBA或SYSOPER连接到备库连接失败
8． Reset the TDE master encryption key
9． 改变主库的数据库参数时。
10．当在主库存开闪回功能时不会同步到备库。
在主库：
SQL> startup mount
ORACLE 例程已经启动。
Total System Global Area 2438529024 bytes
Fixed Size 2228920 bytes
Variable Size 1375735112 bytes
Database Buffers 1040187392 bytes
Redo Buffers 20377600 bytes
数据库装载完毕。
SQL> alter database flashback on;
SQL> alter database open;
SQL> select flashback_on from v$database;
FLASHBACK_ON
------------------
YES
SQL> alter system switch logfile;
在备库：
SQL> select flashback_on from v$database;
FLASHBACK_ON
------------------
NO
可以发现备库的闪回功能并没有打开。
开启备库的flashback:
SQL> shutdown immediate
SQL> startup mount
SQL> alter database flashback on;
alter database flashback on
第 1 行出现错误:
ORA-01153: 激活了不兼容的介质恢复
SQL> alter database recover managed standby database cancel;
SQL> alter database flashback on;
SQL> alter database open;
五、常用视图总结：
V$ARCHIVED_LOG
V$ARCHIVE_DEST
V$ARCHIVE_DEST_STATUS
V$ARCHIVE_GAP
V$DATAGUARD_STATS
V$STANDBY_EVENT_HISTOGRAM
V$STANDBY_LOG
V$REDO_DEST_RESP_HISTOGRAM
V$RECOVER_FILE
V$LOG_HISTORY
V$MANAGED_STANDBY
六、管理常用命令总结：
ALTER SESSION SYNC WITH PRIMARY
alter database recover managed standby database using current logfile disconnect from session;
alter database recover managed standby database cancel;
alter database set standby database to maximize availability,protection,performance;
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE NODELAY;
ALTER SYSTEM SET STANDBY_FILE_MANAGEMENT=MANUAL/auto;(rename file时改为manual，手动同步)
ALTER DATABASE ADD STANDBY LOGFILE ('/oracle/dbs/slog2.rdo') SIZE 500M;
ALTER DATABASE ADD STANDBY LOGFILE THREAD 1 SIZE 500M;
255
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
