dataguard之管理物理备库
启动和关闭物理备库
启动物理备库
The STARTUP statement starts the database, mounts the database as a physical standby database, and opens the database for read-only access.
The STARTUP MOUNT statement starts and mounts the database as a physical standby database, but does not open the database.
一旦mount了，数据库可以在主库上接受归档日志文件，你然后可以指定是否开始redo apply或是实时应用，或是打开数据库以只读的方式。
例子
1.Start and mount the physical standby database:
SQL> STARTUP MOUNT;
2.Start Redo Apply or real-time apply:
To start Redo Apply, issue the following statement:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
2> DISCONNECT FROM SESSION;
To start real-time apply, issue the following statement:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
2> USING CURRENT LOGFILE;
在主库上查询v$archived_dest_status视图的recovery_mode列，这个视图展示了备库的操作，managed_recovery是redo apply,managed real time apply是实时应用。
关闭物理备库
1.Issue the following query to find out if the standby database is performing Redo Apply or real-time apply. If the MRP0 or MRP process exists, then the standby database is applying redo.
SQL> SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY;
2.If Redo Apply is running, cancel it as shown in the following example:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
3.Shut down the standby database.
SQL> SHUTDOWN IMMEDIATE;
只读的模式打开物理备库
在只读的模式下，备库停止了日志应用
当正在应用日志的时候，以只读模式打开数据库
1.Cancel Redo Apply:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
2.Open the database for read-only access:
SQL> ALTER DATABASE OPEN;
将物理备库由只读打开模式改成应用日志模式
2.Restart Redo Apply. To start Redo Apply, issue the following statement:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
2> DISCONNECT FROM SESSION;
To enable real-time apply, include the USING CURRENT LOGFILE clause:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
2> USING CURRENT LOGFILE;
添加数据文件或是创建一个表空间
初始化参数，standby_file_management，控制着当主库添加了个数据文件，是否自动的传输到备库上去。
如果standby_file_management参数设置成了auto，那么在主库上创建的新数据文件会自动在备库上创建。
如果指定了standby_file_managemnet参数是manual，那么当主库上添加了数据文件，你需要手工拷贝新的数据文件到备库。
当standby_file_management是auto的时候
1.Add a new tablespace to the primary database:
SQL> CREATE TABLESPACE new_ts DATAFILE '/disk1/oracle/oradata/payroll/t_db2.dbf'
2> SIZE 1m AUTOEXTEND ON MAXSIZE UNLIMITED;
2.Archive the current online redo log file so the redo data will be transmitted to and applied on the standby database:
SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
3.Verify the new data file was added to the primary database:
SQL> SELECT NAME FROM V$DATAFILE;
NAME
----------------------------------------------------------------------
/disk1/oracle/oradata/payroll/t_db1.dbf
/disk1/oracle/oradata/payroll/t_db2.dbf
4.Verify the new data file was added to the standby database:
SQL> SELECT NAME FROM V$DATAFILE;
NAME
----------------------------------------------------------------------
/disk1/oracle/oradata/payroll/s2t_db1.dbf
/disk1/oracle/oradata/payroll/s2t_db2.dbf
当standby_fie_managment被设置成了manual,当备库数据文件放在裸设备上的时候，你必须指定standby_file_management初始参数成manual,这个不翻译了，这样用的不多吧。
当standby_file_management设置成auto或manual时候，删除主库上的数据文件
1.Drop the tablespace from the primary database:
SQL> DROP TABLESPACE tbs_4;
SQL> ALTER SYSTEM SWITCH LOGFILE;
2.Make sure that Redo Apply is running (so that the change is applied to the standby database). If the following query returns the MRP or MRP0 process, Redo Apply is running.
SQL> SELECT PROCESS, STATUS FROM V$MANAGED_STANDBY;
To verify that deleted data files are no longer part of the database, query the V$DATAFILE view.
3.Delete the corresponding data file on the standby system after the archived redo log file was applied to the standby database. For example:
% rm /disk1/oracle/oradata/payroll/s2tbs_4.dbf
4.On the primary database, after ensuring the standby database applied the redo information for the dropped tablespace, you can remove the data file for the tablespace. For example:
% rm /disk1/oracle/oradata/payroll/tbs_4.dbf
使用drop tablesapce including conents and datafiles删除主库和备库上表空间及数据文件，为了使用这个语句，standby_file_management必须设置成auto
SQL> DROP TABLESPACE INCLUDING CONTENTS AND DATAFILES tbs_4; SQL> ALTER SYSTEM SWITCH LOGFILE;
在主库中修改数据文件的名字
当你在主库上修改文件名的时候，改变并不会传输到备库中，因此，如果你想要在备库上重命名相同的数据文件，你必须咋备库上手工的修改。
The following steps describe how to rename a data file in the primary database and manually propagate the changes to the standby database.
1.To rename the data file 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 data file on the primary system:
% mv /disk1/oracle/oradata/payroll/tbs_4.dbf
/disk1/oracle/oradata/payroll/tbs_x.dbf
3.Rename the data file in the primary database and bring the tablespace back online:
SQL> ALTER TABLESPACE tbs_4 RENAME DATAFILE 2> '/disk1/oracle/oradata/payroll/tbs_4.dbf'
3> TO '/disk1/oracle/oradata/payroll/tbs_x.dbf';
SQL> ALTER TABLESPACE tbs_4 ONLINE;
4.Connect to the standby database, query the V$ARCHIVED_LOG view to verify all of the archived redo log files are applied, and then stop Redo Apply:
SQL> SELECT SEQUENCE#,APPLIED FROM V$ARCHIVED_LOG ORDER BY SEQUENCE#;
SEQUENCE# APP
--------- ---
8 YES
9 YES
10 YES
11 YES
4 rows selected.
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
5.Shut down the standby database:
SQL> SHUTDOWN;
6.Rename the data file at the standby site using an operating system command, such as 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 data file in the standby control file. Note that the STANDBY_FILE_MANAGEMENT initialization parameter must be set to MANUAL.
SQL> ALTER DATABASE RENAME FILE '/disk1/oracle/oradata/payroll/tbs_4.dbf'
2> TO '/disk1/oracle/oradata/payroll/tbs_x.dbf';
9.On the standby database, restart Redo Apply:
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE
2> DISCONNECT FROM SESSION;
添加或删除在线日志文件
Consequently, when you add or drop an online redo log file at the primary site, it is important that you synchronize the changes in the standby database by following these steps:
1.If Redo Apply is running, you must cancel Redo Apply before you can change the log files.
2.If the STANDBY_FILE_MANAGEMENT initialization parameter is set to AUTO, change the value to MANUAL.
3.
Add or drop an online redo log file:
To add an online redo log file, use a SQL statement such as this:
SQL> ALTER DATABASE ADD LOGFILE '/disk1/oracle/oradata/payroll/prmy3.log' SIZE 100M;
To drop an online redo log file, use a SQL statement such as this:
SQL> ALTER DATABASE DROP LOGFILE '/disk1/oracle/oradata/payroll/prmy3.log';
4.Repeat the statement you used in Step 3 on each standby database.
5.Restore the STANDBY_FILE_MANAGEMENT initialization parameter and the Redo Apply options to their original states.
监控主库和备库
Table 8-2 LocationWhere Common Actions on the Primary Database Can Be Monitored
| Primary Database Event |
Primary Site Information |
Standby Site Information |
| A SQL ALTER DATABASE statement is issued with the ENABLE THREAD or DISABLE THREAD clause specified |
|
Alert log |
| Current database role, protection mode and level, switchover status, and fast-start failover information |
V$DATABASE |
V$DATABASE |
| Redo log changed |
|
Alert log |
| CREATE CONTROLFILE statement issued |
Alert log |
Alert log |
| Managed recovery performed |
Alert log |
Alert log |
| Tablespace status changes made (made read/write or read-only, placed online or offline) |
|
V$RECOVER_FILE view |
| Data file added or tablespace created |
|
V$DATAFILE view Alert log |
| Tablespace dropped |
|
V$DATAFILE view Alert log |
| Tablespace or data file taken offline, or data file is deleted offline |
|
V$RECOVER_FILE view DBA_TABLESPACES |
| Rename data file |
|
V$DATAFILE view Alert log |
| Unlogged or unrecoverable operations |
|
Alert log |
| Recovery progress |
|
V$ARCHIVED_LOG view V$LOG_HISTORY view V$MANAGED_STANDBY view Alert log |
| Redo transport status and progress |
|
V$ARCHIVED_LOG view Alert log |
| Auto extend a data file |
Alert log |
Alert log |
| Issue OPEN RESETLOGS or CLEAR UNARCHIVED LOGFILES statements |
Alert log |
Alert log |
| Change initialization parameter |
Alert log |
Alert log |
监控进程的状态
SQL> SELECT PROCESS, CLIENT_PROCESS, SEQUENCE#, STATUS FROM V$MANAGED_STANDBY;
看redo apply的过程
SELECT ARCHIVED_THREAD#, ARCHIVED_SEQ#, APPLIED_THREAD#, APPLIED_SEQ#
2> FROM V$ARCHIVE_DEST_STATUS;
查看归档日志文件的目的地
SQL> SELECT NAME, CREATOR, SEQUENCE#, APPLIED, COMPLETION_TIME
2> FROM V$ARCHIVED_LOG;
NAME CREATOR SEQUENCE# APP COMPLETIO
---------------------------------------------- ------- --------- --- ---------
H:\ORACLE\ORADATA\PAYROLL\STANDBY\ARC00198.001 ARCH 198 YES 30-MAY-02
H:\ORACLE\ORADATA\PAYROLL\STANDBY\ARC00199.001 ARCH 199 YES 30-MAY-02
查看归档日志历史
SQL> SELECT FIRST_TIME, FIRST_CHANGE#, NEXT_CHANGE#, SEQUENCE# FROM V$LOG_HISTORY
查看那个日志文件被备库应用了
Query the V$LOG_HISTORY view on the standby database, which records the latest log sequence number that was applied. For example, issue the following query:
SQL> SELECT THREAD#, MAX(SEQUENCE#) AS "LAST_APPLIED_LOG"
2> FROM V$LOG_HISTORY
3> GROUP BY THREAD#;
THREAD# LAST_APPLIED_LOG
------- ----------------
1 967
In this example, the archived redo log file with log sequence number 967 is the most recently applied log file.
You can also use the APPLIED column in the V$ARCHIVED_LOG fixed view on the standby database to find out which log files were applied on the standby database. For example:
SQL> SELECT THREAD#, SEQUENCE#, APPLIED FROM V$ARCHIVED_LOG;
THREAD# SEQUENCE# APP
---------- ---------- ---
1 2 YES
1 3 YES
1 4 YES
1 5 YES
1 6 YES
1 7 YES
1 8 YES
1 9 YES
1 10 YES
1 11 NO
查看哪些日志没有被备库接受到
For example, assume the current local archive destination ID on your primary database is 1, and the destination ID of one of your remote standby databases is 2. To find out which log files were not received by this standby destination, issue the following query on the primary database:
SQL> SELECT LOCAL.THREAD#, LOCAL.SEQUENCE# FROM 2> (SELECT THREAD#, SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=1) LOCAL 3> WHERE LOCAL.SEQUENCE# NOT IN 5> (SELECT SEQUENCE# FROM V$ARCHIVED_LOG WHERE DEST_ID=2 AND 6> THREAD# = LOCAL.THREAD#); THREAD# SEQUENCE# ---------- ---------- 1 12 1 13 1 14
The preceding example shows the log files that were not received by standby destination 2.
监控物理备库的日志用用服务
Issue the following query to show information about the protection mode, the protection level, the role of the database, and switchover status:
SQL> SELECT DATABASE_ROLE, DB_UNIQUE_NAME INSTANCE, OPEN_MODE, -
PROTECTION_MODE, PROTECTION_LEVEL, SWITCHOVER_STATUS -
FROM V$DATABASE;
Issue the following query to show information about fast-start failover:
SQL> SELECT FS_FAILOVER_STATUS FSFO_STATUS, FS_FAILOVER_CURRENT_TARGET -
TARGET_STANDBY, FS_FAILOVER_THRESHOLD THRESHOLD, -
FS_FAILOVER_OBSERVER_PRESENT OBS_PRES -
FROM V$DATABASE;
Query the physical standby database to monitor Redo Apply and redo transport services activity at the standby site.
SQL> SELECT PROCESS, STATUS, THREAD#, SEQUENCE#, BLOCK#, BLOCKS 2> FROM V$MANAGED_STANDBY; PROCESS STATUS THREAD# SEQUENCE# BLOCK# BLOCKS ------- ------------ ---------- ---------- ---------- ---------- RFS ATTACHED 1 947 72 72 MRP0 APPLYING_LOG 1 946 10 72
The previous query output shows that an RFS process completed archiving a redo log file with sequence number 947. The output also shows that Redo Apply is actively applying an archived redo log file with the sequence number 946. The recovery operation is currently recovering block number 10 of the 72-block archived redo log file.
8.5.4.3 Accessing the V$ARCHIVE_DEST_STATUS Fixed View
To quickly determine the level of synchronization for the standby database, issue the following query on the physical standby database:
SQL> SELECT ARCHIVED_THREAD#, ARCHIVED_SEQ#, APPLIED_THREAD#, APPLIED_SEQ# 2> FROM V$ARCHIVE_DEST_STATUS; ARCHIVED_THREAD# ARCHIVED_SEQ# APPLIED_THREAD# APPLIED_SEQ# ---------------- ------------- --------------- ------------ 1 947 1 945
The previous query output shows that the standby database is two archived redo log files behind the primary database.
To determine if real-time apply is enabled, query the RECOVERY_MODE column of the V$ARCHIVE_DEST_STATUS view. It will contain the value MANAGED REAL TIME APPLY when real-time apply is enabled, as shown in the following example:
SQL> SELECT RECOVERY_MODE FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID=2 ; RECOVERY_MODE ----------------------- MANAGED REAL TIME APPLY
8.5.4.4 Accessing the V$ARCHIVED_LOG Fixed View
The V$ARCHIVED_LOG fixed view on the physical standby database shows all the archived redo log files received from the primary database. This view is only useful after the standby site starts receiving redo data; before that time, the view is populated by old archived redo log records generated from the primary control file.
For example, you can execute the following SQL*Plus statement:
SQL> SELECT REGISTRAR, CREATOR, THREAD#, SEQUENCE#, FIRST_CHANGE#, 2> NEXT_CHANGE# FROM V$ARCHIVED_LOG; REGISTRAR CREATOR THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE# --------- ------- ---------- ---------- ------------- ------------ RFS ARCH 1 945 74651 74739 RFS ARCH 1 946 74739 74772 RFS ARCH 1 947 74772 74774
The previous query output shows three archived redo log files received from the primary database.
8.5.4.5 Accessing the V$LOG_HISTORY Fixed View
Query the V$LOG_HISTORY fixed view on the physical standby database to show all the archived redo log files that were applied:
SQL> SELECT THREAD#, SEQUENCE#, FIRST_CHANGE#, NEXT_CHANGE# 2> FROM V$LOG_HISTORY; THREAD# SEQUENCE# FIRST_CHANGE# NEXT_CHANGE# ---------- ---------- ------------- ------------ 1 945 74651 74739
The previous query output shows that the most recently applied archived redo log file was sequence number 945.
8.5.4.6 Accessing the V$DATAGUARD_STATUS Fixed View
The V$DATAGUARD_STATUS fixed view displays events that would typically be triggered by any message to the alert log or server process trace files.
The following example shows output from the V$DATAGUARD_STATUS view on a primary database:
SQL> SELECT MESSAGE FROM V$DATAGUARD_STATUS; MESSAGE -------------------------------------------------------------------------------- ARC0: Archival started ARC1: Archival started Archivelog destination LOG_ARCHIVE_DEST_2 validated for no-data-loss recovery Creating archive destination LOG_ARCHIVE_DEST_2: 'dest2' ARCH: Transmitting activation ID 0 LGWR: Completed archiving log 3 thread 1 sequence 11 Creating archive destination LOG_ARCHIVE_DEST_2: 'dest2' LGWR: Transmitting activation ID 6877c1fe LGWR: Beginning to archive log 4 thread 1 sequence 12 ARC0: Evaluating archive log 3 thread 1 sequence 11 ARC0: Archive destination LOG_ARCHIVE_DEST_2: Previously completed ARC0: Beginning to archive log 3 thread 1 sequence 11 Creating archive destination LOG_ARCHIVE_DEST_1: '/oracle/arch/arch_1_11.arc' ARC0: Completed archiving log 3 thread 1 sequence 11 ARC1: Transmitting activation ID 6877c1fe 15 rows selected.
The following example shows the contents of the V$DATAGUARD_STATUS view on a physical standby database:
SQL> SELECT MESSAGE FROM V$DATAGUARD_STATUS; MESSAGE -------------------------------------------------------------------------------- ARC0: Archival started ARC1: Archival started RFS: Successfully opened standby logfile 6: '/oracle/dbs/sorl2.log' ARC1: Evaluating archive log 6 thread 1 sequence 11 ARC1: Beginning to archive log 6 thread 1 sequence 11 Creating archive destination LOG_ARCHIVE_DEST_1: '/oracle/arch/arch_1_11.arc' ARC1: Completed archiving log 6 thread 1 sequence 11 RFS: Successfully opened standby logfile 5: '/oracle/dbs/sorl1.log' Attempt to start background Managed Standby Recovery process Media Recovery Log /oracle/arch/arch_1_9.arc 10 rows selected.
调优在物理备库上的日志应用
1在一个备库上设置恢复并行的数量是cpu数量的2倍
2设置db_block_checking=false
3设置parallel_excution_message_size=4096