This document discusses Oracle's Exadata database appliance. It begins by contrasting software-defined systems with engineered appliances like Exadata. It then describes Exadata X3 specifications, architectural considerations for resource management and performance, and specific Exadata features like Smart Scan and storage indexes. Recommendations are provided for workload management and SQL. A case study shows significant performance improvements from migrating applications to Exadata. Some criticisms of Exadata are also mentioned before concluding that Exadata is well-suited for database consolidation.
2. 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
3. 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….
4. 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
5. 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?
6. 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….
7. 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
8. Exadata Smart Scan Processing
• Only the relevant columns
– customer_name
and required rows
– where amount>200
are 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;
9. 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
10. 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
11. 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
12. 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
13. SQL Recommendations
1. 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.
15. Another Large Implementation…
1
Hour
Staging Atomic Delivery
Staging Atomic Delivery
13 18.5 7
6 17 5
1
Hour
2
Hour
Scheduling
Changes Scheduling
Changes
Date
1
0.5
Hour
Index,
Parallelism
Changes
36.5
28
[Start + 4Months]
[Start]
4 +1
Hour
Code
Changes
1
Hour
Code
Changes
2
Hour
New
Changes
Date
2
Date
3
Date
2
Date
3
Date
3
Date
4
Date
5
Index
Changes
1500 Joba
16. 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!