Tài liệu ORACLE8i- P27 docx

CHAPTER 24 • DATABASE PARTITIONING
1040
• Purging data from unused partitions
• Backup and restoration of unused partitions
• Reorganization
• Index building
Partition-Wise Joins
A partition-wise join is a large join operation divided into smaller parts and executed in
parallel. The results of the smaller joins are then brought back together as if the sepa-
ration had never taken place. This utilizes Oracle’s capabilities of both parallel pro-
cessing and partitioning.
For a partition-wise join to occur, the following conditions must exist:
• Both tables in the join statement must be equipartitioned.
• Either the tables or the indexes in the join operation must use the same parti-
tioning method.
• Both tables or indexes must have the same partitioning columns.
• Both tables or indexes must have the same number of partitions.
• In range partitioning, the same partition bounds are required.
• In composite partitioning, only one of the tables need be equipartitioned.
Example of a Partition-Wise Join
Figure 24.1 represents four equipartitioned objects (tables and indexes) in a
project/task relationship. The PROJECTS and TASKS tables are divided into two parti-
tions each, by project number. The indexes have the same partitioning bounds.
Specifically:
• PROJECTS is a table with two partitions, range-partitioned on column PRO-
JECT_NO. The first partition contains project numbers up to 200000. The sec-
ond partition contains project numbers up to 400000.
• PROJECTS_N1 is an index on column PROJECT_NO of the PROJECTS table.
Both the table and index are range-partitioned on column PROJECT_NO into
two partitions, which have the same partition bounds as the PROJECTS table’s
partitions. These are the elements that begin to develop the requirements listed

just above.
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
1041
• TASKS is a table with two partitions, range-partitioned on column PROJECT_NO
(this is the same as the PROJECTS table). PROJECT_NO is a foreign key that ref-
erences PROJECT_NO in PROJECTS.
• TASKS_N1 is an index on columns (PROJECT_NO, TASK_NO) in TASKS. Again,
we are range-partitioned on PROJECT_NO into two partitions, which have the
same partition bounds as the partitions of PROJECTS.
FIGURE 24.1
Equipartitioned tables
and indexes
If a performance gain can be achieved with partition-wise joining, Oracle will use
it. In some cases pruning can be achieved with a partition-wise join resulting in a big-
ger performance gain. This is all handled by Oracle and is transparent to the user and
developer.
PROJECTS
PARTITION1
TASKS
PARTITION1
PROJECTS Index
PARTITION1
TASKS Index
PARTITION1
PROJECTS
1 to 200000
PROJECTS

1 to 200000
PROJECTS
1 to 200000
PROJECTS
1 to 200000
PROJECTS
PARTITION2
TASKS
PARTITION2
PROJECTS Index
PARTITION2
TASKS Index
PARTITION2
PROJECTS
200001 to 400000
PROJECTS
200001 to 400000
PROJECTS
200001 to 400000
PROJECTS
200001 to 400000
PARTITION-WISE JOINS
Oracle8i Distributed
Database
PART
IV
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.

CHAPTER 24 • DATABASE PARTITIONING
1042
Performance versus Availability
Both partitioning and disk striping are techniques utilized to reduce contention for disk
access. In database design, you may have occasion to consider using either or both. If
you’re after performance gains, you’ll want to stripe your partition across as many I/O
devices as possible to get the greatest throughput. If data availability is the goal, you
should place the partition on as few disks as possible.
Figure 24.2 is a common representation of two methods of partitioning and striping.
These are extreme examples but do demonstrate database performance using both
approaches utilized together. The top figure shows what will happen when you stripe
each partition to its own disks (more availability; less performance). The bottom figure
represents the results of striping each partition across all disks on your system; depend-
ing on how your system is configured, this bottom arrangement would give you the
best performance. Notice the following:
• In the top arrangement, you see lessened performance because all your partitions
are resident on the same disks. All I/O is happening on the one device.
• If just one of the disks becomes unavailable (bottom example), all the partitions
suffer because all the partitions are spread across all the disks.
• From an availability standpoint, the top arrangement is better. If a disk becomes
unusable, only the data on that disk is unusable and not all the partitions.
Both performance and processing availability are at issue when you design your parti-
tioning solution. The reliability of your equipment is part of the equation, as well. It has
been our experience that most enterprises have better results making do with slower
data retrieval than coping with no data being retrieved at all.
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
1043

FIGURE 24.2
Two arrangements of
partitioning plus disk
striping
Partition Management
This section discusses merging, splitting, exchanging, and dropping partitions. It lists
partition-related attributes and offers several helpful data dictionary views.
Merging
The MERGE PARTITIONS option lets you take a table that is partitioned into, say, five
parts and bring that back to four parts. Partitions to be merged must be adjacent.
Here’s an example of the merge command.
ALTER TABLE projects
MERGE PARTITIONS projects_q1, projects_q2
INTO projects_a2000 ;
Here we’re merging projects_q1 (first quarter data) and projects_q2 (second quarter
data) into a new partition called projects_a2000 (annual data for 2000). This might
be useful when trying to redistribute data from monthly to quarterly and from quar-
terly to annual.
More performance, less availability
Less performance, more availability
Partition 1
Disk 1 Disk 2
Partition 2
Disk 3 Disk 4
Partition 3
Disk 5 Disk 6
Partition A
Disk 1 Disk 2
Partition B
Disk 3 Disk 4

Partition C
Disk 5 Disk 6
PARTITION MANAGEMENT
Oracle8i Distributed
Database
PART
IV
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 24 • DATABASE PARTITIONING
1044
Splitting
Splitting a partition does exactly that—you split an object that is partitioned into
parts and make more partitions. For example, say your PROJECTS table is partitioned
into four parts, one for each quarter. Your user community is requesting lots of reports
and writing SQL that needs the data separated by month. You can repartition the
table to accommodate this, by splitting a partition with the following command:
ALTER TABLE projects
SPLIT PARTITION projects_expense
AT project_number (200000)
INTO PARTITION projects_flow less then (200000)
PARTITION projects_const (maxvalue);
This breaks the partition called projects_expense into two partitions called projects_
flow and projects_const. This will not touch any other partitions assigned to the
PROJECTS table.
Exchanging
Partition exchanging is a new feature as of Oracle8i. You have the ability to move data
into a partitioned table from any nonpartitioned table. This will be accomplished one

partition at a time. Here’s an example:
ALTER TABLE projects_p8
EXCHANGE projects_w1 WITH projects
INCLUDING INDEXES
WITH VALIDATION
EXCEPTIONS INTO mdb_exceptions ;
This code will move data from the PROJECTS table into a partitioned table projects_
p8; in addition; you’ll move the data from the partitioned table projects_p8 to the
Projects table. The command EXCHANGE means literally to exchange data from one
partition to another.
Dropping Partitions
Before you drop a partition, be sure you want to do it. When you drop a partition,
you drop that partition and all the data stored in it—there’s no exception.
WARNING Even if you’re certain you want to take this step, back up the affected
data or move it into a place from which it can be restored.
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
1045
Either of the following commands will drop a partition:
ALTER TABLE projects
DROP PARTITON projects_p8 ;
The second example will drop the partition projects_p8 from the projects table. The
partition and all the data stored there will be gone.
One last thing: you can’t use the DROP PARTITION command if the object only
contains one partition.
Attributes and Partitioning
We all know and understand attributes. Partitions have the same column and con-
straint definitions. However, the storage specifications may differ from partition to

partition, as will other physical attributes such as PCTFREE, PCTUSED, INITRANS,
and MAXTRANS. (Subpartitions do not follow this convention. All subpartitions must
have the same physical attributes as the partition to which they belong.)
The Appendix F syntax diagrams for CREATE/ALTER TABLE and CREATE/ALTER
INDEX include many attributes concerning partitioning, about 15 of them. Table 24.1
is a complete list of these options.
TABLE 24.1: OPTIONS FOR CONTROLLING ATTRIBUTES IN PARTITIONING
Command Description
ADD_HASH_PARTITION_CLAUSE Adds a new hash partition to the “high” end of a par-
titioned table.
ADD_RANGE_PARTITION_CLAUSE Adds a new range partition to the “high” end of a
partitioned table.
COALESCE_PARTITION_CLAUSE Distributes partition contents into one or more
remaining partitions (determined by the hash func-
tion), and then drops the selected partition. Only
applies to hash-partitioned tables.
DROP_PARTITION_CLAUSE Removes the partition and its stored data from a par-
titioned table. Applies only to range- or composite-
partitioned tables.
EXCHANGE_PARTITION/ Converts a partition or subpartition into a nonparti-
SUBPARTITION_CLAUSE tioned table, and a nonpartitioned table into a parti-
tion or subpartition.
PARTITION MANAGEMENT
Oracle8i Distributed
Database
PART
IV
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 24 • DATABASE PARTITIONING
1046
TABLE 24.1: OPTIONS FOR CONTROLLING ATTRIBUTES IN PARTITIONING (CONTINUED)
MERGE_PARTITION_CLAUSE Merges the contents of two adjacent table partitions
into one new partition, and then drops the two origi-
nal partitions.
MODIFY_DEFAULT_ATTRIBUTES_CLAUSE Specifies new default values for the attributes of the
table.
MODIFY_PARTITION_CLAUSE Modifies physical attributes of the partition.
MODIFY_SUBPARTITION_CLAUSE Lets you allocate or deallocate storage for an individ-
ual subpartition.
MOVE_PARTITION_CLAUSE Moves the table partition to another segment.
MOVE_SUBPARTITION_CLAUSE Moves the table subpartition to another segment.
RENAME_PARTITION/ Renames a table partition or subpartition CURRENT_
SUBPARTITION_CLAUSE NAME to NEW_NAME.
ROW_MOVEMENT_CLAUSE Determines whether a row can be moved to a differ-
ent partition or subpartition because of a change to
one or more of its key values.
SPLIT_PARTITION_CLAUSE Creates two new partitions, each with a new seg-
ment and new physical attributes, and new initial
extents.
TRUNCATE_PARTITION/ Removes all rows from a partition or, if the table is
SUBPARTITION_CLAUSE composite-partitioned, all rows from the partition’s
subpartitions.
TIP We highly recommend that you try and test as many of these attribute options
as your system will allow. They are critical in design and implementation when partitioning
your objects.
Data Dictionary Views Useful in Partitioning
Partitioning is only available for databases using cost-based optimization. Table 24.2

lists data dictionary views at your disposal for viewing partitioning statistics for any
given object. Notice that all are available for ALL_, DBA_, and USER_ areas. The USER_
views display only items that the user owns, and ALL_ is the broadest view of results
from all the tables and indexes that have partition related information. You’ll find
many uses for this information.
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
1047
TABLE 24.2: DATA DICTIONARY VIEWS USEFUL IN PARTITIONING
Objects Description
TAB_PARTITIONS* Tables and their partitioning information
TAB_SUBPARTITIONS* Tables and their subpartitioning information
IND_PARTITIONS* Partitioned indexes, with related information
IND_SUBPARTITIONS* Subpartitions, with related information
PART_COL_STATISTICS* Column statistics associated with the partitions
SUBPART_COL_STATISTICS* Column statistics associated with the subpartitions
* All these data dictionary items are available in ALL_, DBA_, and USER_ views.
Here’s a query using the USER_TAB_PARTITIONS view. Output will list the parti-
tion name, number of rows in the partition, number of blocks occupied by the parti-
tion, and the average row length in the partition. The resulting data will vary
depending on your setup.
SELECT partition_name
, num_rows
, blocks
, avg_row_len
FROM user_tab_partitions ;
PARTITION MANAGEMENT
Oracle8i Distributed

Database
PART
IV
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 25
Simple and
Advanced
Replication
FEATURING:
Simple replication with
materialized views 1050
Refresh groups 1055
Advanced replication 1059
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
R
eplication is exactly what it sounds like: creating and maintaining database
objects in multiple locations. Simply stated, replication is a process by
which you copy and maintain database objects in more then one database.
Using materialized views, you can create an environment in which data
can be duplicated from one database to another, for a simple form of replication.
Advanced replication is more complex, but Oracle 8i provides several tools to help
you develop and maintain an advanced replication environment.
This chapter discusses methods for both simple and advanced replication. First, we
describe how to use materialized views for simple replication. Then we cover how to

create and manage refresh groups, which can be used with simple and advanced repli-
cation schemes. Finally, we detail advanced replication, including some step-by-step
instructions.
Simple Replication with Materialized Views
Oracle8i materialized views (Mviews) store data based on a query. In short, an Mview
is a table that stores a predefined set of data. When you create an Mview, you specify
the SQL used to populate it.
In Chapter 19, you learned about Mviews as a data warehousing feature. That
chapter covered the basics of creating, refreshing, and managing Mviews and Mview
logs. Mviews can also serve as a tool for performing simple replication. Here, we will
look at this application of Mviews.
NOTE In previous versions of Oracle, snapshots were used for simple replication. In
Oracle8i, the terms snapshot and materialized view are used synonymously. They both
contain the results of a query on one or more tables. In fact, when you create a snapshot,
upon completion, Oracle reports “Materialized View Created.” In Oracle8i, CREATE MATERI-
ALIZED VIEW is a synonym for CREATE SNAPSHOT.
An important aspect of using Mviews for replication is that you can keep your
Mviews up to date with the appropriate refresh option. Oracle refreshes Mviews in the
manner that you specify when you create the views. You can even group refresh oper-
ations to coordinate the refresh schedules of related tables (master tables). This will
assist in keeping your Mviews accurate and timely with other views of the related
sources. Using refresh groups is discussed in the “Refresh Groups” section later in this
chapter.
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
For example, suppose that you want to replicate project and task information for
reporting, but you do not want all of the data in the associated tables. You could cre-
ate one or more Mviews with the desired data in them, specifying the refresh option

and mode. That’s all there is to simple replication with Mviews.
Listing 25.1 shows an example of creating an Mview for simple replication. This
Mview contains ten columns: five from a table containing projects information and
five from a table containing tasks information. It uses the PARALLEL option to paral-
lelize the view creation operation.
TIP To make the best use of an Mview, make sure that the SQL that creates the view is
optimized and the frequency for refresh is in accordance with the way the view is used.
Also, if possible, take advantage of partitioning and parallel processing.
Listing 25.1: Creating a Materialized View for Simple Replication
CREATE MATERIALIZED VIEW proj_task_mv
PCTFREE 0 TABLESPACE mviews
STORAGE (INITIAL 16k NEXT 16k PCTINCREASE 0)
PARALLEL
BUILD DEFERRED
REFRESH COMPLETE
ENABLE QUERY REWRITE
AS
SELECT
p.proj_num
, p.proj_name
, p.proj_start
, p.proj_end
, p.proj_status
, t.task_num
, t.task_name
, t.task_start
, t.task_end
, t.task_status
FROM
pa_projects p

, pa_tasks t
WHERE p.project_id = t.project_id;
1051
SIMPLE REPLICATION WITH MATERIALIZED VIEWS
Oracle8i Distributed
Database
PART
IV
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 25 • SIMPLE AND ADVANCED REPLICATION
1052
Notice the BUILD and REFRESH options. These were discussed in Chapter 19, but
let’s review them here in relation to replication.
NOTE The ENABLE QUERY REWRITE option specifies that the Mview is eligible to be
used for query rewrite. See Chapter 19 for a detailed discussion of the query rewrite feature.
Choosing an Mview Build Option
Oracle supplies two methods for building a materialized view:
BUILD DEFERRED This option, used in Listing 25.1, creates the structure
for the view, but the view will be populated at a later time manually by, using
DBMS_MVIEW.REFRESH. You might use this option if the build process will take
hours to complete or could hamper daily processing in another way. This view
will have an UNUSABLE value associated with it, so it cannot be used for query
rewrite until it is populated.
BUILD IMMEDIATE This option builds and populates the view when the
command is issued. You might use this option if you need to have immediate
access to the data in the view or if you know that the build process will not inter-
fere with daily processing.

Choosing an Mview Refresh Option
As explained in Chapter 19, Oracle provides three options for refreshing your Mview
(FAST, COMPLETE, or FORCE), along with two options for the method to use for
refreshing (ON COMMIT or ON DEMAND). Table 25.1 summarizes how the REFRESH
options and modes work together.
TABLE 25.1: MATERIALIZED VIEW REFRESH METHODS
Option Mode Description
FAST ON COMMIT Uses the Mview log (described in Chapter 19) and will
update the view when a COMMIT is performed on the
master table
FAST ON DEMAND Occurs only if you add data using a direct-path method
(SQL*Loader in direct-path mode)
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
1053
TABLE 25.1: MATERIALIZED VIEW REFRESH METHODS (CONTINUED)
Option Mode Description
COMPLETE ON COMMIT Completely rebuilds the Mview every time a COMMIT
occurs on the master table (not recommended)
COMPLETE ON DEMAND Creates a new view or completely refreshes the data.
FORCE ON COMMIT Uses FAST refresh if possible; otherwise, uses COMPLETE
refresh (not recommended)
FORCE ON DEMAND Uses FAST refresh if possible; otherwise, uses COMPLETE
Let’s look at some examples of using the various options and modes.
NOTE When you specify the ON DEMAND mode, you must use one of the procedures
in the DBMS_MVIEW package to refresh your views. See Chapter 19 for details.
Creating an Mview with the FAST/ON COMMIT Refresh
Option

The FAST/ON COMMIT combination will keep the Mview up-to-date with what the
original data represents. Listing 25.2 shows an example of creating this type of view.
Listing 25.2: Using REFRESH FAST ON COMMIT
CREATE MATERIALIZED VIEW proj_task_mv
BUILD IMMEDIATE
REFRESH FAST ON COMMIT
AS
SELECT
p.proj_num
, p.proj_name
, p.proj_start
, p.proj_end
, p.proj_status
, t.task_num
, t.task_name
, t.task_start
, t.task_end
, t.task_status
SIMPLE REPLICATION WITH MATERIALIZED VIEWS
Oracle8i Distributed
Database
PART
IV
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 25 • SIMPLE AND ADVANCED REPLICATION
1054
FROM

pa_projects p
, pa_tasks t
WHERE p.project_id = t.project_id ;
TIP If you want to be able to update an Mview, include the FOR UPDATE keywords.
When FOR UPDATE is specified in the definition of an Mview, Oracle allows a subquery, pri-
mary key, or ROWID in the Mview to be updated. When used in conjunction with advanced
replication, discussed later in this chapter, these updates will be propagated to the master
table of the Mview.
In this example, the view will be built immediately (because of the BUILD IMME-
DIATE option). An Mview log will be created when the Mview is created, allowing the
fast refresh to work. The Mview log will be updated immediately following a COM-
MIT on the master table (in this case, either PA_PROJECTS or PA_TASKS). The ON
COMMIT option will refresh the Mview when a row in one of the tables that make up
the view has a COMMIT submitted against it.
NOTE When you use the ON COMMIT option, check the alert log and trace file to make
sure that no errors were encountered. Should any errors occur during the refresh opera-
tion, you will need to fix the error and manually refresh the Mview using the
DBMS_MVIEW package.
Creating an Mview with the FORCE/ON COMMIT
Refresh Option
The FORCE/ON COMMIT combination will also update the Mview when a COMMIT
is completed on the master table. The Mview will be evaluated by Oracle each and
every time a COMMIT is completed on the master table. If Oracle decides that a fast
refresh can be completed, then that operation will take place. However, if Oracle
decides that the fast refresh cannot be completed successfully, a complete refresh is
performed. Considering that a complete refresh could take some time and impact the
day-to-day operations, you probably don’t want this to happen, so you will want to
avoid using the FORCE/ON COMMIT combination. Instead, use the COMPLETE
option or even the FORCE/ON DEMAND option. That way, you will be able to plan
for a complete refresh and make sure that it occurs after standard operating hours,

when the users have gone home.
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
1055
Creating an Mview with the FAST/ON DEMAND
Refresh Option
When you use the FAST/ON DEMAND combination, your Mview will be refreshed
only if you are adding data using a direct-path method (a SQL*Loader direct-path
load). Listing 25.3 shows an example of using this refresh method.
Listing 25.3: Using REFRESH FAST ON DEMAND
CREATE MATERIALIZED VIEW proj_task_mv
BUILD IMMEDIATE
REFRESH FAST ON DEMAND
AS
SELECT
p.proj_num
, p.proj_name
, p.proj_start
, p.proj_end
, p.proj_status
, t.task_num
, t.task_name
, t.task_start
, t.task_end
, t.task_status
FROM
pa_projects p
, pa_tasks t

WHERE p.project_id = t.project_id ;
In this example, if you are loading data into the PA_PROJECTS or PA_TASKS table
using SQL*Loader with the direct-path load option, your Mview will also be updated.
Refresh Groups
Refresh groups are used to manage the refresh schedule for the objects in the refresh
group. By placing Mviews in refresh groups, you can coordinate the refresh schedules
of related tables (master tables) that make up the Mviews. Refresh groups are a handy
tool for both simple replication and advanced replication (discussed later in this
chapter).
REFRESH GROUPS
Oracle8i Distributed
Database
PART
IV
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 25 • SIMPLE AND ADVANCED REPLICATION
1056
NOTE Remember that the terms materialized view (Mview) and snapshot are syn-
onyms in Oracle8i. In this chapter, we use the term Mview. In the Oracle documentation,
you may see both terms, used interchangeably.
Each refresh group can contain from 1 to 400 Mviews. An Mview can belong to
only one group at a time.
For managing refresh groups, Oracle supplies the DBMS_REFRESH package. The
procedures in this package are listed in Table 25.2.
TABLE 25.2: DBMS_REFRESH PROCEDURES
Procedure Description
ADD Adds a snapshot or an Mview to an existing refresh group

CHANGE Changes the interval at which the refresh will occur for the group
DESTROY Deletes the refresh group
MAKE Creates a refresh group
REFRESH Manually refreshes the objects in the refresh group
SUBTRACT Deletes an object from a refresh group
Let’s look at how these procedures are used to create and modify refresh groups.
Creating a Refresh Group
Creating a refresh group is easy. First, and most important, you must decide which
views will belong to which refresh groups and what the refresh schedule will be for
each group. Then you can use the DBMS_REFRESH package’s MAKE procedure to cre-
ate the group. Listing 25.4 shows an example of how to create a refresh group.
Listing 25.4: Creating a Refresh Group
DBMS_REFRESH.MAKE (
name IN VARCHAR2,
{list IN VARCHAR2,
| tab IN DBMS_UTILITY.UNCL_ARRAY,}
next_date IN DATE,
interval IN VARCHAR2,
implicit_destroy IN BOOLEAN DEFAULT FALSE,
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
1057
lax IN BOOLEAN DEFAULT FALSE,
job IN BINARY INTEGER DEFAULT 0,
rollback_seg IN VARCHAR2 DEFAULT NULL,
push_deferred_rpc IN BOOLEAN DEFAULT TRUE,
refresh_after_errors IN BOOLEAN DEFAULT FALSE,
purge_option IN BINARY_INTEGER := 1,

parallelism IN BINARY_INTEGER := 0,
heap_size IN BINARY_INTEGER : 0);
EXECUTE dbms_refresh.make(
‘projects’, —- name
‘inst.projects, op_stat’,
SYSDATE,
‘next_date(SYSDATE + 1)’,
TRUE,
FALSE);
This example creates a refresh group called projects. In this group are the Mviews
INST.PROJECTS and OP_STAT (for installed projects and operating status). The next
date will be SYSDATE, and the interval will be SYSDATE +1, or every day.
NOTE The MAKE procedure is overloaded, and the LIST and TAB parameters are mutu-
ally exclusive. In other words, if you specify the LIST parameter, you cannot specify the TAB
parameter.
Notice that Listing 25.4 specifies only the name of the refresh group, the Mviews
that are part of the group, and the refresh schedule. The refresh group will use the
defaults for all of the other parameters.
Adding Members to a Refresh Group
You can add an Mview to an existing group by using the DBMS_REFRESH package’s
ADD option. Listing 25.5 shows an example of adding a member to a refresh group.
Listing 25.5: Adding an Mview to a Refresh Group
DBMS_REFRESH.ADD (
name IN VARCHAR2,
{list IN VARCHAR2,
REFRESH GROUPS
Oracle8i Distributed
Database
PART
IV

C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 25 • SIMPLE AND ADVANCED REPLICATION
1058
|tab IN DBMS_UTILITY.UNCL_ARRAY, }
lax IN BOOLEAN DEFAULT FALSE);
EXECUTE dbms_refresh.add(
‘projects’,
‘clo_proj’,
FALSE);
This example will add a new Mview to the projects group (created in Listing 25.4).
The new Mview is named CLO_PROJ (for closed projects).
Removing Members from a Refresh Group
Use the SUBTRACT procedure of the DBMS_REFRESH package to remove Mviews
from a refresh group. Listing 25.6 shows an example that removes the Mview added
in Listing 25.5.
Listing 25.6: Removing an Mview from a Refresh Group
DBMS_REFRESH.SUBTRACT (
name IN VARCHAR2,
{list IN VARCHAR2,
|tab IN DBMS_UTILITY.UNCL_ARRAY,}
lax IN BOOLEAN DEFAULT FALSE );
EXECUTE dbms_refresh.subtract(
‘projects’,
‘clo_proj’,
FALSE);
Changing a Refresh Group’s Schedule
To modify a refresh group’s schedule, use the CHANGE procedure of the DBMS_

REFRESH package. Suppose that, after setting up the refresh group to be refreshed
daily, you later find that you only need to refresh the views in this group weekly. List-
ing 25.7 shows how to modify the refresh schedule to reflect that change.
Listing 25.7: Changing a Refresh Group’s Schedule
DBMS_REFRESH.CHANGE (
name IN VARCHAR2,
next_date IN DATE DEFAULT NULL,
interval IN VARCHAR2 DEFAULT NULL,
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
1059
implicit_destroy IN BOOLEAN DEFAULT NULL,
rollback_segment IN VARCHAR2 DEFAULT NULL,
push_deferred_rpc IN BOOLEAN DEFAULT NULL,
refresh_after_errors IN BOOLEAN DEFAULT NULL,
purge_option IN BINARY_INTEGER := 1,
parallelism IN BINARY_INTEGER := 0,
heap_size IN BINARY_INTEGER : 0);
EXECUTE dbms_refresh.change(
‘projects’,
NULL,
‘next_date(SYSDATE + 1, ‘’MONDAY’’)’;
This example changes the schedule so that views in this refresh group will be
refreshed every Monday.
Deleting a Refresh Group
To delete a refresh group, use the DESTROY procedure of the DBMS_REFRESH pack-
age, as in the following example:
DBMS_REFRESH.DESTROY ( name IN VARCHAR2 )

EXECUTE dbms_refresh.destroy(projects);
Another way to delete a group is through the IMPLICIT_DESTROY parameter avail-
able with the MAKE and CHANGE procedures. This will delete the group and then re-
create it with the new parameters.
Advanced Replication
Advanced replication can support bi-directional transaction capture and replication,
and it provides comprehensive replication conflict detection and resolution. Oracle
has made several improvements in advanced replication with the release of 8i, includ-
ing the following:
• Oracle has internalized several of the PL/SQL replication packages. More of the
replication code is now placed in the database engine.
• Oracle now allows larger refresh groups. As stated in the previous section, up to
400 Mviews are allowed in one refresh group.
ADVANCED REPLICATION
Oracle8i Distributed
Database
PART
IV
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 25 • SIMPLE AND ADVANCED REPLICATION
1060
• For multiple-site replication, you now have the ability to create snapshot tem-
plates. The DBA can create a snapshot (centrally) and distribute it to many dif-
ferent sites.
TIP To learn more about snapshot templates, see the “Snapshot Concepts and Archi-
tecture” section in the Oracle documentation.
• To assist with advanced replication setup, Oracle supplies a Replication Manager

deployment wizard that will help with the selection of objects, parameters, and
authorizations.
• Offline instantiation is now possible. The DBA can package the templates and
associated data onto removable media (such as tape or a CD-R) and ship this
item to the remote site. The remote site can perform a fast refresh after the
offline instantiation is completed.
Over the past few years, advanced replication has gained the reputation of being
difficult, both to set up and administer. Here, we’ll provide a step-by-step approach to
advanced replication design and setup. The goal is to demonstrate how, with a bit of
effort, you can reap the benefits of using Oracle’s advanced replication tools. But first,
we need to go over the requirements and components of advanced replication.
Advanced Replication Requirements
Advanced replication uses two sites: the master definition site and the master site.
The master definition site is the database that has all the objects that you wish to repli-
cate. All SUSPEND and RESUME commands are to be entered from this site, and they
will be automatically propagated to the master site (or sites). The master site is the
database that will hold the replicated objects. One master definition site can be repli-
cated to multiple master sites.
The following requirements are necessary for implementing advanced replication:
• Install the Distributed and Replication option.
• Run catrep.sql (in $ORACLE_HOME/rdbms/admin/) as INTERNAL.
• Establish the same passwords for REPSYS and REPADMIN on the master and
master definition sites.
• Set up mandatory parameters in the init.ora file, as listed in Table 25.3.
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
1061
TABLE 25.3: INIT.ORA PARAMETERS ASSOCIATED WITH ADVANCED REPLICATION

Parameter Mandatory Value Description
SHARED_POOL_SIZE 25M A major piece of the SGA where Oracle
caches PL/SQL programs.
GLOBAL_NAMES TRUE Determines whether or not a database
link is required to have the same name
as the database to which it connects.
JOB_QUEUE_PROCESSES 2 Sets the number of SNPn background
processes per instance, where n is 0 to
9 followed by A to Z.
OPEN_LINKS 6 The maximum number of concurrent
open connections to remote databases
per user process in one session. If set to
0, no distributed transactions are
allowed.
JOB_QUEUE_INTERVAL Sets the interval between wake-ups for
the SNPn background processes of the
instance.
JOB_QUEUE_KEEP_ FALSE Determines whether or not to keep
CONNECTIONS network connections between the exe-
cution of jobs.
Here are examples of the settings listed in Table 25.2 in an init.ora file:
shared_pool_size: 25M
global_names = true
job_queue_processes = 2
open_links = 6
job_queue_interval = 2
job_queue_keep_connections = false
The value for the OPEN_LINKS parameter should equal or exceed the number of
databases referred to in a single SQL statement that references multiple databases, so
that all the databases can be open to execute the statement. You should increase this

value if many different databases are accessed over time. For example, if OPEN_LINKS
is set to 2, and queries alternately access databases A, B, and C, performance would
slow down while one connection was broken and another connection was made. In
this case, you should increase the OPEN_LINKS value to 3 or more to avoid the wait.
Less than interval for
DBA_JOBS submitted
ADVANCED REPLICATION
Oracle8i Distributed
Database
PART
IV
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 25 • SIMPLE AND ADVANCED REPLICATION
1062
Remote Procedure Calls for Replication
There are three Oracle packages that are critical for the replication environment to
work properly: DBMS_DEFER_SYS, DBMS_DEFER, and DBMS_DEFER_QUERY. These
packages are necessary for handling deferred transactions and remote procedure calls
(RPCs), as described in the following sections.
The DBMS_DEFER_SYS Package
Administrative tasks like scheduling, executing, and deleting queued transactions are per-
formed when one of the DBMS_DEFER_SYS package procedures is invoked. Table 25.4
lists the procedures that are available with this package. The views referred to in Table 25.4
are described in the “Viewing Replication Information” section, coming up shortly.
TABLE 25.4: DBMS_DEFER_SYS PROCEDURES
Procedure Description
ADD_DEFAULT_DEST Adds a destination database to the DEFDEFAULTDEST view

COPY Creates a copy of a deferred transaction with a new
destination
DELETE_DEF_DESTINATION Removes a destination database from the DEFSCHEDULE
view
DELETE_DEFAULT_DEST Removes a destination database from the DEFDEFAULT-
DEST view
DELETE_ERROR Deletes a transaction from the DEFERROR view
DELETE_TRAN Deletes deferred transactions
DISABLED Determines if propagation of the deferred transaction
queue from the current site to a given site is enabled
EXCLUDE_PUSH Acquires an exclusive lock that prevents deferred transac-
tion PUSH
EXECUTE_ERROR Forces execution of a transaction that originally failed, leav-
ing a record in DEFERROR
EXECUTE_ERROR_AS_USER Reexecutes a deferred transaction that did not complete
successfully
PURGE Purges pushed transactions from the deferred transaction
queue at your current master or snapshot site
PUSH Forces a deferred call queue at your current master or
snapshot site to be pushed to another master site
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
1063
TABLE 25.4: DBMS_DEFER_SYS PROCEDURES (CONTINUED)
Procedure Description
REGISTER_PROPAGATOR Registers the given user as the propagator for the local
database
SCHEDULE_PURGE Schedules a job to purge pushed transactions from the

deferred transaction queue at your current master or snap-
shot site
SCHEDULE_PUSH Schedules a job to push the deferred transaction queue to
a remote master destination
SET_DISABLED Disables or enables propagation of the deferred transaction
queue from the current site to a given destination site
UNREGISTER_PROPAGATOR Unregisters a user as the propagator from the local database
UNSCHEDULE_PURGE Stops automatic purges of pushed transactions from the
deferred transaction queue at a snapshot or master site
UNSCHEDULE_PUSH Stops automatic pushes of the deferred transaction queue
from a snapshot or master site to another master site
The DBMS_DEFER Package
The DBMS_DEFER package builds deferred RPCs. Table 25.5 lists the procedures avail-
able with this package.
TABLE 25.5: DBMS_DEFER PROCEDURES
Procedure Description
CALL Builds a deferred call to a remote procedure
COMMIT_WORK Performs a transaction commit after checking for well-
formed deferred RPCs
DATATYPE_ARG Provides the data that is to be passed to a deferred RPC
TRANSACTION Allows you to specify destination sites for the ensuing
call(s) to the DBMS_DEFER.CALL procedure
ADVANCED REPLICATION
Oracle8i Distributed
Database
PART
IV
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com

Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
CHAPTER 25 • SIMPLE AND ADVANCED REPLICATION
1064
The DBMS_DEFER_QUERY Package
The DBMS_DEFER_QUERY package provides access to parameters passed to deferred
calls. Table 25.6 lists the procedures available with this package.
TABLE 25.6: DBMS_DEFER_QUERY PROCEDURES
Procedure Description
GET_ARG_FORM Determines the form of an argument in a deferred RPC
GET_ARG_TYPE Determines the type of an argument in a deferred RPC
GET_CALL_ARGS Gets the arguments for the given RPC
GET_DATAYTPE_ARG Determines the value of an argument in a deferred RPC
Replication Views
Oracle has supplied a wide variety of views to assist with day-to-day operations.
Table 25.7 lists the data dictionary views that assist with the management of
replication.
TABLE 25.7: VIEWS FOR REPLICATION
View Description
DEFCALL Contains information about all deferred RPCs. Queries the
SYSTEM.DEF$_CALL table.
DEFCALLDEST Contains the destination database(s) for each deferred RPC in
DEFCALL. Queries SYSTEM.DEF$_CALL, SYSTEM.DEF$_DESTINA-
TION, SYSTEM.DEF$_CALLDEST, SYSTEM.DEF$_ERROR, and
SYSTEM.REPCAT$_REPPROP.
DEFDEFAULTDEST Contains the default destinations for deferred RPCs. Queries
SYSTEM.DEF$DEFAULTDEST.
DEFERROR Contains error information for deferred calls that could not be
applied at their destination. Queries SYSTEM.DEF$_ERROR.
DEFERRORCOUNT Contains the count of errors for each destination. Queries
SYSTEM.DEF$_ERROR.

DEFSCHEDULE Contains information about the scheduling of deferred jobs.
Queries SYSTEM.DEF$_DESTINATION and SYS.JOB$.
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.
1065
TABLE 25.7: VIEWS FOR REPLICATION (CONTINUED)
View Description
DEFTRAN Contains information about all deferred calls. Queries
SYSTEM.DEF$_CALL and SYS.USER$.
DEFTRANDEST Contains the destination database(s) for each deferred transac-
tion. Queries SYSTEM.DEF$_CALL, SYSTEM.DEF$_DESTINATION,
SYSTEM.DEF$_ERROR, SYSTEM.DEF$_CALLDEST, and SYSTEM.
REPCAT$_REPPROP.
Setting Up Advanced Replication
Now that we’ve covered the requirements, RPCs, and views for replication, we’re
ready to tackle the actual setup for advanced replication. Here, I will present a
method that has been developed and used by several DBAs (including myself) at sev-
eral sites. You can use these steps as a guide, modifying them to suit your own
requirements for your replicated environment. I recommend the following steps for
planning and implementing replication:
1. Create two users: REPADMIN AND REPSYS.
2. Create the replication administration users at the master site.
3. At the master site, create the objects to be replicated.
4. At the master definition site, create a replication schema.
5. At the master definition site, create the required replication group.
6. Add the objects to the group.
7. Generate replication support for the object.
8. Add one or more master sites to the group.

Let’s look at each of these steps in detail.
Creating the REPADMIN AND REPSYS Users
The REPADMIN user performs administrative tasks related to advanced replication. The
REPSYS user performs operations on SYS’s behalf, as required by the advanced replica-
tion packages. SYSTEM will hold the replication tables.
As noted earlier in this chapter, the master definition site is the database that con-
tains the objects that you will be replicating. At the master definition site, set up the
ADVANCED REPLICATION
Oracle8i Distributed
Database
PART
IV
C
opyright ©2002 SYBEX, Inc., Alameda, CA
www.sybex.com
Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.