Data Guard学习物理standby高级管理

最新推荐文章于 2021-04-02 22:04:25 发布

sopost

最新推荐文章于 2021-04-02 22:04:25 发布

阅读量1.1k

点赞数

分类专栏： Oracle 文章标签：数据库 database sql archive file parallel

Oracle 专栏收录该内容

197 篇文章 0 订阅

订阅专栏

一、READ ONLY/WRITE模式打开物理STANDBY
前面提到关于物理standby可以有效分担primary数据库压力，提升资源利用，实际上说的就是这个。以read only或read write模式打开物理standby，你可以转移一些查询任何啦，备份啦之类的操作到standby数据库，以这种方式来分担一些primary的压力。下面我们来演示一下，如何切换standby数据库的打开模式，其实，非常简单。例如，以Read-only模式打开物理standby：

这里要分两种情况：
1).standby数据库处于shutdown状态
直接startup即可。
SQL> startup
ORACLE 例程已经启动。
......

2).standby数据库处于redo应用状态。
首先取消redo应用：
SQL> alter database recover managed standby database cancel;

数据库已更改。

然后再打开数据库
SQL> alter database open ;

数据库已更改。
提示：open的时候不需要附加read only子句，oracle会根据控制文件判断是否是物理standby，从而自动启动到read only模式，直接startup也是同理。

3).如果想从open状态再切换回redo应用状态，并不需要shutdown，直接启用redo应用即可，例如：

 
 
  
  
  
  
  
  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

二、管理影响standby的primary数据库事件
为预防可能的错误，你必须知道primary数据库的某些事件可能影响standby数据库，并且了解如何处理。

某些情况下，primary数据库的某些改动会自动通过redo数据传播到standby数据库，因此不需要在standby数据库做额外的操作，而某些情况，则需要你手工调整。

下列事件会由redo传输服务及redo应用自动处理，不需要dba的干预，分别是：
 ALTER DATABASE ENABLE|DISABLE THREAD 语句(主要针对rac环境，目前基本已废弃，因为ENABLE|DISABLE INSTANCE子句完全能够实现类似功能)
 修改表空间状态(例如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，增加及删除表空间和数据文件
我们先来看看初始化参数的设置： ----standby数据库操作
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;  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;  系统已更改。

B).验证standby库 --standby数据库操作

 
 
  
  
  
  
  
  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行。

可以看到，表空间和数据文件已经自动创建，你是不是奇怪为什么数据文件路径自动变成了jsspdg，赫赫，因为我们设置了db_file_name_convert嘛。

C).删除表空间 --primary数据库操作
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子句删除表空间时，

D).验证standby数据库 --standby数据库操作

 
 
  
  
  
  
  
  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都能很好的处理。

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 
  
  --
  
  --------------------------------------------- 
  
   
  
  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;

系统已更改。

B).验证standby库 --standby数据库操作

 
 
  
  
  
  
  
  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';

数据库已更改。

C).删除表空间 --primary数据库操作

 
 
  
  
  
  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;  系统已更改。

D).验证standby数据库 --standby数据库操作

 
 
  
  
  
  
  
  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
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 
  
  --
  
  -------------------------------------------- 
  
   
  
  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

注意，既使你在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 
  
  2
  
   
  
  '
  
  E:/ORA10G/ORADATA/JSSWEB/WEBTBS01.DBF
  
  '
  
   
  
  to
  
   
  
  3
  
   
  
  '
  
  E:/ORA10G/ORADATA/JSSWEB/TBSWEB01.DBF
  
  '
  
  ;  表空间已更改。 SQL
  
  >
  
   
  
  alter
  
   tablespace webtbs online;  表空间已更改。

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的恢复
当primary数据库被以resetlogs打开之后，dg提供了一些方案，能够让你快速的恢复物理standby，当然这是有条件的，不可能所有的情况都可以快速恢复。我们都知道alter database open resetlogs之后，数据库的scn被重置，也就是此时其redo数据也会从头开始。当物理standby接收到新的redo数据时，redo应用会自动获取这部分redo数据。对于物理standby而言，只要数据库没有应用resetlogs之后的redo数据，那么这个过程是不需要dba手工参与的。

下表描述其它情况下如何同步standby与primary数据库。

Standby数据库状态	Standby 服务器操作	解决方案
没有应用resetlog之前的redo数据	自动应用新的redo数据	无须手工介入
应用了resetlog之后的redo数据，不过standby打开了flashback。	可以应用，不过需要dba手工介入	1.手工flashback到应用之前 2.重启redo应用，以重新接收新的redo数据。
应用了resetlog之后的redo数据，而且没有flashback。	完全无法应用	重建物理standby是唯一的选择

很绕是吧，举个例子你就明白了：
    假设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

概括起来主要通过二个方面：
1、Alert Log
一句话：一定要养成有事没事定期不定期随时查看alert.log的好习惯同时特别注意alert中的提示通常不经意间会发现它的提示能够让你的思路豁然开朗。

2、动态性能视图
先也是一句话：做为oracle自己自觉主动维护的一批虚拟表它的作用非常明显通过它可以及时获得当前数据库状态及处理进度总之好处多多也需特别关注后面示例也会多处用到大家要擦亮双眼。

 先来点与恢复进度相关的v$视图应用示例：
A).查看进程的活动状况---v$managed_standby
该视图就是专为显示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

C).检查归档文件路径及创建信息---v$archived_log
该视图查询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

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 
  
  --
  
  -------------------------------------------------------------------------- 
  
   
  
  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

五、调整物理standby log应用频率
调整应用频率说白了就是调整io读取能力，所以通常我们可以从以下几个方面着手：
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 能降低数据库文件并行读取，提高整个恢复时间。

sopost

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Data Guard学习物理standby高级管理

一、READ ONLY/WRITE模式打开物理STANDBY前面提到关于物理standby可以有效分担primary数据库压力，提升资源利用，实际上说的就是这个。以read only或read write模式打开物理standby，你可以转移一些查询任何啦，备份啦之类的操作到standby数据库，以这种方式来分担一些primary的压力。下面我们来演示一下，如何切换standby数据库的打开模式，其实，非常简单。例如，以Read-only模式打开物理standby：这里要分两种情况： 1).standby
复制链接

扫一扫

专栏目录