SQL> startup
ORACLE 例程已经启动。
......
SQL> alter database recover managed standby database cancel;
数据库已更改。
SQL> alter database open ;
数据库已更改。
SQL> select status from v$instance;
STATUS
------------
OPEN
SQL> alter database recover managed standby database disconnect from session;
数据库已更改。
SQL> select status from v$instance;
STATUS
------------
MOUNTED
● 修改表空间状态(例如read-write 到read-only,online 到offline)
● 创建修改删除表空间或数据文件(如果初始化参数STANDBY_FILE_MANAGEMENT 被设置为AUTO 的话,这点在前面第一章的时候提到过)
● 如果设置为manual,则需要手工复制新创建的数据文件到standby 服务器。
SQL> show parameter standby_file
NAME TYPE VALUE
----------------------------- ----------- ---------------
standby_file_management string AUTO
SQL> create tablespace mytmp datafile 'e:\ora10g\oradata\jssweb\mytmp01.dbf' size 20m;
表空间已创建。
检查刚添加的数据文件
SQL> select name from v$datafile;
NAME
-----------------------------------------------
E:\ORA10G\ORADATA\JSSWEB\SYSTEM01.DBF
E:\ORA10G\ORADATA\JSSWEB\UNDOTBS01.DBF
E:\ORA10G\ORADATA\JSSWEB\SYSAUX01.DBF
E:\ORA10G\ORADATA\JSSWEB\USERS01.DBF
E:\ORA10G\ORADATA\JSSWEB\WEBTBS01.DBF
E:\ORA10G\ORADATA\JSSWEB\MYTMP01.DBF
已选择6 行。
SQL> alter system switch logfile;
系统已更改。
SQL> select name from v$datafile;
NAME
----------------------------------------------------
E:\ORA10G\ORADATA\JSSPDG\SYSTEM01.DBF
E:\ORA10G\ORADATA\JSSPDG\UNDOTBS01.DBF
E:\ORA10G\ORADATA\JSSPDG\SYSAUX01.DBF
E:\ORA10G\ORADATA\JSSPDG\USERS01.DBF
E:\ORA10G\ORADATA\JSSPDG\WEBTBS01.DBF
E:\ORA10G\ORADATA\JSSPDG\MYTMP01.DBF
已选择6 行。
SQL> select name from v$tablespace;
NAME
------------------------------
SYSTEM
UNDOTBS1
SYSAUX
TEMP
USERS
WEBTBS
MYTMP
已选择7 行。
SQL> drop tablespace mytmp including contents and datafiles;
表空间已删除。
SQL> select name from v$datafile;
NAME
--------------------------------------------------
E:\ORA10G\ORADATA\JSSWEB\SYSTEM01.DBF
E:\ORA10G\ORADATA\JSSWEB\UNDOTBS01.DBF
E:\ORA10G\ORADATA\JSSWEB\SYSAUX01.DBF
E:\ORA10G\ORADATA\JSSWEB\USERS01.DBF
E:\ORA10G\ORADATA\JSSWEB\WEBTBS01.DBF
SQL> alter system switch logfile;
系统已更改。
提示:使用including 子句删除表空间时,
SQL> select name from v$datafile;
NAME
--------------------------------------------------
E:\ORA10G\ORADATA\JSSPDG\SYSTEM01.DBF
E:\ORA10G\ORADATA\JSSPDG\UNDOTBS01.DBF
E:\ORA10G\ORADATA\JSSPDG\SYSAUX01.DBF
E:\ORA10G\ORADATA\JSSPDG\USERS01.DBF
E:\ORA10G\ORADATA\JSSPDG\WEBTBS01.DBF
SQL> select name from v$tablespace;
NAME
------------------------------
SYSTEM
UNDOTBS1
SYSAUX
TEMP
USERS
WEBTBS
已选择6 行。
得出结论,对于初始化参数STANDBY_FILE_MANAGMENT 设置为auto 的话,对于表空间和数据文件的操作完全无须dba 手工干预,primary 和standby 都能很好的处理。
SQL> create tablespace mytmp datafile 'e:\ora10g\oradata\jssweb\mytmp01.dbf' size 20m;
表空间已创建。
检查刚添加的数据文件
SQL> select name from v$datafile;
NAME
-----------------------------------------------
E:\ORA10G\ORADATA\JSSWEB\SYSTEM01.DBF
E:\ORA10G\ORADATA\JSSWEB\UNDOTBS01.DBF
E:\ORA10G\ORADATA\JSSWEB\SYSAUX01.DBF
E:\ORA10G\ORADATA\JSSWEB\USERS01.DBF
E:\ORA10G\ORADATA\JSSWEB\WEBTBS01.DBF
E:\ORA10G\ORADATA\JSSWEB\MYTMP01.DBF
已选择6 行。
切换日志
SQL> alter system switch logfile;
系统已更改。
SQL> select name from v$datafile;
NAME
----------------------------------------------------
E:\ORA10G\ORADATA\JSSPDG\SYSTEM01.DBF
E:\ORA10G\ORADATA\JSSPDG\UNDOTBS01.DBF
E:\ORA10G\ORADATA\JSSPDG\SYSAUX01.DBF
E:\ORA10G\ORADATA\JSSPDG\USERS01.DBF
E:\ORA10G\ORADATA\JSSPDG\WEBTBS01.DBF
E:\ORA10G\PRODUCT\10.2.0\DB_1\DATABASE\UNNAMED00006
已选择6 行。
SQL> select name from v$tablespace;
NAME
------------------------------
SYSTEM
UNDOTBS1
SYSAUX
TEMP
USERS
WEBTBS
MYTMP
已选择7 行。
可以看到,表空间已经自动创建,但是,数据文件却被起了个怪名字,手工修改其与primary
数据库保持一致,如下(注意执行命令之后手工复制数据文件到standby):
SQL> alter database create datafile'E:\ORA10G\PRODUCT\10.2.0\DB_1\DATABASE\UNNAMED00006'
2 as 'E:\ora10g\oradata\jsspdg\mytmp01.dbf';
数据库已更改。
SQL> drop tablespace mytmp including contents and datafiles;
表空间已删除。
SQL> select name from v$datafile;
NAME
--------------------------------------------------
E:\ORA10G\ORADATA\JSSWEB\SYSTEM01.DBF
E:\ORA10G\ORADATA\JSSWEB\UNDOTBS01.DBF
E:\ORA10G\ORADATA\JSSWEB\SYSAUX01.DBF
E:\ORA10G\ORADATA\JSSWEB\USERS01.DBF
E:\ORA10G\ORADATA\JSSWEB\WEBTBS01.DBF
SQL> alter system switch logfile;
系统已更改。
SQL> select name from v$datafile;
NAME
----------------------------------------------------
E:\ORA10G\ORADATA\JSSPDG\SYSTEM01.DBF
E:\ORA10G\ORADATA\JSSPDG\UNDOTBS01.DBF
E:\ORA10G\ORADATA\JSSPDG\SYSAUX01.DBF
E:\ORA10G\ORADATA\JSSPDG\USERS01.DBF
E:\ORA10G\ORADATA\JSSPDG\WEBTBS01.DBF
E:\ORA10G\PRODUCT\10.2.0\DB_1\DATABASE\UNNAMED00006
已选择6 行。
SQL> select name from v$tablespace;
NAME
------------------------------
SYSTEM
UNDOTBS1
SYSAUX
TEMP
USERS
WEBTBS
MYTMP
已选择7 行。
呀,数据还在啊。赶紧分析分析,查看alert_jsspdg.log 文件,发现如下(特别注意粗体):
File #6 added to control file as 'UNNAMED00006' because
the parameter STANDBY_FILE_MANAGEMENT is set to MANUAL
The file should be manually created to continue.
Errors with log E:\ORA10G\ORADATA\JSSPDG\LOG1_753_641301252.ARC
MRPMRP0:BackgroundMediaRecoveryterminatedwitherror1274
Fri Jan 18 09:48:45 2008
这下明白了,为什么有个UNNAMED00006 的数据文件,也晓得为啥standby 数据库没能删除新加的表空间了吧,原来是后台的redo 应用被停掉了,重启redo 应用再来看看:
SQL> alter database recover managed standby database disconnect from session;
数据库已更改。
SQL> select name from v$datafile;
NAME
----------------------------------------------
E:\ORA10G\ORADATA\JSSPDG\SYSTEM01.DBF
E:\ORA10G\ORADATA\JSSPDG\UNDOTBS01.DBF
E:\ORA10G\ORADATA\JSSPDG\SYSAUX01.DBF
E:\ORA10G\ORADATA\JSSPDG\USERS01.DBF
E:\ORA10G\ORADATA\JSSPDG\WEBTBS01.DBF
SQL> alter tablespace webtbs offline;
表空间已更改。
方式多样,不详述。
SQL> alter tablespace webtbs rename datafile
2 'E:\ORA10G\ORADATA\JSSWEB\WEBTBS01.DBF' to
3 'E:\ORA10G\ORADATA\JSSWEB\TBSWEB01.DBF';
表空间已更改。
SQL> alter tablespace webtbs online;
表空间已更改。
SQL> alter database recover managed standby database cancel;
数据库已更改。
SQL> shutdown immediate
ORA-01109: 数据库未打开
......
方式多样,不详述。
SQL> startup mount
ORACLE 例程已经启动。
Total System Global Area 167772160 bytes
Fixed Size 1289484 bytes
Variable Size 150995700 bytes
Database Buffers 8388608 bytes
Redo Buffers 7098368 bytes
数据库装载完毕。
SQL> alter database rename file
2 'E:\ORA10G\ORADATA\JSSPDG\WEBTBS01.DBF' to
3 'E:\ORA10G\ORADATA\JSSPDG\TBSWEB01.DBF';
数据库已更改。
SQL> alter database recover managed standby database disconnect from session;
数据库已更改。
SQL> alter system switch logfile;
系统已更改。
当primary 数据库被以resetlogs 打开之后,dg 提供了一些方案,能够让你快速的恢复物理standby,当然这是有条件的,不可能所有的情况都可以快速恢复。我们都知道alter database open resetlogs 之后,数据库的scn被重置,也就是此时其redo 数据也会从头开始。当物理standby 接收到新的redo 数据时,redo 应用会自动获取这部分redo 数据。对于物理standby 而言,只要数据库没有应用resetlogs 之后的redo 数据,那么这个过程是不需要dba 手工参与的。
Standby数据库状态 | Standby服务器操作 | 解决方案 |
没有应用resetlog之前的redo数据 | 自动应用新的redo数据 | 无须手工介入 |
应用了resetlog之后的redo数据,不过standby打开了flashback。 | 可以应用,不过需要dba手工介入 | 1.手工flashback到应用之前 2.重启redo应用,以重新接收新的redo数据。 |
应用了resetlog之后的redo数据,而且没有flashback。 | 完全无法应用 | 重建物理standby是唯一的选择 |
本节主要介绍一些监控dg 配置的方式,先给大家提供一个表格(描述不同事件的不同信息监控途径):
primary数据库事件 | primary监控途径 | standby监控途径 |
带有enable|disable thread子句的alterdatabase命令 | Alert.log V$THREAD |
Alert.log |
当前数据库角色,保护模式,保护级别,switchover状态,failover快速启动信息等 | V$DATABASE | V$DATABASE |
Redo log切换 | Alert.log V$LOG V$LOGFILE的status列 |
Alert.log |
重建控制文件 | Alert log | Alert log |
手动执行恢复 | Alert log | Alert log |
表空间状态修改(read-write/read-only,online/offline) | DBA_TABLESPACES Alert log |
V$RECOVER_FILE |
创建删除表空间或数据文件 | DBA_DATA_FILES Alert log |
V$DATAFILE Alert log |
表空间或数据文件offline | V$RECOVER_FILE Alert log DBA_TABLESPACES |
V$RECOVER_FILE DBA_TABLESPACES |
重命名数据文件 | V$DATAFILE Alert log |
V$DATAFILE Alert log |
未被日志记录或不可恢复的操作 | V$DATAFILE view V$DATABASE view |
Alert.log |
恢复的进程 | V$ARCHIVE_DEST_STATUS Alert log |
V$ARCHIVED_LOG V$LOG_HISTORY V$MANAGED_STANDBY Alert log |
Redo传输的状态和进度 | V$ARCHIVE_DEST_STATUS V$ARCHIVED_LOG V$ARCHIVE_DEST Alert log |
V$ARCHIVED_LOG Alert log |
数据文件自动扩展 | Alert log | Alert log |
执行OPEN RESETLOGS或CLEAR UNARCHIVED LOGFILES | Alert log | Alert log |
修改初始化参数 | Alert log | Alert log |
先也是一句话:做为oracle 自己自觉主动维护的一批虚拟表它的作用非常明显通过它可以及时获得当前数据库状态及处理进度总之好处多多也需特别关注后面示例也会多处用到大家要擦亮双眼。
该视图就是专为显示standby 数据库相关进程的当前状态信息,例如:
SQL> select process,client_process,sequence#,status from v$managed_standby;
PROCESS CLIENT_P SEQUENCE# STATUS
--------- -------- ---------- ------------
ARCH ARCH 763 CLOSING
ARCH ARCH 762 CLOSING
MRP0 N/A 764 WAIT_FOR_LOG
RFS LGWR 764 IDLE
RFS N/A 0 IDLE
PROCESS:显示进程信息
CLIENT_PROCESS:显示对应的主数据库中的进程
SEQUENCE#:显示归档redo 的序列号
STATUS:显示的进程状态
该视图显示归档文件路径配置信息及redo 的应用情况等,例如:
SQL> select dest_name,archived_thread#,archived_seq#,applied_thread#,applied_seq#,db_unique_name
2 from v$archive_dest_status where status='VALID';
DEST_NAME ARCHIVED_THREAD# ARCHIVED_SEQ# APPLIED_THREAD#APPLIED_SEQ# DB_UNIQUE_
-------------------- ---------------- ------------- --------------- ------------ ----------
LOG_ARCHIVE_DEST_1 1 765 0 0 jsspdg
LOG_ARCHIVE_DEST_2 0 0 0 0 jssweb
STANDBY_ARCHIVE_DEST 1 764 1 764 NONE
该视图查询standby 数据库归档文件的一些附加信息,比如文件创建时间啦,创建进程啦,归档序号啦,是否被应用啦之类,例如:
SQL> select name,creator,sequence#,applied,completion_time from v$archived_log;
NAME CREATOR SEQUENCE# APP COMPLETION_TIM
-------------------------------------------------- ------- ---------- --- --------------
E:\ORA10G\ORADATA\JSSPDG\LOG1_750_641301252.ARC ARCH 750 YES 18-1 月-08
E:\ORA10G\ORADATA\JSSPDG\LOG1_749_641301252.ARC ARCH 749 YES 18-1 月-08
E:\ORA10G\ORADATA\JSSPDG\LOG1_751_641301252.ARC ARCH 751 YES 18-1 月-08
E:\ORA10G\ORADATA\JSSPDG\LOG1_752_641301252.ARC ARCH 752 YES 18-1 月-08
E:\ORA10G\ORADATA\JSSPDG\LOG1_753_641301252.ARC ARCH 753 YES 18-1 月-08
E:\ORA10G\ORADATA\JSSPDG\LOG1_754_641301252.ARC ARCH 754 YES 18-1 月-08
该视图查询standby 库中所有已被应用的归档文件信息(不论该归档文件是否还存在),例如:
SQL> select first_time,first_change#,next_change#,sequence# from v$log_history;
FIRST_TIME FIRST_CHANGE# NEXT_CHANGE# SEQUENCE#
------------------- ------------- ------------ ----------
2008-01-03 12:00:51 499709 528572 18
2008-01-08 09:54:42 528572 539402 19
2008-01-08 22:00:06 539402 547161 20
2008-01-09 01:05:57 547161 560393 21
2008-01-09 10:13:53 560393 561070 22
例如,查询数据库角色,保护模式,保护级别等:
SQL> selectdatabase_role,db_unique_name,open_mode,protection_mode,protection_level,switchover_status
2 from v$database;
DATABASE_ROLE DB_UNIQUE_NAME OPEN_MODE PROTECTION_MODE PROTECTION_LEVEL SWITCHOVER_STATUS
---------------- --------------- ---------- -------------------- -------------------- ------------------
PHYSICAL STANDBY jsspdg MOUNTED MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY SESSIONS ACTIVE
SQL> select fs_failover_status,fs_failover_current_target,fs_failover_threshold,
2 fs_failover_observer_present from v$database;
FS_FAILOVER_STATUS FS_FAILOVER_CURRENT_TARGET FS_FAILOVER_THRESHOLD FS_FAIL
--------------------- ------------------------------ --------------------- -------
DISABLED 0
查询v$archive_dest_status 视图,如果打开了实时应用,则recovery_mode 会显示为:MANAGEDREAL TIME APPLY,例如:
SQL> select recovery_mode from v$archive_dest_status where dest_id=2;
RECOVERY_MODE
-----------------------
MANAGED REAL TIME APPLY
该视图显示那些被自动触发写入alert.log 或服务器trace 文件的事件。通常是在你不便访问到服务器查询alert.log 时,可以临时访问本视图查看一些与dataguard 相关的信息,例如:
SQL> select message from v$dataguard_status;
MESSAGE
----------------------------------------------------------------------------
ARC0:Archival started
ARC1:Archival started
ARC0: Becoming the 'no FAL' ARCH
ARC0: Becoming the 'no SRL' ARCH
ARC1: Becoming the heartbeat ARCH
Attempt to start background Managed Standby Recovery process
MRP0: Background Managed Standby Recovery process started
Managed Standby Recovery not using Real Time Apply
Media Recovery Waiting for thread 1 sequence 761
SQL> alter database recover managed standby database parallel 2 disconnect from session;
2、加快redo 应用频繁
设置初始化参数DB_BLOCK_CHECKING=FALSE 能够提高2 倍左右的应用效率,该参数是验证数据块是否有效, 对于standby 禁止验证基本上还是可以接受的, 另外还有一个关联初始化参数DB_BLOCK_CHECKSUM,建议该参数在primary 和standby 都设置为true。
如果打开了并行恢复,适当提高初始化参数:PARALLEL_EXECUTION_MESSAGE_SIZE 的参数值,比如4096 也能提高大概20%左右的性能,不过需要注意增大这个参数的参数值可能会占用更多内存。
在恢复期间最大瓶颈就是I/O 读写,要缓解这个瓶颈,使用本地异步I/O 并设置初始化参数DISK_ASYNCH_IO=TRUE 会有所帮助。DISK_ASYNCH_IO 参数控制到数据文件的磁盘I/O 是否异步。某些情况下异步I/O 能降低数据库文件并行读取,提高整个恢复时间。