Migrating databases to exadata database machine
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Migrating databases to exadata database machine

on

  • 1,382 views

EXADATA Migration

EXADATA Migration

Statistics

Views

Total Views
1,382
Views on SlideShare
1,382
Embed Views
0

Actions

Likes
0
Downloads
52
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft Word

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Migrating databases to exadata database machine Document Transcript

  • 1. Migrating Databases to Exadata Database Machine 1. Performing Capacity Planning The biggest Database Machine capacity planning challenge is understanding the difference between your existing storage and Exadata storage. 1. Collect the size and throughput of your current system based on growth, I/O which can be measured by AWR report. 2. Determine the required number of Exadata cells based on capacity of your current system and the appropriate Database Machine storage configuration. 3. Verify cell throughput by running the CALIBRATE command. By using Exadata Smart Flash Cache and Exadata Hybrid Columnar Compression need to be consideered to achieve much greater effective throughpu. 4. Ensure I/O capacity is sufficient to meet the redundancy requirements and performance service levels though exadata cell and disk failures are transparently tolerated using Automatic Storage Management (ASM) redundancy. ASM and database best practice configuration supplied during Exadata deployment should be retained during and after migration
  • 2. Database Machine Migration Considerations • Database Machine is a 64-bit Intel-based platform. The byte order is little-endian. • The Exadata Storage Server, ASM, and database software on Database Machine must be release 11.2.0.1 or later. • ASM disk group attributes (these are not mandatory, they are highly recommended in order to enable all the Exadata Storage Server features and to optimize performance): • COMPATIBLE.ASM=11.2.0.0.0 • COMPATIBLE.RDBMS=11.2.0.0.0 • CELL.SMART_SCAN_CAPABLE=TRUE • AU_SIZE=4M • For better performance , the ASM disk group allocation unit size (AU_SIZE) should be set to 4 MB and the database extent sizes should be a multiple of 4 MB. 2. Choosing the Right Migration Path • Determine what to migrate. – Avoid methods that migrate what you will discard. • Consider the configuration of the source system. – Source Oracle Database version and platform matter. – Target system is fixed: 11.2, ASM, little-endian. • Weigh up the costs and favor methods that facilitate best practices. – Implementing best practices is important in the long term because your future performance depends on it.
  • 3. – Remember: — ASM 4 MB AU size can be set only at disk group creation. — Database extent sizes are set at extent allocation. Synergy between Hardware and Software: – Smart Scans – Storage Indexes – Hybrid Columnar Compression – Smart Flash Cache – High Speed InfiniBand Backbone 3. Migration: Physical or logical Logical migration methods allow more flexibility than physical methods to change the database structure for best performance. Using a logical approach, one can change the database extent size and alter other physical characteristics of the database, such as the database character set, which is not possible by using a physical migration approach. Logical standby database Create logical standby on 11.2 Sun Oracle Database Machine
  • 4. Change table storage characteristics, as desired (Note:737460.1) – Data Pump Unload/Load Data Guard switchover Optionally – combine with Database Upgrade (Note #1055938.1) Streams/ GoldenGate 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 Data Pump Create Exadata database Import user data into Exadata using Data Pump o Network mode -Direct import from source via dblink o File mode -Export to dump file(s), transfer file(s), Import Export all Metadata Create all objects (no data) in Exadata, except MVs Disable triggers, constraints and drop indexes Export all data from source Import all data to Exadata Create indexes of the schema after it’s imported Enable constraints and triggers Import Metadata one last time
  • 5. ASM Rebalance to Exadata Storage  Connect Exadata storage to existing database nodes  ADD grid disks to existing ASM disk groups, DROP legacy  storage from existing ASM disk groups  Transportable Database (Note:732053.1)  RMAN CONVERT DATABASE ON TARGET to generate scripts.  Transfer datafiles to Exadata Storage and Run scripts. Physical standby database  Create Physical Standby on Sun Oracle Database Machine  Data Guard switchover  Optionally Upgrade to 11.2 (Note #1055938.1) Transportable Database (Note:732053.1)  RMAN CONVERT DATABASE ON TARGET to generate scripts.  Transfer datafiles to Exadata Storage and Run scripts. Transportable Tablespace (TTS)
  • 6.  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 A database specific method to migrate the database, for example, RMAN active duplication, Database hot backup/restore and Physical standby don't need to perform the data comparison as for the entire database copy to the exadata. But some other method that doesn't guarantee that the entire data copy to the exadata, then data comparison is required. 4. Post-Migration Best Practices • Check whether ASM disk groups are balanced: – Manual rebalance might be needed. – Script available at My Oracle Support bulletin 367445.1 – Enterprise Manager alert for disk group imbalance • Assess index requirements: – With Exadata, full scans might deliver acceptable performance. – Determine indexes that are not required and remove them. • Configure I/O Resource Management.