Professional Documents
Culture Documents
Goal
Fix
How to move a database using transportable tablespaces:
Assumptions:
Metadata residing in the system or sysaux tablespaces:
System-owned objects in the system or sysaux tablespaces:
Databases using text indexes and spatial indexes
Text:
Spatial:
1. Stop materialized view refresh jobs:
2. Check endianness:
3. Create list of tablespaces and par files
A. Run this script to list all of the tablespaces that are available to be
transported and their block sizes:
B. Ensure you have a valid directory for datapump:
C. Run the following script to create TTS export, and TTS import Data Pump
parameter files.
4. Check for user-created objects in the system and sysaux tablespaces:
5. Create the 'Create user script':
6. Check containment:
7. Export source metadata:
8. Check for tablespaces using a non-default block size. These tablespaces will
need a db_nK_cache_size parameter at the target database to support the
tablespace.
9. Create tablespace scripts:
A. This script creates the tts_tsro.sql script from the source database. Use this
script to set all tablespaces to be transported to READ ONLY mode.
B. Run script tts_tsro.sql to set the tablespaces to be transported to read only
mode.
C. This script creates the tts_tsrw.sql script. Use script tts_tsrw.sql later in
step 13 to set all tablespaces to READ WRITE mode after the transport
tablespace import process.
D. Save script tts_tsrw.sql to be run on the destination database later in step
13.
10. Export the tablespaces:
11. Endianness conversion:
12. Copy the following files to a place that is accessible to the destination
database.
13. Add the db_32k_cache_size parameter to the target database to support the
BIG_DATA tablespace being transported from step 8.
APPLIES TO:
Oracle Database - Enterprise Edition - Version 10.1.0.2 to 11.2.0.0 [Release 10.1 to
11.2]
Information in this document applies to any platform.
GOAL
Explains how to move a database using Transportable Tablespaces.
FIX
How to move a database using transportable tablespaces:
We will also need to ensure that the users, who currently own these objects in
the source database, are created in the destination database prior to the
tablespaces being moved. There is a script provided to do this. An alternative
would be to use the 'Remap_Schema' parameter to put the objects into a
different schema.
Assumptions:
This examples also assumes you want to transport all user tablespaces to the
new database and that there is a destination database already created. If there
are tablespaces that you do not wish to transport, then it will be your
responsibility to properly edit the 'par' files to exclude the unwanted tablespaces
and their associated datafiles.
Note 861911.1 Spatial Indexes And Transportable Tablespaces In The 11gR2 Release
1. Stop materialized view refresh jobs:
Stop all the mview refresh jobs. Once the data is imported to the new database , you
should check the refresh jobs. For the mviews that don't refresh, you can drop the
mview with 'Preserve Table' and then recreate the mview 'on prebuilt table' to enable
the job again.
drop materialized view <mview_name> preserve table;
Create materialized view <mview_name> on prebuilt table;
Note: You must lock the master table or guarantee there are no changes to it from the
time you stop the mview refresh jobs until the time you refresh it again in the new db.
You should also stop all refresh jobs and make sure the mviews are up to date before
the tts process is started.
2. Check endianness:
Determine the endian format of both the source and destination databases with the
following queries. If the endianess is different, the RMAN CONVERT DATAFILE must be
used to convert the datafiles to the endian format of the destination database.
SQL> connect / as sysdba
SQL> -- This list taken from 11.2.0.3. Older RDBMS versions may
contain fewer platforms.
SQL> -- The list will not contain the platform info for the database
from which you are running the query.
SQL> col platform_name for a35
SQL> select * from v$transportable_platform order by platform_id;
PLATFORM_ID
----------1
2
3
4
5
6
7
8
9
10
11
12
PLATFORM_NAME
----------------------------------Solaris[tm] OE (32-bit)
Solaris[tm] OE (64-bit)
HP-UX (64-bit)
HP-UX IA (64-bit)
HP Tru64 UNIX
AIX-Based Systems (64-bit)
Microsoft Windows IA (32-bit)
Microsoft Windows IA (64-bit)
IBM zSeries Based Linux
Linux IA (32-bit)
Linux IA (64-bit)
Microsoft Windows x86 64-bit
ENDIAN_FORMAT
-------------Big
Big
Big
Big
Little
Big
Little
Little
Big
Little
Little
Little
13
14
15
16
17
18
19
20
21
Little
Little
Little
Big
Little
Big
Little
Little
Little
SQL> -- You can easily find the platform info for the database running
the above query by using the following SQL:
SQL> SELECT tp.platform_id,substr(d.PLATFORM_NAME,1,30), ENDIAN_FORMAT
FROM V$TRANSPORTABLE_PLATFORM tp, V$DATABASE d
WHERE tp.PLATFORM_NAME = d.PLATFORM_NAME;
The output of the query can change with version. So please use the query above to find
the current support platforms. In previous releases, the transportable tablespace
feature allowed the transfer between platforms of the same architecture only.
At the source database:
3. Create list of tablespaces and par files
A. Run this script to list all of the tablespaces that are available to be transported
and their block sizes:
select tablespace_name, block_size
from dba_tablespaces
where tablespace_name not in ('SYSTEM','SYSAUX')
and contents = 'PERMANENT';
NOTE: You will need to review the results of this query and verify the block size for all
tablespaces that you are going to Transport. If there are any using a non-standard
block size, you will need to add to the target database the init
parameter, db_nK_cache_size (where 'n' is the desired block size), to support the
transported tablespace. This must be done prior to the TTS import.
B. Ensure you have a valid directory for datapump:
Run the following query to determine the location of DATA_PUMP_DIR:
SELECT * FROM DBA_DIRECTORIES WHERE DIRECTORY_NAME = 'DATA_PUMP_DIR';
OWNER
DIRECTORY_NAME
DIRECTORY_PATH
---------- ---------------- ----------------------------------SYS
DATA_PUMP_DIR
C:\app\orauser\admin\orawin\dpdump\
You can also create a directory to a different location if you like and grant rights to the
directory to the user running the exports/imports using the following syntax:
Create directory DATA_PUMP_DIR as
/usr/apps/datafiles;
You must move the identified objects to a user tablespace prior to beginning the
transport process so the objects can be transported by TTS. Alternatively, you can
move the objects separately with Data Pump or you can manually re-create them after
performing the database upgrade.
5. Create the 'Create user script':
Run the following commands at the source database to generate a 'create user' script
to be used at the destination database to create the users prior to the TTS import. A
subsequent metadata import, run after the TTS, will reset these accounts to their
original passwords and default tablespaces.
connect / as sysdba
spool def_Tbs.sql
select 'CREATE USER '||username||' IDENTIFIED BY test DEFAULT
TABLESPACE SYSTEM;' from dba_users where username not in ('SYS',
'SYSTEM',
'DBSNMP','SYSMAN','OUTLN','MDSYS','ORDSYS','EXFSYS','DMSYS','WMSYS','C
TXSYS','ANONYMOUS','XDB','ORDPLUGINS','OLAPSYS','PUBLIC');
spool off
6. Check containment:
Run this script for the DBMS_TTS.TRANSPORT_SET_CHECK function to perform the
self-containment check for the list of tablespaces to be transported.
connect / as sysdba
declare
checklist varchar2(4000);
i number := 0;
begin
for ts in
(select tablespace_name
from dba_tablespaces
where tablespace_name not in ('SYSTEM','SYSAUX') and contents =
'PERMANENT')
loop
if (i=0) then
checklist := ts.tablespace_name;
else
checklist := checklist||','||ts.tablespace_name;
end if;
i := 1;
end loop;
dbms_tts.transport_set_check(checklist,TRUE,TRUE);
end;
/
select * from transport_set_violations;
Any violations listed must be resolved before the tablespaces are transportable. See
note
Note.114915.1 Ext/Pub Using Dbms_tts.transport_set_check Results in Entry in
Transport_set_violations:
If the tablespace (in this case BIG_DATA )with a 32k block size is being transported,
you will need to create a 32k cache in the target database. We will do this in Step 13.
9. Create tablespace scripts:
A. This script creates the tts_tsro.sql script from the source database. Use this
script to set all tablespaces to be transported to READ ONLY mode.
connect / as sysdba
set heading off
feedback off
trimspool on
linesize 500
spool tts_tsro.sql
prompt /* =================================== */
prompt /* Make all user tablespaces READ ONLY */
prompt /* =================================== */
select 'ALTER TABLESPACE ' || tablespace_name || ' READ ONLY;' from
dba_tablespaces
where tablespace_name not in ('SYSTEM','SYSAUX')
and contents = 'PERMANENT';
spool off
C. This script creates the tts_tsrw.sql script. Use script tts_tsrw.sql later in step
13 to set all tablespaces to READ WRITE mode after the transport tablespace
import process.
connect / as sysdba
set heading off
feedback off
trimspool on
linesize 500
spool tts_tsrw.sql
prompt /* ==================================== */
prompt /* Make all user tablespaces READ WRITE */
prompt /* ==================================== */
select 'ALTER TABLESPACE ' || tablespace_name || ' READ WRITE;' from
dba_tablespaces
where tablespace_name not in ('SYSTEM','SYSAUX')
and contents = 'PERMANENT';
spool off
D. Save script tts_tsrw.sql to be run on the destination database later in step 13.
10. Export the tablespaces:
Invoke the Data Pump export utility on the host system and specify which tablespaces
are in the transportable set.
SQL>HOST
$ EXPDP system/<password> parfile=dp_ttsexp.par
Use the RMAN CONVERT TABLESPACE command to convert the datafiles into a
temporary location on the source platform. In this example, assume that the temporary
location, directory /tmp, has already been created. The converted datafiles are assigned
names by the system. If you have a large amount of tablespaces to convert, you can
issue multiple 'CONVERT TABLESPACE' commands.
--Example
RMAN> CONVERT TABLESPACE sales_1,sales_2
2> TO PLATFORM 'Microsoft Windows IA (32-bit)'
3> FORMAT '/tmp/%U';
RMAN> exit
Recovery Manager complete.
See Also:
Oracle Database Backup and Recovery Reference for a description of the RMAN
CONVERT command
12. Copy the following files to a place that is accessible to the destination
database.
dp_ttsimp.par import parameter file
def_Tbs.sql
dp_full.dmp
tts_tsrw.sql
If your datafiles are on ASM, you will need to use Dbms_file_transfer to move them to
the destination database as seen in note:
How to Create Transportable Tablespaces Where the Source and Destination are ASMBased (Doc ID 394798.1)
Copy the datafiles of the tablespaces to a place that is accessible to the destination
database. To accomplish this, do one of the following:
If no endianness conversion of the tablespace set is needed, or if you already converted
the tablespace set:
Copy the dump file to the directory pointed to by the DATA_PUMP_DIR directory object,
or to any other directory object of your choosing. Run the following query to determine
the location of DATA_PUMP_DIR:
SELECT * FROM DBA_DIRECTORIES WHERE DIRECTORY_NAME = 'DATA_PUMP_DIR';
OWNER
DIRECTORY_NAME
DIRECTORY_PATH
---------- ---------------- ----------------------------------SYS
DATA_PUMP_DIR
C:\app\orauser\admin\orawin\dpdump\
18. Verification:
A. At the source database:
We assume TEMP and UNDO are the names used for your temp and undo tablespaces,
if they are different you will need to edit the script.
set trim on trims on pagesize 150 linesize 999
col owner for a15
col tablespace_name for A30
D. At destination database:
set
col
col
col
col
Create table t2 as
select tablespace_name, owner, segment_name, segment_type,
(bytes/1048576) Size_Mbytes from dba_segments where tablespace_name
not in ('SYSTEM','SYSAUX','UNDO','TEMP') and owner not in
('SYS','SYSTEM','DBSNMP','SYSMAN','OUTLN','MDSYS','ORDSYS','EXFSYS','D
MSYS','WMSYS','CTXSYS','ANONYMOUS','XDB','ORDPLUGINS','OLAPSYS','PUBLI
C') order by tablespace_name, owner, segment_name, segment_type;
select * from t1 where (segment_name) NOT IN ( select segment_name
from t2);
References:
Document 1454872.1 Transportable Tablespace (TTS) Restrictions and
Limitations: Details, Reference, and Version Where Applicable
Master Note for Transportable Tablespaces (TTS) -- Common Questions and
Issues (Doc ID 1166564.1)
Note.114915.1 Ext/Pub Using Dbms_tts.transport_set_check Results in Entry in
Transport_set_violations
Note 228482.1 Schemas CTXSYS MDSYS ORDSYS Are Not Exported