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.