Tài liệu ORACLE8i- P27 docx

CHAPTER 25 • SIMPLE AND ADVANCED REPLICATIONChoosing an Mview Build Option Oracle supplies two methods for building a materialized view: BUILD DEFERRED This option, used in Listing 25.1,

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 ration had never taken place This utilizes Oracle’s capabilities of both parallel pro-cessing and partitioning

sepa-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 tioning method

parti-• 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 aproject/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 JECT_NO The first partition contains project numbers up to 200000 The sec-ond partition contains project numbers up to 400000

PRO-• 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 intotwo partitions, which have the same partition bounds as the PROJECTS table’spartitions These are the elements that begin to develop the requirements listedjust above

• 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 thesame 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 ger performance gain This is all handled by Oracle and is transparent to the user anddeveloper

big-PROJECTSPARTITION1

TASKSPARTITION1

PROJECTS IndexPARTITION1

TASKS IndexPARTITION1

TASKSPARTITION2

PROJECTS IndexPARTITION2

TASKS IndexPARTITION2

CHAPTER 24 • DATABASE PARTITIONING

1042

Performance versus Availability

Both partitioning and disk striping are techniques utilized to reduce contention for diskaccess In database design, you may have occasion to consider using either or both Ifyou’re after performance gains, you’ll want to stripe your partition across as many I/Odevices as possible to get the greatest throughput If data availability is the goal, youshould 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 bothapproaches utilized together The top figure shows what will happen when you stripeeach partition to its own disks (more availability; less performance) The bottom figurerepresents 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 thebest performance Notice the following:

• In the top arrangement, you see lessened performance because all your partitionsare 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 partitionssuffer because all the partitions are spread across all the disks

• From an availability standpoint, the top arrangement is better If a disk becomesunusable, 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 tioning solution The reliability of your equipment is part of the equation, as well It hasbeen our experience that most enterprises have better results making do with slowerdata retrieval than coping with no data being retrieved at all

Here’s an example of the merge command.

ALTER TABLE projectsMERGE PARTITIONS projects_q1, projects_q2INTO projects_a2000 ;

Here we’re merging projects_q1 (first quarter data) and projects_q2 (second quarterdata) 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 terly to annual

quar-More performance, less availability

Less performance, more availability

CHAPTER 24 • DATABASE PARTITIONING

1044

Splitting

Splitting a partition does exactly that—you split an object that is partitioned intoparts and make more partitions For example, say your PROJECTS table is partitionedinto four parts, one for each quarter Your user community is requesting lots of reportsand writing SQL that needs the data separated by month You can repartition thetable to accommodate this, by splitting a partition with the following command:

ALTER TABLE projectsSPLIT 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_flowand projects_const This will not touch any other partitions assigned to thePROJECTS table

Exchanging

Partition exchanging is a new feature as of Oracle8i You have the ability to move datainto a partitioned table from any nonpartitioned table This will be accomplished onepartition at a time Here’s an example:

ALTER TABLE projects_p8EXCHANGE projects_w1 WITH projectsINCLUDING INDEXES

WITH VALIDATIONEXCEPTIONS 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 theProjects table The command EXCHANGE means literally to exchange data from onepartition 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

data or move it into a place from which it can be restored

Either of the following commands will drop a partition:

ALTER TABLE projectsDROP PARTITON projects_p8 ;

The second example will drop the partition projects_p8 from the projects table Thepartition and all the data stored there will be gone

One last thing: you can’t use the DROP PARTITION command if the object onlycontains one partition

Attributes and Partitioning

We all know and understand attributes Partitions have the same column and straint definitions However, the storage specifications may differ from partition topartition, as will other physical attributes such as PCTFREE, PCTUSED, INITRANS,and MAXTRANS (Subpartitions do not follow this convention All subpartitions musthave the same physical attributes as the partition to which they belong.)

con-The Appendix F syntax diagrams for CREATE/ALTER TABLE and CREATE/ALTERINDEX 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

COALESCE_PARTITION_CLAUSE Distributes partition contents into one or more

remaining partitions (determined by the hash tion), and then drops the selected partition Onlyapplies to hash-partitioned tables

func-DROP_PARTITION_CLAUSE Removes the partition and its stored data from a

par-titioned table Applies only to range- or partitioned tables

composite-EXCHANGE_PARTITION/ Converts a partition or subpartition into a SUBPARTITION_CLAUSE tioned table, and a nonpartitioned table into a parti-

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 nal partitions

origi-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_

ROW_MOVEMENT_CLAUSE Determines whether a row can be moved to a

differ-ent partition or subpartition because of a change toone 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 initialextents

TRUNCATE_PARTITION/ Removes all rows from a partition or, if the table is SUBPARTITION_CLAUSE composite-partitioned, all rows from the partition’s

subpartitions

TI P 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 partitioningyour objects

Data Dictionary Views Useful in Partitioning

Partitioning is only available for databases using cost-based optimization Table 24.2lists data dictionary views at your disposal for viewing partitioning statistics for anygiven 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 resultsfrom all the tables and indexes that have partition related information You’ll findmany uses for this information

* 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 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 varydepending on your setup

parti-SELECT partition_name, num_rows

, blocks, avg_row_lenFROM user_tab_partitions ;

CHAPTER 25

Simple and Advanced Replication

F E A T U R I N G : Simple replication with materialized views 1050 Refresh groups 1055 Advanced replication 1059

R eplication is exactly what it sounds like: creating and maintaining database

objects in multiple locations Simply stated, replication is a process bywhich you copy and maintain database objects in more then one database.Using materialized views, you can create an environment in which datacan 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 helpyou develop and maintain an advanced replication environment

This chapter discusses methods for both simple and advanced replication First, wedescribe how to use materialized views for simple replication Then we cover how tocreate and manage refresh groups, which can be used with simple and advanced repli-cation schemes Finally, we detail advanced replication, including some step-by-stepinstructions

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 specifythe SQL used to populate it

In Chapter 19, you learned about Mviews as a data warehousing feature Thatchapter covered the basics of creating, refreshing, and managing Mviews and Mviewlogs Mviews can also serve as a tool for performing simple replication Here, we willlook 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 yourMviews up to date with the appropriate refresh option Oracle refreshes Mviews in themanner 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 willassist in keeping your Mviews accurate and timely with other views of the relatedsources Using refresh groups is discussed in the “Refresh Groups” section later in thischapter

For example, suppose that you want to replicate project and task information forreporting, 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 optionand mode That’s all there is to simple replication with Mviews.

Listing 25.1 shows an example of creating an Mview for simple replication ThisMview contains ten columns: five from a table containing projects information andfive 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 isoptimized 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_mvPCTFREE 0 TABLESPACE mviews

STORAGE (INITIAL 16k NEXT 16k PCTINCREASE 0)PARALLEL

BUILD DEFERREDREFRESH COMPLETEENABLE QUERY REWRITEAS

SELECTp.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_statusFROM

pa_projects p, pa_tasks tWHERE p.project_id = t.project_id;

CHAPTER 25 • SIMPLE AND ADVANCED REPLICATION

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 structurefor the view, but the view will be populated at a later time manually by, usingDBMS_MVIEW.REFRESH You might use this option if the build process will takehours to complete or could hamper daily processing in another way This viewwill have an UNUSABLE value associated with it, so it cannot be used for queryrewrite until it is populated

BUILD IMMEDIATE This option builds and populates the view when thecommand is issued You might use this option if you need to have immediateaccess 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 forrefreshing (ON COMMIT or ON DEMAND) Table 25.1 summarizes how the REFRESHoptions and modes work together

TABLE 25.1: MATERIALIZED VIEW REFRESH METHODS

FAST ON COMMIT Uses the Mview log (described in Chapter 19) and will

update the view when a COMMIT is performed on themaster table

FAST ON DEMAND Occurs only if you add data using a direct-path method

(SQL*Loader in direct-path mode)

TABLE 25.1: MATERIALIZED VIEW REFRESH METHODS (CONTINUED)

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 theoriginal 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_mvBUILD IMMEDIATE

REFRESH FAST ON COMMITAS

SELECTp.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

CHAPTER 25 • SIMPLE AND ADVANCED REPLICATION

1054

FROMpa_projects p, pa_tasks tWHERE p.project_id = t.project_id ;

TI P 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 advancedreplication, discussed later in this chapter, these updates will be propagated to the mastertable of the Mview

In this example, the view will be built immediately (because of the BUILD DIATE option) An Mview log will be created when the Mview is created, allowing thefast 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 ONCOMMIT option will refresh the Mview when a row in one of the tables that make upthe view has a COMMIT submitted against it

IMME-NOTE When you use the ON COMMIT option, check the alert log and trace file to makesure 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 theDBMS_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 andevery time a COMMIT is completed on the master table If Oracle decides that a fastrefresh can be completed, then that operation will take place However, if Oracledecides that the fast refresh cannot be completed successfully, a complete refresh isperformed Considering that a complete refresh could take some time and impact theday-to-day operations, you probably don’t want this to happen, so you will want toavoid using the FORCE/ON COMMIT combination Instead, use the COMPLETEoption or even the FORCE/ON DEMAND option That way, you will be able to planfor a complete refresh and make sure that it occurs after standard operating hours,when the users have gone home

Listing 25.3: Using REFRESH FAST ON DEMAND

CREATE MATERIALIZED VIEW proj_task_mvBUILD IMMEDIATE

REFRESH FAST ON DEMANDAS

SELECTp.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_statusFROM

pa_projects p, pa_tasks tWHERE p.project_id = t.project_id ;

In this example, if you are loading data into the PA_PROJECTS or PA_TASKS tableusing SQL*Loader with the direct-path load option, your Mview will also be updated

CHAPTER 25 • SIMPLE AND ADVANCED REPLICATION

1056

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 toonly one group at a time

For managing refresh groups, Oracle supplies the DBMS_REFRESH package Theprocedures 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 groupCHANGE Changes the interval at which the refresh will occur for the groupDESTROY Deletes the refresh group

MAKE Creates a refresh groupREFRESH Manually refreshes the objects in the refresh groupSUBTRACT 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 whichviews will belong to which refresh groups and what the refresh schedule will be foreach 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,

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 MviewsINST.PROJECTS and OP_STAT (for installed projects and operating status) The nextdate 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 ally exclusive In other words, if you specify the LIST parameter, you cannot specify the TABparameter

mutu-Notice that Listing 25.4 specifies only the name of the refresh group, the Mviewsthat are part of the group, and the refresh schedule The refresh group will use thedefaults 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’sADD 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,

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 Mviewsfrom 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,

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 refresheddaily, 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,

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 berefreshed every Monday

Deleting a Refresh Group

To delete a refresh group, use the DESTROY procedure of the DBMS_REFRESH age, as in the following example:

pack-DBMS_REFRESH.DESTROY ( name IN VARCHAR2 )

EXECUTE dbms_refresh.destroy(projects);

Another way to delete a group is through the IMPLICIT_DESTROY parameter able with the MAKE and CHANGE procedures This will delete the group and then re-create it with the new parameters

avail-Advanced Replication

Advanced replication can support bi-directional transaction capture and replication,and it provides comprehensive replication conflict detection and resolution Oraclehas 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 thereplication 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

CHAPTER 25 • SIMPLE AND ADVANCED REPLICATION

1060

• For multiple-site replication, you now have the ability to create snapshot plates The DBA can create a snapshot (centrally) and distribute it to many dif-ferent sites

tem-TI P To learn more about snapshot templates, see the “Snapshot Concepts and tecture” section in the Oracle documentation

Archi-• To assist with advanced replication setup, Oracle supplies a Replication Managerdeployment wizard that will help with the selection of objects, parameters, andauthorizations

• Offline instantiation is now possible The DBA can package the templates andassociated data onto removable media (such as tape or a CD-R) and ship thisitem to the remote site The remote site can perform a fast refresh after theoffline instantiation is completed

Over the past few years, advanced replication has gained the reputation of beingdifficult, both to set up and administer Here, we’ll provide a step-by-step approach toadvanced replication design and setup The goal is to demonstrate how, with a bit ofeffort, 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 cated to multiple master sites

repli-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 andmaster definition sites

• Set up mandatory parameters in the init.ora file, as listed in Table 25.3