key to a successful exadata poc - umair...

Key to A Successful Exadata POC

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

Umair MansoobKey to A Successful Exadata POC

Overview

Umair Mansoob

Plan AnalyzeOptimizeMigrate Test

Key to A Successful Exadata POC

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 , sostart 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 rolesin successful

If possible , test your scripts on NON EXADATA system before thePOC


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 ornot

You can use many Oracle Native tools like AWR Report, ASH reportand SQL Tuning set

SQL performance analyzer can be used to compare resultsbetween non-Exadata and Exadata system

Make sure , you capture the baseline from target non-exadatasystem.


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


• RMAN

• Data GuardPhysical

• Data Pump

• Insert as SelectLogical

Source Exadata

Migrate Each migration method has its own pros and cons, so analyze themcarefully based on your requirements

Data migration methods can be categorized as physical migrationor logical migration.

You should run exachk utility to review and implement Exadatabest practices.

Physical migration is a block by block copy of data, popularmethods 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 andstraight forward.

Pro : Support cross platform Migrations using RMAN transportabledatabase.

Con : Bring all the characteristics of target database, which mightnot be optimal.

Con : Will require extra effort to implement Exadata best practicesand enable features like compression.


Logical Migration Pro : Exadata best practices will already be in place , if databasewas created using DBCA utility.

Pro : Can POC Exadata specific feature like compression and storageindexes

Con : Not simple , will require extra effort and time to bring dataover to Exadata machine

Con : Since its not a block by block copy , execution plans canchange.


Transferring Data

It is important to mask or encrypt data before you move intoExadata 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 longrunning queries during your POC

Don’t pick too big that it takes days to transfer database to POCmachine


Optimize


Optimize

Smart Scan

Partitioning

Compression

Optimize

You should look into testing following Exadata Features during yourPOC.

Compression not only reduces your storage footprint but alsoimprove performance.

Even though offloading and smart scan are enabled by default butmake sure they are turned on and performing as expected.

Test Storage indexes by making but selected non primary keyindexes 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 compressionand it will also support DML operations.

Please note that there will be some overhead and you will needadvance compression license to use OLTP compression.

You can get extremely good compression ratio with HybridColumnar compression but OLTP operations are not supported


Smart Flash Cache

Exadata smart flash cache has an ability to move data in and outfrom cache based on usage.

It is enabled by default, you don’t have to configure anything toenable it.

if enable , Write back flash cache provides the ability to write I/Osdirectly to PCI flash

Write-back cache can help reduce “"free buffer waits" waits forwrite intensive applications.


Offloading / Smart Scan Exadata extreme performance is archive through offloading andsmart scan.

Offloading means some of Oracle processes are offloaded toExadata Storage node.

Oracle processes that can be offloaded to storage nodes areincremental backups, Data File creation, decompression anddecryption

There are some pre-requisites for smart scan like direct path readand full table scan.


Storage Indexes

Storage indexes are memory structure at storage level.

they reduce Disk I/O by maintaining an entry for minimum andmaximum value for data per 1 MB by default.

You can drop most non-primary key indexes and force queries touse Storage indexes.

Usually BITMAP indexes are ideal candidates for offloading queriesto 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 consolidatemultiple databases to target Exadata Machine.


Analyze

• AWR

• ASH

• STS

Compile

• Elapse time

• CPU

• SPA

Compare• 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 sqlstatements

If possible , run SQL performance analyzer to compare sqlperformances 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 orprocess

Next steps


Thank You


Umair Mansoob

773-297-2061

[email protected]

http://blog.umairmansoob.com/

mailto:[email protected]

http://blog.umairmansoob.com/

key to a successful exadata poc - umair...

Documents