Tài liệu ORACLE8i- P14 ppt

CHAPTER 11 • ORACLE LOGICAL BACKUP AND RECOVERY 514 . importing SYSTEM’s objects into SYSTEM . importing SCOTT’s objects into SCOTT . . importing table “EMP” 14 rows imported Import terminated successfully without warnings. Here, we want to take a table that was exported from the scott schema and import it into the new_scott schema. D:\ORACLE\admin\ORA817\exp>imp system/robert tables=emp fromuser=scott touser=new_scott file=expdmp.dmp ignore=y Import: Release 8.1.7.0.0 - Production on Sun Aug 26 18:11:50 2001 (c) Copyright 2000 Oracle Corporation. All rights reserved. Connected to: Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production With the Partitioning option JServer Release 8.1.7.0.0 - Production Export file created by EXPORT:V08.01.07 via conventional path import done in WE8ISO8859P1 character set and WE8ISO8859P1 NCHAR character set . importing SCOTT’s objects into NEW_SCOTT . . importing table “EMP” 43 rows imported Import terminated successfully without warnings. Row Array Type Commits when Importing By default, Oracle will commit INSERT operations after each table insert. If a large table is being inserted into, a tremendous amount of undo (rollback) will be generated during such operations. In a very large operation, you may generate more undo than there is rollback segment space available, which will cause the import to fail, and the rows imported into the object will be rolled back. To avoid such a problem, Oracle provides the COMMIT parameter with the Import utility. When the COMMIT parameter is set to Y, Oracle will commit the rows as they are being inserted. Oracle writes rows during the import process using an array-type inser- tion process, importing many rows in one array operation. When COMMIT is set to Y, these rows are committed during every array insert. This way, several rows will be inserted at a time and then will be committed. C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 515 Support for Multiple Export Files When you’ve split export files into multiple datafiles, as described in the “Support for Multiple Export Files” section earlier in the chapter, you will need to use the FILESIZE and FILE parameters when importing them. Using the FILESIZE parameter, you define the assigned file size for each import file. (FILESIZE must be set to the same size as it was during the export.) With the FILE parameter, you list each export dump file in a comma-delimited format. An example of an import using multiple export files is shown in Listing 11.12. Listing 11.12: Performing a Multiple Export File Import D:\ORACLE\admin\RECOVER\exp>imp system/robert full=y filesize=100k file=expfull1.dmp, expfull2.dmp ignore=y Import: Release 8.1.6.0.0 - Production on Thu May 3 20:51:50 2001 (c) Copyright 1999 Oracle Corporation. All rights reserved. Connected to: Oracle8i Enterprise Edition Release 8.1.6.0.0 - Production With the Partitioning option JServer Release 8.1.6.0.0 - Production Export file created by EXPORT:V08.01.06 via conventional path import done in WE8ISO8859P1 character set and WE8ISO8859P1 NCHAR character set . importing SYS’s objects into SYS . importing SYSTEM’s objects into SYSTEM . importing SYS’s objects into SYS . importing SYSTEM’s objects into SYSTEM . . Various informational messages appear during the import. . These have been removed in this listing. . . importing SCOTT’s objects into SCOTT . . importing table “BONUS” 0 rows imported . . importing table “DEPT” 4 rows imported . . importing table “DUMMY” 1 rows imported . . importing table “EMP” 14 rows imported . . importing table “SALGRADE” 5 rows imported . . Various informational messages appear during the import. . These have been removed in this listing. . . importing SYSTEM’s objects into SYSTEM THE ORACLE IMPORT UTILITY Oracle Database Administration PART II C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 11 • ORACLE LOGICAL BACKUP AND RECOVERY 516 . importing DBSNMP’s objects into DBSNMP . importing SYSTEM’s objects into SYSTEM . importing OUTLN’s objects into OUTLN . importing SYSTEM’s objects into SYSTEM About to enable constraints Import terminated successfully without warnings. DDL Production with INDEXFILE Using the INDEXFILE parameter of the Import utility produces the DDL required to create the objects contained within the export file. This parameter takes the name of the output file that should be created. This output file will contain the DDL associ- ated with the creation of indexes for the selected schemas. This allows the indexes to be created manually, if that is required. This is handy if you used the SKIP_UNUS- ABLE_INDEXES parameter and you wish to create those indexes after the import. When you use the INDEXFILE parameter, no objects will be imported into the data- base. Listing 11.13 demonstrates the use of this parameter. Listing 11.13: Generating DDL with INDEXFILE D:\ORACLE\admin\RECOVER\exp>imp system/robert full=y filesize=100k file=expfull1.dmp expfull2.dmp indexfile=indexfile.sql Import: Release 8.1.6.0.0 - Production on Thu May 3 21:00:54 2001 (c) Copyright 1999 Oracle Corporation. All rights reserved. Connected to: Oracle8i Enterprise Edition Release 8.1.6.0.0 - Production With the Partitioning option JServer Release 8.1.6.0.0 - Production Export file created by EXPORT:V08.01.06 via conventional path import done in WE8ISO8859P1 character set and WE8ISO8859P1 NCHAR character set . . Various informational messages appear during the import. . These have been removed in this listing. . . . skipping table “BONUS” . . skipping table “DEPT” . . skipping table “DUMMY” . . skipping table “EMP” . . skipping table “SALGRADE” . . Various informational messages appear during the import. C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 517 . These have been removed in this listing. . Import terminated successfully without warnings. The following is example of the output generated by the INDEXFILE parameter: REM CREATE TABLE “SCOTT”.”EMP” (“EMPNO” NUMBER(4, 0) NOT NULL ENABLE, REM “ENAME” VARCHAR2(10), “JOB” VARCHAR2(9), “MGR” NUMBER(4, 0), REM “HIREDATE” DATE, “SAL” NUMBER(7, 2), “COMM” NUMBER(7, 2), “DEPTNO” REM NUMBER(2, 0)) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 LOGGING REM STORAGE(INITIAL 10240 NEXT 10240 MINEXTENTS 1 MAXEXTENTS 121 REM PCTINCREASE 50 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT) REM TABLESPACE “USERS” ; REM 14 rows CONNECT SCOTT; CREATE INDEX “SCOTT”.”IX_EMP_EMPNO” ON “EMP” (“EMPNO” ) PCTFREE 10 INITRANS 2 MAXTRANS 255 STORAGE(INITIAL 10240 NEXT 10240 MINEXTENTS 1 MAXEXTENTS 121 PCTINCREASE 50 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT) TABLESPACE “SYSTEM” LOGGING ; Notice that table-creation DDL, including constraints, is created as well, although these statements are remarked out. You will need to remove the remarks from the out- put file in order to create these objects. THE ORACLE IMPORT UTILITY Oracle Database Administration PART II C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 12 Using Transportable Tablespaces FEATURING: Introducing transportable tablespaces 520 Transporting a tablespace set 522 Sharing a read-only tablespace 528 Transporting partitioned tables 529 Managing transportable tablespaces 531 Using transportable tablespaces for point-in-time recovery 532 C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. O racle8i introduced transportable tablespaces as a new feature for improv- ing the performance of data-movement operations. This feature joins the other features that Oracle has introduced over the years to help DBAs manage large amounts of data: the TRUNCATE command for bulk dele- tions, the APPEND hint and SQL*Loader direct-path loads for insertions, partitions for dividing tables and indexes into smaller sets of data, and parallel processing. This chapter begins with an introduction to the transportable tablespace feature. Then you will learn how to generate a transportable tablespace and copy or move it to a new database. Next, we will discuss using the transportable tablespace feature to share read-only tablespaces and to transport partitioned tables. Finally, we will cover a flexible recovery option that uses temporary tablespaces to allow you to recover table- spaces to a different point in time than that of the rest of the database. Introducing Transportable Tablespaces As you know, an Oracle tablespace is a locally managed division of data within a data- base. The transportable tablespace is like any other tablespace, except that it can be moved or copied from one database to another. When configured and used properly, transportable tablespaces can be an efficient means of moving large amounts of data between databases. For example, you might use transportable tablespaces to copy or move a set of tablespaces, share a read-only tablespace between multiple databases, or quickly rearrange database contents. In pre- vious versions of Oracle, you would need to use SQL*Loader or another tool to accomplish what you can now do with transportable tablespaces. This feature handles most of the necessary verification automatically. Another use of transportable table- spaces is for point-in-time recovery, allowing you to restore a particular tablespace to a point in time that is different from that of the rest of the database. A transportable tablespace contains all the datafiles for the tablespaces being moved, including the metadata. For a tablespace to be transportable, it must meet certain requirements. Also, you need to know what can and cannot be transported. These trans- portable table requirements and capabilities are described in the following sections. Transportable Tablespace Requirements You must have the Oracle8i Enterprise Edition to generate a transportable tablespace set. In order for a tablespace to be transportable, the tablespace and your system must meet the following requirements: • It must be a locally managed tablespace. C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. • It must be self-contained. This means that the objects should depend on objects only from this tablespace, not from other tablespaces. • The source and target database must be on the same operating system. For example, you can transport a tablespace from one NT cluster to another, but not from an NT cluster to database running under a Unix system. • The source and target databases must have the same database block size and must use the same character set. (Although this requirement may change with Oracle9i or a later release.) • The name of tablespace being transported must be unique to the target data- base; that is, the name of the tablespace must not be in use on the destination database. • You must always export primary key constraints. • Both the source and destination database must have a COMPATIBLE parameter of 8.1.0 at a minimum. Several Oracle scripts create the views and packages required for the transportable tablespace feature to work properly. These scripts should have been run during the installation of your database. However, if you have problems using the transportable tablespace feature, you can run the scripts manually. For NT and Sun Solaris systems, you will need to run catplug.sql, which can be found in ORACLE_HOME\rdbms\admin on NT or in $ORACLE_HOME/rdbms/admin on Unix. Refer to your Oracle documentation for the scripts to run to enable transportable tablespaces on other operating systems. What Can Be Transported? With a transportable tablespace, you can transport data, indexes, LOBs, and nested tables. However, if you are transporting LOBs, you must move the BFILE separately, because these are not moved with the LOBs. You cannot transport the following items: • Bitmap indexes • Function-based indexes • Domain indexes • Data containing collectors • Snapshots • Replication • Rollback segments 521 INTRODUCING TRANSPORTABLE TABLESPACES Oracle Database Administration PART II C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 12 • USING TRANSPORTABLE TABLESPACES 522 • Scoped REFs • Oracle 8.0-compatible advanced queues with multiple recipients Transporting a Tablespace Set The steps for creating a transportable tablespace set are to check that the tablespaces are self-contained, make the tablespaces read-only, and then export them. Once you have generated the transportable tablespaces, copying or moving them is a simple matter of importing them and making their data accessible. This section describes the procedures for generating and plugging in transportable tablespaces. Generating a Tablespace Set The key to generating a transportable tablespace set is to produce a self-contained set of tablespaces. The better you organize and distribute your data and index objects among different tablespaces, the easier it is to generate a self-contained set of tablespaces. A self-contained set of tablespaces does not contain any references that point out- side the set. Any of the following situations would violate this rule: • A table not included in the tablespace being transported has an index associated with that table. • A partitioned table is not fully contained in the set of tablespaces. (However, you can transport a subset of a partitioned table by first moving the data you want to transport into a new table, as described in the “Transporting Partitioned Tables” section later in this chapter.) • A table inside the set of tablespaces contains a LOB column that points to a LOB outside the set of tablespaces. • A referential integrity constraint on a table refers to a parent table that is not in the set of tablespaces. (However, if you do not need to maintain the relation- ship, you can choose not to include referential integrity constraints when you export the tablespaces.) For example, suppose that you want to move your PRODUCT table from your pro- duction database to your development database. If you want to transport the PROD- UCT table, you will also need to transport all of the tables that are in the same tablespace as the PRODUCT table. First, consider the indexes associated with the tables. You might transport all tablespaces that contain indexes that are attached to C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. 523 these tables, or you may transport only the tables and re-create the indexes when the data is plugged into the development instance. Other items to keep in mind are the referential integrity constraints and other sup- porting objects of the PRODUCT table and other tables in this tablespace. If all of the supporting objects of the tables are already in existence on the target database, you do not need to transport the supporting objects. As with indexes, you can transport all of the referential integrity constraints, or you can rebuild them after you plug in the tablespace. If you choose to include the referential integrity constraints, keep in mind that the objects needed to keep the constraints intact will increase the size of the transportable tablespace set. This is because it will contain the tables necessary to maintain and check the constraints, as well at the metadata for loading on the receiving end. Excluding the referential integrity constraints will simplify and speed up the move- ment of the tablespace to its destination database. If you design your database with these operations in mind, objects will be distrib- uted among tablespaces in anticipation of their later movement among databases. The design decisions you make up front (which tablespaces you create and what tables are in those tablespaces) can significantly impact your ability to use trans- portable tablespaces effectively. Checking the Transportable Tablespace Oracle8i provides a tool that makes it easy to determine if a tablespace is self-contained: the TRANSPORT_SET_CHECK procedure of the DBMS_TTS package. Here is the syntax of this procedure: DBMS_TTS.TRANSPORT_SET_CHECK ( ts_list IN VARCHAR2, incl_constraints IN BOOLEAN); As you can see, this procedure takes two input parameters: • The TS_LIST parameter is a list of the tablespaces being moved, separated by commas. • The INCL_CONSTRAINTS parameter is a Boolean flag. Set this parameter to TRUE to move the referential integrity constraints with the tablespaces, or set it to FALSE if you do not want to include the referential integrity constraints. The following is an example of using the DBMS_TTS.TRANSPORT_SET_CHECK procedure to check the MDB_DATA and MDB_INDEXES tablespaces for movement, without including referential integrity constraints: SQL> EXECUTE DBMS_TTS.TRANSPORT_SET_CHECK (‘mdb_data,mdb_indexes’,’false’); TRANSPORTING A TABLESPACE SET Oracle Database Administration PART II C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark. CHAPTER 12 • USING TRANSPORTABLE TABLESPACES 524 If Oracle finds any violations in the specified set, it will populate the TRANSPORT_ SET_VIOLATIONS data dictionary view. If there are no violations, the view will be empty. Use this query to check for violations: SQL> SELECT * FROM transport_set_violations; The TRANSPORT_SET_VIOLATIONS view will not be created until you run the TRANSPORT_SET_CHECK procedure for the first time. This view will be accessible only to the schema in which it is created, since no synonyms are created. This view will also be cleared when the user who created it logs out. So, if you want to keep the results, you will need to save them somewhere. NOTE Unfortunately, object references, such as REFs, are not checked for validity by the TRANSPORT_SET_CHECK routine. You will need to check the REFs manually (where they are stored) to see if they are self-contained in the tablespace. You should also note the names of the accounts that own objects in the trans- portable tablespace set. Each object’s owner will come across with the tablespace, and these owners will need to exist in the destination database before you plug in the transportable tablespace. Remember that the transportable tablespace cannot have the same name as a table- space that exists on the destination database. Use the DBA_TABLESPACES view to check if the tablespace already exists on the destination database. Also, the source and target databases must use the same character set for the table- space transport operation to be successful. You can query the PROPS$ table to check the database’s character set. The NLS_CHARACTERSET column shows the database character set, and the NLS_NCHAR_CHARACTERSET column shows the NCHAR char- acter set. Making the Tablespaces Read-Only After you have checked the tablespaces and resolved any violations, you need to make the tablespaces read-only, as shown here: SQL> ALTER TABLESPACE mdb_data READ ONLY; SQL> ALTER TABLESPACE mdb_indexes READ ONLY; Exporting the Metadata Your next step is to export the metadata for the tablespace, using the Export utility’s TRANSPORT_TABLESPACE and TABLESPACES commands. Oracle’s EXP command with a tablespace exports only the data dictionary for the tablespace contents, not the C opyright ©2002 SYBEX, Inc., Alameda, CA www.sybex.com Please purchase PDF Split-Merge on www.verypdf.com to remove this watermark.