Decode360's Blog

业精于勤而荒于嬉 QQ:150355677 MSN:decode360@hotmail.com

  BlogJava :: 首页 :: 新随笔 :: 联系 ::  :: 管理 ::
  397 随笔 :: 33 文章 :: 29 评论 :: 0 Trackbacks
本文作者: junsansi     转载网址: http://www.5ienet.com/index.shtml
 
 
第三部分逻辑standby(4)高级管理  2008.03.04
 
 
一、监控逻辑standby
 
    与物理standby 的管理一样,oracle 提供了一系列动态性能视图来查看逻辑standby 的状态,有一些我们前面已经接触过,而有一些,我们还从未用过。。。。。
 
1、DBA_LOGSTDBY_EVENTS
 
    可以把该视图看成逻辑standby 操作日志,因此如果发生了错误,可以通过该视图查看近期逻辑standby都做了些什么。默认情况下, 该视图保留100 条事件的记录, 不过你可以通过DBMS_LOGSTDBY.APPLY_SET()过程修改该参数。
 
    例如:

    JSSLDG2> select event_time,status,event from dba_logstdby_events;
    EVENT_TIME          STATUS                                    EVENT
    ------------------- ----------------------------------------- ----------------------------------------
    2008-03-06 08:58:11 ORA-16112: 日志挖掘和应用正在停止
    2008-03-06 09:02:00 ORA-16111: 日志挖掘和应用正在启动
    2008-03-06 09:52:53 ORA-16128: 已成功完成用户启动的停止应用操作
    2008-03-12 15:52:53 ORA-16111: 日志挖掘和应用正在启动
    2008-03-12 16:09:17 ORA-16226: 由于不支持而跳过DDL              ALTER DATABASEOPEN
    2008-03-05 17:21:46 ORA-16111: 日志挖掘和应用正在启动
    ..............................

 
2、DBA_LOGSTDBY_LOG
 
    该视图用来记录当前的归档日志应用情况,等同于物理standby 中的v$archived_log,多数情况下,你只需要关注SEQUENCE#,APPLIED,即查看日志序号和是否应用,当然该视图还能提供更多信息,比如应用的scn,应用时间等,例如:

    JSSLDG2> select sequence#,first_change#,next_change#,timestamp,applied from dba_logstdby_log;
    SEQUENCE# FIRST_CHANGE# NEXT_CHANGE# TIMESTAMP           APPLIED
    ---------- ------------- ------------ ------------------- --------
    869        1319212       1319811      2008-03-12 16:09:15 CURRENT

 
    通常情况下,该查询只会返回几条记录,如果说你的数据库操作非常频繁,可能记录数会稍多一些,但如果记录数非常多,那你可能就需要关注一下,是不是出了什么问题,难道sql 应用没有启动?
 
3、V$LOGSTDBY_STATS

    从名字就大致猜的出来,该视图显示的是状态信息,没错,你猜对了,该视图就是用来显示LogMiner的统计信息及状态。

    JSSLDG2> select *from v$logstdby_stats;
    NAME                                     VALUE
    ---------------------------------------- ---------------
    number of preparers                      1
    number of appliers                      5
    maximum SGA for LCR cache                30
    parallel servers in use                  9
    maximum events recorded                  100
    preserve commit order                    TRUE
    transaction consistency                 FULL
    record skip errors                      Y
    record skip DDL                          Y
    record applied DDL                       N
    .........................

 
4、V$PROCESV$LOGSTDBY_PROCESS
 
    该视图显示当前log 应用服务的相关信息。常用于诊断归档日志逻辑应用的性能问题(后面优化部分会有涉及),包含的信息也很广:
    ※ 身份信息:SID,SERIAL#,SPID
    ※ SQL 应用进程:COORDINATOR, READER, BUILDER, PREPARER, ANALYZER, 或APPLIER
    ※ 进程当前的状态:见status_code 或status 列
    ※ 该进程当前操作redo 记录最大SCN:high_scn 列
 
    例如:

    JSSLDG2> select sid,serial#,spid,type,status,high_scn from v$logstdby_process;
    SID      SERIAL#   SPID   TYPE            STATUS                                          HIGH_SCN
    -------- ------- -------- --------------- ----------------------------------------------- ----------
    145      1       508      COORDINATOR     ORA-16116: 无可用工作                            1319811
    146      2       2464     READER          ORA-16240: 正在等待日志文件(线程号1,序列号870)     1319811
    143      1       1512     BUILDER         ORA-16116: 无可用工作                            1319742
    142      1       4000     PREPARER        ORA-16116: 无可用工作                            1319741
    139      1       2980     ANALYZER        ORA-16116: 无可用工作                            1319707
    135      1       1648     APPLIER         ORA-16116: 无可用工作                            1319430
    138      1       2332     APPLIER         ORA-16116: 无可用工作                            1319439
    132      1       2200     APPLIER         ORA-16116: 无可用工作                            1319443
    134      1       4020     APPLIER         ORA-16116: 无可用工作
    ...........................................

 
5、V$PROGRESV$LOGSTDBY_PROGRESS

    该视图显示log 应用服务当前进展状况,比如当前应用到逻辑standby 的scn 及时间,sql 应用开始应用的scn 及时间,最后接收及应用的scn 和时间等等。
    例如:

    JSSLDG2> select * from v$Logstdby_progress;
    APPLIED_SCN APPLIED_TIME        RESTART_SCN RESTART_TIME        LATEST_SCNLATEST_TIME         MINING_SCN MINING_TIME
    ----------- ------------------- ----------- ------------------- ---------- ------------------- ---------- -------------------
    1319810     2008-03-12 16:06:51 1319662     2008-03-12 16:03:22 1319810    2008-03-12 16:45:331319811    2008-03-12 16:06:51

 
6、V$LOGSTDBY_STATE

    该视图就最简单了,就是显示sql 应用的大致状态,比如primary 库的dbid 啦,是否启动了实时应用啦,当前sql 应用的状态啦之类。
 
    注意state 列,该列可能有下述的几种状态:
    INITIALIZING: LogMiner session 已创建并初始化
    LOADING DICTIONARY: SQL 应用调用LogMiner 字典
    WAITING ON GAP: SQL 应用正等待日志文件,可能有中断
    APPLYING: SQL 应用正在工作
    WAITING FOR DICTIONARY LOGS: SQL 应用等待LogMiner 字典信息
    IDLE: SQL 应用工作非常出色,已经干的没什么可干了:)
 
    例如:

    JSSLDG2> select * from v$Logstdby_state;
    PRIMARY_DBID SESSION_ID REALTIME_APPLY       STATE
    ------------ ---------- -------------------- ----------------------
    3408827880   42         Y                    APPLYING

 
 
二、管理逻辑standby

1、接收到的归档文件

    前章曾经提到,逻辑standby 应用完归档后会自动删除该归档文件,该特性你如果觉着不爽,没关系,执行下面这个过程,屏蔽掉它:

    JSSLDG2> EXECUTE DBMS_LOGSTDBY.APPLY_SET('LOG_AUTO_DELETE', FALSE);

 
    提示:这种操作并非毫无意义,比如说逻辑standby 打开了flashback database,那如果你想恢复到之前的某个时间点,然后再接着应用,就必须要有该时间点后对应的归档,假如LOG_AUTO_DELETE 为TRUE的话,显然应用过的归档就不存在了,想回都回不去。
 
2、启动实时应用
 
    默认情况下,log 应用服务会等待单个归档文件全部接收之后再启动应用(在前面redo 传输服务中我们介绍了不同形式的传输方式),如果standby 端使用了standby redologs,就可以打开实时应用(real-time apply),这样dg 就不需要再等待接收完归档文件,只要rfs 将redo 数据写入standby redologs,即可通过MRP/LSP
实时写向standby,这样就可以尽可能保持standby 与primary 的同步。
 
    要启动逻辑standby 的实时应用,只需要在启动逻辑standby 应用时加上immediate 子句即可,前面我们已经无数次的演练过,例如:

    JSSLDG2> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;

 
3、定义DBA_EVENTDBA_LOGSTDBY_EVENTS视图中事件记录的相关参数。
 
    Dba_logstdby_events 视图前面刚讲过,里面记录了逻辑standby 的一些操作事件,如果你希望修改该视图中记录的事件信息的话,可以通过下列的方式:
 
    例如,希望该视图能够保留最近999 条事件,可以通过执行下列语句:

    JSSLDG2> select *from v$logstdby_stats where name='maximum events recorded';
    NAME                                         VALUE
    -------------------------------------------- ---------------
    maximum events recorded                      100

    JSSLDG2> alter database stop logical standby apply;
    数据库已更改。

    JSSLDG2> execute dbms_logstdby.apply_set('max_events_recorded','999');
    PL/SQL 过程已成功完成。

    JSSLDG2> alter database start logical standby apply immediate;
    数据库已更改。

    JSSLDG2> select *from v$logstdby_stats where name='maximum events recorded';
    NAME                                         VALUE
    -------------------------------------------- ---------------

    maximum events recorded                      999

 
    再比如,你如果想在视图中记录ddl 操作的信息,可以通过执行下列语句:

    JSSLDG2> execute dbms_logstdby.apply_set('RECORD_APPLIED_DDL','TRUE');

 
4、指定对象跳过应用,请用DBMS_LOGSTDBY.SKIP

    默认情况下,接收自primary 的redo 数据中,所有能够被standby 支持的操作都会在逻辑standby 端执行,如果你希望跳过对某些对象的某些操作的话,DBMS_LOGSTDBY.SKIP 就能被派上用场了。
 
    先来看看dbms_logstdby.skip 的语法:
    DBMS_LOGSTDBY.SKIP (
    stmt            IN VARCHAR2,
    schema_name     IN VARCHAR2 DEFAULT NULL,
    object_name     IN VARCHAR2 DEFAULT NULL,
    proc_name       IN VARCHAR2 DEFAULT NULL,
    use_like        IN BOOLEAN DEFAULT TRUE,
    esc             IN CHAR1 DEFAULT NULL);
    除stmt 外,其它都是可选参数,并且看字面意义就能明白其所指,下面简单描述一下stmt 参数调用的关键字都是指定值,详细见下列:
 
STMT关键字 包含的操作
NON_SCHEMA_DDL 不属于模式对象的所有其它ddl操作
提示:使用该关键字时,SCHEMA_NAMEOBJECT_NAME两参数也必须指定。
SCHEMA_DDL 创建修改删除模式对象的所有ddl操作(例如: tables, indexes, and columns)
提示:使用该关键字时,SCHEMA_NAMEOBJECT_NAME两参数也必须指定。
DML Includes DML statements on a table (for example: INSERT, UPDATE, and DELETE)
CLUSTER AUDIT CLUSTER
CREATE CLUSTER
DROP CLUSTER
TRUNCATE CLUSTER
CONTEXT CREATE CONTEXT
DROP CONTEXT
DATABASE LINK CREATE DATABASE LINK
CREATE PUBLIC DATABASE LINK
DROP DATABASE LINK
DROP PUBLIC DATABASE LINK
DIMENSION  ALTER DIMENSION
CREATE DIMENSION
DROP DIMENSION
DIRECTORY  CREATE DIRECTORY
DROP DIRECTORY
INDEX ALTER INDEX
CREATE INDEX
DROP INDEX
PROCEDURE  ALTER FUNCTION
ALTER PACKAGE
ALTER PACKAGE BODY
ALTER PROCEDURE
CREATE FUNCTION
CREATE LIBRARY
CREATE PACKAGE
CREATE PACKAGE BODY
CREATE PROCEDURE
DROP FUNCTION
DROP LIBRARY
DROP PACKAGE
DROP PACKAGE BODY
DROP PROCEDURE
PROFILE  ALTER PROFILE
CREATE PROFILE
DROP PROFILE
ROLE ALTER ROLE
CREATE ROLE
DROP ROLE
SET ROLE
ROLLBACK STATEMENT ALTER ROLLBACK SEGMENT
CREATE ROLLBACK SEGMENT
DROP ROLLBACK SEGMENT
SEQUENCE ALTER SEQUENCE
CREATE SEQUENCE
DROP SEQUENCE
SYNONYM CREATE PUBLIC SYNONYM
CREATE SYNONYM
DROP PUBLIC SYNONYM
DROP SYNONYM
TABLE  ALTER TABLE
CREATE TABLE
DROP TABLE
TABLESPACE  CREATE TABLESPACE
DROP TABLESPACE
TRUNCATE TABLESPACE
TRIGGER  ALTER TRIGGER
CREATE TRIGGER
DISABLE ALL TRIGGERS
DISABLE TRIGGER
DROP TRIGGER
ENABLE ALL TRIGGERS
ENABLE TRIGGER
TYPE  ALTER TYPE
ALTER TYPE BODY
CREATE TYPE
CREATE TYPE BODY
DROP TYPE
DROP TYPE BODY
USER  ALTER USER
CREATE USER
DROP USER
VIEW  CREATE VIEW
DROP VIEW
 
    例如,你想跳过jss 用户下对tmp1 表的dml 操作,可以通过执行下列语句实现(执行该过程前需要先停止redo 应用):

    JSSLDG2> alter database stop logical standby apply;
    数据库已更改。

    JSSLDG2> executedbms_logstdby.skip('DML','JSS','TMP1');
    PL/SQL 过程已成功完成。

    JSSLDG2> alter database start logical standby apply;
    数据库已更改。


    提示:DBMS_LOGSTDBY.SKIP 的功能非常强大,限于篇幅,这里仅举示例,而且由于其操作非常灵活,此篇俺也不可能就其用法做个一一列举,因此,更丰富的操作方式就留待看官们下头自行发现去吧:)
 

三、修改逻辑standby端数据

    我们前面提到,逻辑standby 一个极具实用价值的特性即是可以边查询边应用,因此将其做为报表服务器专供查询是个很不错的想法,而且逻辑standby 相对于物理standby 而言更具灵活性,比如我们可以在逻辑standby上,对一些表创建primary 库上并不方便创建的索引,约束,甚至可以做dml,ddl 操作(当然,需要注意不要破坏了与primary 之间同步的逻辑关系)。不过由于此时dg 仍然控制着对逻辑standby 表的读写操作,因此,如果你想对逻辑standby 中的数据做些什么的话,alter session database disable|enable guard 语句就必须牢记在心了,它拥有像“芝麻开门”一样神奇的能力,不信?下面我们就来感受一下吧。
 
1、逻辑standby端执行ddl
 
    在逻辑standby 端开始了redo 应用的情况下,执行ddl 操作:

    JSSLDG2> create table tmp55 as select * From b;
    create table tmp55 as select * From b
    *
    第1 行出现错误:
    ORA-01031: 权限不足

    看看,出错了吧~~~

    JSSLDG2> alter session disable guard;
    会话已更改。
    JSSLDG2> create table tmp55 as select * From b;
    表已创建。


    只有关闭了guard 保护之后,才能操作数据,然后别忘了再启用guard,以避免不经意的操作对逻辑standby 的配置造成影响。

    JSSLDG2> alter session enable guard;
    会话已更改。

 
    提示:oracle 建议还是尽可能不要在逻辑standby 执行执行dml 之类操作,以免破解其与primary 之间同步的逻辑关系,当然,这只是个建议,如果你已经仔细看完了3.1 章,并且对数据库表结构及存储结构了如指掌,那您就爱干嘛爱嘛。
 
2、取消对象同步

    如果说,某些表或者数据不需要dataguard 保护(比如一些在逻辑standby 端生成的统计表),这个时候就需要DBMS_LOGSTDBY.SKIP,前头已经介绍过了dbms_logstdby.skip 的基本用法,下面我们来具体演示一下!
    下面我们假设standby 端有一批表名为tmp 开头的表,这张表不再需要保持与primary 的同步,那么按照步骤执行下列语句,sql 应用即可跳过这些表:
 
    老规矩,先停了redo 应用

    JSSLDG2> alter database stop logical standby apply;
    数据库已更改。

    JSSLDG2> executexecute dbms_logstdby.skip('SCHEMA_DDL','JSS','TMP%'); --跳过对象的ddl 操作
    PL/SQL 过程已成功完成。

    JSSLDG2> executedbms_logstdby.skip('DML','JSS','TMP%'); --跳过对象的dml 操作
    PL/SQL 过程已成功完成。

    JSSLDG2> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
    数据库已更改。

 
    注意其中的%,该符号为通配符,作用与在sql 语句中的相同。
 
    OK,下面来测试一下,先看看逻辑standby 中表的信息,我们选择两张表,一张是我们前面已经指定了跳过的表tmp1,另一张是普通表b:

    JSSLDG2> select max(aa) from jss.tmp1;
    Max(aa)
    --------------------
    h

    JSSLDG2> select max(id) from jss.b;
    Max(id)
    ----------
    9

    JSSLDG2> select sequence#,applied from dba_logstdby_log;
    SEQUENCE# APPLIED
    ---------- --------
    872        YES

 
    然后在primary 数据库执行插入操作

    JSSWEB> select max(aa) from jss.tmp1;
    Max(aa)
    --------------------
    h

    JSSWEB> insert into jss.tmp1 values ('i');
    已创建1 行。
    JSSWEB> insert into jss.b values (10);
    已创建1 行。
    JSSWEB> commit;
    提交完成。

    JSSWEB> alter system switch logfile;
    系统已更改。

    JSSWEB> select max(sequence#) from v$archived_log;
    MAX(SEQUENCE#)
    --------------
    873

 
    再来看看逻辑standby 端的同步情况:

    JSSLDG2> select sequence#,applied from dba_logstdby_log;
    SEQUENCE# APPLIED
    ---------- --------
    873        YES

 
    显然日志已经接收,再看看数据:

    JSSLDG2> select max(id) from b;
    Max(id)
    ----------
    10

    JSSLDG2> select max(aa) from jss.tmp1;
    Max(aa)
    --------------------
    h

 
    b 表已应用,而tmp1 表则无变化。
 
3、恢复对象同步

    如果说某些表某个时候取消了同步,现在希望再恢复同步,没问题,DBMS_LOGSTDBY 家大业大,它还有个叫UNSKIP 的门生就是专干这个的。
 
    我们来看一下dbms_logstdby.unskip 的语法:

    DBMS_LOGSTDBY.UNSKIP (
    stmt         IN VARCHAR2,
    schema_name IN VARCHAR2,
    object_name IN VARCHAR2);

 
    三项均为必选参数,各参数的定义与skip 过程相同,这里不再复述。
 
    此处我们来演示恢复tmp%表的同步。

    JSSLDG2> select *from dba_logstdby_skip;
    ERROR STATEMENT_OPT   OWNER      NAME            U E PROC
    ----- --------------- ---------- --------------- - - --------------------
    N     SCHEMA_DDL      JSS        TMP%                Y
    N     DML             JSS        TMP%                Y
    N     DML             JSS        TMP1                Y
    ........

    JSSLDG2> alter database stop logical standby apply;
    数据库已更改。

    JSSLDG2> execute dbms_logstdby.unskip('DML','JSS','TMP1'); --本步操作是为解决历史遗留问题,不用关注
    PL/SQL 过程已成功完成。

    JSSLDG2> executexecute dbms_logstdby.unskip('DML','JSS','TMP%');
    PL/SQL 过程已成功完成。

    JSSLDG2> execute
    dbms_logstdby.unskip('SCHEMA_DDL','JSS','TMP%');
    PL/SQL 过程已成功完成。


    跳过同步已经取消了,紧接着我们需要再调用dbms_logstdby.instantiate_table 过程重新同步一下跳地的对象,将skip 这段时间,primary 对tmp1 表所做的操作同步过来(就俺看来,instantiate_table 过程实际上是借助dblink 重建了一遍对象),以保持与primary 的一致。Dbms_logstdby.instantiate_table 的语法如下:

    DBMS_LOGSTDBY.INSTANTIATE_TABLE (
    schema_name     IN VARCHAR2,
    table_name      IN VARCHAR2,
    dblink          IN VARCHAR2);

 
    使用DBMS_LOGSTDBY.INSTANTIATE_TABLE 过程重新执行一下同步(执行前别忘了暂停redo 应用):

    JSSLDG2> EXECUTE DBMS_LOGSTDBY.INSTANTIATE_TABLE('JSS','TMP1','GETJSSWEB');
    PL/SQL 过程已成功完成。

    JSSLDG2> select *from jss.tmp1;
    AA
    --------------------
    a
    b
    c
    d
    e
    f
    g
    h
    i
    已选择9 行。

 
    数据已重建,下面测试一下该表的redo 应用是否恢复了。

    JSSWEB> insert into jss.tmp1 values ('j');
    已创建1 行。
    JSSWEB> insert into jss.tmp1 values ('k');
    已创建1 行。
    JSSWEB> commit;
    提交完成。

    JSSWEB> alter system switch logfile;
    系统已更改。

    JSSWEB> select max(sequence#) from v$archived_log;
    MAX(SEQUENCE#)
    --------------
    877

 
    启动逻辑standby 端的redo 应用,看看对象的应用情况:

    JSSLDG2> alter database start logical standby apply immediate;
    数据库已更改。

    JSSLDG2> select sequence#,applied from dba_logstdby_log;
    SEQUENCE#  APPLIED
    ---------- --------
    875        YES
    876        YES
    877        YES

    JSSLDG2> select *from jss.tmp1;
    AA
    --------------------
    a
    b
    c
    d
    e
    f
    g
    h
    i
    j
    k
    已选择11 行。

 
    OK,恢复正常啦!
 
    注意哟,此处我们清楚明白的知道我们之前只操作了tmp1 一张表,如果是正式应用的话,那你恐怕有必要将所有tmp 开头的表都同步一下,不然有可能会造成数据丢失的哟。
 

四、特殊事件的控制

    时间紧任务急,呵呵,这里三思就只描述流程,过程就不做演示了,相信你的智力,你一定能看懂。
 
1、导入传输表空间
 
    ※ 第一步:屏蔽guard 保护,逻辑standby 端操作

    SQL> ALTER SESSION DISABLE GUARD;

 
    ※ 第二步:导入传输表空间,逻辑standby 端操作
    具体操作步骤可参考三思之前的笔记:使用可传输表空间的特性复制数据!
 
    ※ 第三步:恢复guard 保护(或者直接退出本session 也成),逻辑standby 端操作

    SQL> ALTER SESSION ENABLE GUARD;

 
    ※ 第四步:导入传输表空间,primary 端操作
    同第二步。
 
2、使用物化视图
 
    SQL 应用不支持下列对物化视图的ddl 操作:
    ※ create/alter/drop materialized view
    ※ create/alter/drop materialized view log
 
    因此,对于现有逻辑standby,primary 端对物化视图的操作不会传播到standby 端。不过,对于primary创建物化视图之后创建逻辑standby,则物理视图也会存在于逻辑standby 端。
 
    ※ 对于同时存在于primary 和逻辑standby 的ON-COMMIT 物化视图,逻辑standby 会在事务提交时自动刷新,而对于ON-DEMAND 的物化视图不会自动刷新,需要手动调用dbms_mview.refresh 过程刷新。
    ※ 对于逻辑standby 端建立的ON-COMMIT 物化视图会自动维护,ON-DEMAND 物化视图也还是需要手工调用dbms_mview.refresh 过程刷新。
 
3、触发器及约束的运作方式
 
    默认情况下,约束和触发器同样会在逻辑standby 端正常工作。
 
    对于有sql 应用维护的约束和触发器:
    ※ 约束:由于约束在primary 已经检查过,因此standby 端不需要再次检查
    ※ 触发器:primary 端操作时结果被记录,在standby 端直接被应用。
 
    没有sql 应用维护的约束和触发器:
    ※ 约束有效
    ※ 触发器有效
 
 
五、优化逻辑standbstandby
 
1、创建PrimaryKeyRELY约束
 
    某些情况下能够有效提高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 STANDBYAPPLY 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 STANDBYAPPLY 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 STANDBYAPPLY;

 

    允许事务不按照 primary 的提交顺序应用
    SQL> EXECUTE DBMS_LOGSTDBY.APPLY_SET('PRESERVE_COMMIT_ORDER', 'FALSE');

 

    重新启动 sql 应用
    SQL> ALTER DATABASE START LOGICAL STANDBYAPPLY IMMEDIATE;

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

    还是先停止 sql 应用:
    SQL> ALTER DATABASE STOP LOGICAL STANDBYAPPLY;

 

    重置参数 PRESERVE_COMMIT_ORDER 的初始值:
    SQL> EXECUTE DBMS_LOGSTDBY.APPLY_UNSET('PRESERVE_COMMIT_ORDER');

 

    重新启动 sql 应用:
    SQL> ALTER DATABASE START LOGICAL STANDBYAPPLY IMMEDIATE;

 
 
posted on 2009-02-26 23:27 decode360 阅读(131) 评论(0)  编辑  收藏 所属分类: 10.DB_Tools

只有注册用户登录后才能发表评论。


网站导航: