As shown in the previous example, the specified object skipped the application although it was canceled, but it is possible that during this time due to the primary database data modification, both ends are not synchronized at this time, if the standby end of the application is very likely to cause the application of the wrong data.
Oracle databases have also been foreseen for such cases, and a process called instantiate_table in the Dbms_logstdby package is designed to synchronize skipped objects to maintain consistency with the primary database.
Dbms_logstdby. The instantiate_table invocation syntax is as follows:
1. Dbms_logstdby. Instantiate_table (
2. Schema_name in VARCHAR2,
3. table_name in VARCHAR2,
4. Dblink in VARCHAR2);
In addition to the schema name and table name, you need to provide a database chain, so here we first create a chain of database connections to the primary database on the logical standby side:
1. jssldg> CREATE DATABASE LINK pre_tbl_data CONNECT to
2. SYSTEM identified by Verysafe USING ' jsspre_192.168.100.100 ';
3. Database link created.
Perform the use of Dbms_logstdby. Instantiate_table the procedure, resynchronize the SCOTT.TMP1 table (Note that the current SQL application is paused before executing this procedure):
1. jssldg> EXEC Dbms_logstdby. Instantiate_table
2. (' SCOTT ', ' TMP1 ', ' pre_tbl_data ');
3. Pl/sql procedure successfully completed.
4. jssldg> SELECT * from SCOTT. TMP1;
5. NAME
6.--------------------
7. Test1
8. Test2
9. Test3
Test4
Test5.
Test6
6 rows selected.
The object has been rebuilt, and then the SQL application can be restarted:
1. jssldg> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
2. Database altered.
See more highlights of this column: http://www.bianceng.cnhttp://www.bianceng.cn/database/Oracle/