一步一步学DataGuard(19)逻辑standby之高级管理4

特殊事件的控制

时间紧任务急，呵呵，这里三思就只描述流程，过程就不做演示了，相信你的智力，你一定能看懂。

1、 导入传输表空间

v  第一步：屏蔽guard保护，逻辑standby端操作

SQL> ALTER SESSION DISABLE GUARD;

v  第二步：导入传输表空间，逻辑standby端操作

具体操作步骤可参考三思之前的笔记：使用可传输表空间的特性复制数据！

v  第三步：恢复guard保护(或者直接退出本session也成)，逻辑standby端操作

SQL> ALTER SESSION ENABLE GUARD;

v  第四步：导入传输表空间，primary端操作

同第二步。

2、 使用物化视图

SQL应用不支持下列对物化视图的ddl操作：

v  create/alter/drop materialized view

v  create/alter/drop materialized view log

因此，对于现有逻辑standby，primary端对物化视图的操作不会传播到standby端。不过，对于primary创建物化视图之后创建逻辑standby，则物理视图也会存在于逻辑standby端。

v  对于同时存在于primary和逻辑standby的ON-COMMIT物化视图，逻辑standby会在事务提交时自动刷新，而对于ON-DEMAND的物化视图不会自动刷新，需要手动调用dbms_mview.refresh过程刷新。

v  对于逻辑standby端建立的ON-COMMIT物化视图会自动维护，ON-DEMAND物化视图也还是需要手工调用dbms_mview.refresh过程刷新。

3、 触发器及约束的运作方式

默认情况下，约束和触发器同样会在逻辑standby端正常工作。

对于有sql应用维护的约束和触发器：

v  约束：由于约束在primary已经检查过，因此standby端不需要再次检查

v  触发器：primary端操作时结果被记录，在standby端直接被应用。

没有sql应用维护的约束和触发器：

v  约束有效

v  触发器有效

优化逻辑standby

1、 创建Primary Key RELY 约束

某些情况下能够有效提高sql应用效率，具体可参见第三部分第一章。

2、 生成统计信息

这个很容易理解嘛，因为cbo要用，生成方式即可用analyze，也可以用dbms_stats包。看你个人喜好了。

3、 调整进程数

A) .调整APPLIER进程数

首先查看当前空闲的applier进程数：

JSSLDG2> SELECT COUNT(*) AS IDLE_APPLIER FROM V$LOGSTDBY_PROCESS

  2  WHERE TYPE = 'APPLIER' and status_code = 16166;

IDLE_APPLIER

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

           0

提示：

status_code = 16166 表示进程是空闲状态，可以看到"STATS"为"ORA-16116: no work available"，当然空闲的applier进程数为0不一定代表应用应用非常繁忙，也有可能是因为当前没什么需要应用的日志，因此甚至应用进程都没启动:)

检查事务的应用情况：

JSSLDG2> select name,value from v$logstdby_stats where name like 'TRANSACTION%';

NAME                          VALUE

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

transactions ready             896

transactions applied           871

如果ready-applied的值比applier进程数的两倍还要大，则说明你有必要考虑增加applier进程的数目了，反之如果applied与ready的值差不多大，或者其差比applier进程数还小，则说明applier进程数偏多，你有必要考虑适当减小进程的数目。

如果确认当前applier进程都非常繁忙，要增加applier进程，可按如下步骤操作：

停止sql应用

ALTER DATABASE STOP LOGICAL STANDBY APPLY; 

调整applier进程数为20，默认是5个

EXECUTE DBMS_LOGSTDBY.APPLY_SET('APPLY_SERVERS', 20);

重启sql应用

ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

B) .调整PREPARER进程数

需要调整preparer进程数的机会不多，通常只有一种情况：applier进程有空闲，transactions ready还很多，但没有空闲的preparer进程，这时候你可能需要增加一些preparer进程。

要检查系统是否存在这种情况，可以通过下列的sql语句：

首先检查空闲preparer进程数量：

SELECT COUNT(*) AS IDLE_PREPARER FROM V$LOGSTDBY_PROCESS WHERE TYPE = 'PREPARER' and status_code = 16166;

检查事务的应用情况：

select name,value from v$logstdby_stats where name like 'TRANSACTION%';

查看当前空闲的applier进程数：

SELECT COUNT(*) AS IDLE_APPLIER FROM V$LOGSTDBY_PROCESS WHERE TYPE = 'APPLIER' and status_code = 16166;

如果确实需要调整preparer进程数量，可以按照下列步骤，例如：

停止sql应用

ALTER DATABASE STOP LOGICAL STANDBY APPLY; 

调整preparer进程数量为4(默认只有1个preparer进程)

EXECUTE DBMS_LOGSTDBY.APPLY_SET('PREPARE_SERVERS', 4); 

重启sql应用

ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE; 

4、 调整LCR使用的内存

执行下列语句，查询当前LCR可用的最大内存：

JSSLDG2> select * from v$logstdby_stats where name='maximum SGA for LCR cache';

NAME                                 VALUE

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

maximum SGA for LCR cache            30

要增加LCR可用的内存，按照下列步骤操作：

停止sql应用：

JSSLDG2> alter database stop logical standby apply;

数据库已更改。

调整内存大小，注意默认单位是M：

JSSLDG2> execute dbms_logstdby.apply_set('MAX_SGA',100);

PL/SQL 过程已成功完成。

重启sql应用

JSSLDG2> alter database start logical standby apply immediate;

数据库已更改。

5、 调整事务应用方式

默认情况下逻辑standby端事务应用顺序与primary端提交顺序相同。

如果你希望逻辑standby端的事务应用不要按照顺序的话，可以按照下列的步骤操作：

①　 停止sql应用:

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;

②　 允许事务不按照primary的提交顺序应用

SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('PRESERVE_COMMIT_ORDER', 'FALSE');

③　 重新启动sql应用

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

恢复逻辑standby按照事务提交顺序应用的话，按照下列步骤：

①　 还是先停止sql应用：

SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;

②　 重置参数PRESERVE_COMMIT_ORDER的初始值：

SQL> EXECUTE DBMS_LOGSTDBY.APPLY_UNSET('PRESERVE_COMMIT_ORDER');

③　 重新启动sql应用：

SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

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

转载于:http://blog.itpub.net/7607759/viewspace-220533/