-
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
2009 Oracle Corporation 4
-
Migration strategy
2009 Oracle Corporation 5
-
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
2009 Oracle Corporation 6
-
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)
2009 Oracle Corporation 7
-
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
2009 Oracle Corporation 8
-
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
2009 Oracle Corporation 9
-
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 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
2009 Oracle Corporation 13
-
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
2009 Oracle Corporation 15
-
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
2009 Oracle Corporation 16
-
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
2009 Oracle Corporation 17
-
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
2009 Oracle Corporation 18
-
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
2009 Oracle Corporation 19
-
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
2009 Oracle Corporation 20
-
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
2009 Oracle Corporation 21
-
Logical migrationMethods 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 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
2009 Oracle Corporation 23
-
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?
2009 Oracle Corporation 24
-
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
2009 Oracle Corporation 25
-
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
2009 Oracle Corporation 26
-
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
2009 Oracle Corporation 27
-
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
2009 Oracle Corporation 28
-
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
2009 Oracle Corporation 29
-
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
2009 Oracle Corporation 30
-
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
2009 Oracle Corporation 31
-
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
2009 Oracle Corporation 32
-
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
2009 Oracle Corporation 33
-
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
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 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
2009 Oracle Corporation 37
-
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
2009 Oracle Corporation 38
-
Bulk data movementProtocol
Oracle Net TCP Set SDU=32767
Yields more efficient write by Oracle Net to socket buffer
2009 Oracle Corporation 39
-
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
2009 Oracle Corporation 40
-
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
2009 Oracle Corporation 41
-
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
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
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