ORACLE DataGuard Logical Standby 详解之：修改逻辑Standby端数据

• Dataguard Logical Standby 系列文章:
• 一、逻辑Standby的准备工作
• 二、逻辑Standby创建时的操作步骤
• 三、管理逻辑Standby的相关视图
• 四、逻辑Standby数据库的自定义配置
• 五、修改逻辑Standby端数据
• 六、优化逻辑Standby数据同步性能
• 七、利用REDO数据到Standby数据库

本节内容

相对物理Standby，逻辑Standby的管理要复杂一点点。这个就是管理一个半数据库和管理两个数据库的差异（假定Data Guard环境为一主一备的情况下），毕竟逻辑Standby只是逻辑上，恍如与Primary数据库一致，其实它是一个独立运行的，乃至可能与Primary数据库完全区别的数据库系统，对这类配置环境，管理上多花点工夫想一想也是应当的。

1 指定对象跳过利用
在默许情况下，接收自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外，其他都是可选参数，并且看字面意义就可以明白其所指。例如，你想跳过SCOTT用户下对dept表的DML操作，可以通过履行以下语句实现（履行该进程前需要先停止REDO利用）：
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
Database altered.
SQL> EXEC DBMS_LOGSTDBY.SKIP(‘DML’, ‘SCOTT’, ‘DEPT’);
PL/SQL procedure successfully completed.
SQL>ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
Database altered.

2 恢复对象同步
如果逻辑Standby中的某些表取消了与Primary的同步保护，现在希望再恢复同步，没问题，DBMS_LOGSTDBY家大业大，它还有个叫UNSKIP的门生专干这个。
我们来看一下DBMS_LOGSTDBY.UNSKIP的语法：
DBMS_LOGSTDBY.UNSKIP (
stmt IN VARCHAR2,
schema_name IN VARCHAR2,
object_name IN VARCHAR2);
三项均为必选参数，各参数的定义与SKIP进程相同。

下面演示恢复tmp1表的同步。
首先查看当前逻辑Standby都有哪几种对象处于区别步状态，可以通过DBA_LOGSTDBY_SKIP视图查看，例如：
SQL> select * from dba_logstdby_skip;
ERROR STATEMENT_OPT OWNER NAME U E PROC

N DML SCOTT DEPT Y
N INTERNAL SCHEMA SYSTEM % Y
N INTERNAL SCHEMA SYS % Y
N INTERNAL SCHEMA OLAPSYS % Y
N INTERNAL SCHEMA SI_INFORMT % Y
N INTERNAL SCHEMA MGMT_VIEW % Y
N INTERNAL SCHEMA ORDPLUGINS % Y
N INTERNAL SCHEMA XDB % Y
N INTERNAL SCHEMA SYSMAN % Y
N INTERNAL SCHEMA WMSYS % Y
N INTERNAL SCHEMA DBSNMP % Y

注意在履行DBMS_LOGSTDBY.UNSKIP进程前，要停止当前的SQL利用状态：
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
Database altered.
履行DBMS_LOGSTDBY.UNSKIP进程，恢复前面停止的scott.tmp1表的利用：
SQL> execute dbms_logstdby.unskip(‘DML’, ‘SCOTT’, ‘dept’);
PL/SQL procedure successfully completed.

3 添加或重建对象
指定对象跳过利用虽然被取消，但是有可能在此期间由于Primary数据库做过数据修改，两端此时已区别步，如果Standby端继续利用极有可能致使利用毛病的数据。
对这类情况，Oracle也早有预感，DBMS_LOGSTDBY包中还有一个进程叫INSTANTIATE_TABLE，专门用来同步一下跳过的对象，以保持与Primary数据库的一致。

DBMS_LOGSTDBY.INSTANTIATE_TABLE的调用语法以下：
DBMS_LOGSTDBY.INSTANTIATE_TABLE (
schema_name IN VARCHAR2,
table_name IN VARCHAR2,
dblink IN VARCHAR2);
除SCHEMA名称和表名称外，还需要提供一个数据库链，因此这里我们首先在逻辑Standby端创建一个连接Primary数据库的数据库链：
SQL> CREATE DATABASE LINK PRE_TBL_DATA CONNECT TO SYSTEM IDENTIFIED BY ADMIN
USING ‘ORCL_PD’;
Database link created.
履行使用DBMS_LOGSTDBY.INSTANTIATE_TABLE进程，重新同步SCOTT.TMP1表（注意履行该进程前别忘了暂停当前的SQL利用）：
SQL>EXEC DBMS_LOGSTDBY.INSTANTIATE_TABLE(‘SCOTT’, ‘DEPT’, ‘PRE_TBL_DATA’);
PL/SQL procedure successfully completed.
SQL> SELECT * FROM SCOTT.DEPT;

对象已被重建，然后重新启动SQL利用便可：
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
Database altered.

4 逻辑Standby端修改数据
逻辑Standby的一个极具实用价值的特性就是可以边查询边利用，因此将其作为报表服务器专供查询是个很不错的想法，而且逻辑Standby相对物理Standby而言更具灵活性，如我们可以在逻辑Standby上，对一些表创建Primary数据库其实不方便创建的索引、束缚，乃至可以做DML/DDL操作（固然，需要注意不要破坏了与Primary数据库之间同步的逻辑关系）。
不过由于此时Data Guard依然控制着对逻辑Standby数据库中表的读写操作，因此，如果你想对逻辑Standby中的数据做些甚么的话，ALTER SESSION DISABLE|ENABLE GUARD语句就一定要牢记在心了，它具有像”芝麻开门”一样奇异的能力。 下面我们就来感受一下吧。

在逻辑Standby端启动SQL利用的情况下，履行DDL操作：
SQL> GRANT DBA TO SCOTT;
Grant succeeded.
SQL> CONN SCOTT/TIGER;
Connected.
SQL> CREATE TABLE DAVE AS SELECT * FROM USER_OBJECTS;
CREATE TABLE DAVE AS SELECT * FROM USER_OBJECTS
*
ERROR at line 1:
ORA-01031: insufficient privileges

出错了，提示权限不足，实际上SCOTT被授与了DBA角色，肯定具有CREATE TABLE权限的，因此此处与用户的权限无关，而是有其他因素制约了SCOTT没法进行修改。
下面禁用Data Guard保护以后，再次尝试操作数据：
SQL> ALTER SESSION DISABLE GUARD;
Session altered.
SQL> CREATE TABLE DAVE AS SELECT * FROM USER_OBJECTS;
Table created.
这下可以了，这就是Data Guard的作用。
注 意： 数据修改完以后，别忘了再次启用Data Guard，以免不经意的误操作对逻辑Standby的配置造成影响��你说不手动启用Data Guard保护，直接退出行不行，固然也能够，ALTER SESSION所做修改仅对当前会话有效，退出重新登录，原会话设置自然就失效了）。
SQL> ALTER SESSION ENABLE GUARD;
Session altered.

依照Oracle的建议，或者尽量不要在逻辑Standby端履行DML之类操作，以避免破解其与Primary之间同步的逻辑关系，

也能够通过以下语句查看当前数据库会不会处于Data Guard保护状态：
SQL> SELECT GUARD_STATUS FROM V$DATABASE;

ALL

该参数对应三个值：
ALL：表示对数据库中所有对象启动修改保护，除SYS用户外，其他用户均不能直接修改数据。
STANDBY：表示对处于逻辑Standby保护关系的对象启动修改保护，除SYS用户外，其他用户均不能直接修改数据。
NONE：不启动数据保护。

如果要永久设置数据库的Data Guard保护模式，则是通过ALTER DATABASE命令来完成，可指定的值也正是上述的三种，例如：
SQL> ALTER DATABASE GUARD STANDBY;
Database altered.

履行完上述语句后，Data Guard仅对处于逻辑Standby保护关系的对象进行避免修改操作的保护。

斟酌到逻辑Standby中也有可能对数据进行修改（正如上例演示），因此这里引伸谈一谈在逻辑Standby数据库中，束缚和触发器的履行模式。默许情况下，束缚和触发器都能在逻辑Standby端正常运行。束缚和触发器在逻辑Standby真个履行可以分成两种情况：
对SQL利用保护的束缚和触发器，由于在Primary数据库已检查过束缚，因此Standby端不需要再次检查；触发器的情况也是这样，Primary端操作时结果已被记录，因此逻辑Standby端将直接被利用，而不会二次触发。
对没有SQL利用保护的束缚和触发器，其履行情况与普通的Oracle数据库环境相同。

5 重定义REDO利用履行的操作
对逻辑Standby数据库，你乃至可以通过编写自定义的PROCEDURE，来重新定义SQL利用时履行的操作。
如逻辑Standby数据库的文件路径与Primary数据库路径区别，如果是物理Standby，可以通过*_FILE_NAME_CONVERT之类的参数处理，在逻辑Standby环境中这几个参数无效，应当怎么处理呢？答案就是通过编写自定义的进程，修改SQL利用时履行的操作。

下面通过示例，演示通过编写自定义的PROCEDURE，修改创建表空间时逻辑Standby端数据文件的路径。
首先固然是创建一个进程，建议创建在SYS下，由于在这个用户下的操作肯定不会有同步的问题，以下所示：
SQL> CREATE OR REPLACE PROCEDURE SYS.HANDLE_TBS_DDL (
2 OLD_STMT IN VARCHAR2,
3 STMT_TYP IN VARCHAR2,
4 SCHEMA IN VARCHAR2,
5 NAME IN VARCHAR2,
6 XIDUSN IN NUMBER,
7 XIDSLT IN NUMBER,
8 XIDSQN IN NUMBER,
9 ACTION OUT NUMBER,
10 NEW_STMT OUT VARCHAR2
11 ) AS
12 BEGIN
13
14 NEW_STMT := REPLACE(OLD_STMT, ‘/u01/oradata/orcl_pd/’, ‘/u01/oradata/orcl_st’);
15 ACTION := DBMS_LOGSTDBY.SKIP_ACTION_REPLACE;
16
17 EXCEPTION
18 WHEN OTHERS THEN
19 ACTION := DBMS_LOGSTDBY.SKIP_ACTION_ERROR;
20 NEW_STMT := NULL;
21 END HANDLE_TBS_DDL;
22 /
Procedure created.
逻辑非常简单，基本上就是一个REPLACE，不过PROCEDURE中声明的变量看起来很多，这个是固定格式，不建议修改。

停止逻辑Standby的SQL利用：
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
Database altered.

如果不停，PROCEDURE不能生效。

履行DBMS_LOGSTDBY.SKIP进程，将编写的进程注册到表空间处理的SQL利用中：
SQL> EXEC DBMS_LOGSTDBY.SKIP (stmt => ‘TABLESPACE’,proc_name => ‘sys.handle_tbs_ddl’);
PL/SQL procedure successfully completed.

这里也要借助DBMS_LOGSTDBY.SKIP进程实现。该进程功能非常强大，而且操作非常灵活。

重启SQL利用：
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
Database altered.

测试一下，在Primary端创建一个新的表空间：
SQL> CREATE TABLESPACE BOOKS DATAFILE ‘/u01/oradata/orcl_pd/books01.dbf’ SIZE 20m;
Tablespace created.
SQL> SELECT FILE_NAME FROM DBA_DATA_FILES WHERE TABLESPACE_NAME=’BOOKS’;

/u01/oradata/orcl_pd/books01.dbf

转向逻辑Standby数据库查看：
SQL> SELECT FILE_NAME FROM DBA_DATA_FILES WHERE TABLESPACE_NAME=’BOOKS’;

/u01/oradata/orcl_st/books01.dbf
表空间成功创建，并且数据文件路径也被转换为我们指定的路径。

此时如果你查看Alert日志文件，会发现其中记录下了类似这样的信息：
LOGSTDBY stmt: create tablespace books datafile ‘/u01/oradata/orcl_pd/books01.dbf’ size 20m
LOGSTDBY status: ORA⑴6110: 逻辑备用利用 DDL 的用户进程处理
LOGSTDBY id: XID 0x0001.009.000000d1, hSCN 0x0000.0012ec41,
lSCN 0x0000.0012ec41, Thread 1, RBA 0x007f.0000079a.80,
txnCscn 0x0000.0012ec43, PID 5816, ORACLE.EXE (P004)
LOGSTDBY stmt: create tablespace books datafile ‘/u01/oradata/orcl_st/books01.dbf’ size 20m
LOGSTDBY status: ORA⑴6202: 跳过进程已要求替换语句
LOGSTDBY id: XID 0x0001.009.000000d1, hSCN 0x0000.0012ec41,
lSCN 0x0000.0012ec41, Thread 1, RBA 0x007f.0000079a.80,
txnCscn 0x0000.0012ec43, PID 5816, ORACLE.EXE (P004)
create tablespace books datafile ‘/u01/oradata/orcl_st/books01.dbf’ size 20m
Completed: create tablespace books datafile ‘/u01/oradata/orcl_st/books01.dbf’ size 20m
LOGSTDBY stmt: create tablespace books datafile ‘/u01/oradata/orcl_st/books01.dbf’ size 20m
LOGSTDBY status: ORA⑴6204: 成功利用了 DDL