9ib REPL

Oracle9i Replication New Features
Schedule: Timing Topic

60 minutes Lecture
60 minutes Total
Objectives
At the end of this lesson, you should be able to:

• Describe the DDL which can be performed on
replicated tables without quiescing the replication
group
• Configure fast refresh for a materialized view which
contains a UNION clause
• Use the EXPLAIN_MVIEW procedure to troubleshoot
fast refresh of a materialized view
• Create a materialized view based on another
materialized view
• Understand the changes made to the job queue and
the data dictionary views for replication.
• Discuss LONG to LOB migration issues.
Objectives
This lesson will introduce the new replication features for Oracle9i. The main features are quiesce
reduction, multi-tier materialized views, and fast refresh enhancements.
While it is true that the differences between materialized views used for summary management and
materialized views used for replication (formally known as snapshots) are becoming less distinct with
each release, there are still a few fundamental differences. In this lesson, we will focus only on
materialized views which are used for replication. Summary management abilities, such as aggregate
functions and query rewrite are not available, unless so noted.
Oracle9i Replication New Features AR1- 2

Replication Quiesce Reduction
• Allows the DBA to perform certain DDL without

quiescing the replication group.
• In Oracle 8.1.7, quiesce reduction features were
added for single master sites only.
• There are additional restrictions if the master site
contains updatable materialized view.
• These features allowed the DBA to do the following
without quiescing the replication group:
– Define, modify, or drop conflict resolution
– Add an object to a replication group
– Generate replication support

Quiescing can take a fair amount of time, especially when there are backlogged queues. The goal is to
re-implement existing functionality to permit administration of a replicated environment without the
need for quiescing whenever it is always correct to do so. The existing APIs will be preserved
wherever possible by simply removing the quiesce precondition for certain API calls under certain
documented conditions. There will also be some extensions to the APIs to handle the remaining
cases. API calls that truly need quiescing to avoid data divergence will still require quiescing.
The operations that do not require you to quiesce a master group in a single master environment were
introduced in 8.1.7.
• Specify that an object is a replicated object (ADD_MASTER_REPOBJECT)
• Generate replication support (GENERATE_REPLICATION_SUPPORT).
• Define, modify, or drop conflict resolution
Note: Defining or modifying conflict resolution must be at the end of the Conflict Resolution chain.

In Oracle9i, the following additional DDL actions can be

performed without quiescing the replication group:
• Add new masters to the replication group
• Make a safe change to a replicated object (single
master sites only):
– Table, View, Synonym
– Index, Indextype, Operator
– Procedure, Function, Trigger,
– Package, Package Body, Type, Type Body

Oracle9i extends the functionality introduced in release 8.1.7 by introducing DDL which can be
performed on replicated tables in a multi-master environment without quiescing the replication group.
The new DDL action allowed is adding new masters to a replication group.
For single master sites you can additionally alter a replicated object to make a safe change to it
without quiescing the replication group by calling the ALTER_MASTER_REPOBJECTprocedure of
DBMS_REPCAT and setting the safe_table_change procedural parameter to TRUE.
The following changes are considered “safe”:
• Changing storage and extent information
• Making existing columns larger. For example, changing a VARCHAR2(20) column to a
VARCHAR2(50) column.
• Adding, altering, enabling, or disabling non primary key constraints
The following are unsafe changes:
• Changing the primary key by adding or deleting columns in the key
• Adding or dropping columns or changing the datatype of a column
• Making existing columns smaller. For example, changing a VARCHAR2(50) column to a
VARCHAR2(20) column.
• Disabling a primary key constraint

Add New Master Site without Quiescing
• Adding new master sites without quiescing

requires offline instantiation which can be
implemented with:
– Full or table level export
– Incomplete recovery to a specific SCN
• The DBMS_REPCAT package has been extended
to support this new feature:
– SPECIFY_NEW_MASTERS
– ADD_NEW_MASTERS
– RESUME_PROPAGATION_TO_MDEF
– PREPARE_INSTANTIATED_MASTER
Adding a New Master Site without Quiescing

A new implementation of offline instantiation for masters lets you add one or more databases to an
existing replication group without quiescing the masters group. There can be any number of existing
masters in each replication group you are extending. The new databases may or may not already be
master sites or materialized view sites in other replication groups.
• You can use full database export/import or change-based (SCN-based) recovery to instantiate
the new masters.
• Table-level export/import is useful for adding one or more replication groups to a database that
already has some replication groups or other data.
The following steps show how to add new masters without quiescing existing master sites:
1.Specify your intention to add one or more new masters in an existing replication group with a new
master definition site procedural call, SPECIFY_NEW_MASTERS. The new sites to be created are
added to the view DBA_REPSITES_NEW. If no new master sites are specified, all sites previously
listed in DBA_REPSITES_NEW will be removed.

Add New Master Site without Quiescing
SPECIFY_NEW_MASTERS
ADD_NEW_MASTERS
Export
RESUME_PROPAGATION_TO_MDEF
At MDEF
Perform SCN- At New

Import Master
based recovery
Site
PREPARE_INSTANTIATED_MASTER
Adding a New Master Site without Quiescing (continued)

2. After specifying all replication group extensions with SPECIFY_NEW_MASTERS, you then
invoke a new master definition site procedural call, ADD_NEW_MASTERS, which does the
following:
• Adds new masters to the replication catalog at all existing masters and at all new masters to be
instantiated with table-level export/import.
• Adds replicated objects to the replication catalog at new masters to be instantiated with table-
level export/import
• At each existing master, including the masterdef, either partially or completely disables
propagation to each new master.
• Returns to the calling session the SCN to which the new masters should be instantiated.
3. If using change-based recovery to instantiate all new masters, skip to step 4. Otherwise, perform a
full database or table level export, specifying the system change number (SCN) obtained in Step 2
for the CONSISTENT_AT export parameter. Then call RESUME_PROPAGATION_TO_MDEFto
indicate that the export has finished.
4. At each new master site, the replication administrator then imports the data or does change-based
recovery to the SCN obtained in Step 2. After the database is instantiated, make sure the correct
database links exists between the new masters sites and the master definition site. Then invoke a
new master site procedural call, PREPARE_INSTANTIATED_MASTER, which ensures the
database has the correct global name, renaming the database if necessary.
PREPARE_INSTANTIATED_MASTERmodifies the replication catalog to reflect the global name
of the database, drains the deferred RPC queue and error queue, and enables the new master sites
to propagate and receiveOracle9i Replication
replicated data. New Features AR1- 6
SPECIFY_NEW_MASTERS
DBMS_REPCAT.SPECIFY_NEW_MASTERS
DBMS_REPCAT.SPECIFY_NEW_MASTERS ((
gname
gname IN
IN VARCHAR2,
VARCHAR2,
[master_list
[master_list IN
IN VARCHAR2
VARCHAR2 ||
master_table
master_table IN
IN DBMS_UTILITY.dblink_array]
DBMS_UTILITY.dblink_array]
);
);
DBMS_REPCAT.SPECIFY_NEW_MASTERS
DBMS_REPCAT.SPECIFY_NEW_MASTERS ((
gname
gname =>
=> 'HR_REP_GRP',
'HR_REP_GRP',
master_list
master_list =>
=> 'HR_GERMANY.ACME.COM,
'HR_GERMANY.ACME.COM,
HR_RUSSIA.ACME.COM');
HR_RUSSIA.ACME.COM');
DBMS_REPCAT Additions
SPECIFY_NEW_MASTERS is used to specify the master sites you intend to add to an existing
replication group. This routine is called on the master definitions site and replaces any masters in the
local DBA_REPSITES_NEW view for the given replication group with the list of masters specified.
In the example above, we are indicating that two new masters sites (HR_RUSSIA and
HR_GERMANY) are going to be added to the replication group HR_REP_GRP.
Arguments:
Note: This procedure is overloaded.
• GNAME - name of an existing replication group.
• MASTER_LIST - the set of masters that will be instantiated.
• MASTER_TABLE - the set of masters that will be instantiated. MASTER_TABLE must be 1-
based and dense. A terminating NULL is permitted, but not required.
Notes:
• If master_list is empty, all masters for the given replication group will be removed from the
DBA_REPSITES_NEW view.
• This procedure must be called at the master definition site for the given replication group.

SPECIFY_NEW_MASTERS
After executing the procedure, check the view

DBA_REPSITES_NEW to see the results:
SELECT
SELECT ** FROM
FROM dba_repsites_new;
dba_repsites_new;
EXTENSION_ID
EXTENSION_ID GOWNER
GOWNER
--------------------------------
-------------------------------- -------------------
-------------------
GNAME
GNAME DBLINK
DBLINK
--------------------
-------------------- -------------------------
-------------------------
FF MASTER_STATUS
MASTER_STATUS
-- ---------------
---------------
7E7961B3FE81625DE034080020CAFF6B
7E7961B3FE81625DE034080020CAFF6B PUBLIC
PUBLIC
HR_REP_GRP
HR_REP_GRP HR_GERMANY.ACME.COM
HR_GERMANY.ACME.COM
READY
READY
SEPCIFY_NEW_MASTERS
The output shown above resulted from having run the following command:
SQL> begin
2 dbms_repcat.specify_new_masters (
3 gname => 'HR_REP_GRP',
4 master_list => 'HR_GERMANY.acme.com');
5 end;
6 /
The replication group HR_REP_GRP maintains the READY status, so DML operations are still
allowed on the tables within this replication group.

Instantiating New Master Sites
When using database level instantiation:

• The master definition site:
– Cannot have any materialized view replication
groups.
– Must be the same for all replication groups at
the new master sites.
• The new master sites:
– Cannot have existing replication groups.
– Must include all the replication groups of the
master definition site when the extension
process is complete.
Instantiating New Master Sites

For a new master site to be instantiated using change-based recovery or full database export/import,
the following conditions apply:
• The new master sites cannot have any existing replication groups.
• The master definition site cannot have any materialized view groups.
• The master definition site must be the same for all of the master groups. If one or more of these
master groups has a different master definition site, then do not use change-based recovery or full
database export/import. Use table-level export/import instead.
• The new master site must include all of the replication groups in the master definition site when
the extension process is complete. That is, you cannot add a subset of the master groups at the
master definition site to the new master site; all of the groups must be added.
Note:
To use change-based recovery, the existing master site and the new master site must be running
under the same operating system, although the release of the operating system can differ.

ADD_NEW_MASTERS
DBMS_REPCAT.ADD_NEW_MASTERS
DBMS_REPCAT.ADD_NEW_MASTERS ((
export_required
export_required IN
IN BOOLEAN,
BOOLEAN,
[available_master_list
[available_master_list IN
IN VARCHAR2
VARCHAR2 ||
available_master_table
available_master_table IN
IN DBMS_UTILITY.dblink_array],
DBMS_UTILITY.dblink_array],
masterdef_consistent_at
masterdef_consistent_at OUT
OUT VARCHAR2,
VARCHAR2,
extension_id
extension_id OUT
OUT RAW,
RAW,
break_trans_to_masterdef
break_trans_to_masterdef IN
IN BOOLEAN
BOOLEAN :=
:= FALSE,
FALSE,
break_trans_to_new_masters
break_trans_to_new_masters IN
IN BOOLEAN
BOOLEAN :=
:= FALSE,
FALSE,
percentage_for_catchup_mdef
percentage_for_catchup_mdef IN
IN BINARY_INTEGER
BINARY_INTEGER :=
:= 100,
100,
cycle_seconds_mdef
cycle_seconds_mdef IN
IN BINARY_INTEGER
BINARY_INTEGER :=
:= 60,
60,
percentage_for_catchup_new
percentage_for_catchup_new IN
IN BINARY_INTEGER
BINARY_INTEGER :=
:= 100,
100,
cycle_seconds_new
cycle_seconds_new IN
IN BINARY_INTEGER
BINARY_INTEGER :=
:= 60);
60);
DBMS_REPCAT Additions
The ADD_NEW_MASTERS procedure adds the masters in the DBA_REPSITES_NEW view to the
master groups specified when the SPECIFY_NEW_MASTERSprocedure was run. All masters being
instantiated with table-level export must be accessible at this time. Masters instantiated by full
database export/import or change-based recovery need not be accessible. The return value is the
instantiation SCN that should be used for export or change-based recovery.
After running this procedure, do not disable or enable propagation of the deferred transaction queue
until after the new master sites have been added. The DBA_REPEXTENSIONS view must be empty
before you disable or enable propagation.
When you use either export/import or SCN-based recovery, propagation of deferred transactions to the
new master site is partially (for parallel propagation) or completely (for serial propagation) disabled
while the new master sites are being added. Therefore, make sure each existing master site has
enough free space to store the largest unpropagated deferred transaction queue that you may
encounter.
Arguments
NOTE: This procedure is overloaded.
• EXPORT_REQUIRED: set it to TRUE if and only if export is required.
• AVAILABLE_MASTER_LIST: a comma-separated list of masters to be instantiated using
table-level export/import.
DBMS_REPCAT Additions (continued)
• AVAILABLE_MASTER_TABLE: list of masters to be instantiated using table-level
export/import. Do NOT specify masters which will be instantiated using full database export-
import or change-based recovery. A terminating NULL is permitted, but not required.
• MASTERDEF_CONSISTENT_AT: the instantiation SCN that should be used for export
(CONSISTENT_AT parameter) or change-based recovery (RECOVER DATABASE UNTIL
CHANGE).
• EXTENSION_ID: the identifier for the current pending add master database without quiesce
request.
• BREAK_TRANS_TO_MASTERDEF: [Optional] If TRUE and export_required is TRUE,
existing masters may continue to propagate their deferred RPC queues to the masterdef for
replication groups that are not adding master sites. Default value is FALSE.
• BREAK_TRANS_TO_NEW_MASTERS: [Optional] If TRUE, existing masters may continue to
propagate their deferred RPC queues to the new masters for replication groups that are not
adding master sites. Otherwise, propagation to the new masters will be disabled. Default value is
FALSE.
• PERCENTAGE_FOR_CATCHUP_MDEF: [Optional] Only used if EXPORT_REQUIRED and
BREAK_TRANS_TO_NEW_MASTERSare TRUE. The percentage of propagation resources
that should be used for catching up to masterdef. Must be a multiple of 10 between 0 and 100.
Default value is 100.
• CYCLE_SECONDS_MDEF: [Optional] Indicates the longest time propagation for the extended
replication groups to masterdef will be done before switching to the unaffected replication
group. This parameter is ignored if percentage_for_catchup_mdef is 100. Default value is 60.
• PERCENTAGE_FOR_CATCHUP_NEW: [Optional] Only used if BREAK_TRANS_TO_
NEW_MASTERS is TRUE.The percentage of propagation resources that should be used for
catching up to new masters. Must be a multiple of 10 between 0 and 100. Default value is 100.
• CYCLE_SECONDS_NEW: [Optional] indicates the longest time propagation for the extended
replication groups to new masters will be done before switching to the unaffected replication
group. This parameter is ignored if percentage_for_catchup_new is 100. Default value is 60.
Notes:
• For masters to be instantiated via change-based recovery or full database export/import, they
must include all replication groups in the master definition site.
• For table-level export-import, ensure that all the repcatlog requests in DBA_REPCATLOG view
for the extended groups have been processed without any error before import.
• This procedure must be called at the master definition site.

ADD_NEW_MASTERS Example
VARIABLE masterdef_consistent_at VARCHAR2(15);

VARIABLE extension_id VARCAHR2(32);
BEGIN
DBMS_REPCAT.ADD_NEW_MASTERS (
export_required => FALSE,
available_master_list => 'HR_GERMANY.ACME.COM’,
masterdef_consistent_at => :masterdef_consistent_at,
extension_id => :extension_id,
break_trans_to_new_masters => TRUE,
percentage_for_ catchup_new => 60,
cycle_seconds_new => 300);
END;
/
ADD_NEW_MASTERS Example
In this example, we specify the method to be used to instantiate the HR_GERMANY master site. We
have chosen to perform SCN-based recovery (export_required => FALSE), and to allow existing
masters to continue to propagate their deferred RPC queues to the new masters for replication groups
that are not adding master sites.
The bind variable masterdef_consistent_at, declared in SQL*Plus, allows you to display
the return variable after the procedure has executed by using the following command:
SQL> PRINT masterdef_consistent_at;
You can also view these values by querying the data dictionary views DBA_REPSITES_NEW and
DBA_REPEXTENSIONS:
SQL> SELECT CONSISTENT_AT FROM DBA_REPEXTENSIONS;
CONSISTENT_AT
-------------
3456871

Adding New Master Sites
DBMS_REPCAT.RESUME_PROPAGATION_TO_MDEF
DBMS_REPCAT.RESUME_PROPAGATION_TO_MDEF ((
extension_id
extension_id IN
IN RAW
RAW
);
);
DBMS_REPCAT.RESUME_PROPAGATION_TO_MDEF (
extension_id => '75AFDBD77CD83C4EE034080020CAFF6B');
DBMS_REPCAT Additions: RESUME_PROPAGATION_TO_MDEF

This procedure indicates that export has finished and propagation to the master definition site for both
extended and unaffected replication groups existing at master sites can be enabled.
Arguments:
• EXTENSION_ID: The identification for the current pending request to add master databases to
a master group without quiesce. You can find the value for extension_id by querying the
DBA_REPSITES_NEWand DBA_REPEXTENSIONSdata dictionary views.
SQL> select extension_id, dblink, master_status

2 from dba_repsites_new;
EXTENSION_ID DBLINK
MASTER_STATUS
-------------------------------- ----------
-----------
75AFDBD77CD83C4EE034080020CAFF6B REP3.WORLD READY

Adding New Master Sites
DBMS_REPCAT.PREPARE_INSTANTIATED_MASTER
DBMS_REPCAT.PREPARE_INSTANTIATED_MASTER ((
extension_id
extension_id IN
IN RAW,
RAW,
new_global_name
new_global_name ININ VARCHAR2
VARCHAR2 :=
:= NULL
NULL
);
);
DBMS_REPCAT.PREPARE_INSTANTIATED_MASTER (
extension_id => :ext_id,
new_global_name => 'HR.MYCOM.DE');
DBMS_REPCAT Additions: PREPARE_INSTANTIATED_MASTER

This procedure enables the propagation of deferred transactions from other prepared master sites and
existing master sites to the invocation master site. It also enables propagation of deferred transactions
from the invocation master site to the other prepared new master sites and existing master sites. This
procedure also optionally changes the global_name of the database to the new_global_name.
Replication catalog and deferred transaction queue will be appropriately adjusted.
• Do NOT invoke this procedure until instantiation, export-import or change-based recovery, for the
new master is done.
• Do NOT perform any DMLs directly on the objects in the extended group in the new master until
PREPARE_INSTANTIATED_MASTERreturns successfully. Those DMLs may not be replicated.
• For table-level export-import, ensure that all the repcatlog requests in DBA_REPCATLOG view for
the extended groups have been processed without error before import.
Arguments:
• EXTENSION_ID: [Optional] The identified for the current pending request to add master
databases to a master group without quiesce. You can find the value for extension_id by
querying the DBA_REPSITES_NEW and DBA_REPEXTENSIONS data dictionary views.
• NEW_GLOBAL_NAME: [Optional] The new global_name. Use a valid, non-null value if the
new master is instantiated via full database export-import or change-based recovery, and the new
master has a different name from the one specified in SPECIFY_NEW_MASTERS. Do NOT
specify a value if the new master is instantiated via table-level export/import. Default value is
NULL. Oracle9i Replication New Features AR1- 14
Adding New Masters without Quiescing
ADD_NEW_MASTERS restrictions:
• Synchronous replication is not supported.
• Master definition site cannot be relocated for
any replication group being extended.
• Connection qualifier for all master group
database links must be the same.
• Parallel propagation is fully supported.
Serial propagation is only supported when
queue propagation is completely disabled
• All master sites must be using Oracle9i release
Adding Masters without Quiescing

Restrictions:
• Asynchronous replication, but not synchronous replication, is supported.
• All database links for the affected master group must have the same connection qualifier or not
use any connection qualifier.
• Parallel propagation, but not serial propagation, is supported when queue propagation is not
completely disabled. Both parallel and serial propagation are supported when queue
propagation is completely disabled through procedure arguments.
• Once you begin adding a set of masters to replication groups with the same master definition
site, you must wait until the new masters have been added before you can add another set of
master sites to any of the affected master groups.
• COMPATIBLE for all affected master sites must be at version 9.0 or higher.

When to Add New Masters without
Quiescing
• You want to perform data manipulation language

(DML) operations on replicated tables while the
new master sites are being added
• Each existing master site has enough free space
to store a large unpropagated deferred transaction
queue while the master sites are being added.
• You have a stable connection to the new master
site, or you meet the requirements for using
Export/Import or SCN-based recovery.
• Your system does not meet any of the restrictions
listed on the previous slide.
When to Add New Master Sites without Quiescing

As your replication environment expands, you may need to add new master sites to a master group.
You can either add new master sites to a master group that is running normally or to a master group
that is quiesced. If the master group is not quiesced, then users can perform data manipulation
language (DML) operations on the data while the new master sites are being added. However, more
administrative actions are required when adding new master sites if the master group is not quiesced.
When you add new master sites without quiescing the replication group, propagation of deferred
transactions to the new master site is partially or completely disabled while the new master sites are
being added. Therefore, make sure each existing master site has enough free space to store the largest
unpropagated deferred transaction queue that you may encounter.
When using full database export/import and change-based recovery to add all of the replication groups
at the master definition site to the new master sites, the following conditions apply:
• The new master sites cannot have any existing replication groups.
• The master definition site cannot have any materialized view groups.
• The master definition site must be the same for all of the master groups. If one or more of these
master groups have a different master definition site, then do not use change-based recovery or
full database export/import. Use table-level export/import instead.
• The new master site must include all of the replication groups in the master definition site when
the extension process is complete. That is, you cannot add a subset of the master groups at the
master definition site to the new master site; all of the groups must be added.
Removing Added New Masters
• If there is a need to stop the process of adding new

master sites to a repgroup, the procedure
UNDO_ADD_NEW_MASTERS_REQUEST can be used:
– SPECIFY_NEW_MASTERS and ADD_NEW_MASTERS
have been executed
– RESUME_PROPAGATION_TO_MDEF or
PREPARE_INSTANTIATED_MASTER have not yet
been executed
– Procedure called at all master sites involved
DBMS_REPCAT.UNDO_ADD_NEW_MASTERS_REQUEST
DBMS_REPCAT.UNDO_ADD_NEW_MASTERS_REQUEST ((
extension_id
extension_id IN
IN RAW,
RAW,
drop_contents
drop_contents IN
IN BOOLEAN
BOOLEAN :=
:= TRUE
TRUE );
);
Removing Added New Masters

The UNDO_ADD_NEW_MASTERS_REQUESTprocedure undoes all of the changes made by the
SPECIFY_NEW_MASTERSand ADD_NEW_MASTERS procedures for a specified extension_id.
It is executed at one master site, and it only affects that master site. If you run this procedure at one
master site affected by the request, you must run it at all new and existing master sites affected by the
request. You can query the DBA_REPSITES_NEW data dictionary view to see the new master sites
affected by the extension_id. This data dictionary view also lists the replication group name, and you
must run this procedure at all existing master sites in the replication group.
Note:
Do NOT run this procedure after you have run either RESUME_PROPAGATION_TO_MDEFor
PREPARE_INSTANTIATED_MASTERfor a particular extension_id.
Parameters:
• EXTENSION_ID: The identifier for the current pending request to add master databases to a
master group without quiesce. You can find the extension_id by querying the
DBA_REPSITES_NEWand DBA_REPEXTENSIONSdata dictionary views.
• DROP_CONTENTS: [Optional] Specify TRUE, the default, to drop the contents of objects in
new replication groups being extended at the local site. Specify FALSE to retain the contents.

Parallel Propagation and Row-Level SCN
• When using parallel propagation Oracle orders the

execution of dependent transactions to preserve
data integrity.
• The ordering of transactions uses the SCN found
in the data block header.
• If the Row-level SCN feature is used, each row has
its own SCN, providing better granularity when
ordering the changes made to a data block.
• Using row-level SCN can help provide better
ordering of transactions for parallel propagation.
Parallel Propagation and Row-Level SCN

When Oracle commits a transaction, each block that the transaction changed is not immediately
marked with the commit SCN. This is done later, upon demand— when the block is next read or
updated. This is called block cleanout. By default, only one cleanout SCN is stored for a data block.
Using the Row level SCN feature, each row will have an SCN that represents a time greater than or
equal to the commit time of the last transaction that modified the row. It is not the exact commit time,
but rather the cleanout time of the transaction that last modified the row.
The dependent SCN computation for parallel propagation that currently exists leads to less than an
optimal ordering of changes made to rows because the computation relies upon the cleanout SCN
stored at the block level. Storing an SCN with each row will enable the parallel propagation feature of
Advanced Replication to produce a better ordering of the changes when applying the replication
queue.
By introducing a row level SCN that is updated during block cleanout, you can maintain for each row
that last commit time of the changes made to that row. Therefore, two rows changed by different
transactions on the same block can and might have different row level SCNs (depending of course on
the commit times of those transactions), whereas the dependent SCN for parallel propagation would
have been computed solely based on the block state. Using the fine-grained row-level SCNs to
calculate dependent SCNs can enable better dependency tracking between transactions in the
replication queue.
NOTE: Internal testing has not shown much in the way of performance improvements when using
this feature. At this time, whether using Row-Level SCNs is actually beneficial is unknown.
This feature is implemented
Oracle9iinReplication
Oracle9i beta,
Newbut it is not AR1-
Features a feature
18 scheduled for beta testing.
Features of Row Level SCNs
• A table can be created so that the commit SCN is

stored in the head piece of each table row.
CREATE TABLE master_rep … ROWDEPENDENCIES;
• Each row has an SCN that:

– Is greater than or equal to the commit time of the
last transaction that modified the row.
– Represents the cleanout time of the last
transaction for each row.
– Takes up 6 bytes of additional storage per row.
• The row level SCN is updated during delayed block
cleanout.
Features of Row Level SCNs

The CREATE TABLE SQL statement syntax has been modified to include a clause that controls
whether the table uses this feature or not. The row level dependency feature applies only to tables that
are created with this special clause. Options are:
• CREATE TABLE … ROWDEPENDENCIES
• CREATE TABLE … NOROWDEPENDENCIES(default)
• CREATE CLUSTER … [ ROWDEPENDENCIES | NOROWDEPENDENCIES ]
Note:
• Not available for ALTER TABLE

Row Level SCN Implementation
Row Lock # of Cluster Row Column

Column
flag byte cols key idx SCN length
data
(1) (1) (1) (1) (6) (1 or 3)
block_row_dump:
block_row_dump:
tab
tab 0,
0, row
row 0,
0, @0x1f5c
@0x1f5c
tl:
tl: 44
44 fb:
fb: --H-FL--
--H-FL-- lb:
lb: 0x0
0x0 cc:
cc: 88
dscn
dscn 0x0000.00014866
0x0000.00014866
col
col 0:0: [[ 3]
3] c2
c2 4a
4a 46
46
col
col 1:1: [[ 5]
5] 53
53 4d
4d 49
49 54
54 48
48
col
col 2:2: [[ 5]
5] 43
43 4c
4c 45
45 52
52 4b
4b
Row Level SCN Implementation

The first picture above shows a graphical representation of the elements in a row header stored in a
data block and their sizes in bytes. The cluster key index and Row SCN are optional. The partial
block dump shows a table row which holds a row dependent SCN (RDSCN) in its head piece. The
RDSCN is updated from the commit time in the ITL:
• when the transaction commits if ITL cleanout is performed at that time
• when the ITL cleanout occurs during a subsequent block cleanout
While a transaction is active, the head piece of the row holds the RDSCN of the previous transaction,
or a zero if the row is being newly inserted.
Below is a partial block dump showing a row in the HR.DEPARTMENTS table, which was created
without Row-level SCNs. Notice the DSCN entry is missing.
tab 0, row 3, @0x1ecf
tl: 50 fb: --H-FL-- lb: 0x1 cc: 5
col 0: [ 2] c1 29
col 1: [15] 48 75 6d 61 6e 20 52 65 73 6f 75 72 63 65 73
col 2: [ 3] c2 03 04
col 3: [ 2] c2 19
col 4: [20] 22 6f 75 3d 48 52 2c 20 6f 3d 49 4d 43 2c 20 63 3d 5553 22
To learn more about interpreting data block dumps, see WebIV Note 28983.1 "QREF: Blockdump -
Data Block **INTERNAL ONLY**".
Constraint SCNs
• When constraints are created on a table, this can

create additional dependencies for the table
transactions.
• Constraint SCNs represent the highest commit
SCN of all transactions that a particular row
depends on:
– Index entries for unique constraints
– Referential constraints
• Using constraint SCNs helps to reduce false
dependencies which can occur when using the
Dependent SCN calculation method of Oracle8i.
Constraint SCNs
A constraint SCN is the SCN that is larger than the commit times of all the transactions that a
particular row operation depends on due to constraints. Constraints may be one of uniqueness or
referential integrity. For example, if there is a unique index on a table, a successful row insertion is
dependent on all the previously committed transactions that deleted the given unique key. The
constraint SCN captures this dependency.
Referential integrity (foreign key) constraint dependencies are of two kinds:
• Existence dependency on the parent: Inserting a row into a child table depends on the existence
of the foreign key in the parent table.
• Non-existence dependency on the child table: Deleting a row from a parent table depends on
the absence of rows with the foreign key in the child table.
The constraint SCN captures both of these forms of foreign key dependencies.
In Oracle8i, a dependency SCN was computed using the last committed transaction in a block.
Dependent SCN (DSCN) can result in the tracking of false dependencies. For example, the insertion
of a single key into an index block is made to depend on all other transactions that commit in the same
block. This includes the insertion of other keys. For rightmost or leftmost growing indexes, this can
lead to the tracking of false dependencies.

Constraint SCN Implementation
• Index leaf blocks contain a Last Delete SCN

(LDSCN)
• The LDSCN takes up 6 bytes per leaf block for
each index defined on a table with
ROWDEPENDENCIES enabled.
Leaf
Leaf block
block dump
dump
header
header address
address 37764156=0x2403c3c
37764156=0x2403c3c
kdxcolev
kdxcolev 00
KDXCOLEV
KDXCOLEV Flags
Flags == RR -- --
……
kdxledsz
kdxledsz 66
ldscn:
ldscn: scn:
scn: 0x0000.0002317e
0x0000.0002317e
kdxlebksz
kdxlebksz 8032
8032
Constraint SCN Implementation

The Last Delete SCN is associated with key ranges in the index. Every leaf block in the index contains an
LDSCN. The LDSCN monotonically increases during the life of the index. When the index is created, the
LDSCN of the initial leaf block(s) is set to the SCN of the creation of the index. When a key is deleted in an
index leaf block, the LDSCN of the leaf block is increased to the commit SCN of that transaction. The Oracle
database uses delayed block cleanout to delete keys from the index. When inserting into an index, when the
appropriate leaf block is found in which to place the new key, the LDSCN in this leaf block becomes the
dependent SCN for this insert in the transaction.
Note: The LDSCN does not accumulate the SCNs of the transactions that insert into an index block, as shown
below. This should improve dependency tracking, especially for rightmost and leftmost growing indexes.
buffer tsn: 2 rdba: 0x00c009a4 (3/2468)
scn: 0x0000.00023206 seq: 0x01 flg: 0x02 tail: 0x32060601
frmt: 0x02 chkval: 0x0000 type: 0x06=trans data
Block header dump: 0x00c009a4

seg/obj: 0x1988 csc: 0x00.23204 itc: 2 flg: - typ: 2 - INDEX
Itl Xid Uba Flag Lck Scn/Fsc

0x01 xid: 0x0000.000.00000000 uba: 0x00000000.0000.00 ---- 0 fsc 0x0000.00000000
0x02 xid: 0x0003.061.00000037 uba: 0x00801c5d.004b.3a --U- 1 fsc 0x0000.00023206
Leaf block dump

----------------
ldscn: scn: 0x0000.0002317e
After a delete and insert into this leaf block, the LDSCN (0x0000.002317e) remains lower than the cleanout
SCN (0x0000.00023206).
To learn more about interpreting index leaf block dumps, see WebIV Note 33190.1 "QREF: Blockdump - Index
Block **INTERNAL ONLY**".
New MV Fast Refresh Abilities
Fast refresh ability extended to:

• Allow MVs with aggregates to have remote
masters
• Support many-to-many relationships by not
requiring the unique key constraint on the
inner table join for subqueries
• Support subqueries which contain unions
– Updatable MVs restrict the UNION to an
identical set of columns and the same table
New MV Fast Refresh Abilities

MAVs (Materialized View Aggregate) are used in data warehousing and were not previously
considered part of replication, since they could only be created local to the master table. The ability
for MAVs to have remote masters is implemented by internal changes to the fast refresh algorithms.
Subqueries can now be fast refreshable if the relation between the outer table and inner table is many-
many. In addition, the query can use the keywords OR or UNION, with limitations:
• Fast refreshable Primary Key (PK) MVs can be updatable. Since the changes are propagated
based on row changes identified by the PK, it is necessary that a given row can only be derived
from one table. Otherwise it won’t be clear which base table a local update should be applied
to. Thus, the UNIONs must be over an identical list of columns in the SELECT clause based on
the same table.

Materialized View Log Change
• Fast refresh support of extended subqueries

requires the MV logs to store the join column.
• The join column does not have to be recorded
for many-to-one subqueries.
CREATE MATERIALIZED VIEW LOG

ON oe.customers (account_mgr_id);
SELECT * FROM oe.orders@hq.acme.com o

WHERE EXISTS
(SELECT * FROM oe.customers@hq.acme.com c
WHERE o.customer_id = c.customer_id
AND c.account_mgr_id = 30);
Materialized View Log Change

A unique key constraint on the inner join column, a previous restriction, is no longer required.
The query above selects all orders that are associated with the account manager whose ID number is
30. In this example, it is not possible to create a unique index on the ACCOUNT_MGR_ID column of
the table OE.CUSTOMERS because a customer may deal with more than one account manager.
The ACCOUNT_MGR_ID column must be stored in the materialized view log in order to support fast
refresh since the subquery is a many-to-many subquery.

Extended Subquery Fast Refresh
The following query is now fast refreshable:
CREATE MATERIALIZED VIEW oe.orders REFRESH FAST AS

SELECT * FROM oe.orders@dbs1.acme.com o
WHERE EXISTS
(SELECT * FROM oe.customers@dbs1.acme.com c
AND c.credit_limit > 50)
UNION
SELECT *
FROM oe.orders@dbs1.acme.com o
WHERE EXISTS
(SELECT * FROM oe.customers@dbs1.acme.com c
AND c.account_mgr_id = 30);
Extended Subquery Fast Refresh

The above statement creates the OE.ORDERS materialized view. This materialized view is fast
refreshable because the subquery in each union block satisfies the restrictions for subqueries. The
query selects all orders that are associated with the account manager whose ID number is 30, as well
as all orders for customers who have a credit limit greater than 50.

Explain Materialized View
• Sometimes it can be difficult to determine why

a materialized view cannot fast refresh.
• EXPLAIN MATERIALIZED VIEW allows a user to
specify either an existing materialized view or
the query for a proposed materialized view.
• EXPLAIN MATERIALIZED VIEW then reports:
– The capabilities of the MV
– Whether or not each capability is possible
– Why a capability is not possible

There are several restrictions which govern when a materialized view can support fast refresh.
Determining why a particular query fails to meet the requirements can be difficult. Error and Catalog
views only list whether fast refresh is possible or not for a materialized view, not the reason why.
With the new EXPLAIN MATERIALIZED VIEW interface, it is now possible to determine why a
materialized view or query is not fast refreshable.

• Available through the PL/SQL interface

DBMS_MVIEW.EXPLAIN_MVIEW()
• Output placed in the MV_CAPABILITIES_TABLE
– Created by the utlxmv.sql script
– There is one row in the table for each reason a
refresh capability is not possible
Explain Materialized View: MV_CAPABILITIES_TABLE

The possible capabilities listed for a materialized view are:
•REFRESH : If this capability is enabled, at least complete refresh is possible. If this capability is
disabled, no form of refresh is possible.
•REFRESH_FROM_LOG_AFTER_INSERT: If this capability is enabled, fast refresh from a
materialized view log or change capture table is possible at least in the case where the updates are
restricted to INSERT operations; complete refresh is also possible. If this capability is disabled, no
form of fast refresh from a materialized view log or change capture table is possible.
•REFRESH_FROM_LOG_AFTER_ANY: If this capability is enabled, fast refresh from a materialized
view log or change capture table is possible regardless of the type of update operation; complete
refresh is also possible. If this capability is disabled, fast refresh from a materialized view log or
change capture table is not possible at least when the update operations include DELETE or UPDATE.
•REWRITE : If this capability is enabled, at least full text match query rewrite is possible. If this
capability is disabled, no form of query rewrite is possible.
•REWRITE_PARTIAL_TEXT_MATCH : If this capability is enabled, at least full and partial text
match query rewrite are possible. If this capability is disabled, at least partial text match query
rewrite and general query rewrite are not possible.
•REWRITE_GENERAL : If this capability is enabled, all query rewrite capabilities are possible,
including general query rewrite and full and partial text match query rewrite. If this capability is
disabled, at least general query rewrite is not possible.
•PCT : Can do Enhanced
Oracle9i Update Tracking
Replication on AR1-
New Features the 27
table named in the
RELATED_NAME column. EUT is needed for fast refresh after
partitioned maintenance operations on the table named in the
RELATED_NAME column and to do non-stale tolerated rewrite when the
PROCEDURE
PROCEDURE explain_
explain_mview
mview ((
mv
mv IN
IN VARCHAR2,
VARCHAR2,
stmt_id
stmt_id IN
IN VARCHAR2
VARCHAR2 :=
:= NULL
NULL );
);
PROCEDURE
PROCEDURE explain_
explain_mview
mview ((
mv
mv IN
IN VARCHAR2,
VARCHAR2,
msg_array
msg_array IN
IN OUT
OUT ExplainMVArrayType
ExplainMVArrayType);
);

The explain materialized view feature is implemented by tapping into the DDL processing of the
CREATE MATERIALIZED VIEWstatement. The new EXPLAIN MATERIALIZED VIEW
statement operates as a DDL command with DDL auto-commit suppressed. Processing of EXPLAIN
MATERIALIZED VIEW bypasses the acquisition of exclusive locks normally obtained by
materialized view DDL processing.

CREATE MATERIALIZED VIEW oe.orders_ mv

REFRESH FAST
WITH PRIMARY KEY
FOR UPDATE AS
SELECT * FROM oe.orders@ORC1.acme.com
WHERE customer_id BETWEEN 120 AND 140;
EXECUTE DBMS_MVIEW.EXPLAIN_MVIEW ('OE.ORDERS_MV');

The first example creates a materialized view. The second example shows how EXPLAIN_MVIEW
can be used to determine if the materialized view query can be fast refreshed or not. Running the
EXPLAIN_MV procedure will populate the MV_CAPABILITIES_TABLE table.

Explain Materialized View Results
Results from EXPLAIN_MVIEW for OE.DEPT_INFO

SELECT capability_name, possible, msgno, msgtxt
FROM mv_capabilities_table;
Capability MsgNo MsgTxt
Possible
REFRESH_COMPLETE Y
REFRESH_FAST N
REWRITE N
no joins or aggregation in
REFRESH_FAST_AFTER_INSERT N 2154 materialized view
see the reason why
REFRESH_FAST_AFTER
REFRESH_FAST_AFTER_ONETAB_DML N 2146 _INSERT is disabled
see the reason why
REFRESH_FAST_AFTER
_ONETAB_DML is
REFRESH_FAST_AFTER_ANY_DML N 2161 disabled
Explain Materialized View Results

This feature was developed primarily for Summary Management Materialized Views, but can also be
used to check if a proposed Replication-related Materialized View will be fast refreshable or not.

Multi-Tier Materialized Views (MVs)
• Multi-Tier MVs allow updatable MVs to be

declared on updatable MVs.
• Multi-Tier MVs provide a solution for:
– Applications which need data subsetting at
multiple levels with no permanently available
connection between the levels
– Replicating multi-level business data
HQ, Subsidiaries, and Local offices
– Low bandwidth networks by replicating less data
– Mass deployment customization requirements
• If dependent MV's do not need to update master
table, use Nested MV's instead.
Multi-Tier Materialized Views

Cascading MVs enable usage of lower bandwidth networks by not needing to refresh from the master
site each time.
Hierarchical updateable MVs will be useful in scenarios where some replication customers do not
want a complete instantiation of a table at every site because they do not need to see all the data and
may not have the storage capacity. Also, because of the limitation of the network bandwidth, having
every site propagate transaction to every other site is not desirable. Most of the times, companies are
structured at least three levels: international, national and local offices. Many nodes at both the
national and local office level are required. The best possible solution in such cases is to setup a
master site at the Headquarters and updateable MV at national subsidiaries and another updateable
MV at local office which is based off the MV at the national level office.
In Oracle 8.1.6, the Nested Materialized Views feature allows you to create Read-Only materialized
views on materialized views. Since there is no support for conflict resolution in the nested MVs, no
data changes are allowed.

Master Table Master Table
Master Updatable MV Master Updatable MV
Level 2 updatable MV Level 2 updatable MV Level 2 updatable MV
Level n updatable MV Level n updatable MV

A Master MV is a materialized view with dependent, updatable materialized views defined upon it. In
this graphic, the Level 1 MV's are labeled Master Updatable MV's.
A materialized view at any level can be a master materialized view and can have more than one
materialized view based on it.

Multi-Tier Materialized Views (MVs)
• Level 1 updatable MV (Master MV) behaves like

a master for the level 2 MV.
– Must have RECEIVER user and
PROPAGATOR database links
– Level 1 MV pulls down conflict resolution
information from master table when
needed.
• Conflict resolution can only defined on the
master table.
• Structure or conflict resolution changes at the
master table require MV sites at all levels to
regenerate replication support.

With multi-tier MVs, the level 1 updatable MV acts like a master for the level 2 updatable MV. Any
changes done at the level 2 MV site will be pushed to the level 1 MV. This can potentially cause
conflicts at the level 1 updatable MV site. To handle this conflict, level 1 (parent) updatable MV site
now needs to have information to detect conflicts, and, if possible, use the system defined conflict
resolution methods or user defined conflict resolution routines to resolve the conflicts.
This requires that, in addition to other object-level information, the level 1 MV must also pull down
the conflict resolution information from the master. This conflict resolution information must be
provided to updatable MV sites that support another updatable MV.
The conflict resolution routines cannot be defined at the MV sites. They are defined only at the
topmost level, the master site, and pulled into the updatable MV site when needed. If at the topmost
level, the conflict resolution information is altered for a master table, then the materialized view
replicated objects must regenerate replication support at all levels. It is up to the DBA to notify the
MV sites at all levels that are participating in the replicated environment.
Since the level 1 updatable MV, or Master MV, acts like a master for the level 2 updatable MV, a
receiver user must be created at the level 1 updatable MV site. Similarly, a database link must be
created between the propagator at the level 2 site to the Receiver at the Level 1 site.

• A level 2 updatable MV and its materialized view

repgroup must be registered at the level 1 MV site.
• Dropping a level 2 MV unregisters it from the
Master Materialized View site.
• Dropping a master updatable MV or master
replication group does not enforce the dropping
of the level 2 MVs and MV replication groups.

When creating multi-tier Materialized Views, the conflict resolution routines need to be regenerated at
each level, in the order they were created.
The level 2 updatable MV and the materialized view replication group that it belongs to must be
registered at the level 1 udpatable MV site. The level 2 MV and materialized view groups are not
registered at the master site.
Dropping an level 1 updatable MV unregisters it from its master site. Similarly, dropping a level 2
updatable MV unregisters it from the level 1 updatable MV site. And dropping a level 2 materialized
view replication group unregisters the replication group from the level 1 updatable MV site.
Synchronous and asynchronous replication are supported at all levels.

Refreshing Multi-Tier Materialized Views
• Complete refresh of a master MV forces a complete

refresh of the level 2 MV.
• For fast refresh:
– Both MV log and updatable MV log are created
for the MV at the master MV site.
– DML changes are logged in both logs when the
materialized view is updated.
• DML changes made at level 2 updatable MV site
may be pulled back to the same MV site multiple
times, as illustrated in the following slides.
Refreshing Multi-Tier Materialized Views

If a lower level MV tries to perform a fast refresh after the Master MV has performed a complete
refresh, you may end up with the error:
ORA-12034 “Materialized view log is younger than last refresh”
A master materialized view may have both a materialized view log (MLOG$) and an updatable
materialized view log (USLOG$). When changes are made to the master table or master materialized
view using DML, an internal trigger records information about the affected rows in the materialized
view log. If the master materialized view was updated, then the DML is also recorded in the
updateable materialized view log. The updatable materialized view log is used to determine which
rows must be overwritten or removed from the dependent materialized view during a fast refresh.

Refreshing Multi-Tier MVs with
Conflict Resolution
M
M Table
Table MLOG$_M
0 AA 2
15 Update:
Update: AA :=
:= 38
38
15 38
38
USLOG$_MV1
MV1
MV1 MView
MView
AA MLOG$_MV1
1
deftran 15
15
1 1 USLOG$_MV2
MV2
MV2 MView
MView
2 U:
U: A:=10
A:=10
AA Trigger Update:
Update: AA :=
:= 10
10
15
15 10
10
deftran Update: A := 10
Refreshing Multi-Tier Materialized Views: Conflict Resolution

Consider a level 1 updatable MV named MV1 at Site 1 defined on a master table M at Site 0. The level
2 updatable MV named MV2 at Site 2 is defined on MV1 at Site 1.
1. The column A of MV2 is updated to 10 at Site 2. An entry is made in the deferred transaction
queue and the USLOG$_MV2 log at Site 2.
2. Meanwhile, the master site has received an update, changing the value for A from 15 to 38.

Level
Conflict Resolution
M
M Table
Table MLOG$_M
0 AA
38 Update:
Update: AA :=
:= 38
38
38
USLOG$_MV1
2 MV1
MV1 MView
MView
2 Update:
U:
U: A:=10
A:=10 Update: AA :=
:= 10
10
AA MLOG$_MV1
1
deftran 15
15 10
10 Update:
Update: AA :=
:= 10
10
2
Conflict Res.
1 3
First refresh USLOG$_MV2
MV2
MV2 MView
MView 3
2 U:
U: A:=10
A:=10
AA Update:
Update: AA :=
:= 10
10
10
10
deftran
Refreshing Multi-Tier Materialized Views: Conflict Resolution (continued)

1. A fast refresh of MV2 pushes the updated row to Site 1 where it encounters conflict detection
and a Site Priority conflict resolution routine pulled down from the master table. However,
there has been no previous update to the Master MV MV1, so no conflict detection and no
conflict resolution.
2. The column A of MV1 is updated, and an entry is created in the deferred transaction queue at
Site 1. Also, an entry is made in MLOG$_MV1 and USLOG$_MV1.
3. The changed value is pulled back to MV2 during the refresh. The USLOG$_MV2 and
MLOG$_MV1 are purged after the refresh (indicated by a dashed line through the row entry).

Conflict Resolution
M
M Table
Table MLOG$_M
0 AA
38 Update:
Update: AA :=
:= 38
38
38 1
Push U:A:=10 1
Conflict Res. 1
USLOG$_MV1
U:
U: A:=10
A:=10
MV1
MV1 MView
MView 1 Update:
Update: AA :=
:= 10
10
AA MLOG$_MV1
1
deftran 10
10 38
38 Update:
Update: AA :=
:= 38
38
2
MV2
MV2 MView
MView USLOG$_MV2
2 AA
10
10
deftran
Refreshing Multi-Tier Materialized Views: Conflict Resolution (continued)

1. A fast refresh of MV1 pushes the updated row to the Master table where a conflict is detected.
The Site Priority conflict resolution method is used to resolve the discrepancy. Since the master
site received its update from a site with a higher priority, the change from the materialized view
is overruled. When the contents of MLOG$_M are applied to MV1, the row gets updated on
MV1 to contain the resolved value for this row.
2. When MV1 is updated, the change is also logged in the MV log of MV1, MLOG$_MV1. The
next fast refresh of MV2 will see this change in the MV log of MV1 and pull back the updated
row to MV2.

Conflict Resolution
M
M Table
Table MLOG$_M
0 AA
38
38
USLOG$_MV1
MV1
MV1 MView
MView
AA MLOG$_MV1
1
deftran 38
38 Update:
Update: AA :=
:= 38
38
Second refresh
MV2
MV2 MView
MView USLOG$_MV2
2 AA
10
10 38
38
deftran
Refreshing Multi-Tier Materialized Views (continued)

The next fast refresh of MV2 will see the change in the MV log of MV1 (MLOG$_MV1) and pull back
the updated row to MV2.

Creating Multi-Tier Materialized Views
CREATE MATERIALIZED VIEW regional_orders

REFRESH FAST FOR UPDATE
AS SELECT * FROM oe.orders@hq.acme.com
WHERE EXISTS
(SELECT customer_id FROM oe.customers@hq.acme.com c
WHERE c.cust_address.postal_code = '19555');
CREATE MATERIALIZED VIEW my_orders

REFRESH FAST FOR UPDATE
AS SELECT * FROM oe.regional_orders@reg1.acme.com
WHERE sales_rep_id = 205;
Creating Multi-Tier Materialized Views

In this example, we show the SQL used to create a Level 1 and a Level 2 materialized view.
The first materialized view (Level 1) is based on the oe.orders master table at headquarters. It creates
a materialized view at the regional office reg1.us containing only orders whose postal code is 19555.
The materialized views at the regional office are in the hq_group materialized view group. The second
statement creates a Level 2 materialized view based on the materialized view at the regional office
containing only orders for ZIP code 19555. Additionally, this materialized view restricts the data to
show only those orders assigned to a specific sales person.

Job Queue Changes
• Parameter JOB_QUEUE_INTERVAL is now

obsolete.
• The SNP process is obsolete.
• JOB_QUEUE_PROCESSES now determines
the maximum number of slave processes
(J000, J001, … ) that can be started.
– Support for thousands of child processes
– Less overhead
• The number of job queue processes used by
the database can be altered dynamically.
ALTER SYSTEM SET JOB_QUEUE_PROCESSES = 12;
Job Queue Changes

Job queue processes process requests created by DBMS_JOB. Replication automatically creates jobs
to handle tasks such as asynchronous data propagation at scheduled intervals and purging the deferred
transaction queue.
The SNP process has been retired and in its place comes a single-parent family of processes that work
similar to the parallel query family of processes. The head of the family is called CJQ0, which stands
for Coordinator, Job Queue. The child processes, or slave processes, are numbered J000 and up and
are started automatically when needed. The parameter JOB_QUEUE_PROCESSES sets a limit on the
number of slaves which can be started. The CJQ0 process is always active, scanning the job queue for
available work, so the JOB_QUEUE_INTERVAL process is no longer needed. The CQJ0 process is
started only if JOB_QUEUE_PROCESSES is greater than 0.
When a Jnnn process finishes execution of a job, it polls for another job to execute. If there are no jobs
selected for execution, it enters an idle state, but wakes up periodically to poll again. If, after a
predetermined number of tries, it still finds no jobs to execute, it terminates.
For more information, refer to the Oracle9i Administrator's Guide and the DBMS_JOB package
description in the Oracle9i Replication API Reference guide.

Replication Installation Changes
• Advanced Replication installation is now the

default.
Catrep.sql is now called from catproc.sql
• Database creation time will take approximately
30 more minutes since catrep.sql is being
loaded.
• The default datafile size is bumped up to 200M
for non-Java and 300M for Java databases.
• Replication upgrade/downgrade has been
cleaned up so that the process becomes the
same as non-replication upgrade/downgrade.
Replication Installation Changes

The Advanced Replication feature is now installed automatically during database creation through a
callout in catproc.sql. This will increase the time it takes for catproc.sql to complete, and also will
require all databases to have a larger SYSTEM tablespace than previous releases.

New Dynamic Views for Replication
• V$REPLQUEUE
Instance-wide statistics for deferred transaction
queue
• V$REPLPROP
– Session-level view of parallel propagation status
– Rebuilt for each session or query

VIEW V$REPLQUEUE (
TXNS_ENQUEUED NUMBER,
CALLS_ENQUEUED NUMBER,
TXNS_PURGED NUMBER,
LAST_ENQUEUE_TIME DATE,
LAST_PURGE_TIME DATE );
Usage:
Contains information on the replication transactions queued or purged since instance
startup.
Questions answered by this view:
• What is the average number of calls (row changes) in my replication transaction
since instance startup?
SELECT calls_enqueued/txns_enqueued FROM V$REPLQUEUE;
• What is the incoming rate of replicated transactions in my database since

instance startup?
SELECT txns_enqueued/((sysdate - startup_time)*24*60*60) TPS
FROM V$REPLQUEUE, V$INSTANCE;
VIEW V$REPLPROP (
SID NUMBER,
SERIAL# NUMBER,
NAME VARCHAR2(71),
DBLINK VARCHAR2(129),
STATE VARCHAR2(12),
XID VARCHAR2(22),
SEQUENCE
Oracle9i Replication New Features AR1-
NUMBER );
43
Usage:
Gives the state of the coordinator and slave for currently ongoing parallel propagation
V$MVREFRESH
• Visible only on the materialized view site
• Lists information on local materialized views
DESCRIBE
DESCRIBE VIEW
VIEW V$MVREFRESH;
V$MVREFRESH;
Name
Name Null?
Null? Type
Type
--------------------
-------------------- --------
-------- --------------------
--------------------
SID
SID NUMBER
NUMBER
SERIAL#
SERIAL# NUMBER
NUMBER
CURRMVOWNER
CURRMVOWNER VARCHAR2(31)
VARCHAR2(31)
CURRMVNAME
CURRMVNAME VARCHAR2(31)
VARCHAR2(31)

VIEW V$MVREFRESH (
SID NUMBER,
SERIAL# NUMBER,
CURRMVOWNER VARCHAR2(31),
CURRMVNAME VARCHAR2(31) );
Usage:
Contains information on the materialized view currently being refreshed. Does not contain
information for updatable materialized views in the ‘push’phase (check V$REPLPROP instead).
Use this view to answer questions such as:
• What materialized view in the database is currently being refreshed?
SELECT * FROM V$MVREFRESH;

• DEFSCHEDULE contains statistics for

scheduled database links
– Total transaction count
– Average throughput
– Average latency
• Also contains information about propagation to
different destinations
– Total bytes sent
– Total round trips
– Total error count
– Total sleep time

VIEW DEFSCHEDULE (
DBLINK VARCHAR2(128),
JOB NUMBER,
INTERVAL VARCHAR2(200),
NEXT_DATE DATE,
LAST_DATE DATE,
DISABLED CHAR(1),
LAST_TXN_COUNT NUMBER,
LAST_ERROR_MESSAGE VARCHAR2(2000),
CATCHUP RAW(16),
TOTAL_TXN_COUNT NUMBER,
AVG_THROUGHPUT NUMBER,
AVG_LATENCY NUMBER,
TOTAL_BYTES_SENT NUMBER,
TOTAL_ROUND_TRIPS NUMBER,
TOTAL_ADMIN_COUNT NUMBER,
TOTAL_ERROR_COUNT NUMBER,
TOTAL_SLEEP_TIME NUMBER );
Usage:
Contains information and propagation statistics for different database link destinations.
Notes:
• Latency is defined as the time since the transaction’s first call is locally enqueued to the
time the transaction’s remote commit is confirmed (or the time until the error
transaction’s remote commit is confirmed for a transaction with unresolved conflicts).
• Unlike the dynamicOracle9i Replication
performance views,New
thisFeatures AR1-
view is not 45
instantaneously updated, but is
updated at regular intervals.
DEFSCHEDULE can be used to answer questions such as:
DBMS_DEFER_SYS.CLEAR_PROP_STATISTICS
• DEFSCHEDULE view is not instantaneously

updated, but is updated at regular intervals.
• Use CLEAR_PROP_STATISTICS to clear the
statistics for a destination in the DEFSCHEDULE
view in between update periods.
DBMS_DEFER_SYS.CLEAR_PROP_STATISTICS ((
DBLINK
DBLINK IN
IN VARCHAR2
VARCHAR2 );
);
EXECUTE DBMS_DEFER_SYS.CLEAR_PROP_STATISTICS ( -
'REG1.ACME.COM');
This procedure clears all the statistics (all columns after CATCHUP) from DEFSCHEDULE
for a specified database link.
Arguments:
• DBLINK - The destination whose statistics in DEFSCHEDULE are to be cleared.

Changes to Existing Dictionary Views
• SNAPSHOT is being replaced with MVIEW in all

data dictionary views:
– DBA_MVIEW_REFRESH_TIMES
– DBA_REGISTERED_MVIEWS
– DBA_MVIEW_LOG_FILTER_COLUMNS
– DBA_MVIEW_LOGS
• DBA_SNAPSHOT_LOGS has been split into
two views:
– DBA_MVIEW_LOGS based on mlog$
– DBA_BASE_TABLE_MVIEWS based on
slog$
Changes to Existing Dictionary Views

In order to support the change from Snapshots to Materialized Views, the data dictionary views are
being changed in Oracle9i to remove references to snapshots. The old views are being retained for
backwards compatibility, and the new MVIEW views will be supported and enhanced in the future.
Even though the slide only shows DBA_* views, the same applies to USER_* and ALL_* views as
well.
MLOG$ contains a list of local master tables used by materialized
views, while SLOG$ contains a list of materialized views on loca l
masters.

Changes to DDL statements
• The TRUNCATE command is being modified to

remove references to snapshots:
– TRUNCATE TABLE … PRESERVE
MATERIALIZED VIEW LOG
– TRUNCATE TABLE … PURGE
MATERIALIZED VIEW LOG
• The old syntax is being retained for backwards
compatibility:
– TRUNCATE TABLE … PRESERVE
SNAPSHOT LOG
– TRUNCATE TABLE … PURGE SNAPSHOT
LOG

Oracle9i LONG to LOB migration
• ALTER TABLE command has been enhanced to

allow the datatype of a LONG column to be modified
to a CLOB and that of a LONG_RAW column to be
modified to a BLOB.
• The syntax for this is as follows:
ALTER
ALTER TABLE
TABLE [schema].table_name
[schema].table_name
MODIFY
MODIFY (( long_column_name
long_column_name {CLOB|
{CLOB| BLOB
BLOB |NCLOB
|NCLOB }}
[DEFAULT
[DEFAULT default_value])
default_value]) [LOB_storage_clause];
[LOB_storage_clause];
• Applications which perform DML on tables with

migrated LONG columns do not have to be
modified.
Existing Method for LONG TO LOB MIGRATION

Oracle8i introduced the new TO_LOB() operator that copies LONG to LOB. The TO_LOB() operator
can be used in CREATE TABLE AS subquery and INSERT INTO as subquery statements, to copy the
data from a LONG to a LOB.
In Oracle9i, the ALTER TABLE command can be used to change a LONG to a LOB. Default values
can be specified for the LOB column and a LOB storage clause can be specified for storing the LOB
segment. The null/not-null constraints of the old LONG column are maintained for the new LOB
column.
The new ALTER TABLE MODIFY command only modifies a LONG or a LONG RAW column to a
LOB column. It does not modify a VARCHAR or a RAW column.
Example
ALTER TABLE long_tab MODIFY (long_col CLOB);
The "ALTER TABLE MODIFY LONG … LOB" command works like the "ALTER TABLE MOVE"
command . Hence the contents of the table are copied into a new space, and the old space is removed at
the end of the operation. This temporarily doubles the space requirements. But the advantage is that
after the transformation , the table will not have any embedded NULLs in place of the old LONG
column, so the performance of subsequent DMLs / queries on the table will not deteriorate.

Implications of LOB Migration for
Replication
• LONG columns cannot replicated, but LOB

columns can be replicated.
• Converting LONG columns to LOB columns
means the "LONG" data can now be replicated.
– May increase bandwidth requirements
• The migration of a LONG column to LOB for a
replicated table cannot itself be replicated.
– Tables at remote sites have to be
regenerated
– Materialized Views defined on a LOB
migrated table have to be manually rebuilt
Implications of LOB Migration for Replication

If a table is replicated or has materialized views, and its LONG column is changed to LOB, the replica
tables need to be manually rebuilt. Since the converted LONG data can now be replicated, this may
increase the bandwidth requirements for the replication system. DBAs should be aware of the impact
it may have on their replication systems.

Summary
In this lesson, you should have learned about the

following:
• Reduced quiesce
• Fast Refresh ability extensions
• Multi-Tier Materialized Views
• Job Queue process changes
• Changes to data dictionary views for
Replication
• LONG to LOB migration issues

Oracle9i: Replication with Objects
Schedule: Timing Topic

60 minutes Lecture
60 minutes Total
Objectives
At the end of this lesson, you should be able to:

• Create a replicated table which contains an object
data type.
• Understand the limitations of replicating objects.
• List the different types of materialized views which
can be created on master tables which contain user-
defined objects.
• Understand changes made to materialized view logs
to support object replication.
Objectives
This lesson will introduce the new replication features: replication of objects.
Note:
In this lesson, we will focus only on materialized views which are used for replicating data between
two databases. These features do not apply to materialized views used for data warehousing or
summary management unless so indicated.
Oracle9i Replication New Features BETA- 2

Replicating Objects, Multimaster
• Oracle9i gives you the ability to replicate the

following:
– Tables with:
– Object columns
– Collection type columns
– REF columns
– Object tables
– Object views and instead-of triggers
– Index types, operators, and domain indexes
• No support for replicating method invocation
initially
Replicating Objects, N-Way Masters

Multimaster replication treats an object table like a regular relational table except that it preserves the
object identifier (OID) of the object table (EOID) and the OID for each row. A user defined conflict
resolution function for uniqueness and delete conflicts can only take one parameter (the object type of
the table).
For object views, any type information for object types, VARRAYs, and nested tables involved in the
view definition must be replicated explicitly.
Users cannot specify alternate key columns for a replicated object table:
• If the OID is system-generated, replication uses this OID column as the key
• If the OID is user-defined, replication uses the underlying primary key as the key

• The attributes for an object type must be

ordered the same at each site.
• Type owner, type name, and type object ID
(TOID) must be preserved at each site.
• Version of types (Evolution) must also be the
same at each site.
• Objects must be instantiated through
DBMS_REPCAT.CREATE_MASTER_REPOBJECT or
by using export/import.

Related Object enhancements included with Oracle9i:
• Single Inheritance:
– Define subtypes under a particular type
– Can add new attributes and methods to the subtype
– Can specialize methods inherited from the supertype
• Type Evolution:
– Add, delete, or modify attributes for a user-defined datatype
– Add or change method definitions for a user-defined datatype.
– Each evolution marked by a VERSION number for that user-defined datatype.
– Users can specify if all dependent objects should be upgraded immediately to handle the
new version or upgrade later by using ALTER TABLE <name> MERGE TYPES;
See the Presentation “Objects Enhancements” under the Developme nt Platform
category for more details on the object enhancements of Oracle9i .
Notes:
• The initial release of Oracle9i will not support inheritance or evolution of object types. If an
object definition is modified at the master definition site, all replicated tables which use that
object definition will have to be regenerated.
• There is no support within the export or import utilities for specifying that only object types are
to be selected. When using export and import to instantiate replicated objects, the lowest level
of export that can be used is the schema, or owner level.
BEGIN
DBMS_REPCAT.CREATE_MASTER_REPOBJECT (
gname => 'OBJ_REP', type => 'TYPE',
sname => 'OE', oname => 'CUST_ADDRESS_TYP');
END;
BEGIN
DBMS_REPCAT.CREATE_MASTER_REPOBJECT (
gname => 'OBJ_REP', type => 'TABLE',
sname => 'OE', oname => 'CUST');
END;

The above example illustrates the procedural call used to replicate an object type and the table which
uses this object type for a column. The OE.CUST table was created with the following SQL
statement:
SQL> CONNECT OE/OE
SQL> CREATE TABLE cust AS SELECT customer_id,

cust_first_name, cust_last_name,
2 cust_address, credit_limit, cust_email,
account_mgr_id
3 FROM customers;

• Communication minimization is supported on

leaf attributes only.
• A column object type cannot span column
groups.
• An object attribute can be used to resolve
conflicts if it is not a LOB, collection, or REF.
• DBMS_RECTIFIER_DIFF accepts only top-level
object type columns.
• User must ensure correctness of any
additional dependencies introduced by type
definitions among different object groups.

When defining column groups, a column object type must be entirely contained within a column
group. Individual attributes for a column object type cannot belong to multiple column groups. For
object tables, however, you can specify column groups that include a subset of the columns.
Procedures in the DBMS_RECTIFIER_DIFF package only accept logical column names; they can
accept entire column objects, but not attributes of column objects. They can accept column names of a
replicated object table.
A replication object group is a logical group of replicated objects (tables, packages, triggers, objects)
for ease of maintenance. Everything in an object group is replicated together. It is the user’s
responsibility to ensure the correctness of any additional dependencies introduced by type definitions
among different object groups. For example:
• A table called Sales_Sep_00 containing a column called product of type REF is replicated in the
Sales_Grp object group.
• The table referenced by the column product is called Products and is replicated in the
Inventory_Grp.
• If you attempt to replicate the Sales_Sep_00 but the Products table has not yet been replicated,
creation of the Sales_Sep_00 table results in an error. Users need to have the referenced object
table created first.
• Likewise, table data can be incorrect if rows in the Products table are replicated at a different
interval than the Sales_Sep_00 table.
BEGIN
DBMS_RECTIFIER_DIFF.DIFFERENCES (
sname1 => 'OE',
oname1 => 'CUST',
reference_site => 'HQ.ACME.COM',
sname2 => 'OE',
oname2 => 'CUST',
comparison_site => 'REG1.ACME.COM',
column_list => 'customer_id, cust_address',
missing_rows_sname => 'repadmin',
missing_rows_oname1 => 'missing_rows_data',
missing_rows_oname2 => 'missing_rows_location',
missing_rows_site => 'hq.acme.com',
commit_rows => 50);
END;
/
Replicating Objects Multimaster

In this example, we are trying to locate rows in the replicated table OE.CUST which have different
addresses or ID numbers between the HQ site and the Region1 replication site. CUST_ADDRESS is
defined as an object of type CUST_ADDRESS_TYP.

Conflict Detection when Replicating User-
Defined Types
• Two objects are considered equal if and only if one

of the following is true:
• Both values are atomically NULL
• All the corresponding valid attributes are equal
• If a column object is NULL, then its attributes are
undefined(bad NULLs)
• System implemented conflict resolution routines
cannot resolve conflicts based on bad NULLs.
• User defined MAP and ORDER methods are not
used in conflict detection.
• A nested table's storage table is treated as an
independent table in conflict resolution.
Conflict Detection when Replicating User-Defined Types

Replication extends column-level equality checks for conflict detection to object types. Replication
performs NULL checks on embedded objects and performs equality checks on valid leaf attributes of
the same ordinal position. When comparing two object type instances of the same type, replication
treats them equal if and only if one of the following is TRUE:
• Both instances are atomically NULL.
• All the corresponding valid attributes are equal.
If an embedded object is NULL or an object type column is atomically NULL, all attributes it directly
or indirectly contains have an undefined value. These attribute values are called bad NULLs. System
implemented conflict resolution routines cannot resolve conflicts based on bad NULLs and will raise
an error if any needed attribute has a bad NULL value.
Since a nested table is treated as a separate table for conflict resolution, you can specify a subset of the
nested table’s columns as a column group.

Replicating Collection Columns
• Collections type data is stored separate from

the table data in one of two ways:
– VARRAY greater than 4K stored as a BLOB
– Nested table rows stored in a separate
STORAGE table
• Ability to replicate collections is dependent
upon ability to replicate type definitions
Example: Multi-level nested tables cannot
be replicated
Examples of Collection Columns:

VARRARY columns can be stored in-line or out-of line, depending on size.
CREATE TYPE oe.phone_list_typ AS VARRAY(9) OF VARCHAR2(25);
CREATE TABLE oe.customers (
customer_id NUMBER(6),
cust_first_name VARCHAR2(20) CONSTRAINT cust_fname_nn NOT
NULL,
cust_last_name VARCHAR2(20) CONSTRAINT cust_lname_nn NOT
NULL,
cust_address cust_address_typ,
phone_numbers phone_list_typ, …);
Nested table rows are stored in a separate Storage Table:
CREATE TYPE oc.product_ref_list_ typ AS TABLE OF NUMBER(6);
CREATE TYPE oc.category_typ AS OBJECT (
category_name VARCHAR2(50),
category_description VARCHAR2(1000),
category_id NUMBER(2))
NOT INSTANTIABLE NOT FINAL;
CREATE TYPE oc.leaf_category_typ UNDER category_typ (
product_ref_list product_ref_list_ typ);
CREATE TABLE oc.leaf_categories_tab OF leaf_category_typ
NOT SUBSTITUTABLE AT ALL LEVELS
Oracle9i Replication New
NESTED TABLE product_ref_list Features
STORE AS BETA- 9
product_ref_list_ntab;
Replication of Nested Tables
• min_communication defined at collection level

• Support for storage table stored as an Index
Organized Table (IOT)
• Storage table considered a child table for:
– Making column groups
– Registering conflict resolution routines
– Using DBMS_RECTIFIER_DIFF
• Users cannot:
– Select a subset of storage table columns for data
replication
– Generate replication support on storage table
Replication of Nested Tables

Replication performs row-level replication for each changed row in the storage table.
A collection column belongs to a single column group and cannot be a replication key or part of a
replication key.
DBMS_RECTIFIER_DIFF can be called on the storage table for nested table collections.
Comparisons on VARRAY collections are not supported in Oracle9i.

Replication of REF Columns
• ROWID information of a REF with ROWID

becomes invalid when the table is replicated:
– Not automatically fixed at receiving site
– User must use ANALYZE command to
update the REFs
ANALYZE TABLE <name> VALIDATE REF UPDATE;
• Only SCOPED REFs are supported.

– The referenced object must be created
or replicated first.
Replication of REF Columns

When a table with a REF column containing a ROWID component is replicated, the ROWID portion
is invalid on any remote site. The table must be analyzed so that the ROWIDs for all REFs in the
table can be recalculated.
Unscoped REFs are not supported in the first Oracle9i release. Only SCOPED REFs are supported.
If the Line_Item table has a REF column which refers to the Orders table, then the Orders table must
be created on the remote site before the Line_Item table can be replicated.

Replicated Objects: API Support
Object type, VARRAY, nested table, and REF

support has been extended to:
• Procedural replication and deferred RPC
arguments
• Error creation, both serial and parallel
• Error execution
• Retrieval of call variables for verification
DBMS_DEFER_QUERY.GET_ANYDATA_ARG ()
Replicated Objects: API Support

The ANYDATA datatype (new for Oracle9i) supports user-defined types, nested tables, VARRAYS,
and REFS. Not all types supported by this function can be enqueued by the ANYDATA_ARG
procedure of DBMS_DEFER.
The returned text for type arguments includes the following values separated by colons (:)
• Type owner
• Type name
• Type version
• Length
• Precision
• Character set identifier
• Character set form
• Number of elements

Objects and Materialized Views
Enhancements to Materialized Views for Oracle9i

include:
• Materialized views (MV) with column objects
• Object materialized views
• Support for REF columns
• Support for collection columns
• Changes to materialized view logs
• Changes to Updatable MV logs
Objects and Materialized Views

Some new terminology for materialized views in Oracle9i:
• Materialized views created on tables which contain column-level objects are called Object-
Relational materialized views.
• Materialized views created on object tables are called Object materialized views.
• Object materialized views created on relational tables (similar to Object Views), which are
known as Derived Object materialized Views, are not supported in the first release of Oracle9i.

Materialized Views with Column Objects
• When creating materialized views, you can:

– Select column objects in the MV query
– Select individual attributes of a column
object for read-only materialized views
• All user-defined types required for MV creation
must:
– Exist at the MV site prior to creation
– Have the same type object ID (TOID) and
version as the object type at the master site

Object Materialized Views
Object Materialized Views are created against an

object table using the keyword OF
CREATE MATERIALIZED VIEW <name> OF <object_type>…;
CREATE MATERIALIZED VIEW categories_ omv

OF category_typ
FOR UPDATE
AS SELECT * FROM oc.categories_tab@ hq.acme.com;

While you can create a read-only object-relational MV on an object table, you cannot create an
updatable object-relational materialized view on an object table. You can, however, create an
updatable Object Materialized View on an object table by using the OF keyword in the MV definition.

Features of Object materialized views:

• Read-only object-relational MV can be created
on an object table by omitting the OF keyword.
– Creates a relational view, not an object view
• Attribute subsets cannot be selected from an
object table when creating an updatable MV.
• OIDs of each row are inherited from the master
table:
– System-generated or primary key based
– REFs pointing to this table remain valid on the
MV site

Materialized Views and REF Columns
• REF columns can be selected in the

materialized view query.
• SCOPED REFs can be rescoped to a local
table.
– Selecting UNSCOPED REFs will result in
dangling REFs at MV site.
• Both Primary Key and system-generated REFs
are supported.

Materialized Views and Collection
Columns
• VARRAY and Nested Table collections are

supported
• VARRAYs are considered atomic
• Storage table for Nested Tables treated as a
separate, secondary MV:
– Created automatically
– Refreshed automatically with parent MV
– Dropped when parent MV is dropped
– Cannot be refreshed or manipulated directly
Materialized Views and Collection Columns

Storage tables must be created with SETID preserved in order to preserve the correct relationship with
the parent table.
Restrictions
• Horizontal or vertical subsetting of collections is not allowed
• Storage tables for nested tables must have PK constraint logged for fast refresh ability

Objects and Materialized View Logs
• Materialized view log tracks OIDs for object tables

• Supports Scalar object attributes
• Can log REF columns
• MV created on table with Nested Table must have
MV log created explicitly on storage table at the
master site to support fast refresh
Objects and Materialized View Logs

The Materialized View Log construct has been updated to support objects. Object attributes can be
used as filter columns, but collections are not supported as filter columns. If a REF column is being
logged, the information contained in the MV log differs, depending on the type of REF.
– For REFs with system-generated OIDs, the REF column itself is stored in the MV log
– For REFs with primary key-based OIDs, the REF attribute columns are logged.
If a materialized view is created on a master table which contains a nested table collection object, in
order to support fast refresh a materialized view log must be created on both the master table and the
storage table at the master site. The MV log on the storage table is not created automatically.

Updatable Materialized View Logs
• For object-relational MVs, the updatable MV log will

log either the ROWID column and/or PK.
CREATE MATERIALIZED VIEW LOG ON table_ pkbased
WITH PRIMARY KEY;
• When you create a materialized view log on an

object table, you must also log the object identifier.
CREATE MATERIALIZED VIEW LOG ON obj_table
WITH OBJECT ID, PRIMARY KEY;
Updatable Materialized View Logs

Object-relational materialized view logs will track either the ROWID or Primary Key of the master
table. The primary key can consist of scalar object attributes. If you are creating an object
materialized view (created against an object table), the MV log must also log the OID for each row.
This is specified with the clause WITH OBJECT ID. The WITH OBJECT ID clause can be in
addition to the Primary key or ROWID.
For nested tables, the updatable MV log on the storage table is automatically created as part of the
creation of the secondary MV.

Summary
In this lesson, you should have learned about the

following:
• Replication of objects between master tables
• Materialized view support for objects
• Changes to the materialized view logs to
support objects

9ib REPL

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

9ib REPL

Uploaded by

Copyright:

Available Formats

Oracle9i Replication New Features

Schedule: Timing Topic

At the end of this lesson, you should be able to:

Oracle9i Replication New Features AR1- 2

• Allows the DBA to perform certain DDL without

Replication Quiesce Reduction

Oracle9i Replication New Features AR1- 3

In Oracle9i, the following additional DDL actions can be

Replication Quiesce Reduction

Oracle9i Replication New Features AR1- 4

• Adding new master sites without quiescing

Adding a New Master Site without Quiescing

Oracle9i Replication New Features AR1- 5

Perform SCN- At New

Adding a New Master Site without Quiescing (continued)

Oracle9i Replication New Features AR1- 7

After executing the procedure, check the view

Oracle9i Replication New Features AR1- 8

When using database level instantiation:

Instantiating New Master Sites

Oracle9i Replication New Features AR1- 9

Oracle9i Replication New Features AR1- 11

VARIABLE masterdef_consistent_at VARCHAR2(15);

Oracle9i Replication New Features AR1- 12

DBMS_REPCAT Additions: RESUME_PROPAGATION_TO_MDEF

SQL> select extension_id, dblink, master_status

Oracle9i Replication New Features AR1- 13

DBMS_REPCAT Additions: PREPARE_INSTANTIATED_MASTER

Adding Masters without Quiescing

Oracle9i Replication New Features AR1- 15

• You want to perform data manipulation language

When to Add New Master Sites without Quiescing

• If there is a need to stop the process of adding new

Removing Added New Masters

Oracle9i Replication New Features AR1- 17

• When using parallel propagation Oracle orders the

Parallel Propagation and Row-Level SCN

• A table can be created so that the commit SCN is

• Each row has an SCN that:

Features of Row Level SCNs

Oracle9i Replication New Features AR1- 19

Row Lock # of Cluster Row Column

Row Level SCN Implementation

• When constraints are created on a table, this can

Oracle9i Replication New Features AR1- 21

• Index leaf blocks contain a Last Delete SCN

Constraint SCN Implementation

Block header dump: 0x00c009a4

Itl Xid Uba Flag Lck Scn/Fsc

Leaf block dump

Fast refresh ability extended to:

New MV Fast Refresh Abilities

Oracle9i Replication New Features AR1- 23

• Fast refresh support of extended subqueries

CREATE MATERIALIZED VIEW LOG

SELECT * FROM oe.orders@hq.acme.com o

Materialized View Log Change

Oracle9i Replication New Features AR1- 24

The following query is now fast refreshable:

CREATE MATERIALIZED VIEW oe.orders REFRESH FAST AS

Extended Subquery Fast Refresh

Oracle9i Replication New Features AR1- 25