Expert Oracle Exadata - Parent Directory

CHAPTER 13 MIGRATING TO EXADATA Kevin Says: During Technical Review I approached this chapter with skepticism. In my thinking, the idea of anentire chapter dedicated to migrating a database to the Exadata Database Machine seemed like a waste of space.Allow me to explain.I routinely remind people that unless Exadata Hybrid Columnar Compression (EHCC) is being used, there is nodifference between data segments stored in Exadata Storage Server cells and those in conventional storage. TheOracle Database software deployed in the Exadata Database Machine is Oracle Database 11g—with a very smallamount of code that knows how to compress data into EHCC form and otherwise interface with Exadata via iDB. Iconducted my first review pass of this chapter with the mindset of an imaginary customer who, for whateverreason, finds no need for EHCC. With that mindset I expected this chapter to be nothing more than an overview ofdatabase migration concepts, an occasional reference to Oracle product documentation, and perhaps, a paragraphor two of special handling considerations for EHCC. However, after my first reading of the chapter I felt compelledto add this note to the reader. Even if you know everything there is to know about database migration, in thecontext of Oracle database, I encourage you to read this chapter. Having said that, I still wish to reinforce theprinciple that there is no difference between a database stored in Exadata Storage Server cells and one stored inconventional storage—unless HCC is involved. To end up with an Oracle database stored in Exadata StorageServer cells, you have to flow the data through the database grid using the same tools used for any other migrationto Oracle. However, I believe that the principles conveyed in this chapter will be quite helpful in any migrationscenario to Oracle. I consider that a bonus!Migration StrategiesOnce you have a good understanding what Exadata is, and how it works, you are ready to start thinkingabout how you are going to get your database moved. Migration strategies fall into two generalcategories, logical migration and physical migration. Logical migration involves extracting the data fromone database and loading it into another. Physical migration refers to lifting the database, block byblock, from one database server and moving it to another. The data access characteristics of yourdatabase are a key consideration when deciding which migration method is best. This is primarilybecause of the way the data is accessed on Exadata. OLTP databases tend to use single block reads andupdate data across all tables, whereas Data Warehouse (DW) databases are typically optimized for fulltable scans and only update current data. Exadata uses Flash Cache on the storage cells to optimizesingle block reads and improve the overall performance for OLTP databases. For DW databases Exadatauses Smart Scan technology to optimize full table scans. The details of these two optimization methodsare covered in Chapters 2 and 5. Logical migration allows you the opportunity to make changes to yourdatabase to optimize it for the Exadata platform. Such changes might include resizing extents,implementing or redesigning your current partitioning schemes, and compressing tables using HCC.These are all very important storage considerations for large tables and especially so for DW databases.Because OLTP applications tend to update data throughout the database, HCC compression is not a420