Migrating and Upgrading to

Oracle Database 12c

Quickly With Near-Zero Downtime

Session ID: 1344

Prepared by:

Jim Czuprynski
OnX Enterprise Solutions
April 11, 2016
@JimTheWhyGuy

My Credentials
35+ years of database-centric IT
experience
Oracle DBA since 2001
Oracle 9i, 10g, 11g OCP
Oracle ACE Director
100+ articles on databasejournal.com
and ioug.org
Oracle-centric blog (Generally, It
Depends)
Regular speaker at Oracle OpenWorld,
IOUG COLLABORATE, and OTN ACE
Tours
Oracle University instructor core
Oracle DBA courses

Assess. Design. Build. Manage.

Who We Are
>Solution Provider focused on
>Technology Solutions
>Comprehensive Service Offerings
>Extensive reach U.S., Canada, and
the U.K.
>$700M annual revenue with over
$100M in Services
>Industry Certifications across a
broad selection of best-in-class IT
manufacturers and technologies
>Significant investment in technical
3

Our Agenda
Migration Planning: Not a Trivial
Subject!
Migration Via Oracle GoldenGate
(OGG)
Piecemeal Migration and Conversion
Via Transportable Tablespace Sets
(TTS)
Pre-12c to 12c Database Migration
Techniques
Cross-Platform Transportable Tablespace
Sets (XTTS)
Fully Transportable Export/Import (FTE/I)
Cross-Platform Transfer (CPT)

Database Migration Planning

Windows of Inopportunity
Reversibility, Repeatability, and the Rule of Three
Migratibility
Potential Migration Approaches

Database Migration Planning: Not a Trivial Subject!

What is your window of

Can
your database applications user community
inopportunity?
withstand a limited amount of time with readonly access to the database being migrated?

Data Warehouse?
Certainly if
scoped properly.
Air Traffic Control
System? (Please not
while Im travelling!)

Order Entry
System?
Likely if
handled
carefully.
6

Database Migration Planning: Not a Trivial Subject!

Reversibility and Repeatability
What if the migration should fail unexpectedly?
Will your team have sufficient time to simulate the
migration more than once?
Works once: Luck.
Works twice: You probably missed something the 1st
time!
Works thrice: Probably covered all the bases.

Migratability
Does all application data have to move
simultaneously?
Older historical data can be staged for later
migration
A great time to consider new / revamped
partitioning schemes!
Migrating to 12c? Consider new ILM features!

Database Migration Planning: Potential Approaches

Migration Method

Advantages

Drawbacks

Oracle GoldenGate

Simple to set up,

supports Oracle > Oracle
DB migration best

How much money do you

have?

Piecemeal
Transportable
Tablespace Sets (TTS)
Migration

Supports endian
conversion, welldocumented, simple to
checklist

Mainly a manual process

and thus prone to error;
requires final down time
to complete

Cross-Platform
Transportable
Tablespace Sets
(XTTS)

Supports endian
conversion and most
11gR2 databases
forward

Mainly a manual process

and thus prone to error;
requires final down time
to complete

Cross-Platform
Transport
(CPT)

One set of RMAN

commands to migrate
everything

Designed for 12cR1

database migrations
only; requires scripting
as well; limited down
time to complete

Full Transportable
Export/Import (FTE/I)

Merges DataPump and

RMAN commands for
faster transfer of a
complete database (or
just key parts of it!)

Only works for later

releases; requires
scripting and at least
some down time

Leveraging Oracle GoldenGate

You Down With OGG?

Yeah, You Know Me!

Migrating / Upgrading with OGG

Ora10205

AP_DAT
A
AP_IDX
AP_CLO
B

Ora12102

AP_DAT
A
AP_IDX
AP_CLO
B

EXTRA
EXTRA
CT
CT

PUMP
PUMP

Networ
k
Trail
Trail
Files
Files

REPLIC
REPLIC
AT
AT

Trail
Trail
Files
Files
whichprocesses
PUMP
EXTRACT
processes
create
localconsume
trail files
and transmit

securely over
network to the
destination
and become
remote trail
files at the
destination
which REPLICAT
processes consume
and apply to the
destination.

Leveraging Oracle GoldenGate for Migration and Upgrade

Advantages:
Since its essentially logical replication, there are almost an
innumerable variety of ways data can be filtered, transformed, and
processed
Depending on source and target database releases, several ways to
increase speed and efficiency of change data capture and delivery
Initial loading is definitely required, but at least four different methods
are available for Oracle databases
Easy to set up, configure, and tune (as compared to Streams)

Drawbacks:
Since its logical replication, it may take significantly longer to
process some types of transactions, especially when LOB data is
involved
Encrypting data transmission and trail files requires Advanced
Security option
Separately licensed software but term licensing may be available
11

Piecemeal Migration and Conversion:

RMAN and Transportable Tablespace Sets (TTS)

Piecemeal Migration and Conversion Using

RMAN and Transportable Tablespace Sets (TTS)
Advantages:
Only sections of the source database (i.e. tablespace sets) need
to be taken into READ ONLY mode; the remainder of the database
is fully accessible!
Leverages simple, well-known RMAN concepts
Avoids having to migrate all SYSTEM-level tablespaces, online redo
logss, TEMPFILEs, or control files
Supports cross-Endian conversion via RMAN CONVERT
command

Drawbacks:
Unexpected surprises during tablespace set migration discovery
are not uncommon so be sure to check once more before actual
migration
Scripted approach only requires careful attention via checklist!
See MOS #1457743.1, Upgrading a Database Using
Transportable Tablespaces
13

Piecemeal Migration Via TTS

Ora10205
ARCHIVELOG ON
COMPATIBLE =
10.2.0.5
OPEN READ
AP_DAT
WRITE
A
AP_IDX
AP_CLO
B

2
2
expdp system/******
B
A 1
Build
desired
tablespace
PARFILE=tts_10205.d
Make desired
TTS tablespaces
set(s)
pectl
Export
READ ONLY
DUMPFILE=tts_10205.d
RMAN> TRANSPORT

SQL>
ALTER TABLESPACE
ap_data
ap_data, metadata
mpTABLESPACE
READ
ONLY;
for desired
ap_idx,
ap_clob
LOGFILE=tts_10205.log
ALTER TABLESPACE ap_idx
TTS
TRANSPORT_TABLES
TABLESPACE
READ
ONLY;
DESTINATION
+FRA
PACE=Y
3
TABLESPACES=ap_da
AUXILIARY DESTINATION
Copy
ta,+FRA
datafiles
;
DBMS_FILE_TRA
& metadata
NSFER
dump set to
Ora12102 ARCHIVELOG ON destination
COMPATIBLE = 12.x
4
4
impdp
OPEN READ WRITE
B
AP_DAT
A
AP_IDX
AP_CLO
B

system/******

A5

5
If
desired,
bring all transported
Plug
TTS
RMAN>
CONVERT
PARFILE=tts_12102
If necessary,
DIRECTORY=DPDIR
TSPs
back into READ WRITE
mode
datafiles
DATAFILE
.dpictl
convert
DUMPFILE=tts_10205.dm
into to
<dfname>
FROM
SQL>
ALTER TABLESPACE
ap_data
datafiles
pPLATFORM
12.1.0.2
READ WRITE;
destinations
LOGFILE=tts_12102.log
database
<platform type>
endian-ness
TRANSPORT_DATAFILE
FORMAT
S=
<new_dfname>;
ap_data, ap_idx, ap_clob

Cross-Platform Transportable Tablespaces (XTTS) Via

Incremental Backups: Nearly Real-Time Migration

XTTS: Concepts, Advantages, and Drawbacks

Advantages:
10gR2 - 11gR2 source databases supported
Leverages simple RMAN concepts:
IMAGE COPY for initial synchronization
INCREMENTAL LEVEL 1 backups for incremental synchronization

Multiple resynchs can occur before final synch-up

Can be spread out over hours or even days

Supports cross-Endian conversion within execution

Drawbacks:
Requires final, manually initiated resynchronization between both
platforms
Source tablespace sets must be brought into READ ONLY mode for
final synchronization
Scripted approach only requires careful attention via checklist!
See MOS #1389592.1, Reduce Transportable
Tablespace Downtime using Cross Platform
Incremental Backup

16

XTTS: Prerequisites
# Create source database objects:
1
CREATE OR REPLACE DIRECTORY ora10g_dbf
AS '+DATA/ORA10G/DATAFILE';
GRANT READ, WRITE ON DIRECTORY ora10g_dbf TO PUBLIC;
CREATE OR REPLACE DIRECTORY xttsfiles
AS '/home/oracle/XTTSFILES';
GRANT READ, WRITE ON DIRECTORY xttsfiles TO PUBLIC;
# Create destination database objects:
CREATE PUBLIC DATABASE LINK ora10g
CONNECT TO system
IDENTIFIED BY R3alS3cu5
USING 'ORA10G';

CREATE OR REPLACE DIRECTORY ora12c_dbf

AS '+DATA/ORA12010/DATAFILE';
GRANT READ, WRITE ON DIRECTORY ora12c_dbf TO PUBLIC;
CREATE OR REPLACE DIRECTORY xttsfiles
AS '/home/oracle/XTTSFILES';
GRANT READ, WRITE ON DIRECTORY xttsfiles TO PUBLIC;

XTTS: Prerequisites
# Unzip XTTS objects and scripts:
$> unzip d /home/oracle/XTTS rman_xttconvert_1.4.zip
Edit xtt.properties on source and destination:
4
# Tablespace(s) for XTTS transport:
tablespaces=AP_DATA,AP_IDX,AP_CLOB
# Source database parameters:
platformid=2
srcdir=ORA10G_DBF
srclink=ORA10G
dfcopydir=/home/oracle/XTTSFILES
backupformat=/home/oracle/XTTSFILES
# Destination database parameters:
dstdir=ORA12C_DBF
stageondest=/home/oracle/XTTSFILES
storageondest=+DATA
backupondest=+FRA
asm_home=/u01/app/oracle/product/12.1.0/grid
asm_sid=+ASM
parallel=4
rollparallel=2

XTTS: Prepare Phase

ARCHIVELOG ON
Oracle DBA decides to migrate
COMPATIBLE =
self-contained tablespace set
Ora10205 10.2.0.5
from 10.2.0.5 database to
OPEN READ WRITE5A 12.1.0.2 database using XTTS:
5B
AP_DAT
Generateinitial
initialdatafile
datafileimage
11 Generate
A
image copies:
copies:
AP_IDX
$>./xttdriver.pl
./xttdriver.plS
p
$>
AP_CLO
Copy
to RMAND_F_T
Copyscripts
scripts&tofiles
destination:
destination
B
$> scp platform:
$> scp

ARCHIVELOG
ON
COMPATIBLE =
Ora12010 12.0
OPEN READ
WRITE

5B
5A
22

Transfer
copies
files
to
Pull
initial image
datafile
image
copies
todestination:
destination:

$>./xttdriver.pl
scp
$>
G

D_F_T
Convert datafiles
different
Conversion
handled(if
implicitly!
RMAN
endianness):
RMAN> CONVERT

XTTS: Roll Forward Phase (Ongoing Synchronization)

ARCHIVELOG ON
COMPATIBLE =
Ora10205 10.2.0.5
OPEN READ WRITE
AP_DAT
A
AP_IDX
AP_CLO
B

Oracle DBA can continue to

synchronize self-contained
tablespace set between source and
6destination until desired cutover:

Generate incremental backup

sets:
RMAN

$> ./xttdriver.pl i

Copy incremental backups to

destination:

$> scp
ARCHIVELOG
ON
COMPATIBLE =
Ora12010 12.0
OPEN READ
WRITE

6
B

Apply incremental backups at

RMAN
destination:

$> ./xttdriver.pl -r
Capture FROM_SCN for next
synchronization:

$> ./xttdriver.pl -s

This can be repeated innumerable

times
until its time to cut over!

XTTS: Transport Phase (Final Synchronization)

ARCHIVELOG ON
At cutover, self-contained
COMPATIBLE =
tablespace set must be brought
Ora10205 10.2.0.5
into READ ONLY mode briefly to
OPEN READ WRITE 7 guarantee consistency:
AP_DAT
A Take tablespaces into READ ONLY
A
at source:
AP_IDX
SQL> ALTER TABLESPACE
ap_data READ ONLY;
AP_CLO
...
B
Do one final synchronization:

$> (See steps 6A and 6B)

ARCHIVELOG
ON
Ora12010 COMPATIBLE =
12.0
AP_DAT
OPEN READ
A
WRITE
AP_IDX
AP_CLO
B

7
B

Generate Data{Pump metadata

import script:

$> ./xttdriver.pl -e
Import tablespaces into
destination database:
$> impdp ... parfile=xtts.dpictl
Bring tablespaces into READ
WRITE mode:
SQL> ALTER TABLESPACE ap_data
READ WRITE;
...

12cR1 Migration Techniques

Cross-Platform Transport (CPT)

Full Transportable Export/Import (FTE/I)

Cross-Platform Transport (CPT)

Advantages:
Merges Data Pump and RMAN into one complete bundle
Simple and familiar syntax easy to learn and implement
Fewer steps than XTTS method (its ancestor)
Drawbacks:
Source and destination databases must be at least 12.1.0.1
Source tablespaces must be taken into READ ONLY mode

See also:
MOS #2013540.1, Cross-Platform Database Migration (Across Same Endian)
Using RMAN Backupset In 12c
MOS # 2013271.1, 12c How To Perform Cross-Platform Database Transport To
Different Endian Platform With RMAN Backup Sets

23

Example: Migrate from 12.1.0.1 to 12.1.0.2 with CPT

DB12101 ARCHIVELOG ON

RMAN> BACKUP
Back up 1
FOR TRANSPORT
READ
FORMAT +DATA1
ONLY
DATAPUMP
tablespa
FORMAT
ces as
/home/oracle/dfte.d
backup
+RECO
mp
set from
TABLESPACE
12.1.0.1
2 tpch_data,
tpch_idx;
Copy RMAN
backup sets +
DBMS_FILE_TRA
DP dump set to
NSFER
destination
database
ARCHIVELOG ON
3
DB12102
COMPATIBLE >= RMAN> RESTORE
12.0
Restore
FOREIGN TABLESPACE
OPEN READ WRITEtpch_data, tpch_idx
tablespace
+DATA1
s into
FORMAT +DATA1
12.1.0.2
FROM BACKUPSET
non-CDB
+RECO
+RECO
or PDB
DUMP FILE FROM
BACKUPSET
/home/oracle/dfte.dmp;
COMPATIBLE >=
12.0
OPEN READ
WRITE
+DATA1

Full Transportable Export/Import (FTE/I)

Advantages:
Leverages well-known migration concepts
Non-user-defined tablespaces remain in READ WRITE mode
Excellent way to migrate a smaller database with a reasonable
window of inopportunity
If network bandwidth is sufficient, transporting over network will limit downtime
Import is significantly faster at destination using this method

If transformation to Multitenant is the goal, the source database is

automatically translated to PDB status at the existing CDB
destination

Drawbacks:
Source database must be at least Release 11.2.0.3
At the source, the entire tablespace set must be brought into READ
ONLY mode
but remember: Intent is to migrate to new platform / environment!
See Oracle Database 12c Administrators Guide, Chapter
15: Transporting Data
25

Example: Migrate from 11.2.0.3 to 12.1.0.2 With FTE/I

DB11203

ARCHIVELOG ON
COMPATIBLE >=
11.2.0.3
OPEN READ WRITE

expdp system/******
1
PARFILE=fte_11203.d
Export
pectl

DUMPFILE=fte_11203.
entire
dmp
contents
+DATA1
LOGFILE=fte_11203.lo
of 11.2.0.3
g
database
TRANSPORTABLE=A
+FRA
2LWAYS
VERSION=12.0
Copy
datafiles &
DBMS_FILE_TRA
FULL=Y dump
metadata
NSFER
set to 12.1.0.2
DB12102
database
ARCHIVELOG ON
COMPATIBLE >=
3
impdp
12.0
OPEN READ WRITEsystem/******
Plug nonPARFILE=fti_11203.
SYSTEM
DIRECTORY=DPDIR
+DATA1
datafiles &
dpictl
DUMPFILE=fte_11203.dm
all objects
p
+FRA
into
LOGFILE=fti_11203.log
12.1.0.2
FULL=Y
database
TRANSPORT_DATAFILE
S=

FTE/I: Notable Restrictions

FTE/I jobs cannot be restarted
Encrypted tablespaces cannot be transported if the source and
destination database have different endianness
If source and destination are of different endianness, then use either
DBMS_FILE_TRANSFER package or RMAN CONVERT command to perform
endian conversion

The segments of objects selected for export must be:

Entirely within SYSTEM / SYSAUX tablespaces; or
Entirely within user-defined tablespaces

When transporting over a network:

Tables with LONG or LONG RAW columns that reside in SYSTEM / SYSAUX
cannot be transported
Auditing must be disabled for tables stored in user-defined tablespace

Other standard transport restrictions apply

See Oracle Database 12c Administrators Guide, Chapter

15: Transporting Data General Limitations on Transporting
Data
27

Q+A

Upgrading to 12c? Migrating to Exadata?

Oracle Database Upgrade,
Migration & Transformation
Tips & Techniques
Covers everything you need to know
to upgrade, migrate, and transform
any Oracle 10g or 11g database to
Oracle 12c
Discusses strategy and tactics of
planning Oracle migration,
transformation, and upgrade
projects
Explores latest transformation
features:
Recovery Manager (RMAN)
Oracle GoldenGate
Cross-Platform Transportable
Tablespaces
Cross-Platform Transport (CPT)
Full Transportable Export (FTE)

Please complete the session evaluation

We appreciate your feedback and insights!

Session #1344:
Migrating and Upgrading to Oracle
Database 12c Quickly With Near-Zero
Downtime

If you have any questions or comments, feel free to:

E-mail me at jim.czuprynski@onx.com
Follow my blog (Generally, It Depends):
http://jimczuprynski.wordpress.com
Follow me on Twitter (@JimTheWhyGuy)
Connect with me on LinkedIn (Jim
Czuprynski)

Get Published in IOUG SELECT Journal

Quarterly journal of peer-reviewed technical articles and news published

by the Independent Oracle Users Group
We are always looking for new authors, interested?

Technical Tip ~500 words

Column ~ 500 1000 words
Technical Article ~ 1500 2500 words
Blog posting ~ 500 2500 words

Visit http://ioug.org/select for more information.

Questions? select@ioug.org
IOUG Members have unlimited access to the current and archives of
SELECT Journal
Including more than 3,000 papers and presentations in the IOUG Library

31