<Insert Picture Here>

Sun Oracle Database Machine Oracle Database 11g Release 2 Migration Maximum Availability Architecture Best Practices
Name:

Agenda
Database Machine Software Considerations Migration Strategy Migration Methods Scenarios
Migrating from HP v1 DBM Migrating from Oracle Database 10g Release 2 / Oracle Database 11g Release 1 On big endian platform On little endian platform

Bulk Data Movement Q/A

2009 Oracle Corporation

Database Machine Software

Considerations Exadata and Oracle Database
Versions must match Cannot run 11.2 Exadata with 11.1 Database (or vice versa) 11.1 and 11.2 cannot coexist on same machine Important consideration for migration from v1 to v2 Sun hardware 11.2 only HP hardware either 11.1 or 11.2

Operating system
Oracle Enterprise Linux (OEL5) Linux x86_64 Little endian format

2009 Oracle Corporation

Migration strategy

2009 Oracle Corporation

Migration strategy
Choose the right migration method Determine what to migrate
Because of Exadata unique features (e.g. smart scan) expect differences between source and Exadata warehouse databases Fewer indexes, fewer materialized views, different partitioning strategy, compression Avoid methods that migrate what you will discard

Consider configuration of source system

Not all migration methods available for all source environments Non-Oracle: Only cover Oracle source systems in this presentation Oracle: Source database version and platform matters Target system fixed: 11.2, ASM, Linux x86-64
2009 Oracle Corporation

Migration strategy
Choose the right migration method Implement Best Practices
Will the migration method accommodate best practices? Examples ASM disk group 4MB AU size at disk group creation Large extents (8MB) for large segments at extent allocation Avoid methods that prevent proper best practices

Minimize downtime
Yes, but implementing best practices is more important (your future performance depends on it)

2009 Oracle Corporation

Migration methods
Methods overview Physical migration
Data remains in datafiles (block-for-block) Most methods are whole database migration Generally more restrictive

Logical migration
Data unloaded from source, loaded into Exadata database w/ SQL Easier to migrate subset Easier to implement structural best practices Generally less restrictive

2009 Oracle Corporation

Migration methods
Strategy for database types No single best method for all cases, but in general Data Warehouse (DW)
Typical strategy
Change structure
Reduce / remove indexes, MVs

OLTP
Typical strategy
Structure intact

Change storage
Use new compression (EHCC) Optimize extent sizing

Migration method
1st: Physical 2nd: Logical

Change platform
Source big endian

Migration method
1st: Logical 2nd: Physical
2009 Oracle Corporation

Migration methods

2009 Oracle Corporation

10

Physical migration
Data remains in datafiles (block-for-block)
Database extent sizes remain the same

Most methods whole database migration (except TTS)

Inherit legacy database configuration indexes, MVs, no compression

Stricter requirements
Platform and version changes restricted

2009 Oracle Corporation

11

Physical migration
Best practice challenged
Suboptimal sizing Migrate unnecessary objects

Objects can be recreated post migration, but

Why not use logical method in the first place?

2009 Oracle Corporation

12

Physical migration
Methods at a glance ASM rebalance Partition roll-in/out Data Guard Physical Standby Transportable database (TDB) Transportable tablespaces (TTS) Review logical migration methods if best practices not already implemented on source database

2009 Oracle Corporation

13

Physical migration
Method
ASM rebalance Partition roll-in/out Data Guard Physical Standby Transportable database

When to use
Add Exadata storage to existing 11.2 Linux x86-64 database that uses ASM w/ 4MB AU Add Exadata storage to existing 11.2 Linux x86-64 database Linux source on 11.2, archiving and LOGGING Little endian source on 11.2

Transportable tablespaces Big endian source >= 10.1 Little endian source >=10.1, <11.2

2009 Oracle Corporation

14

Physical migration
ASM rebalance to Exadata storage Overview - Let ASM rebalance move the data
Connect Exadata storage to existing database nodes ADD grid disks to existing ASM disk groups, DROP legacy storage from existing ASM disk groups

Source system criteria

11.2 on Linux x86-64 w/ ASM redundancy and InfiniBand

Outage time
None

Consider
Must already use 4MB ASM AU in existing disk groups

2009 Oracle Corporation

15

Physical migration
Partition roll-in, roll-out to Exadata storage Overview Load new partitions into Exadata storage
Connect Exadata storage to existing database nodes Only load into newly created partitions on Exadata storage Drop old partitions from traditional storage

Source system criteria

11.2 on Linux x86-64 w/ InfiniBand

Outage time
None

Consider
Set 4MB ASM AU for new disk groups on Exadata storage If source using ASM, should already have 4MB ASM AU

2009 Oracle Corporation

16

Physical migration
Data Guard Physical standby Overview (Note 1055938.1)
Create Physical Standby on Sun Oracle Database Machine Data Guard switchover

MAA on OTN

Source system criteria

11.2 on Linux (or Windows see Note 413484.1) Use this method migrating from HP Oracle Database Machine running 11.2

Outage time
Data Guard switchover

Consider
Archivelog mode and LOGGING required New DB_UNIQUE_NAME needed
2009 Oracle Corporation

17

Physical migration
Physical standby plus database upgrade Overview (Note 1055938.1)
Create Physical Standby on Sun Oracle Database Machine Apply archives Activate standby database Run database upgrade scripts

Source system criteria

11.1+ on Linux

Outage time
Time to apply archives + run database upgrade scripts

Consider
Archivelog mode and LOGGING required New DB_UNIQUE_NAME needed

2009 Oracle Corporation

18

Physical migration
Transportable database (TDB)
Overview
RMAN CONVERT DATABASE Transfer datafiles to Exadata storage CONVERT subset of datafiles, as required (up to 2GB/s) (Note:732053.1) Run transport script

MAA on OTN

Source system criteria

11.2 on little endian

Outage time
Transfer all datafiles + partial CONVERT + transport script

Consider
Do not use source system conversion Staging space requirement size of files that need CONVERT OLAP AWs need special consideration (Note 352306.1)

2009 Oracle Corporation

19

Physical migration
Transportable tablespace (TTS)
Overview
Build empty 11.2 Exadata database TTS export source system metadata Transfer files to Exadata (CONVERT if source system big endian) TTS import metadata into Exadata database

MAA on OTN

Source system criteria

10.1 or later, any endian

Outage time
TTS export + Transfer files + CONVERT (if necessary) + TTS import

Consider
If source system big endian, CONVERT on source system Staging space requirement - size of files that need CONVERT OLAP AWs need special consideration (Note 352306.1)

2009 Oracle Corporation

20

Migration methods
Logical migration Data unloaded from source, loaded into Exadata database w/ SQL Move only the user data Best practices can be added
4MB ASM AU size set for new disk groups Large extents (8MB) for large database segments Table compression, if desired Partitioning (added or changed), if desired

2009 Oracle Corporation

21

Logical migration
Methods at a glance Data Guard Logical Standby GoldenGate / Streams Data Pump Create Table As Select (CTAS) or Insert As Select (IAS)

2009 Oracle Corporation

22

Logical migration
Method
Data Guard Logical Standby

When to use
Rolling database upgrade requirement Table storage characteristics will be changed

Oracle GoldenGate* Minimal downtime requirement Streams Different source platform Data Pump CTAS / IAS Data type restriction with other methods Initial bulk load

2009 Oracle Corporation

23

Logical migration
Data Guard Logical standby
Overview
Steps depend on starting point - See following slides 1. Source database 11.2 2. Source database < 11.2 (including HP Oracle Database Machine)

Source system criteria

Linux (check Note 413484.1 for cross-platform support)

Outage time
Typically Data Guard switchover + application failover

Consider
Archivelog mode, LOGGING, and supplemental logging required Data type support Can apply catch up?

2009 Oracle Corporation

24

Logical migration
Logical standby source system 11.2 Overview
Create logical standby on 11.2 Sun Oracle Database Machine Change table storage characteristics, as desired (Note:737460.1) Data Guard switchover

MAA on OTN

When to use this method

Table storage characteristics will be changed If not, use Data Guard Physical Standby method

2009 Oracle Corporation

25

Logical migration
Logical standby source system < 11.2
Overview (Note 1055938.1)
Create Data Guard Logical Standby on source system (e.g. 11.1 HP Oracle Database Machine) Shutdown and copy Logical Standby + controlfile to 11.2 Sun Oracle Database Machine
duplicate target database for standby from active database

Upgrade Data Guard logical standby to 11.2 (run upgrade scripts manually) Enable redo transport and standby apply to catch up Change table storage characteristics, as desired (Note:737460.1) Data Guard switchover

When to use
Table storage characteristics will be changed, or Rolling database upgrade

2009 Oracle Corporation

26

Logical migration
GoldenGate / Streams
Overview
Create and upgrade replica on Sun Oracle Database Machine Stop apply Implement best practices on replica (e.g. unload, recreate, reload) Start apply to catch up Disconnect users from primary, reconnect to Sun Oracle Database Machine

MAA on OTN

Source system criteria

10.1 or later on any platform (GoldenGate allows different DBMS, too)

Outage time
Application reconnection

Consider
Archivelog mode, LOGGING, and supplemental logging required Data type support Can apply catch up?

2009 Oracle Corporation

27

Logical migration
Data Pump Overview
Create Exadata database Import user data into Exadata using Data Pump Network mode - Direct import from source via dblink File mode - Export to dump file(s), transfer file(s), Import

Source system criteria

10.1 or later on any platform

Outage time
Network mode - 1x data movement File mode - 3x data movement and 2x staging space

2009 Oracle Corporation

28

Logical migration
CTAS / IAS
Overview
Create Exadata database CTAS or IAS From external tables in DBFS staging area From dblink to source database

Source system criteria

Any version or platform

Outage time
Significant (3x) variation depending on partitioning (and what scheme), compression, target data type

Consider
Use DBFS for staging external tables, not local filesystem Dblink - Manually parallelize

2009 Oracle Corporation

29

Migration methods
In practice Current DWs usually not on Linux x86-64 and not running 11g, so most physical methods eliminated
Most DWs replaced by Exadata are running either Oracle on bigendian UNIX, or competitor (e.g. DB2, Netezza, Teradata)

Customers only want tables with user data in order to implement new database configuration determined during testing

2009 Oracle Corporation

30

Migration methods
In practice Most common methods used thus far
Combination for staged migration CTAS/IAS or Data Pump for the initial bulk load into Exadata while source remains in use Perform daily loads (external tables) into both source and Exadata Initially users serviced by source database Move users over to Exadata Stop daily load into source

2009 Oracle Corporation

31

Migration Scenario
From 11.1 HP DBM Restriction
RDBMS 11.1 cannot use Exadata 11.2 RDBMS 11.2 cannot use Exadata 11.1

Option #1 Data Guard Physical Standby + Database Upgrade Option #2 Data Guard Logical Standby source system < 11.2
Reduce downtime rolling database upgrade

2009 Oracle Corporation

32

Migration Scenario
From 10gR2 / 11gR1 on Big Endian Option #1 Transportable Tablespaces Option #2 Data Pump
Implement best practices not in source database

Option #3 GoldenGate, Streams

Reduce downtime Implement best practices not in source database

2009 Oracle Corporation

33

Migration Scenario
From 10gR2 / 11gR1 on Little Endian (non-DBM) Option #1 Physical Standby + Database Upgrade
Check Note 413484.1 for cross platform standby support

Option #2 - Logical Standby source system < 11.2

Reduce downtime rolling database upgrade Check Note 413484.1 for cross platform standby support

Option #3 - Data Pump

Implement best practices not in source database No cross platform standby support

Option #4 GoldenGate, Streams

Reduce downtime Implement best practices not in source database No cross platform standby support
2009 Oracle Corporation

34

Bulk data movement

2009 Oracle Corporation

35

Bulk data movement

Performance criteria
Network Protocol Source system Target system (i.e. Sun Oracle Database Machine)

Note: Bulk data movement to the database servers you do NOT move data directly to the storage it always goes through an instance on a database server first.

2009 Oracle Corporation

36

Bulk data movement

Network 2 networks can get data to database servers on Sun Oracle Database Machine
InfiniBand (IB) 4x QDR 40Gb/s per link Gigabit Ethernet (GbE) 1Gb/s eth1 and eth2 can be bonded for aggregation

In practice, IB is about 20x faster than single GbE

IB 2GB/s vs GbE 110MB/s for single connection (TCP)

Use IB network

2009 Oracle Corporation

37

Bulk data movement

Protocol
TCP over IB (TCPoIB)
On source system Use IP connected mode (CM) Set Large MTU (65520) Sun Oracle Database Machine database servers already configured

RDS - only used by Oracle for RAC and storage traffic SDP - stick w/ TCP

2009 Oracle Corporation

38

Bulk data movement

Protocol Oracle Net TCP
Set SDU=32767 Yields more efficient write by Oracle Net to socket buffer

2009 Oracle Corporation

39

Bulk data movement

Source system Source system
I/O subsystem must deliver Fast IB network cant compensate for slow I/O CPU usage varies Data transfer with very fast networks can cause high CPU usage One CPU may be pegged while others have headroom (e.g. interrupt handling) Use mpstat(1) to investigate

2009 Oracle Corporation

40

Bulk data movement

Target system Target system (database servers of the Exadata system)
ASM for staging Stored in Exadata Oracle-structured files only (e.g. data files, DP dump files) Excellent disk I/O throughput Oracle tool required to move data (DFT, ASMCMD CP, RMAN BACKUP AS COPY AUXILIARY, XDB FTP) DFT 115 MB/s for single connection (use multiple to scale) Double (or triple) writes for ASM redundancy 600MB/s network rate translates to 1200+MB/s ASM write rate

2009 Oracle Corporation

41

Bulk data movement

Target system Target system (database servers of the Exadata system)
DBFS for staging (Note 1054431.1) File system in a database, using Exadata storage Standard OS tools http://dbdev.us.oracle.com/twiki/bin/view/ExadataExternal/Exad ataBestPracticesApp Local disk file system for staging Do NOT use it for staging Not designed for performance Use DBFS better performance, higher capacity, shared

2009 Oracle Corporation

42

Summary
Best practices leads to the best performance
Make sure migration doesnt break them

Use the InfiniBand network for the fastest network performance For more information
Maximum Availability Architecture http://www.oracle.com/technology/deploy/availability/htdocs/maa.htm Sun Oracle Database Machine and Exadata Storage Server http://www.oracle.com/technology/products/bi/db/exadata/index.html

2009 Oracle Corporation

43