Oracle Dataguard之Real-Time Apply

Oracle Dataguard一共支持三种植模式:最老可用模式(Maximum
Availability),最深性模式(Maximum
Performance),最酷保护模式(Maximum
Protection)。默认创建的凡太特别性模式(Maximum
Performance)。关于三者的区别,我们来拘禁官方的定义。

Maximum Availability

Transactions do not commit until all redo data needed to recover those
transactions has been written to the online redo log and to the standby
redo log on at least one synchronized standby database.If the primary
database cannot write its redo stream to at least one synchronized
standby         database,it operates as if it were in maximum
performance mode to preserve primary database availability until it is
again able to write its redo stream to a synchronized standby database.

Maximum Performance

This is accomplished by allowing transactions to commit as soon as all
redo data generated by those transactions has been written to the online
log. Redo data is also written to one of more standby databases,but this
is done asynchronously with respect to transaction commitment,so primary
      database performance is unaffected by delays in writing redo data
to the standby databases.

Maximum Protection

This protection mode ensures that no data loss will occur if the primary
database fails.To provide this level of protection,the redo data needed
to      recover a transaction must be written to both the online redo
log and to the standby redo on at least one synchronized standby
database before the transaction commits.To ensure that data loss cannot
occur,the primary database will shut down,rather than continue
processing transactions,if it     cannot write its redo stream to at
least one synchronized standby database.

其三种植模式对日记传输的渴求如下:

图片 1

以头里篇稿子中-《Oracle
Dataguard之物理standby的着力配备》,我们最终安排出的凡Physical
Standby Database
最可怜性模式下之异步传输,现在咱们配备该模式下的Real-Time
Apply。启用Real-Time Apply需要配备standby redo
log,而及时也是另少栽模式的根基。

一、 创建standby redo log

      1> 查询主库上online redo log的组数和大小   –>> node1
上操作

         SQL> select group#,bytes/1024/1024 “size” from v$log;

         GROUP#  size
         ——     ———-
         1             50
         2             50
         3             50

      2> 在备库上补偿加standby redo log   –>> group比主库多一致组,大小及主库一样,node2上操作

         [oracle@node2 ~]$ mkdir /u01/standby

         SQL> alter database add standby logfile
‘/u01/standby/standby01.log’ size 50M;

         SQL> alter database add standby logfile
‘/u01/standby/standby02.log’ size 50M;

         SQL> alter database add standby logfile
‘/u01/standby/standby03.log’ size 50M;

         SQL> alter database add standby logfile
‘/u01/standby/standby04.log’ size 50M;

         注意:请保管已经关闭Redo
Apply,不然会报以下错误

                 SQL> alter database add standby logfile
‘/u01/standby/standby01.log’ size 50M;

                 alter database add standby logfile
‘/u01/standby/standby01.log’ size 50M
                 *
                 ERROR at line 1:
                 ORA-01156: recovery or flashback in progress may need
access to files

         关闭Redo Apply,

                SQL> alter database recover managed standby database
cancel;

次、
修改主库的配备参数
 –>> node1 上操作

          SQL> alter system set
log_archive_dest_2=’service=to_victor lgwr affirm sync
valid_for=(online_logfiles,primary_role) db_unique_name=victor’;

          SQL> alter system switch logfile;

老三、 在备库上启用Real-Time
Apply
 –>> node2 上操作

          SQL> alter database recover managed standby database using
current logfile disconnect from session;

四、 测试

     
 除了用前篇稿子中,查看归档日志的利用情况来验证dataguard的配置之外,本文将祭实际案例进行测试。 

      1> 在主库上新建一个测试表

           SQL> create table test(id number);

           SQL> insert into test values(1);

      2> 在备库中检测

          SQL> select * from test;

          no rows selected

      3> 在主库中付出业务

          SQL> commit;

      4> 在备库中检测

          SQL> select * from test;

          ID
          ———-
          1

总结:

      这个总结概括物理standby的骨干配备以及本文中的Real-Time Apply

   
 1> 如果只有设置主/次两单地面归档目的地,可以使初始化参数log_archive_dest指定主归档目的地,使用初始化参数log_archive_duplex_dest指定次归档目的地。

         
在数据库中,初始换参数log_archive_dest和log_archive_duplex_dest与log_archive_dest_n只能使用同一组来装归档目的地,不能够以用

     2>
备库log_archive_dest_1而无显性指定,默认的存档目录将凡$ORACLE_HOME/dbs.倘若显性指定,但valid_for不是

         
(standby_logfiles,standby_role)或者(all_logfiles,all_roles),则该装置无效,报警日志中将报以下错误:

            ORA-16032: parameter STANDBY_ARCHIVE_DEST destination
string cannot be translated

            归档目录将延续为$ORACLE_HOME/dbs

      3> 在本文中,log_archive_dest_1=’location=/u01/archivelog
valid_for=(standby_logfiles,standby_role)
db_unique_name=victor’,如果再次显性指定

            log_archive_dest_3=’location=/u01/standbyarchive
valid_for=(standby_logfiles,standby_role)
db_unique_name=victor’,将会生半点客standby的

            归档日志产生,没有必要,只待一个log_archive_dest_1即可

      4>
最深性模式下,如果是async,即异步,则要主库切一不良日志,备库采用采取。而只要启用Real-Time
Apply,则就需要主库事务commit, 备库就能运用

      5> 删除日志  

           SQL> alter database drop logfile group 7;

      6> 如果有了alter database recover managed standby database
cancel;这个令,MRP(Media Recovery process)将告一段落工作,但

           RFS(Remote file server)仍延续做事

      7> 如果没standby redo logs,是勿克开行real time apply的

           SQL> alter database recover managed standby database using
current logfile disconnect from session;
           alter database recover managed standby database using current
logfile disconnect from session
           *
           ERROR at line 1:
           ORA-38500: USING CURRENT LOGFILE option not available without
standby redo logs

      8> standby数据库startup后,没有生出alter database recover
managed standby database disconnect from
session这个令,RFS仍然工作,只要监听

           都ok

      9> disconnect from session代表是命令后台运行。

      10> Real-Time Apply的规律图

            图片 2

相关文章