2013年（350）
分类： Mysql/postgreSQL
2013-04-25 10:05:57
特殊事件的控制
时间紧任务急，呵呵，这里三思就只描述流程，过程就不做演示了，相信你的智力，你一定能看懂。
1、导入传输表空间
v 第一步：屏蔽guard保护，逻辑standby端操作
SQL> ALTER SESSION DISABLE GUARD;
v 第二步：导入传输表空间，逻辑standby端操作
具体操作步骤可参考三思之前的笔记：使用可传输表空间的特性复制数据！
v 第三步：恢复guard保护(或者直接退出本session也成)，逻辑standby端操作
SQL> ALTER SESSION ENABLE GUARD;
v 第四步：导入传输表空间，primary端操作
同第二步。
2、使用物化视图
应用不支持下列对物化视图的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;
