All (that I know) About Exadata!

Prasad Chitta

Agenda

• Technology Trends– Software Defined Everything vs Engineered Appliances

• Exadata X3 Specifications – Compute, Storage, Network & Software

• Architectural Considerations– Resource Management, Performance, High Availability

• Exadata Specific Features Explained– Smart Scan, Storage Indexes, HCC, Smart Flash Cache

• Exadata Specific Recommendations– And results from a Practical Implementations

• Finally, Some Criticism

Technology Trends

• Software Defined Everything…– (some times) Open

source– Virtualization– SDN– Highly Customizable – May involve multiple

vendors– Google like…

• Engineered Systems– Hardware aware

software– Software aware

hardware– Optimized (for a

workload)– One vendor for complete

ownership– Apple like….

Exadata Specifications

Welcome to the Oracle’s Engineered Database Appliance with intelligent Exadata storage and Infiniband Connectivity….

From: http://www.oracle.com/technetwork/server-storage/engineered-systems/exadata/dbmachine-x3-twp-1867467.pdf

Architectural Considerations

• Exadata comes in its own predefined size / Capacity – “capacity planning” is really “resource

management” – Suited for consolidation – Instance Caging, DBRM and IORM • One database with multiple schemas?• Multiple databases?• Mixed, multi-workload consolidation?

Architectural Considerations

• Performance – Smart Scans or Query Offloading– Storage Indexes– Hybrid Columnar Compression (HCC) – Smart flash cache

• High Availability– X3-2 is built in RAC capabilities for local failover– A “DR” is still needed….

Traditional Scan Processing

• With traditional storage, all database intelligence resides in the database hosts

• Very large percentage of data returned from storage is discarded by database servers

• Discarded data consumes valuable resources, and impacts the performance of other workloads

I/Os Executed:1 terabyte of data returned to hosts

DB Host reduces terabyte of data to 1000 customer names that are returned to client

Rows Returned

SELECT customer_name FROM calls WHERE amount > 200;

Table Extents Identified

I/Os Issued

Exadata Smart Scan Processing• Only the relevant columns

– customer_nameand required rows – where amount>200are are returned to hosts

• CPU consumed by predicate evaluation is offloaded

• Moving scan processing off the database host frees host CPU cycles and eliminates massive amounts of unproductive messaging– Returns the needle, not the

entire hay stack

2MB of data returned to server

Rows Returned

Smart Scan Constructed And Sent To Cells

Smart Scan identifies rows and columns within terabyte table that match request

Consolidated Result Set Built From All Cells

SELECT customer_name FROM calls WHERE amount > 200;

Storage Index explained….

• A –ve index built automatically

http://www.oracle.com/technetwork/issue-archive/2011/11-may/o31exadata-354069.html

select avg(amt) from sales where cust_level = 3

EHCC explained….

• Hybrid Columnar Compression – Row major– Column major– Hybrid / Bank (compression unit ‘CU’) major

http://www.oracle.com/technetwork/middleware/bi-foundation/ehcc-twp-131254.pdf

Flash Cache – The OLTP acceleration..

• Flash Cache for Objects– ALTER TABLE customers STORAGE

(CELL_FLASH_CACHE KEEP) • Flash Logging– log_file_sync events?

http://www.oracle.com/technetwork/server-storage/engineered-systems/exadata/exadata-smart-flash-cache-366203.pdf

Workload Management Recommendations

•Separate the database instances that are processing completely separate subject areas that do not need linking. E.g., APP1 and APP2 need not share the same database.

•Separate DEV/QA Environments from the production instances

Run Multiple Databases

•Use different services and server pools within a given instance to isolate different services for different workloads

•Each service uniquely identifies the type of workload and can be tied to a server pool if needed.

Design Services to isolate Load, Transform &

Reporting Streams

•Use as many as qualifiers to associate a user session to resource consumer groups like Service, User, Client User, Client program, module, action etc.

•Design simple high level plans using mgmt_p1, mgmt_p2 parameters

DBRM and IORM design to allocate and limit resources within and across databases

http://www.oracle.com/technetwork/database/features/availability/exadata-consolidation-522500.pdf

SQL Recommendations1. Smart scan: Use suitable selection and projection on the SQL queries with operators that can be cell

offload. Take the free flash course - http://apex.oracle.com/pls/apex/f?p=44785:24:0:::24:P24_CONTENT_ID,P24_PREV_PAGE:5827,1 Determine if _serial_direct_read=TRUE will help your session.

2. Avoid concurrent reads and updates to the same table blocks. When blocks are not current, smart scan cannot happen.

3. Storage indexes: Use an ordered load of tables where possible for exploiting the storage indexes (read more on http://www.oracle.com/technetwork/issue-archive/2011/11-may/o31exadata-354069.html )

4. Consider creating indexes only when the data accessed is < 1% of the total rows in the table.

5. Avoid having LOB columns along with the other columns in the table.

6. Consider Hybrid columnar compression to the tables that are always truncated and loaded. This will help the tables with > 255 columns also to be offloaded.

7. Partition large tables either using range partitions or hash partitions.

8. Use direct read and write wherever possible.

9. Avoid row-by-row operations and use bulk operations.

10. Avoid updates / deletes to the data when possible. Consider achieving the result by copying the data using CATS (Create table as select) in parallel and nologging mode.

A Practical ImplementationAPP_NAME Superdome

(in Mins)Exadata (in Mins)

Improvement Over Superdome

(in Mins)%

Improvement

APP1 117.53 1.78333 115.75 98%App2 157.08 8.55 148.53 95%APP3 48.92 3.01 45.91 94%App4 68.27 5.4 62.87 92%APP5 276.00 24.48 251.52 91%App6 146.15 13.28 132.87 91%APP7 129.73 12.07 117.66 91%App8 33.35 3.78 29.57 89%APP9 113.00 13.00 100.00 88%

App10 101.48 12.02 89.46 88%APP11 6.23 0.77 5.46 88%App12 198.00 25.74 172.26 87%APP13 18.77 2.50 16.27 87%App14 55.83 7.92 47.91 86%APP15 16.85 2.68 14.17 84%App16 66.58 11.98 54.60 82%APP17 59.98 13.08 46.90 78%App18 44.70 9.79 34.91 78%APP19 132.03 32.56 99.47 75%App20 5.13 1.27 3.86 75%APP21 108.32 30.60 77.72 72%App22 166.95 64.46 102.49 61%APP23 110 46.30 63.70 58%App24 60.17 26.02 34.15 57%App25 8 3.81 4.19 52%App26 4.28 2.29 1.99 47%App27 15.88 11.15 4.73 30%

Another Large Implementation…

1Hour

Staging Atomic Delivery

Staging Atomic Delivery

13 18.5 7

6 17 5

1Hour

2Hour

SchedulingChanges Scheduling

Changes

Date1

0.5Hour

Index, Parallelism

Changes

36.5

28

[Start + 4Months]

[Start]

4 +1Hour

CodeChanges

1Hour

CodeChanges

10.5HOURS

2 Hour

New Changes

Date 2

Date 3

Date 2

Date 3

Date 3

Date 4

Date 5

2HOURSIndex

Changes

1500 Joba~1500 jobs, 140 TB of I/O per cycle

Some Criticism…

• Software based acceleration is not guaranteed to work….

• It is still Oracle… • Does “Flash Cache” in Exadata really improve

performance?• etc..,

• But, if you really want a OLTP + DW database appliance based consolidation solution, EXADATA is here to stay!

LinkedIn: http://www.linkedin.com/in/prasadchittaBlog: http://technofunctionalconsulting.blogspot.com

http://www.oracle.com/us/products/database/exadata/overview/index.html

http://www.oracle.com/technetwork/server-storage/engineered-systems/exadata/index.html

And

Google “exadata” for latest updates! All the best!!