BY UMAIR MANSOOB
Who Am I Oracle Certified Administrator from Oracle 7 12c Exadata Certified Implementation Specialist since 2011 Oracle Database Performance Tuning Certified Expert Oracle Business Intelligence Foundation Suite 11g Certified Implementation Specialist Oracle Database Data Warehousing Certified Implementation Specialist Multiple Exadata Implementations / POC s for large financial organizations Migrate / Upgrade databases between various versions of Oracle Capacity Planning for Oracle Engineered Systems Database Consolidation to Exadata / 12c Platform Architect Databases for OLTP and OLAP applications Not an Oracle Employee or Nor I represent Oracle in any way
Overview Plan Migrate Optimize Test Analyze
Plan Start Early Identify Targets Capture Statistics Data Migration Success Criteria
Start Early Most cases you will only get 2-3 weeks to do an EXADATA POC, so start early If you are not ready, you will end up losing very valuable time. It is important for note that dedicated resources can play a key roles in successful If possible, test your scripts on NON EXADATA system before the POC
Identify Targets You should identify all the process and sql s, which will be part of your POC. How you go about picking targets for your POC will depend on your target application It is best to pick your targets based on criticality, elapse time and resource utilization It is import to understand that you might not be able to test all the statements and process running on target system during your POC
Capture Statistics You will need captured statistics to declare your POC successful or not You can use many Oracle Native tools like AWR Report, ASH report and SQL Tuning set SQL performance analyzer can be used to compare results between non-exadata and Exadata system Make sure, you capture the baseline from target non-exadata system.
Data Migration You will be needing to migrate data to Exadata machine for your POC. It will best if you choose same migration method that you are planning to use for actual migration. Lot of customer run in issues during data migration and end up wasting valuable time during POC You might have to get proper approval to migration data and may be following specific guidelines.
Success Criteria You should also clearly define a success criteria before the start your POC. Success criteria should not be verbal or vague like 30% increase or 200% increase in performance. Share your success criteria between all the parties involves in POC including Oracle folks. A lot of customer seems to only care about elapse time, can be deceptive.
Migrate Source Exadata Physical RMAN Data Guard Logical Data Pump Insert as Select
Migrate Each migration method has its own pros and cons, so analyze them carefully based on your requirements Data migration methods can be categorized as physical migration or logical migration. You should run exachk utility to review and implement Exadata best practices. Physical migration is a block by block copy of data, popular methods are data guard and RMAN. Popular logical methods are data pump or insert as select.
Physical Migration Pro : Migrating data using physical methods can be very simple and straight forward. Pro : Support cross platform Migrations using RMAN transportable database. Con : Bring all the characteristics of target database, which might not be optimal. Con : Will require extra effort to implement Exadata best practices and enable features like compression.
Logical Migration Pro : Exadata best practices will already be in place, if database was created using DBCA utility. Pro : Can POC Exadata specific feature like compression and storage indexes Con : Not simple, will require extra effort and time to bring data over to Exadata machine Con : Since its not a block by block copy, execution plans can change.
Transferring Data It is important to mask or encrypt data before you move into Exadata POC Machine. You might need to get proper approval for certain types of data. Don t pick something too small that you are not able to run long running queries during your POC Don t pick too big that it takes days to transfer database to POC machine
Optimize Compression Partitioning Smart Scan Optimize
Optimize You should look into testing following Exadata Features during your POC. Compression not only reduces your storage footprint but also improve performance. Even though offloading and smart scan are enabled by default but make sure they are turned on and performing as expected. Test Storage indexes by making but selected non primary key indexes invisible.
Compression Regardless of Exadata, Oracle has two native compression types, basic table compression and OLTP Compression You can get reasonable compression ratio with OLTP compression and it will also support DML operations. Please note that there will be some overhead and you will need advance compression license to use OLTP compression. You can get extremely good compression ratio with Hybrid Columnar compression but OLTP operations are not supported
Smart Flash Cache Exadata smart flash cache has an ability to move data in and out from cache based on usage. It is enabled by default, you don t have to configure anything to enable it. if enable, Write back flash cache provides the ability to write I/Os directly to PCI flash Write-back cache can help reduce "free buffer waits" write intensive applications. waits for
Offloading / Smart Scan Exadata extreme performance is archive through offloading and smart scan. Offloading means some of Oracle processes are offloaded to Exadata Storage node. Oracle processes that can be offloaded to storage nodes are incremental backups, Data File creation, decompression and decryption There are some pre-requisites for smart scan like direct path read and full table scan.
Storage Indexes Storage indexes are memory structure at storage level. they reduce Disk I/O by maintaining an entry for minimum and maximum value for data per 1 MB by default. You can drop most non-primary key indexes and force queries to use Storage indexes. Usually BITMAP indexes are ideal candidates for offloading queries to Storage Indexes.
Test Start Testing Testing Methodologies Testing Variation
Start Testing Testing should include should include all the variation you want to test during your POC. You can a test like for like, which means you are not planning to make any changes to your database architecture like compression, partition or encryption There are different type of tests you can run during your POC, like Performance test, load test, break test. Don t forget to capture statistics during test phase of POC.
Testing Methodologies Remember you are moving your application to new hardware You might be changing underline hardware system for your database You might be moving from NON-RAC to RAC database system Performance testing provides most important statistics for your POC Some customer like to perform failover and break test for their critical applications
Testing Variation Test Like for Like, No changes to database architecture. Test compression, Compress only selected tables. Without Indexes, make non-primary key indexes invisible. Test Write Back-Cache feature, for write intensive applications. Test Exadata IORM feature, if you are planning to consolidate multiple databases to target Exadata Machine.
Analyze AWR ASH STS Compile Compare Elapse time CPU SPA Success Criteria Next Steps Conclude
Compile Collect AWR reports from source system & target system to compression Collect ASH report for important SQL and critical processes If you have install OS watcher, collect logs Run and collect exachk report for POC Exadata machine
Compare Compare AWR reports between source and target Exadata system Compare Resource utilization between source and target Exadata system Compare Elapse time for all the critical processes and sql statements If possible, run SQL performance analyzer to compare sql performances between source and target system
Conclude Now it is time to conclude your POC Check if POC meet your success criteria fully or partially Part of POC might not meet your success criteria You might have to spend some cycle to improve slow running sql or process Next steps
Thank You 773-297-2061 umairmansoob@gmail.com http://blog.umairmansoob.com/