presentation - oracle database 11g release 2 migration maximum availability architecture best...

Sun Oracle Database MachineOracle Database 11g Release 2 MigrationMaximum Availability Architecture Best PracticesName:

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 3

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


Migration strategy


Migration strategyChoose 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


Migration strategyChoose 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)


Migration methodsMethods 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


Migration methodsStrategy for database types

No single best method for all cases, but in general

Data Warehouse (DW) Typical strategy

Change structureReduce / remove indexes, MVs

Change storageUse new compression (EHCC)Optimize extent sizing

Change platformSource big endian

Migration method 1st: Logical 2nd: Physical

OLTP Typical strategy

Structure intact

Migration method 1st: Physical 2nd: Logical


Migration methods


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


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?


Physical migrationMethods 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


Physical migration

Method When to useASM rebalance Add Exadata storage to existing 11.2 Linux

x86-64 database that uses ASM w/ 4MB AU

Partition roll-in/out Add Exadata storage to existing 11.2 Linux x86-64 database

Data GuardPhysical Standby

Linux source on 11.2, archiving and LOGGING

Transportable database Little endian source on 11.2

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

Physical migrationASM 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


Physical migrationPartition 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


Physical migrationData Guard Physical standby

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

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

MAA on OTN

New DB_UNIQUE_NAME needed


Physical migrationPhysical 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


Physical migrationTransportable 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

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)

MAA on OTN


Physical migrationTransportable 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

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)

MAA on OTN


Migration methodsLogical 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


Logical migrationMethods at a glance

Data Guard Logical Standby GoldenGate / Streams Data Pump Create Table As Select (CTAS) or Insert As Select (IAS)


Logical migration

Method When to useData GuardLogical Standby

Rolling database upgrade requirementTable storage characteristics will be changed

Oracle GoldenGate*Streams

Minimal downtime requirementDifferent source platform

Data Pump Data type restriction with other methods

CTAS / IAS Initial bulk load


Logical migrationData Guard Logical standby

Overview Steps depend on starting point - See following slides

1. Source database 11.22. 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?


Logical migrationLogical 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

When to use this method Table storage characteristics will be changed

If not, use Data Guard Physical Standby method

MAA on OTN


Logical migrationLogical 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


Logical migrationGoldenGate / 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

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?

MAA on OTN


Logical migrationData 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


Logical migrationCTAS / 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


Migration methodsIn 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 big-

endian 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


Migration methodsIn practice

Most common methods used thus far Combination for staged migration

CTAS/IAS or Data Pump for the initial bulk load into Exadatawhile source remains in use

Perform daily loads (external tables) into both source andExadata Initially users serviced by source database Move users over to Exadata

Stop daily load into source


Migration ScenarioFrom 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


Migration ScenarioFrom 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


Migration ScenarioFrom 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


Bulk data movement


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.


Bulk data movementNetwork

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


Bulk data movementProtocol

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


Bulk data movementProtocol

Oracle Net TCP Set SDU=32767

Yields more efficient write by Oracle Net to socket buffer


Bulk data movementSource 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


Bulk data movementTarget 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


Bulk data movementTarget 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


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


Sun Oracle Database MachineOracle Database 11g Release 2 MigrationMaximum Availability Architecture Best PracticesAgendaDatabase Machine Software ConsiderationsMigration strategyMigration strategyChoose the right migration methodMigration strategyChoose the right migration methodMigration methodsMethods overviewMigration methodsStrategy for database typesMigration methodsPhysical migrationPhysical migrationPhysical migrationMethods at a glancePhysical migrationPhysical migrationASM rebalance to Exadata storagePhysical migrationPartition roll-in, roll-out to Exadata storagePhysical migrationData Guard Physical standbyPhysical migrationPhysical standby plus database upgradePhysical migrationTransportable database (TDB)Physical migrationTransportable tablespace (TTS)Migration methodsLogical migrationLogical migrationMethods at a glanceLogical migrationLogical migrationData Guard Logical standbyLogical migrationLogical standby source system 11.2Logical migrationLogical standby source system < 11.2Logical migrationGoldenGate / StreamsLogical migrationData PumpLogical migration CTAS / IASMigration methodsIn practiceMigration methodsIn practiceMigration ScenarioFrom 11.1 HP DBMMigration ScenarioFrom 10gR2 / 11gR1 on Big EndianMigration ScenarioFrom 10gR2 / 11gR1 on Little Endian (non-DBM)Bulk data movementBulk data movementBulk data movementNetworkBulk data movementProtocolBulk data movementProtocolBulk data movementSource systemBulk data movementTarget systemBulk data movementTarget systemSummary

presentation - oracle database 11g release 2 migration maximum availability architecture best...

Documents