11g Active DataGuard初探

原本dataguard中日志应用和数据库只读查询是一个互斥的关系,两者不能并存。如果需要应用日志,则数据库只能在Mount状态下 使用recover managed standby database disconnect from session来不断地从后台进行日志应用。
如果想查看备库中的数据情况,则只能使用recover managed standby database cancel来取消日志应用,然后把数据库启动到read only 状态下。这种情况从道理上也讲也是有理有据,但是终归还是感觉不够方便,毕竟我们希望备库能够起到一些作用,不只是应用日志,一些大查询可以直接在备库上执行,能够分担主库的压力。11g的active dataguard就做到了这一点,重点就在于所说的active,所以这个时候数据库启动到了read only状态下,而且可以同时应用日志。如果配置备库的模式级别较高,甚至感觉和主库是一致的。
我们来简单看看这个特性。
我们来看看备库的信息。
idle> select name,database_role from v$database;
NAME      DATABASE_ROLE
--------- ----------------
TEST11G   PHYSICAL STANDBY
1 row selected.
对应的Instance信息。此时在Mount状态。
idle> select instance_name,status from v$instance;
INSTANCE_NAME    STATUS
---------------- ------------
DG11G            MOUNTED
1 row selected.
查看日志的应用情况,发现最新的记录中日志应用的需要为 78
idle>  select *from v$dataguard_status
Remote File Server       Warning                0          28          0 NO  01-JUN-15          RFS[2]: No standby redo logfiles of size 84490 blocks available
Log Apply Services       Informational          0          29          0 NO  01-JUN-15          Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_77_880742847.dbf
Log Apply Services       Warning                0          30          0 NO  01-JUN-15          Media Recovery Waiting for thread 1 sequence 78
30 rows selected.

我们在主库切换一下日志。
#### primary database
alter system switch logfile;

备库这边很快得到相应,可见dataguard的日志应用是没有问题的。这些部分和在10g中是一致的。
########## standby alert log
Mon Jun 01 22:46:51 2015
RFS[2]: No standby redo logfiles of size 57697 blocks available
RFS[2]: Opened log for thread 1 sequence 78 dbid 1028247664 branch 880742847
Archived Log entry 110 added for thread 1 sequence 78 rlc 880742847 ID 0x3d942dcb dest 2:
Mon Jun 01 22:46:54 2015
Media Recovery Log /u02/dg11g/flash_recovery_area/DG11G/archivelog/1_78_880742847.dbf
Media Recovery Waiting for thread 1 sequence 79

这个时候我们取消日志应用,把数据库启动起来。
idle> recover managed standby database cancel;
Media recovery complete.
idle> alter database open;
Database altered.

这个时候查看数据库的状态是read only.
idle> select open_mode from v$database;
OPEN_MODE
--------------------
READ ONLY
1 row selected.

这个时候我们来启用日志应用,这个也是在11g中的特色了。
idle> recover managed standby database using current logfile disconnect from session;
Media recovery complete.
这个时候查看状态就发生了细微的变化。
idle> select open_mode from v$database;
OPEN_MODE
--------------------
READ ONLY WITH APPLY
1 row selected.

这个时候为了验证,我们从主库做点什么,比如创建一个小表看看备库能够在open状态也能应用日志。
主库中执行。
sys@TEST11G> conn n1/n1
Connected.
n1@TEST11G> create table aaa as select *from cat;
Table created.

n1@TEST11G> select count(*)from aaa;
  COUNT(*)
----------
        19
1 row selected.

这个时候在备库中马上查看是没有效果的。
##### standby datababse
n1@TEST11G> select *from aaa;
select *from aaa
             *
ERROR at line 1:
ORA-00942: table or view does not exist

n1@TEST11G> show user
USER is "N1"
n1@TEST11G> 

这个时候我们尝试切一下主库的日志,看看备库有啥反应。
#### primary 
alter system switch logfile;

备库中的alert日志显示如下:
### standby log
Mon Jun 01 22:59:57 2015
RFS[2]: Selected log 8 for thread 1 sequence 79 dbid 1028247664 branch 880742847
Mon Jun 01 22:59:57 2015
Archived Log entry 111 added for thread 1 sequence 79 ID 0x3d942dcb dest 1:
Archived Log entry 112 added for thread 1 sequence 79 ID 0x3d942dcb dest 3:
Mon Jun 01 22:59:57 2015
Media Recovery Log /u02/dg11g/switchover/DG11G/archivelog/1_79_880742847.dbf
Media Recovery Waiting for thread 1 sequence 80

这个时候再次在备库查看,就发现数据变更都同步过来了。
n1@TEST11G> select count(*) from aaa;
  COUNT(*)
----------
        19
1 row selected.
n1@TEST11G> show user
USER is "N1"

时间: 2024-09-18 17:08:51

11g Active DataGuard初探的相关文章

最简单的11g Active DataGuard(ADG)搭建配置过程(项目步

最简单的11g Active DataGuard(ADG)搭建配置过程(项目步骤) 一.环境介绍:     我在db01和db02两台Linux虚拟机上首先分别安装了一套数据库软件,在db01主机上创建了名为woo的数据库:我们这次的实验是要搭建了一套Oracle 11g Active DataGuard:目的是为了实现数据库同步的功能,并且了解Oracle 11g DG的基本功能. db01:192.168.1.50db02:192.168.1.51 二.11g ADG部署: 1.pri端和s

Oracle 11g Dataguard物理备库配置(二) Active Dataguard测试

在Oracle 11g之前,物理备库(physical Standby)在应用redo的时候,数据库需要处于mount状态.从11g开始,应用redo的时候,物理备库可以处于read-only模式,这就称为Active Data Guard,这种状态可以实现实时查询功能. 1. 备库上操作 1) 查看备库当前状态 mount SQL> select open_mode,database_role,db_unique_name from v$database; OPEN_MODE        

ORACLE Active dataguard 一个latch: row cache objects BUG

在Active dataguard遇到latch: row cache objects 查询如下语句 select a.SAMPLE_TIME,a.SQL_ID,a.EVENT,a.P1TEXT,a.P1,a.P2TEXT,a.P2,a.P3TEXT,a.P3,  b.f2   from v$active_session_history a,     (select max(b.SQL_TEXT) f2,sql_id from  v$sql b group by sql_id ) b  wher

Oracle 11g DataGuard 物理备库配置及Active DataGuard测试

说明: 本文安装配置了Oracle 11g Dataguard 物理备库,并测试了11g Dataguard 物理备库新特性Active Data Guard, 是Oracle Database Enterprise Edition的一个功能,需要额外授权,本文只用于测试. 一.环境介绍 1. 主数据库环境 操作系统版本: OEL5.8 x64 数据库版本  : Oracle 11.2.0.3 x64 数据库sid名 : orcl 2. 备库环境 操作系统版本: OEL5.8 x64 数据库版本

【RAC】启用 Active Dataguard on 11gR2 RAC Standby

    对于已经建立的rac dataguard 环境,standby rac和主库对应拥有两个节点并且可以应在一个节点用日志!在此情况下 启用 ADG 特性 主库:rac1 rac2 备库: rac3 rac4 一 非dataguard·broker 情况下: 1. 日志已经在rac3上应用,所以只需在节点rac3上取消日志应用,注意:对于节点rac4 不用做任何操作! rac3> alter database recover managed standby database cancel;

11g dataguard使用总结

11g的dataguard相比于10g来说,最优越的特性应该算就是active dataguard了,这一点改进在很大意义上促使用户需要把数据库从10g升级到11g,读写分离在这个时候得到了升华,而且在后台会根据需要进行数据的同步,相比于使用10g,想读数据的时候把数据库启动到read only 阶段,但这个时候不接受日志同步数据,如果需要同步数据还需要把数据库再启动到mount阶段,感觉还是比较繁琐的. 11g的active dataurad功能很强大,同时搭建的时候使用rman 的dupli

oracle中一次dataguard坏块的修复

客户有个11g的active dataguard库,mrp进程停了,看alertlog,可以看到有关ora-7445[kdxlin]的报错: cat alert*.log .... Exception [type:SIGSEOV,Address not mapped to object] [ADDR:0xC] |PC:0x96504C7,kdxlin()+4153][flags: 0x0,count:1] Errors in le /aabb/app/oracle/rdbms/diag/rdbm

从Oracle 10g到11g,到底该升不该升?

    话题 Topic Oracle 10gR2目前运行比较平稳,从你的角度来说说,是否有升级的必要性?可从正反两方面来讨论,先抛出论点,再阐述论据.(本期话题贡献人:杨志洪)    正方:升  彭小波:在今年的7月份,我们10多套生产库从10g升级到了11g,高版本是下兼容的,10g在市场运行了这么多年,是相当稳定了.但是11g中改进了很多优化器的算法,也增加很多新特性.不管是从优化,还是管理上,对DBA来说都是一大福音.在升级的过程,我们也遇到一点小问题.   1.在10g升级到11g时,

10g和11g中的一些差别

最近有时候看官方文档,感觉11g里面已经有了很多的变化,无论是使用还是安装上的细节上,11g似乎总是能够带给我更多的惊喜.而从以往的使用情况中感觉10g已经足够了,但是越多的使用11g,逐渐的改变了自己的固有思维,很多原来不好,不方便的操作习惯都得到了很大的改善.我就从10g和11g共有的一些细节之处来一窥两个版本中的差别.细节还是太多,我就扒出小部门. 大体会从下面几个部分进行对比和说明,有一些部分已经写了一些文章了,所以突然回顾一下会发现原来这些看似清汤寡水的文章里面还是有值得推敲的东西.