Tài liệu ORACLE8i- P14 ppt

Next, we will discuss using the transportable tablespace feature toshare read-only tablespaces and to transport partitioned tables.. • Scoped REFs• Oracle 8.0-compatible advanced queues

CHAPTER 11 • ORACLE LOGICAL BACKUP AND RECOVERY

514

importing SYSTEM’s objects into SYSTEM importing SCOTT’s objects into SCOTT importing table “EMP” 14 rowsimported

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=empfromuser=scott touser=new_scott file=expdmp.dmp ignore=yImport: 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 optionJServer Release 8.1.7.0.0 - Production

Export file created by EXPORT:V08.01.07 via conventional pathimport done in WE8ISO8859P1 character set and WE8ISO8859P1NCHAR character set

importing SCOTT’s objects into NEW_SCOTT importing table “EMP” 43 rowsimported

Import terminated successfully without warnings

Row Array Type Commits when Importing

By default, Oracle will commit INSERT operations after each table insert If a largetable is being inserted into, a tremendous amount of undo (rollback) will be generatedduring such operations In a very large operation, you may generate more undo thanthere is rollback segment space available, which will cause the import to fail, and therows imported into the object will be rolled back To avoid such a problem, Oracleprovides the COMMIT parameter with the Import utility

When the COMMIT parameter is set to Y, Oracle will commit the rows as they arebeing 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 beinserted at a time and then will be committed

Support for Multiple Export Files

When you’ve split export files into multiple datafiles, as described in the “Support forMultiple Export Files” section earlier in the chapter, you will need to use the FILESIZEand FILE parameters when importing them Using the FILESIZE parameter, you definethe assigned file size for each import file (FILESIZE must be set to the same size as itwas during the export.) With the FILE parameter, you list each export dump file in acomma-delimited format An example of an import using multiple export files isshown in Listing 11.12

Listing 11.12: Performing a Multiple Export File Import

D:\ORACLE\admin\RECOVER\exp>imp system/robert full=yfilesize=100k file=expfull1.dmp, expfull2.dmp ignore=yImport: 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 - ProductionWith the Partitioning option

JServer Release 8.1.6.0.0 - ProductionExport file created by EXPORT:V08.01.06 via conventional pathimport 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

Oracle Database Administration

P A R T

II

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 SYSTEMAbout to enable constraints

Import terminated successfully without warnings

DDL Production with INDEXFILE

Using the INDEXFILE parameter of the Import utility produces the DDL required tocreate the objects contained within the export file This parameter takes the name ofthe 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 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

SKIP_UNUS-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.sqlImport: 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 - ProductionWith the Partitioning option

JServer Release 8.1.6.0.0 - ProductionExport file created by EXPORT:V08.01.06 via conventional pathimport 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.

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 LOGGINGREM STORAGE(INITIAL 10240 NEXT 10240 MINEXTENTS 1 MAXEXTENTS 121REM PCTINCREASE 50 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT)REM TABLESPACE “USERS” ;

REM 14 rowsCONNECT SCOTT;

CREATE INDEX “SCOTT”.”IX_EMP_EMPNO” ON “EMP” (“EMPNO” ) PCTFREE 10INITRANS 2 MAXTRANS 255 STORAGE(INITIAL 10240 NEXT 10240 MINEXTENTS 1MAXEXTENTS 121 PCTINCREASE 50 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOLDEFAULT) TABLESPACE “SYSTEM” LOGGING ;

Notice that table-creation DDL, including constraints, is created as well, althoughthese statements are remarked out You will need to remove the remarks from the out-put file in order to create these objects

Oracle Database Administration

P A R T

II

CHAPTER 12

Using Transportable Tablespaces

F E A T U R I N G : Introducing transportable

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

O other features that Oracle has introduced over the years to help DBAs

manage large amounts of data: the TRUNCATE command for bulk tions, the APPEND hint and SQL*Loader direct-path loads for insertions, partitions fordividing tables and indexes into smaller sets of data, and parallel processing

dele-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 toshare read-only tablespaces and to transport partitioned tables Finally, we will cover aflexible 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 efficientmeans of moving large amounts of data between databases For example, you mightuse transportable tablespaces to copy or move a set of tablespaces, share a read-onlytablespace between multiple databases, or quickly rearrange database contents In pre-vious versions of Oracle, you would need to use SQL*Loader or another tool toaccomplish what you can now do with transportable tablespaces This feature handlesmost 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 certainrequirements 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 tablespaceset In order for a tablespace to be transportable, the tablespace and your system mustmeet the following requirements:

• It must be a locally managed tablespace

• It must be self-contained This means that the objects should depend on objectsonly from this tablespace, not from other tablespaces.

• The source and target database must be on the same operating system Forexample, you can transport a tablespace from one NT cluster to another, but notfrom an NT cluster to database running under a Unix system

• The source and target databases must have the same database block size andmust use the same character set (Although this requirement may change withOracle9i or a later release.)

• The name of tablespace being transported must be unique to the target base; that is, the name of the tablespace must not be in use on the destinationdatabase

data-• 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 transportabletablespace feature to work properly These scripts should have been run during theinstallation of your database However, if you have problems using the transportabletablespace 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 documentationfor 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 nestedtables 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:

INTRODUCING TRANSPORTABLE TABLESPACES

Oracle Database Administration

P A R T

II

• 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 tablespacesare self-contained, make the tablespaces read-only, and then export them Once youhave generated the transportable tablespaces, copying or moving them is a simplematter of importing them and making their data accessible This section describes theprocedures 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 oftablespaces The better you organize and distribute your data and index objects amongdifferent 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 side the set Any of the following situations would violate this rule:

out-• A table not included in the tablespace being transported has an index associatedwith 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 youwant to transport into a new table, as described in the “Transporting PartitionedTables” section later in this chapter.)

• A table inside the set of tablespaces contains a LOB column that points to a LOBoutside the set of tablespaces

• A referential integrity constraint on a table refers to a parent table that is not inthe set of tablespaces (However, if you do not need to maintain the relation-ship, you can choose not to include referential integrity constraints when youexport the tablespaces.)

For example, suppose that you want to move your PRODUCT table from your 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 sametablespace as the PRODUCT table First, consider the indexes associated with thetables You might transport all tablespaces that contain indexes that are attached to

sup-If you choose to include the referential integrity constraints, keep in mind that theobjects needed to keep the constraints intact will increase the size of the transportabletablespace set This is because it will contain the tables necessary to maintain andcheck the constraints, as well at the metadata for loading on the receiving end.

Excluding the referential integrity constraints will simplify and speed up the ment of the tablespace to its destination database

move-If you design your database with these operations in mind, objects will be uted among tablespaces in anticipation of their later movement among databases

distrib-The design decisions you make up front (which tablespaces you create and whattables 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 bycommas

• The INCL_CONSTRAINTS parameter is a Boolean flag Set this parameter toTRUE 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_CHECKprocedure 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

P A R T

II

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 beempty 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 theTRANSPORT_SET_CHECK procedure for the first time This view will be accessibleonly to the schema in which it is created, since no synonyms are created This viewwill also be cleared when the user who created it logs out So, if you want to keep theresults, you will need to save them somewhere

NOTE Unfortunately, object references, such as REFs, are not checked for validity by theTRANSPORT_SET_CHECK routine You will need to check the REFs manually (where theyare 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 portable tablespace set Each object’s owner will come across with the tablespace, andthese owners will need to exist in the destination database before you plug in thetransportable tablespace

trans-Remember that the transportable tablespace cannot have the same name as a space that exists on the destination database Use the DBA_TABLESPACES view tocheck if the tablespace already exists on the destination database

Also, the source and target databases must use the same character set for the space transport operation to be successful You can query the PROPS$ table to checkthe database’s character set The NLS_CHARACTERSET column shows the databasecharacter set, and the NLS_NCHAR_CHARACTERSET column shows the NCHAR char-acter set

table-Making the Tablespaces Read-Only

After you have checked the tablespaces and resolved any violations, you need to makethe 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’sTRANSPORT_TABLESPACE and TABLESPACES commands Oracle’s EXP commandwith a tablespace exports only the data dictionary for the tablespace contents, not the

physical data The following example exports the MDB_DATA and MDB_INDEXEStablespaces, and uses the FILE parameter to place the export contents in themdb_database.dmpand mdb_indexes.dmp files:

SQL> EXP transport_tablespace=y tablespaces=mdb_data, mdb_indexesfile=mdb_database.dmp, mdb_indexes.dmp

By default, constraints, grants, and triggers are included in the export If you want

to exclude any of these, you will need to specify the CONSTRAINTS, GRANTS, andTRIGGERS parameters appropriately Here is an example of exporting the metadatawithout constraints or triggers:

SQL> EXP transport_tablespace=y tablespaces=mdb_data, mdb_indexesconstraints=n grants=y triggers=n

Notice that this example does not specify the FILE parameter In this case, the exportcontents will go into a file named expdat.dmp, by default

When prompted for a username, you must enter SYS AS SYSDBA (using the priate syntax for your operating system) Only the SYS user can transport a tablespace,because the stored procedures required to transport a tablespace are owned by SYS

appro-WARNING If you export triggers, they will be exported without a validity check Anyinvalid triggers will cause compilation errors during the import

If you want to be prompted for the various parameters, just enter the EXP mand followed by your username and password Then the Export utility will display aseries of questions on how you want the export to proceed, like this:

com-SQL> EXP username/password

FULL=yFILE=mdb_test.dmpGRANTS=y

INDEXES=yCONSISTENT=ySee Chapter 11 for details on using the Export utility, including its various parametersand modes

Copying the Tablespace Datafiles

Now you can copy the tablespace datafiles to a separate area for movement All youneed to do is copy the datafiles to a location that the destination database will be able

TRANSPORTING A TABLESPACE SET

Oracle Database Administration

P A R T

II

to access You can use any command available to the operating system, such as copy,

cp, or FTP

If the source and destination databases can access the file system on which thedatafiles reside, this step is not required This is because both databases can access thelocation where the export file resides

TIP You can also copy tablespace datafiles to CD-Rs Then they can be added to the get database without actually moving them to the hard disk

tar-Plugging in the Transportable Tablespace Set

Your transportable tablespace files are now moved to an area that is accessible to thetarget location To “plug in” the transportable tablespace set, you simply need toimport it and then put the tablespaces back into read/write mode

Importing the Tablespace

To move the transportable tablespace set into the target database, you use Oracle’sImport utility to bring in the exported metadata You can simply specify the datafilesthat were part of the EXP command used to export the desired tablespaces Here is anexample of using the IMP command to import the data exported in the previous section:SQL> IMP transport_tablespace=y datafiles=(mdb_data, mdb_indexes)

As with the EXP command, you can also simply issue the IMP command followed

by your username and password Then the Import utility will prompt you for theparameters, as follows:

SQL> IMP username/password

FILE=mdb_test.dmpGRANTS=y

FROMUSER=scottTABLES=(project,task)Another way to import the data is to create a parameter file containing each param-eter and its setting, and save it under an appropriate name (mdb_database.txt in thisexample), like this:

TRANSPORT_TABLESPACE=YDATAFILES=(mdb_data,mdb_indexes)FILE=mdb_test.dmp

LOG=mdb_test.log

Then run the Import utility using the PARFILE parameter (which imports the datausing the settings in the specified parameter file):

IMP parfile=mdb_database.txtWhen prompted for a username, enter SYS AS SYSDBA

WARNING There must be a corresponding user ID in the target database for all theowners of objects in the transported tablespace; otherwise, the import will fail

TRANSPORT_TABLESPACE and DATAFILES are required parameters when youimport transportable tablespaces Table 12.1 describes several optional Import utilityparameters that you can use with transportable tablespaces See Chapter 11 for details

on the general use of Oracle’s Import utility

TABLE 12.1: OPTIONAL IMPORT PARAMETERS FOR TRANSPORTABLE TABLESPACES

Parameter Description

TABLESPACES A list of tablespaces to be imported The list is surrounded with

quota-tion marks, and each tablespace is separated with a comma

TTS_OWNERS A list of users who own the data in the transportable tablespace set

FROMUSER The owner of the objects in the source database This parameter can be

used with TOUSER to change ownership of objects when they areimported into the target database

TOUSER The owner of the objects in the target database This parameter can be

used with FROMUSER to change ownership of objects when they areimported into the target database

Making the Data Accessible

Upon completion of the import, check the log file to ensure that no errors haveoccurred If the import was successful, you will now want to place the tablespacesback in read/write mode in their current database, so they will be accessible Use theALTER TABLESPACE command to switch modes, as follows:

SQL> ALTER TABLESPACE mdb_data READ WRITE;

SQL> ALTER TABLESPACE mdb_indexes READ WRITE;

TRANSPORTING A TABLESPACE SET

Oracle Database Administration

P A R T

II

Backing Up the Control Files

After you have successfully transported the tablespace set to a new location, it’s agood idea to back up the control files, for documentation purposes Back up the con-trol files for both the target and source databases using the following command:SQL> ALTER DATABASE BACKUP CONTROLFILE TO TRACE;

Moving Tablespaces

If you want to move the tablespace, rather than just copy it, you simply remove itfrom its original location after completing the transport process Drop the tablespaceyou moved from the source database, as shown here:

SQL> ALTER TABLESPACE mdb_data OFFLINE;

SQL> DROP TABLESPACE mdb_data INCLUDING CONTENTS;

Sharing a Read-Only Tablespace

Sharing a read-only tablespace among multiple databases is useful when you have aseries of tables that never or hardly ever change, such as tables that hold information

on states and cities By taking this approach, you can save space on multiple bases, because you will have only one set of these tables in existence You will also beable to save time and effort in backup and recovery operations and other mainte-nance tasks

data-To set up a read-only tablespace to share, take the following steps:

• Select a source database that owns the tablespace

• Generate a transportable tablespace set from the source database (as described inthe “Generating a Tablespace Set” section earlier in the chapter)

• Plug the tablespace set into each of the target databases, using the proceduresdescribed in the preceding “Plugging in the Transportable Tablespace Set” sec-

tion, except do not put the tablespace into read/write mode; leave the tablespace

in read-only mode

WARN I NG Do not take the tablespace out of read-only mode in any of the bases, because doing so could corrupt the tablespace If at a later time you drop the trans-ported tablespace from all but one of the databases, you can put it in read/write mode

Transporting Partitioned Tables

Partitioned tables are as easy to transport as nonpartitioned tables The only ence in the procedures for transporting tablespaces described earlier in this chapter isthat you will need to remember to identify each and every partition for the tablespaceyou want to transport

differ-WARNING If you forget to move a partition that you wanted, you will no longer haveaccess to that data when the transport is complete

If you don’t want to transport all of the partitions, there is a way to transport onlysome of them For example, suppose that you have a large table with multiple parti-tions, and you want to use the transportable tablespace feature to move only one par-tition’s worth of data To move just selected data, in the source tablespace, create atable for the data you want to move (thus creating a table with no partitions) Forexample, you can use a CREATE TABLE AS SELECT command with a WHERE clausethat selects only the data you want from one or more of the partitions and puts it intothe new table Optionally, you can create indexes for the new table, in either the newtablespace or in a separate, isolated one

TI P Parallel processing will speed up the process of querying the partitioned table toextract the data and putting it into a new table See Chapter 18 for details on parallel pro-cessing in Oracle

Remember that the tablespace being moved needs to be in read-only mode Placethe tablespace in read-only mode as follows:

SQL> ALTER TABLESPACE trans_tablespace READ ONLY;

Next, insert the data into the target tables on the new database You can do thiswith INSERT AS SELECT command or, if the target table is partitioned, by using theEXCHANGE PARTITION option to make the newly plugged-in table a partitionwithin the target table Commit the inserted data, and verify that everything worked

Finally, back up the control files for the source and the target database

Be aware that the transportable tablespace exists only until you have completedthe move and stored the data in the source database, and it may possibly exist onlytemporarily in the target database as well Each time you move a partitioned table,

TRANSPORTING PARTITIONED TABLES

Oracle Database Administration

P A R T

II

you will need to decide if you wish to move all of the partitions or only some of thepartitions You will need to identify the data that is going to be moved and decide ifyou will be using the EXCHANGE PARTITION option or the CREATE TABLE andINSERT commands to fulfill your needs Unless you use the EXCHANGE PARTITIONoption, the tables you use to store the data during the data transfer are not consideredpart of the permanent database until you issue a COMMIT command after theINSERT command is complete.

N OTE Following the procedures outlined here ensures that the files and databaseobjects you use to support data movement are separate and independent from the rest ofthe database Each of the procedures requires the preceding process to be successful Youmay want to have error checking in place to ensure the success of each process

The result of these operations is a database that can support the storage of largedata volumes (via partitions), as well as the movement of large data volumes (viatransportable tablespaces)

Transportable Tablespaces and the Data Warehouse

The transportable tablespace feature can help DBAs meet the ever-growing need foraccurate and up-to-date data on a 24/7 basis Along with need for 24/7 availability isthe challenge of managing the great amount of data that is required to keep everybodyhappy and functional The data warehouse environment is probably one of the mostdemanding in terms of data updates and volume Currently, we use the old standby ofthe Export and Import utilities and REFRESH command to meet these demands Movingmany gigabytes from an OLTP database to the data warehouse through the traditionalstaging tables is time-consuming By combining the present methods with the newtransportable tablespace feature, you can bring the OLTP database up faster

The combination of partitioning with transportable tablespaces makes it much fasterand easier to populate a data warehouse or data mart You can now design the propertablespace and transport the tablespaces required to update the destination, regainingmuch of the time spent using the existing methods of exporting and importing orunloading and loading Transporting a tablespace involves only copying datafiles and

in the source table to hold the next quarter’s data.

Of course, using the transportable tablespace feature requires some design on yourpart However, you will likely see the benefit of moving datafiles and metadata in thismanner, instead of using SQL scripts

Managing Transportable Tablespaces

As with most database features, transportable tablespaces require some management

Following are some of the tasks:

• Monitor the size of the datafiles to ensure adequate free space for the new tablespace

• You may need to restrict AUTOEXTEND to control the datafiles’ sizes

• Because the source and target databases must have the same database block size,you may want to implement a standard database block size for all the databasesyou set up Remember that you can establish block size only when the database

MANAGING TRANSPORTABLE TABLESPACES

Oracle Database Administration

P A R T

II

Using Transportable Tablespaces for Point-in-Time Recovery

Tablespace point-in-time recovery (TSPITR) is a convenient way to quickly recoverany non-SYSTEM tablespaces to a particular point in time that is different from thepoint in time of the rest of the database When you use this option, you are recover-ing a whole tablespace, rather than an object in the tablespace

Simply put, you use the transportable tablespace feature to move the needed

table-spaces from the clone database to the recovery database, known as the primary

data-base All of the requirements that apply to transportable tablespaces (outlined in the

“Transportable Tablespace Requirements” section earlier in this chapter) apply toTSPITR as well

For the TSPITR process, you need two sets of items:

• The recovery set, which includes the tablespace or tablespaces that are in need of

recovery

• The auxiliary set, which includes the other items that assist in the recovery, such

as the backup control file, SYSTEM tablespaces, datafiles containing rollbacksegments, and temporary tablespace

Recovering a tablespace when the primary and clone databases are on differentcomputers requires the following steps:

1 Determine which objects could be lost.

2 Resolve any dependencies.

3 Prepare the primary database.

4 Create the clone parameter file.

5 Prepare the clone database.

6 Export the tablespaces.

7 Import the tablespaces.

The following sections provide more details on accomplishing these steps

Determining Which Objects Could Be Lost

You will need to query the TS_PITR_OBJECTS_TO_BE_DROPPED view to see if anyobjects have been created on the primary database after the point in time of theobjects on the clone database This can be accomplished with the following query:

SELECTOwner, name, tablespace_name, to_char(creation_time, ‘YYYY-MM-DD:HH24:MI:SS’)FROM ts_pitr_objects_to_be_dropped

WHERE tablespace_name IN (‘list of tablespace to recover’)AND creation_time > to_date(date and time for recovery)ORDER BY

tablespace_name, creation_time;

Resolving Dependencies

On the primary database, use the TS_PITR_CHECK view to check for objects that arerelated and overlap the boundaries of the recovery set (If the view is empty, you canproceed to the next step.) The following is a query you can use to assist with thisprocess

SELECT *FROM sys.ts_pitr_checkWHERE (tablespace_name IN (‘list of tablespaces’)AND tablespace_name2 NOT IN (‘list of tablespaces’))

OR (tablespace_name NOT IN (‘list of tablespaces’)AND tablespace_name2 IN (‘list of tablespaces’));

TIP Given the size of some of the columns in the TS_PITR_CHECK view, you may want

to format the columns for readability

Remember that you will need to have a tablespace that is self-contained Also, ifyou are transporting only one partition of a partitioned table, you will need to create

a stand-alone table of that partition and use it as the recovery table You will want tokeep track of all of the steps you take to resolve dependencies, so you will be able tore-create the relationships on the primary database if required

USING TRANSPORTABLE TABLESPACES FOR POINT-IN-TIME RECOVERY

Oracle Database Administration

P A R T

II

Preparing the Primary Database

To prepare the primary database for receipt of the data, follow these steps:

1 Execute the ALTER SYSTEM ARCHIVE LOG CURRENT command to archive the

current redo logs

2 Execute the ALTER ROLLBACK SEGMENT segment_name OFFLINE command to

take any rollback segments in the recovery set offline

3 If you need to recover a lot of datafiles, execute the ALTER TABLESPACE

table-space_name_to_recover OFFLINE FOR RECOVER command to improve the

recov-ery performance

Creating the Clone Parameter File

You can create the clone parameter file by copying the primary file or by creating anew init.ora file You will need to set the following parameters:

Preparing the Clone Database

To prepare the clone database for startup, follow these steps:

1 Put the recovery set and the auxiliary set in a location that is different from that

of the primary database

2 Execute the ALTER DATABASE MOUNT CLONE DATABASE command to mount

the clone database

3 Execute the ALTER DATABASE DATAFILE ‘datafile_name’ ONLINE command to

bring the recovery and auxiliary set files online