=== WORKSHOP ORACLE : PERFORM A VLDB MIGRATION WITH ...

Introduction 

=== WORKSHOP ORACLE : PERFORM A VLDB MIGRATION WITH DATAPUMP === 

In this workshop it will be explained how to use datapump to migrate a database PROD with datapump from a AIX 

platform to a Linux platform. The size of the source database is about 6 TB. About 50 % are data segments and the 

rest are mainly index segments. The source database PROD is a standalone database and the target database 

PRODNEW is a cluster database with 4 instances running on exadata. 

The datapump migration is run as fast as possible, a window for the migration has been set to allow a downtime for 

36 hours. In a non-VLDB migration, the best approach would simply be a full export/import as that approach will not 

require a lot of DBA attention. However, when speed is an issue that the full export/import scenario has 2 

drawbacks: 

1. There is only one worker process to creates all the indexes. This can still be done in parallel as the worker uses PX 

processes up to the PARALLEL value. But nevertheless, since there is only 1 worker process, the parallel process is 

limited to 1 index at the time. 

2. Constraints will be validated during the import operation by default. It would however, be much faster, to load 

the constraints with the NOVALIDATE clause. 

An analysis of the source database (dba_segments) shows that there is only 1 very large schema (PROD_OWNER). 

The other schema’s are quite small compared to that one large schema. So the approach will be to fully import the 

database with an exclude of the large schema and deal with that schema differently to speed up the import 

operation and workaround the 2 performance issues as shown above. So the plan for the operation will be: 

• Phase 1: Perform Export operation 

o Prepare source for export 

o Perform export in parallel 

• Phase 2: Perform import operation 

o Prepare target for import 

o Perform 2 imports in parallel: 

Full import operation, exclude PROD_OWNER 

Import PROD_OWNER, exclude indexes and constraints 

• Phase 3: Build indexes and constraints in parallel. 

• Phase 4: Perform post migration activities 

o Perform import checks 

o Restore old values source and target 

1

Phase 1: Export phase 

1A Prepare source for export 


Before starting the export, make sure init.ora setting max_parallel_servers is set. In this example the setting was 0, 

so during the migration the setting is increased. Therefore the following script was run in source database PROD: 

spool source_change_parameters_before.lis 

PROMPT 

PROMPT script source_change_parameters_before.sql 

PROMPT Script to change parameters on source database prior to migration 

PROMPT Don’t forget to reset after the migration 

PROMPT 

PROMPT 

PROMPT 

PROMPT Hit to continue 

PAUSE 

PROMPT Changing parameter max_parallel_servers from 0 to 64 

ALTER SYSTEM SET max_parallel_servers = 64 SCOPE = BOTH; 

Although not strictly necessary since we make a consistent export, it is advisable to run the export while the 

database is in restricted mode. This can be done as follows: 

SQL> alter system enable restricted session; 

Because the restricted session does not log off existing sessions in the database, you should either stop/start the 

database to get rid of existing sessions, or you should kill the existing sessions. Use the query below to detect 

running sessions and kill those sessions with the generated kill statements: 

SQL> select 'ALTER SYSTEM KILL SESSION ''' ||sid||','||serial# ||''';', username, 

program, status from v$session@DP_LINK01 order by username; 

Now we create an additional user to be part of the export/import operation. This information will be used to check 

afterwards if the export/import operation was successful. 

REM create user mig_temp 

create user mig_temp identified by mig_temp default tablespace users; 

grant dba to mig_temp; 

REM create some tables with usefull information 

create table mig_temp.mig_objects as select * from dba_objects; 

create table mig_temp.mig_tables as select * from dba_tables; 

create table mig_temp.mig_indexes as select * from dba_indexes; 

create table mig_temp.mig_segments as select * from dba_segments; 

create table mig_temp.mig_constraints as select constraint_name 

from dba_constraints where owner = 'PROD_OWNER'; 

REM export the statistics just in case. 

exec dbms_stats.create_stat_table(ownname => 'MIG_TEMP', stattab => 

'MIG_STATS', tblspace => 'USERS'); 

exec dbms_stats.EXPORT_DATABASE_STATS('MIG_STATS','MIGRATION','MIG_TEMP'); 

2

1B Starting the export 

$ expdp parfile=exp_full.par 


Contents of the parfile: 

PARALLEL=12 

FLASHBACK_TIME="SYSTIMESTAMP" 

DIRECTORY=MIG_DUMP 

DUMPFILE=PROD_%U.dmp 

LOGFILE=exp_full.log 

METRICS=Y 

FILESIZE=48G 

FULL=Y 

ACCESS_METHOD=EXTERNAL_TABLE 

Some remarks regarding the export parameter files: 

• ACCES_METHOD should not be set by default. However, in this case, the parameter setting led to a much 

faster export time. 

• In this approach, a dump is made to a NFS file system. Alternatively, an import can be made straight from 

the source database into the target database. In that scenario (which is not further described in this article) a 

database link should be created and added as NETWORK_LINK parameter to the parameter file. When 

importing over database links take note that the database link transfer rate is limited to about 30 MB/sec. So 

if you have a higher bandwith you should split the import operation in several sessions at the schema or 

table level and use a number of database links to get a higher transfer rate. 

• The FILESIZE parameter ensures that a large number of dumpfiles are generated, which allows the import 

operation to be performed with a much higher degree of parallelism. 

• The parameter FLASHBACK_TIME ensures that a consistent export is made. 

The export ran for 4 hours and the total dumpfile size was 2,8 TB. In supplement 1 3 SQL Queries are provided to 

monitor the progress of the datapump export. Also you can regularly issue the statements below in the dumpfile 

location to monitor the growth of the dumpfiles: 

[dumpfile location]$ du 

3048166105 . 

[dumpfile location]$ du -h 

2.9T . 

3

Phase 2: Import phase 

2A Prepare target for import 


While the export is running you can start some actions to prepare the import operation. 

Prep-target-01: Configure a NFS Mount on the Target Database Server 

The exadata database machine is connected with a Sun ZFS Backup appliance for rman backup’s. This system is also 

used to temporarily host the dumpfile. The connection between the Sun ZFS appliance and the exadata database 

machine is a high speed infiniband connection (40 Gb/sec). A 10 TB NFS mount is configured to access the dumpfile. 

Prep-target-02: Create a directory in target database PRODNEW 

A directory is created in the target database to refer to the NFS mount as configured above. 

SQL> create directory mig_db as '/mnt/export/PRODNEW'; 

Prep-target-03: Set database parameters on the target 

In order to speed up the migration some database parameters need to be set in the target database. They will be 

reset after the datapump operation has completed: 

SQL> ALTER SYSTEM SET parallel_servers_target = 32 SCOPE = BOTH; 

SQL> ALTER SYSTEM SET db_block_checksum = FALSE SCOPE = BOTH; 

• The default value for parallel_servers_target on this platform is 8 ( as it is a consolidation platform), which is 

too low for the datapump operation. Make sure to also check parallel_max_servers is sufficiently high. We 

will be running the operation in parallel with a degree of 24. 

• DB_BLOCK_CHECKSUM will be changed from TYPICAL to FALSE to speed up the migration. 

• Make sure PGA_AGGREGATE_TARGET is sufficiently large as well. Especially during the create index part a 

large PGA will speed up the index creation process. In database PRODNEW the PGA_AGGREGATE_TARGET = 

8 GB, which is sufficient. 

Prep-target-04: Configure the target database for the migration 

During the migration we do not want archiving or logging to slow down the operation, so perform the following: 

SQL> alter database disable block change tracking; 

SQL> alter database no force_logging; 

SQL> alter database flashback off; 

$ srvctl stop database –d PRODNEW –o immediate; 

SQL> startup mount; 

SQL> alter database noarchivelog; 

SQL> shutdown immediate; 

$ srvctl start database –d PRODNEW 

Prep-target-05: Startup the database in restricted session 

In order to prevent users from accessing the database during the migration the database should be in restricted 

session mode. The best thing to do is to shutdown the database and startup the database in restricted mode. 

4


Alternatively, you can enable the restricted session without restarting the database. But in that case all existing 

database sessions will remain in the database so you need to kill those user sessions before you proceed: 

SQL> alter system enable restricted session; 

SQL> select 'ALTER SYSTEM KILL SESSION ''' ||sid||','||serial# ||''';', username, 

program, status from v$session@DP_LINK01 order by username; 

Use the output of the statement above to kill the user sessions. 

An added benefit of restricted session is that scheduled oracle jobs such as for example AWR snapshots will be 

prevented from running. 

2B Perform 2 import operations in parallel: 

$ impdp system parfile=dp_imp_full.par 

-- contents parameter file 

DIRECTORY=rob_temp 

DUMPFILE=full_PROD_%U.dmp 

LOGFILE=imp_full.log 

PARALLEL=24 

FULL=Y 

METRICS=Y 


EXCLUDE=schema:"('SYSTEM','TSMSYS','OLAPSYS','OUTLN','ANONYMOUS','APPQOSSYS','D 

BSNMP','DIP','ORACLE_OCM','MDDATA','LBACSYS','WMSYS','XDB', 

'PROD_OWNER')",tablespace:"='UNDO'" 

$ impdp system parfile=dp_imp_prod_owner.par 

-- contents parameter file 



LOGFILE=imp_prod_owner.log 

PARALLEL=24 

METRICS=Y 

SCHEMAS=PROD_OWNER 

EXCLUDE=INDEX,CONSTRAINT 


Afterwards, check the logfiles for any serious errors 

5


Phase 3: Building Indexes and Constraints 

3A Generate the create scripts 

Generate the required create index and add constraints scripts in the source database: 

SQL>@source_generate_indexes.sql 

SQL>@source_generate_scripts.sql 

You can find the scripts mentioned in Supplement 2 at the end of this workshop. 

Generate the required constraints scripts: 

$ expdp system parfile=dp_extract_constraints.par 

--Script generates create statements and uses datapump export as source 

--Contents parfile: 



LOGFILE=extract_constraints.log 

PARALLEL=24 

METRICS=Y 

SQLFILE=target_create_constraints.sql 

SCHEMAS=PROD_OWNER 

INCLUDE=CONSTRAINT 

After the script is generated, edit it with the vi-editor. We do not want the constraints to be added with the 

VALIDATE clause as that will take a very long time to complete: 

: 1,$ s/ENABLE;/ENABLE NOVALIDATE;/g 

3B Create the indexes for user PROD_OWNER 

Start 4 separate linux sessions to the 4 separate cluster nodes and run the scripts. It is best to use SCREEN so the 

scripts will continue to run in the background: 

Node exa1db01: SQL> @target_create_index01.sql 




After the indexes are created, it needs to be checked if they are all created: 

set linesize 200 

set pagesize 100 

spool target_check_indexes.lis 

PROMPT This script checks the number of indexes and reports any missing indexes 

PROMPT press to continue 

PAUSE 

PROMPT number of indexes on source and target database: 

set heading off 

select 'indexes prod_owner in target database: '||count(index_name) from 

dba_indexes where owner = 'PROD_OWNER'; 

6


select 'indexes prod_owner in source database: '||count(index_name) from 

mig_temp.mig_indexes where owner = 'PROD_OWNER'; 

PROMPT detail info missing indexes 

PROMPT note that you can ignore the LOB indexes, they are automatically created 

PROMPT with different names. 

set heading on 

select table_name, index_name, index_type from mig_temp.mig_indexes where owner 

= 'PROD_OWNER' and index_name not in (select index_name from dba_indexes where 

owner = 'PROD_OWNER') order by index_name; 

PROMPT 

PROMPT **** End of Script (=: **** 

spool off 

Finally run the script to reset the indexes, back to the original settings. (The script below was generated during the 

export preparation step): 

SQL> @target_reset_indexes.sql 

3B part 2: Run the script to add the constraints 

Now the constraints need to be added to the tables. Note that the INLINE NOT NULL constraints are already in place 

as they were part of the data import of OZG_OWNER. Now all the other constraints will be added. Run the script 

target_create_constraints.sql that was generated earlier on: 

SQL> @target_create_constraints.sql 

After the script has run, you need to run it again!! The reason we run it twice: FK constraints can only be created 

once a PMK is in place. And this is not always the case in the first run. 

SQL> @target_create_constraints.sql 

Afterwards, check if the number of constraints match with the source database: 

SQL> select constraint_name from mig_temp.mig_constraints where 

constraint_name not in (select constraint_name from dba_constraints where owner 

= 'PROD_OWNER'); 

7

Phase 4: Post migration steps 


4A Run the script to create directories 

The directory settings were changed on the target. During the preparation phase scripts were generated to create 

the directories. Run those scripts here: 

SQL> @target_create_directories.sql 

$ chmod +x target_create_directories.sh 

$ ./target_create_directories.sh 

4B Execute the sys grants 

Grants done by user SYS to other users are not part of the export dumpfile. So they will need to be created on the 

source manually and then execute on the target. 

Run on the source database (see supplement C for the script): 

SQL> @source_generate_sys_grants.sql 

Run on the target database: 

SQL> @target_sys_grants.sql 

4C Recompile invalid objects 

SQL> @?/rdbms/admin/utlrp 

4D Check the objects on the target and compare with the source 

PROMPT number of objects in source database 

SQL> select owner, object_type, count(object_name) from mig_temp.mig_objects 

group by owner, object_type order by owner, object_type 

PROMPT number of objects in target database 

SQL> select owner, object_type, count(object_name) from dba_objects group by 

owner, object_type order by owner, object_type 

PROMPT invalid objects in target which were valid in source database 

SQL> select owner, object_name from dba_objects where status 'VALID ' and 

object_name not in (select object_name from mig_temp.mig_objects where status 

'VALID ') 

Fix any issues you encounter 

4E Restore old values on source and target database 

Reverse the actions you executed during the preparation phase on both source and target in behalf of the migration. 

4E Gather new statistics 

The best thing is to gather new statistics. Proceed as follows: 

alter session force parallel DML; 

EXEC DBMS_STATS.gather_database_stats (estimate_percent => 15, degree 64); 

8


This procedure can run for a long time. (6 hours in the database we used). If you do not want to wait, you can also 

import the statistics from the dumpfile, hand over the database for production and start the gathering of statistics in 

the background. Import the source db statistics as follows (remember that they were part of the export preparation 

phase earlier on): 

SQL> exec dbms_stats.IMPORT_DATABASE_STATS('MIG_STATS','MIGRATION','MIG_TEMP'); 

==== End of migration workshop (=: ==== 

9


SUPPLEMENT 1: QUERIES TO MONITOR DATAPUMP IMPORT AND EXPORT OPERATION 

PROMPT Query 1: View datapump worker processes 

set lines 150 pages 100 numwidth 7 

col program for a38 

col username for a10 

col spid for a7 

select to_char(sysdate,'YYYY-MM-DD HH24:MI:SS') "DATE", s.program, s.sid, 

s.status, s.username, d.job_name, p.spid, s.serial#, p.pid 

from v$session s, v$process p, dba_datapump_sessions d 

where p.addr=s.paddr and s.saddr=d.saddr; 

PROMPT Query 2: View long running operations: 

set lines 120 

col opname for a25 trunc 

col username for a15 trunc 

col target for a20 

col sid for 999999 

col serial# for 999999 

col %DONE for a8 

select b.sid, b.username,a.sid,b.opname,b.target,round(b.SOFAR*100 / b.TOTALWORK,0) || 

'%' as "%DONE", 

b.TIME_REMAINING,to_char(b.start_time,'YYYY/MM/DD HH24:MI:SS') START_TIME 

from V$SESSION_LONGOPS b,V$SESSION a where a.sid=b.sid and TIME_REMAINING > 0 order by 

b.start_time; 

Query 3: View wait operations 

Tip: start the datapump export under a certain user and you can monitor this user’s 

wait. In the example below user SYS is applied: 

PROMPT Query 3: User Waits 

SELECT NVL(s.username, '(oracle)') AS username, 

s.sid, 

s.serial#, 

sw.event, 

sw.wait_time, 

sw.seconds_in_wait, 

sw.state 

FROM v$session_wait sw, v$session s 

WHERE s.sid = sw.sid and s.username = 'SYS' 

ORDER BY sw.seconds_in_wait DESC; 

10


SUPPLEMENT 2: GENERATE IMPORT CREATE SCRIPTS 

Supplement 2 - Script source_generate_indexes.sql 

PROMPT 

PROMPT script target_generate_indexes.sql 

PROMPT Script to generate 4 PROD_OWNER index creation scripts 

PROMPT . . . target_create_index_01.sql .. target_create_index_08.sql 

PROMPT 

PROMPT = all indexes are evenly distributed across the 4 files 

PROMPT = all indexes related to 1 table are grouped together 

PROMPT = top 24 largest tables are evenly distributed across the 4 files 

PROMPT 


PAUSE 

REM Step 1: Create a temporary table: 

create table rob_temp (file_no number(4), table_name varchar2(30)); 

insert into rob_temp(file_no, table_name) select 0,table_name from dba_tables where 

owner = 'PROD_OWNER'; 

REM Step 2: Assign 4 numbers to table_names in temporary table 

DECLARE 

teller NUMBER(4); 

CURSOR cur_tabel IS SELECT * FROM rob_temp for update of file_no; 

BEGIN 

teller := 1; 

FOR i IN cur_tabel 

LOOP 

if teller >= 5 then 

teller := 1; 

end if; 

UPDATE rob_temp SET file_no = teller where current of cur_tabel; 

teller := teller + 1; 

END LOOP; 

END; 

/ 

REM Step 3: Make sure top 24 largest tables are distributed evenly across the different 

files 

update rob_temp set file_no = 1 where table_name in 

('LARGE1','LARGE2','LARGE3','LARGE4','LARGE5','LARGE6'); 







REM Add any changes based on runtime experience: 

REM fill this after some testruns to evenly distribute the indexes. 

11


REM Step 4: spool the index script definitions to 4 seperate files: 

set heading off; 

set echo off; 

Set pages 999; 

set long 90000 pages 0 lines 131; 

column txt format a121 word_wrapped 

set linesize 1000; 

set feedback off 


set trimspool on 

set verify off 

set embedded on 

spool target_create_index_01.sql 

select 'spool target_create_index_01.lis' from dual; 

select 'select to_char(sysdate,''DD-MON-YYYY HH24-MI-SS'') starttijd_01 from dual;' 

from dual; 

select 'set timing on' from dual; 

select 'set echo on' from dual; 

select 'set feedback on' from dual; 

select 'alter system set parallel_force_local=true;' from dual; 

select 'alter session set nls_sort=BINARY;' from dual; 

prompt 

select dbms_metadata.get_ddl('INDEX',index_name,'PROD_OWNER')||' nologging parallel 

24;' txt 

from dba_indexes where table_name in (select table_name from rob_temp where file_no = 

1); 

select 'select to_char(sysdate,''DD-MON-YYYY HH24-MI-SS'') eindtijd_01 from dual;' from 

dual; 

select 'spool off' from dual; 




from dual; 






prompt 


24;' txt 


2); 


dual; 





from dual; 



12





prompt 


24;' txt 


3); 


dual; 





from dual; 






prompt 


24;' txt 


4); 


dual; 


drop table rob_temp; 

prompt **** End of Script (=: **** 

spool off 

13


Supplement 2 -Script source_scripts.sql 

PROMPT script source_gen_scripts.sql 

PROMPT Script to generate several scripts for later steps 

PROMPT 

PROMPT This script will spool 3 files: 

PROMPT . . . target_create_directories.sql 

PROMPT . . . target_create_directories.sh 

PROMPT . . . target_reset_indexes.sql 

PROMPT 


PAUSE 


set feedback off 

set echo off 


REM ***** Create script target_create_directories.sql ***** 

spool target_create_directories.sql 

select 'spool target_create_directories.lis' from dual; 



select 'create or replace directory '||DIRECTORY_NAME|| ' as 

''/tooling/CST'||directory_path||''';' 

from dba_directories where directory_path like '%condir%' order by directory_name; 

select 'PROMPT **** End of Script (=: ****' from dual; 


REM grants are being preserved with the REPLACE option. 

REM ***** Create script target_create_directories.sh ***** 

REM Generate linux script to create directories on platform 

REM Execute on compute nodes as user oracle 

spool target_create_directories.sh 

select 'dcli -g /opt/oracle.SupportTools/onecommand/dbs_group -l oracle mkdir -p 

/tooling/CST'||directory_path 

from dba_directories where directory_path like '%condir%' order by directory_name; 

REM ***** Create script target_reset_indexes.sh ***** 

spool target_reset_index.sql 

select 'spool target_reset_index.lis' from dual; 



select 'alter index PROD_OWNER.'||index_name||' logging'||';' from dba_indexes where 

owner = 'PROD_OWNER' and logging = 'YES' order by index_name; 

select 'alter index PROD_OWNER.'||index_name||' noparallel'||';' from dba_indexes where 

owner = 'PROD_OWNER' order by index_name; 

select 'PROMPT **** End of Script (=: ****' from dual; 


spool off 

exit 

14


SUPPLEMENT 3: SCRIPT SOURCE_GENERATE_SYS_GRANTS.SQL 

column k_time new_value d_time noprint 

column k_sid new_value d_sid noprint 

select to_char(sysdate, 'dd-mm-yyyy hh24:mi') k_time from dual; 

select name k_sid from v$database; 

spool target_sys_grants_&d_sid..sql 


set termout on 

set feedback on 

select 'spool target_sysgrants_&d_sid..lis' from dual; 

select 'grant ' || privilege || ' on ' || owner|| '.' ||table_name || ' to ' 

||grantee|| ';' from sys.dba_tab_privs 

where grantee not in('SYS', 'SYSTEM', 

'PUBLIC','SELECT_CATALOG_ROLE','EXP_FULL_DATABASE','EXECUTE_CATALOG_ROLE', 

'DELETE_CATALOG_ROLE','AQ_ADMINISTRATOR_ROLE','IMP_FULL_DATABASE','AQ_USER_ROLE 

','DBA','OUTLN','SNMPAGENT','CTXSYS','OLAPSYS','LBACSYS','ORDSYS', 

'MDSYS','DMSYS','XDB','WMSYS','EXFSYS','TKPROFER','HS_ADMIN_ROLE','OEM_MONITOR' 

,'WM_ADMIN_ROLE','OLAP_USER','DBSNMP','XDBADMIN','GATHER_SYSTEM_STATISTICS', 

'LOGSTDBY_ADMINISTRATOR') 

and grantor='SYS'; 

spool off; 

15

=== WORKSHOP ORACLE : PERFORM A VLDB MIGRATION WITH ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?