2008年（105）
分类： Oracle
2008-06-11 18:40:57
这里要分两种情况:
1).standby数据库处于shutdown状态
直接startup即可。
SQL> startup
ORACLE 例程已经启动。
......
2).standby数据库处于redo应用状态。
首先取消redo应用：
SQL> alter database recover managed standby database cancel;
数据库已更改。
然后再打开数据库
SQL> alter database open ;
数据库已更改。
3).如果想从open状态再切换回redo应用状态，并不需要shutdown，直接启用redo应用即可，例如：
|
SQL> select status from v$instance; STATUS SQL> alter database recover managed standby database disconnect from session; 数据库已更改。 SQL> select status from v$instance; STATUS |
二、管理影响standby的primary数据库事件
为预防可能的错误，你必须知道primary数据库的某些事件可能影响standby数据库，并且了解如何处理.
某些情况下，primary数据库的某些改动会自动通过redo数据传播到standby数据库，因此不需要在standby数据库做额外的操作，而某些情况，则需要你手工调整。
下列事件会由redo传输服务及redo应用自动处理，不需要dba的干预，分别是：
? 修改表空间状态(例如read-write到read-only，online到offline)
? 创建修改删除表空间或数据文件(如果初始化参数STANDBY_FILE_MANAGEMENT被设置为AUTO的话，这点在前面第一章的时候提到过)
下列事情则需要dba手工干预：
1、添加修改删除数据文件或表空间
前面提到了，初始化参数STANDBY_FILE_MANAGEMENT可以控制是否自动将primary数据库增加删除表空间、数据文件的改动继承到standby。
? 如果该参数值设置为auto，则自动创建。
? 如果设置为manual，则需要手工复制新创建的数据文件到standby服务器。
不过需要注意一点，如果数据文件是从其它数据库复制而来(比如通过tts)，则不管STANDBY_FILE_MANAGEMENT参数值如何设置，都必须同时复制到standby数据库，并注意要修改standby数据库的控制文件。
下面分别通过示例演示STANDBY_FILE_MANAGEMENT参数值为AUTO/MANUAL值时增加及删除数据文件时的情形：
1).STANDBY_FILE_MANAGEMENT设置为AUTO，增加及删除表空间和数据文件
SQL> show parameter standby_file
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
standby_file_management string AUTO
A).增加新的表空间 --primary数据库操作
SQL> create tablespace mytmp datafile 'e:\ora10g\oradata\jssweb\mytmp01.dbf' size 20m;
表空间已创建。
|
SQL> select name from v$datafile;
系统已更改。 |
B).验证standby库 --standby数据库操作
|
SQL> select name from v$datafile; 已选择6行。 NAME |
可以看到，表空间和数据文件已经自动创建，你是不是奇怪为什么数据文件路径自动变成了jsspdg，赫赫，因为我们设置了db_file_name_convert嘛。
C).删除表空间 --primary数据库操作
SQL> drop tablespace mytmp including contents and datafiles;
表空间已删除。
|
SQL> select name from v$datafile; SQL> alter system switch logfile; |
提示：使用including子句删除表空间时，
D).验证standby数据库 --standby数据库操作
|
SQL> select name from v$datafile; SQL> select name from v$tablespace; NAME 已选择6行。 |
得出结论，对于初始化参数STANDBY_FILE_MANAGMENT设置为auto的话，对于表空间和数据文件的操作完全无须dba手工干预，primary和standby都能很好的处理。
2).STANDBY_FILE_MANAGEMENT设置为MANUAL，增加及删除表空间和数据文件
A).增加新的表空间 --primary数据库操作
SQL> create tablespace mytmp datafile 'e:\ora10g\oradata\jssweb\mytmp01.dbf' size 20m;
表空间已创建。
检查刚添加的数据文件
|
SQL> select name from v$datafile; NAME 已选择6行。 |
切换日志
SQL> alter system switch logfile;
系统已更改。
B).验证standby库 --standby数据库操作
|
SQL> select name from v$datafile; 已选择6行。 NAME |
可以看到，表空间已经自动创建，但是，数据文件却被起了个怪名字，手工修改其与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';
数据库已更改。
C).删除表空间 --primary数据库操作
|
SQL> drop tablespace mytmp including contents and datafiles; 表空间已删除。 NAME SQL> alter system switch logfile; |
D).验证standby数据库 --standby数据库操作
|
SQL> select name from v$datafile; 已选择6行。 NAME |
呀，数据还在啊。赶紧分析分析，查看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
MRP0: Background Media Recovery terminated with error 1274
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 |
注意，既使你在primary数据库执行删除时加上了including子句，在standby数据库仍然只会将表空间和数据文件从数据字典中删除，你还需要手工删除表空间涉及的数据文件。
再次得出结论，初始化参数STANDBY_FILE_MANAGMENT设置为manual的话，对于表空间和数据文件的操作必须有dba手工介入，你肯定会问，这太麻烦了，那我干脆配置dg的时候直接把初始化参数设置为auto不就好了嘛，en，你想的很好，不过三思需要提醒你地是，如果你的存储采用文件系统，那当然没有问题，但是如果采用了裸设备，你就必须将该参数设置为manual。
2、重命名数据文件
如果primary数据库重命令了一个或多个数据文件，该项修改并不会自动传播到standby数据库。因为此，如果你想让standby和数据文件与primary保持一致，那你也只能自己手工操作了。这会儿就算STANDBY_FILE_MANAGEMENT也帮不上忙啦，不管它是auto还是manual。
下面通过示例做个演示：
A).将重命名的数据文件所在表空间offline --primary数据库操作
SQL> alter tablespace webtbs offline;
表空间已更改。
B).手工将数据文件改名(操作系统) --primary数据库操作
方式多样，不详述。
C).通过命令修改数据字典中的数据文件路径，并online表空间 --primary数据库操作
|
SQL> alter tablespace webtbs rename datafile 表空间已更改。 表空间已更改。 |
D).暂停redo应用，并shutdown --standby数据库操作
SQL> alter database recover managed standby database cancel;
数据库已更改。
SQL> shutdown immediate
ORA-01109: 数据库未打开
......
E).手工将数据文件改名(操作系统) --standby数据库操作
方式多样，不详述。
F).重启standby，修改数据文件路径(数据字典) --standby数据库操作
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';
数据库已更改。
G).重新启动redo应用。
SQL> alter database recover managed standby database disconnect from session;
数据库已更改。
H).切换日志 --primary数据库操作
SQL> alter system switch logfile;
系统已更改。
峻工~~~~
3、添加或删除Online redo logs
数据库调优时极有可能会涉及到重置大小或增加删除日志组等操作，基本上这种操作不会传播到standby数据库，也不会影响到standby数据库的运行，但是如果你不注意其中的关系，造成的影响可能会很深远，
比如，我们假设我们的一台primary数据库拥有5组online redo文件，standby数据库拥有2组，当你执行switch over之后，新的primary执行归档的频率会比standby高的多，因此，当你在primary数据库增加或移除online redologs时，一定记的手工同步一相standby数据库中相关的设置。
这就是我们前面提到的standby redologs与online redologs之间的关系，即保证standby redologs比online redologs要至少多一组。
操作的过程很简单(总不会复杂过添加删除数据文件)，这里就不演示了，需要你注意的就是在standby做操作前务必将STANDBY_FILE_MANAGEMENT设置为MANUAL。
三、对open resetlogs的primary数据库standby的恢复
下表描述其它情况下如何同步standby与primary数据库。
| Standby数据库状态 | Standby服务器操作 | 解决方案 |
| 没有应用resetlog之前的redo数据 | 自动应用新的redo数据 | 无须手工介入 |
|
应用了resetlog之后的redo数据， 不过standby打开了flashback。 |
可以应用，不过需要dba手工介
入 |
1.手工flashback到应用之前
2.重启redo应用，以重新接收新的
redo数据。 |
|
应用了resetlog之后的redo数据， 而且没有flashback。 |
完全无法应用 |
很绕是吧，举个例子你就明白了：
假设primary数据库当前生成的archive sequence#如下：...26,27,28，然后在28的时候执行了resetlogs，又生成了新的1,2,3.....，那么standby能够正常接收并应用26,27,28及新产生的1,2,3....
如果primary数据库在28的时候发生数据出现故障，recover到27，然后resetlogs，又生成了新的1,2,3.....，这个时候(大家注意，招子放亮点)：如果standby还没有应用28，刚刚应用到27，则standby还可以继续接收新的redo数据1,2,3.....并应用。
如果此时不幸，standby由于是实时应用，已经应用了28的redo数据，那么如果standby打开了flashback，不幸中的万幸啊，这时候只需要dba手工介绍先flashback到27,然后再接收并应用新的1,2,3....
如果此时非常不幸，standby由于是实时应用，已经应用了28的redo数据，并且standby也没有打开flashback，那么，重建物理standby是你唯一的选择。
四、监控primary/standby数据库
本节主要介绍一些监控dg配置的方式，先给大家提供一个表格(描述不同事件的不同信息监控途径
|
primary数据库事件 |
primary监控途径 |
standby监控途径 |
|
带有enable|disable thread子句的alter database命令 |
? 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 |
2、动态性能视图
先也是一句话：做为自己自觉主动维护的一批虚拟表它的作用非常明显通过它可以及时获得当前数据库状态及处理进度总之好处多多也需特别关注后面示例也会多处用到大家要擦亮双眼。
? 先来点与恢复进度相关的v$视图应用示例：
该视图就是专为显示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列显示的进程状态
通过上述查询可以得知primary开了两个归档进程，使用lgwr同步传输方式与standby通信，已经接收完763的日志，正等待764。
B).确认redo应用进度---v$archive_dest_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 |
D).查询归档历史---v$log_history
该视图查询standby库中所有已被应用的归档文件信息(不论该归档文件是否还存在)，例如：
? 再来点与log应用相关的v$视图应用示例：
A).查询当前数据的基本信息---v$database信息。
例如，查询数据库角色，保护模式，保护级别等：
SQL> select database_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
再比如，查询failover后快速启动的信息
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
B).检查应用模式(是否启用了实时应用)---v$archive_dest_status
查询v$archive_dest_status视图，如果打开了实时应用，则recovery_mode会显示为：MANAGED REAL TIME APPLY，例如：
SQL> select recovery_mode from v$archive_dest_status where dest_id=2;
RECOVERY_MODE
-----------------------
MANAGED REAL TIME APPLY
C).Data guard事件---v$dataguard_status
该视图显示那些被自动触发写入alert.log或服务器trace文件的事件。通常是在你不便访问到服务器查询alert.log时，可以临时访问本视图查看一些与dataguard相关的信息，例如：
|
SQL> select message from v$dataguard_status; MESSAGE |
五、调整物理standby log应用频率
1、设置recover并行度
在介质恢复或redo应用期间，都需要读取重做，默认都是串行恢复，我们可以在执行recover的时候加上parallel子句来指定并行度，提高读取和应用的性能，例如：
SQL> alter database recover managed standby database parallel 2 disconnect from session;
推荐parallel的值是#CPUs*2;
2、加快redo应用频繁
设置初始化参数DB_BLOCK_CHECKING=FALSE能够提高2倍左右的应用效率，该参数是验证数据块是否有效，对于standby禁止验证基本上还是可以接受的，另外还有一个关联初始化参数DB_BLOCK_CHECKSUM，建议该参数在primary和standby都设置为true。
3、设置PARALLEL_EXECUTION_MESSAGE_SIZE
如果打开了并行恢复，适当提高初始化参数：PARALLEL_EXECUTION_MESSAGE_SIZE的参数值，比如4096也能提高大概20%左右的性能，不过需要注意增大这个参数的参数值可能会占用更多内存。
4、优化磁盘I/O
在恢复期间最大瓶颈就是I/O读写，要缓解这个瓶颈，使用本地异步I/O并设置初始化参数DISK_ASYNCH_IO=TRUE会有所帮助。DISK_ASYNCH_IO参数控制到数据文件的磁盘I/O是否异步。某些情况下异步I/O 能降低文件并行读取，提高整个恢复时间。
