dataguard之逻辑备库创建

最新推荐文章于 2022-10-17 11:18:26 发布

aoerqileng

最新推荐文章于 2022-10-17 11:18:26 发布

阅读量652

点赞数

分类专栏： dataguard 文章标签： dataguard 逻辑备库

dataguard 专栏收录该内容

51 篇文章 0 订阅

订阅专栏

创建逻辑备库之前的准备

1确定支持的表的数据类型和存储属性

2确认表中的行在主库中能被唯一标识

逻辑备库的物理组织与主库的不同，即使逻辑备库是由主库的备份创建的。因此，主库中在redo records中的rowid不能用于标识在逻辑备库中相应的行。

oracle在逻辑备库中使用主键或唯一键补充日志来逻辑的标识一个修改的行。当数据库级主键和唯一键补充日志被启用，每个update语句写列值到redo log来唯一标识修改的行。

如果表有主键定义，那么主键被写到日志中作为update语句的一部分来标识修改的行。

在缺失主键的情况下，最短非空唯一键被写到日志中作为update语句的一部分来标识修改的行。

在主键和非空唯一键都缺失的情况下，所有的行被写到日志中作为update的一部分来标识修改的行。所有的行中不包含下面的类型：long,lob,long row，对象类型和集合。

oracle建议在主库的表上添加主键或非空唯一索引，确保sql apply能有效应用redo数据来在逻辑备库中更新。做下面的步骤来确保sql apply能唯一标识表中的行。

1在主库中找到没有唯一标识符的表

SELECT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_NOT_UNIQUE WHERE (OWNER, TABLE_NAME) NOT IN (SELECT DISTINCT OWNER, TABLE_NAME FROM DBA_LOGSTDBY_UNSUPPORTED) AND BAD_COLLUMN = 'Y'；

2添加禁用的主键 rely约束

ALTER TABLE mytab ADD PRIMARY KEY (id, name) RELY DISABLE;

当你指定了rely约束，系统会假设行是唯一的，因为你告诉系统依赖信息，但是在每次修改的时候不回去验证，一定要小心选择rely约束的列，确保能唯一标识每行，如果不能唯一的话，sql apply不能正确的维护表。

为了提高sql apply的性能，在逻辑备库表的唯一标识行的列上添加一个索引，如果没有的话在update或delete的时候会走全表扫。

开始创建逻辑备库

1要创建逻辑备库，先创建一个物理备库出来，然后转换成逻辑备库。

2在物理备库上停止redo 应用

如果数据库是rac，那么要在执行下面的语句的时候，将活动实例的个数降为1个。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;

3为了支持逻辑备库准备主库

在配置物理备库的时候，已经设置了一些初始化参数，如果要转换主库成逻辑备库，那么主库上还要设置一个log_archive_dest_3的参数，这样在角色转换后就不用来做别的改动了，这个参数只有在主库转换成备库的时候有用。下面是个例子

LOG_ARCHIVE_DEST_3=
'LOCATION=/arch2/chicago/
VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)
DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_STATE_3=ENABLE

下面是这个参数的解释

	When the Chicago Database Is Running in the Primary Role	When the Chicago Database Is Running in the Logical Standby Role
`LOG_ARCHIVE_DEST_3`	Is ignored; `LOG_ARCHIVE_DEST_3` is valid only when `chicago` is running in the standby role.	Archives redo data received from the primary database to the local archived redo log files in `/arch2/chicago/`.

在redo数据中构建数据字典

一个logminer的数据字典一定要在redo数据中构建，这样sql apply才能正确解释redo中的改变。补充日志在主键和唯一索引列上设置。使用下面的语句创建数据字典：

SQL> EXECUTE DBMS_LOGSTDBY.BUILD;

dbms_logstdby.build存储过程使用闪回查询来获取数据字典的一致性快照，然后把它记录到redo流中，oracle建议在主库和逻辑备库上设置undo_retention为3600

4转换到逻辑备库

redo日志包含了转换物理备库到逻辑备库的信息，为了继续应用red数据到物理备库上直到转换成一个逻辑备库，执行下面的语句

ALTER DATABASE RECOVER TO LOGICAL STANDBY new-db_name;

这个语句等待，应用redo数据直到logminer数据字典在日志文件中被找到，这也许会花费几分钟时间，依赖与生成的数据字典传输到备库的时间，以及多少的redo数据需要被应用。如果主库上的数据字典没有成功的被创建，那么这个命令就不会结束，你可以再另外的一个会话上执行下面的命令来结束：

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL

创建一个新的口令文件

因为转换进程改变了逻辑数据库的名字，你必须重新创建口令文件。

为逻辑备库设置初始化参数

在逻辑备库，使用startup mount命令来启动mount数据库，不要打开书库，需要修改log_archive_dest_n参数，与物理备库不同，逻辑备库打开数据产生redo数据，逻辑备库有多个类型的redo文件（在线日志文件，归档日志文件，和standby日志文件），为下面的指定分开的本地目的地是最佳实践：

1逻辑备库生成的归档redo日志在下面的示例中配置到了LOG_ARCHIVE_DEST_1=LOCATION=/arch1/boston 目的地

2在主库传输过来的redo数据的归档放到了 LOG_ARCHIVE_DEST_3=LOCATION=/arch2/boston 这个目的地

LOG_ARCHIVE_DEST_1=
'LOCATION=/arch1/boston/
   VALID_FOR=(ONLINE_LOGFILES,ALL_ROLES)
   DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_2=
'SERVICE=chicago LGWR ASYNC
   VALID_FOR=(ONLINE_LOGFILES,PRIMARY_ROLE)
   DB_UNIQUE_NAME=chicago'
LOG_ARCHIVE_DEST_3=
'LOCATION=/arch2/boston/
   VALID_FOR=(STANDBY_LOGFILES,STANDBY_ROLE)
   DB_UNIQUE_NAME=boston'
LOG_ARCHIVE_DEST_STATE_1=ENABLE
LOG_ARCHIVE_DEST_STATE_2=ENABLE
LOG_ARCHIVE_DEST_STATE_3=ENABLE
下面是解释3个目的地的

	When the Boston Database Is Running in the Primary Role	When the Boston Database Is Running in the Logical Standby Role
`LOG_ARCHIVE_DEST_1`	Directs archival of redo data generated by the primary database from the local online redo log files to the local archived redo log files in `/arch1/boston/`.	Directs archival of redo data generated by the logical standby database from the local online redo log files to the local archived redo log files in `/arch1/boston/`.
`LOG_ARCHIVE_DEST_2`	Directs transmission of redo data to the remote logical standby database `chicago`.	Is ignored; `LOG_ARCHIVE_DEST_2` is valid only when `boston` is running in the primary role.
`LOG_ARCHIVE_DEST_3`	Is ignored; `LOG_ARCHIVE_DEST_3` is valid only when `boston` is running in the standby role.	Directs archival of redo data received from the primary database to the local archived redo log files in `/arch2/boston/`.