DataGuard:Logical Standby Create Sample

DataGuard:Logical Standby Create Sample

 

Oracle 10g logical standby配置前的一些注意点:

(1)不支持的数据类型有：

BFILE、Encrypted columns、ROWID, UROWID、XMLType、对象类型、VARRAYS、嵌套表、自定义类型,

可以通过查询视图DBA_LOGSTDBY_UNSUPPORTED来确定主数据库中是否含有不支持的对象 ：

SQL> SELECT * FROM DBA_LOGSTDBY_UNSUPPORTED;

 

(2)此外还有若干ddl,pl/sql包不被logical standby支持，具体可以参考oracle的文档描述。

 

(3)确保primary库中各表的行可被唯一标识

 

Oracle 通过主键、唯一索引/约束补充日志(supplemental logging)来确定待更新逻辑standby库中的行。

当数据库启用了补充日志(supplemental logging)，每一条update语句写redo的时候会附加列值唯一信息，比如：

如果表定义了主键，则主键值会随同被更新列一起做为update语句的一部分，以便执行时区别哪些列应该被更新。 如果没有主键，则非空的唯一索引/约束会随同被更新列做为update语句的一部分，以便执行时区分哪些列应该被更新，如果该表有多个唯一索引/约束，则oracle自动选择最短的那个。 如果表即无主键，也没有定义唯一索引/约束，所有可定长度的列连同被更新列作为update语句的一部分。更明确的话，可定长度的列是指那些除:long,lob,long raw,object type,collection类型外的列。

 

逻辑STANDBY需要确保主库中每一行每一列的更新都能被日志应用到逻辑备用库里面，因此最好主库中的表都具备唯一约束。可以通过视图DBA_LOGSTDBY_NOT_UNIQUE来查找主库中不具备唯一约束的表。

 

确定在主数据库上，补充日志是否被启用，可以查询v$database，如下：

SQL> select supplemental_log_data_pk,supplemental_log_data_ui from v$database;

SUP SUP

--- ---

YES YES

 

如果没有开启supplemental log

SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY, UNIQUE INDEX) COLUMNS;

 

查询DBA_LOGSTDBY_NOT_UNIQUE 可以得到主数据库中没有primary key，也没有unique index 的表

SQL> Select * From DBA_LOGSTDBY_NOT_UNIQUE;

BAD_COLUMN列值，该列有两个值：

Y：表示该表中有采用大数据类型的字段，比如LONG啦，CLOB啦之类。如果表中除log列某些行记录完全匹配，则该表无法成功应用于逻辑standby。standby会尝试维护这些表，不过你必须保证应用不允许

N：表示该表拥有足够的信息，能够支持在逻辑standby的更新，不过仍然建议你为该表创建一个主键或者唯一索引/约束以提高log应用效率。

 

 

 

 

具体步骤

 

1,确定primary ,standby的状态信息，并取消standby库的redo应用

   Primary库

   db1>select database_role,open_mode,protection_mode from v$database;

 

DATABASE_ROLE    OPEN_MODE  PROTECTION_MODE

---------------- ---------- --------------------

PRIMARY          READ WRITE MAXIMUM PERFORMANCE

 

Standby 库

 

db2>select database_role,open_mode,protection_mode from v$database;

 

DATABASE_ROLE    OPEN_MODE  PROTECTION_MODE

---------------- ---------- --------------------

PHYSICAL STANDBY MOUNTED    MAXIMUM PERFORMANCE

    alter database recover managed standby database cancel;

    先取消redo应用，否则在左第四步时会长时间没有相应的情况

2.primary库中注册logminer元数据信息

   execute dbms_logstdby.build;

3.standby 库查询v$standby_log视图，确定现有standby log 是否合理，是否需要增加standby log group,如需要，执行如下语句即可。

    alter database add standby logfile gourp 4 'xxxx' size 10m;

4.转换为logical standby

   alter database recover to logical standby db1;

alert_db1.log 报警日志

alter database recover to logical standby db1

 

Tue Jan 20 17:11:50 2009

Managed Standby Recovery not using Real Time Apply

 parallel recovery started with 2 processes

Media Recovery Log C:\ARCH\DB2\STANDBY\DB2_ARC00041_0675443184.001

Media Recovery Log C:\ARCH\DB2\STANDBY\DB2_ARC00042_0675443184.001

Media Recovery Log C:\ARCH\DB2\STANDBY\DB2_ARC00043_0675443184.001

Tue Jan 20 17:11:58 2009

Incomplete Recovery applied until change 1039571

RESETLOGS after incomplete recovery UNTIL CHANGE 1039571

Resetting resetlogs activation ID 1269940896 (0x4bb1c2a0)

Online log C:\ORACLE\PRODUCT\10.2.0\ORADATA\DB2\REDO01.LOG: Thread 1 Group 1 was previously cleared

Online log C:\ORACLE\PRODUCT\10.2.0\ORADATA\DB2\REDO02.LOG: Thread 1 Group 2 was previously cleared

Online log C:\ORACLE\PRODUCT\10.2.0\ORADATA\DB2\REDO03.LOG: Thread 1 Group 3 was previously cleared

Standby became primary SCN: 1039569

Tue Jan 20 17:12:07 2009

Setting recovery target incarnation to 3

Tue Jan 20 17:12:07 2009

Converting standby mount to primary mount.

*** DBNEWID utility started ***

DBID will be changed from 1269306797 to new DBID of 1270581031 for database DB1

DBNAME will be changed from DB1 to new DBNAME of DB1

Starting datafile conversion

Setting recovery target incarnation to 1

Datafile conversion complete

Database name changed to DB1.

Modify parameter file and generate a new password file before restarting.

Database ID for database DB1 changed to 1270581031.

All previous backups and archived redo logs for this database are unusable.

Database has been shutdown, open with RESETLOGS option.

Succesfully changed database name and ID.

*** DBNEWID utility finished succesfully ***

Completed: alter database recover to logical standby db1

Tue Jan 20 17:12:16 2009

ARC0: Archival disabled due to instance shutdown

Shutting down archive processes

Archiving is disabled

Tue Jan 20 17:12:21 2009

ARCH shutting down

ARC1: Archival stopped

Tue Jan 20 17:12:31 2009

ARCH shutting down

ARC0: Archival stopped

5.检查是否需要重建密码文件(sys密码要和primary一致)，参数文件是否需要调整

6.打开logical database

    alter database open resetlogs;

    查询v$database视图，看到已经是logical standby 了 

    db2>select database_role,open_mode,protection_mode from v$database;

 

DATABASE_ROLE    OPEN_MODE  PROTECTION_MODE

---------------- ---------- --------------------

LOGICAL STANDBY  READ WRITE MAXIMUM PERFORMANCE   

 

7.logical standby库上开始应用redo log

    alter database start logical standby apply或

    alter database start logical standby apply immediate;

    加了immediate，表示启用适时sql应用，primary的修改立刻在standby中被应用，如没有带immediate，

    则需要依赖primary的logfile switch来传递archived logfile 给standby，standby中的logminer 再来抽

    取分析该文件中的sql。

   

8.验证测试logical standby是否可以正常工作

 

primary 库执行

db1>insert into test.a(col1)  values ('My Logical Standby Database ...');

 

standby库执行

db2>select * from test.a;

 

COL1

--------------------------------------------------------------------------------

My Data Guard!!!

Switch Protection Mode

Real Apply Redo

Switchover successful....

Switchover successful on realtime apply....

My Logical Standby Database ...

 

9.测试完毕，关闭redo 的应用

    alter database stop logical standby apply immediate

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10159839/viewspace-598220/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/10159839/viewspace-598220/