Download Technical Overview of Oracle Exadata

Technical Overview of
Oracle Exadata
The Oracle Exadata Database Machine is an easy to deploy solution for hosting the Oracle Database that
delivers the highest levels of database performance available. The Exadata Database Machine is a cloud
in a box composed of database servers, Oracle Exadata Storage Servers, an InfiniBand fabric for storage
networking and all the other components required to host an Oracle Database. It delivers outstanding
I/O and SQL processing performance for online transaction processing (OLTP), data warehousing (DW)
and consolidation of mixed workloads. Extreme performance is delivered for all types of database
applications by leveraging a massively parallel grid architecture using Real Application Clusters and
Exadata storage. Database Machine and Exadata storage delivers breakthrough analytic and I/O
performance, is simple to use and manage, and delivers mission-critical availability and reliability.
Feature of Oracle Exadata:
1. Smart Scan :
One of the most important Exadata software features is Smart Scan. Exadata Smart Scan processes
queries at the storage layer, returning only relevant rows and columns to the database server. As a
result, much less data travels over fast 40GB InfiniBand interconnects--dramatically improving the
performance and concurrency of simple and complex queries.
Legacy Vs Exadata :
Legacy:
SQL> select count(*)
from north_pots_addenda where batch_date = '20140701' ;
COUNT(*)
---------137356344
Elapsed:
Explain Plan:
----------------------------------------------------------------------------------------| Id | Operation
| Name
| Rows | Bytes | Cost | Pstart| Pstop |
----------------------------------------------------------------------------------------|
0 | SELECT STATEMENT
|
|
1 |
6 | 38570 |
|
|
|
1 | SORT AGGREGATE
|
|
1 |
6 |
|
|
|
|
2 |
PARTITION RANGE SINGLE|
| 1300K| 7617K| 38570 |
176 |
176 |
|
3 |
INDEX FULL SCAN
| NPA_MERCH_IDX | 1300K| 7617K| 38570 |
176 |
176 |
-----------------------------------------------------------------------------------------
Note
----- 'TOAD_PLAN_TABLE' is old version
EXADATA :
SQL> select count(*)
07-01' ;
from north_pots_addenda where batch_date = date '2014-
COUNT(*)
---------137356344
Elapsed: 00:00:04.62
Explain Plan:
Plan hash value: 2266057032
------------------------------------------------------------------------------------------------| Id | Operation
| Name
| Rows | Bytes | Cost (%CPU)| Time
-----------------------------------------------------------------------------------------------|
0 | SELECT STATEMENT
|
|
1 |
8 | 80569
(2)| 00:00:04
|
1 | SORT AGGREGATE
|
|
1 |
8 |
|
|
2 |
PARTITION RANGE SINGLE
|
|
137M| 1047M| 80569
(2)| 00:00:04
|* 3 |
TABLE ACCESS STORAGE FULL| NORTH_POTS_ADDENDA |
137M| 1047M| 80569
(2)| 00:00:04
------------------------------------------------------------------------------------------------Predicate Information (identified by operation id):
--------------------------------------------------3 - storage("BATCH_DATE"=TO_DATE(' 2014-07-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
filter("BATCH_DATE"=TO_DATE(' 2014-07-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))
Note
----- automatic DOP: Computed Degree of Parallelism is 1
First query is executed in Legacy system and it took more than 2 min to scan about 137 million records,
Storage Servers delivering the full amount of data to the Database Layer.
Now the very same statement with the standard functionality Smart Scan is executed in Exadata
runtime was reduced to less than 5 seconds with Smart Scan.
Let’s examine the execution plans for the two statements. In Legacy an ordinary full table scans
happened as expected but in Exadata the Storage Layer did filter on the predicate
“storage("BATCH_DATE"=TO_DATE(' 2014-07-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss'))” before
transmitting the result to the Database Layer, which is the reason for the reduced runtime.
Exadata is not only strong hardware but also Database intelligence on the storage layer. Smart Scan
means the capability of the Storage Layer to do filtering of columns and predicates before sending the
result to the Database Layer.
2. Storage Index:
Another important feature of the Exadata Database Machine that makes it more than just a collection of
High-End Hardware are Storage Indexes. Storage Indexes are constructed automatically inside of the
memory of the Storage Servers when Database segments (like heap tables) are being scanned. The
Storage Cells are divided into 1 MB chunks and inside of these chunks, we record the minimum and
maximum values of the columns of the table that allocated space inside that chunk. Look at following
example.
So, in a very simple example, if we have an SQL predicate such as WHERE B < 2, if a corresponding
Storage Index on the B column of the first 1M region of the table has MIN=1 and MAX=3, Oracle would
need to access this portion of the table as the B value of interest could potentially exist here. However,
if the next 1M storage region had a MIN=2 and MAX=8 , then the B value of less than 2 will not scan
that portion of table and can be ignored and not accessed at all during the Smart Scan.
The Storage Indexes are created automatically and transparently based on the SQL predicate
information executed by Oracle and passed down to the storage servers from the database servers.
Storage Indexes take up no physical storage of themselves and are built and maintained entirely in
memory. As only this very basic summary information is stored for a maximum of 8 columns for each
1M of storage, Storage Indexes are very lightweight and can be created and maintained with minimal
general overheads. In below example we’ll notice that a storage index has been created and used.
SQL> select count(*) from TXN_DATA where batch_date=date '2013-12-02' ;
COUNT(*)
---------41161200
Elapsed: 00:00:02.21
SQL> select name , value/1024/1024 MB from v$statname n, v$mystat s
2 where n.statistic# = s.statistic# and n.name in
3
('cell physical IO interconnect bytes returned by smart scan',
4
'cell physical IO bytes saved by storage index');
NAME
MB
---------------------------------------------------------------- ---------cell physical IO bytes saved by storage index
172097.984
cell physical IO interconnect bytes returned by smart scan
18.7208939
Elapsed: 00:00:00.24
Database index will take precedence over storage index and in many scenarios where database indexes
are still critical for optimal performance and scalability in an Exadata environment.
3. Compression:
Hybrid Columnar Compression on Exadata enables the highest levels of data compression and provides
enterprises with tremendous cost-savings and performance improvements due to reduced I/O. HCC is
optimized to use both database and storage capabilities on Exadata to deliver tremendous space savings
AND revolutionary performance. Following are different compression method available in oracle:
1. BASIC compression, introduced in Oracle 8 already and only recommended for Data Warehouse
2. OLTP compression, introduced in Oracle 11 and recommended for OLTP Databases as well
3. QUERY LOW compression (Exadata only), recommended for Data Warehouse with Load Time as
a critical factor
4. QUERY HIGH compression (Exadata only), recommended for Data Warehouse with focus on
Space Saving
5. ARCHIVE LOW compression (Exadata only), recommended for Archival Data with Load Time as a
critical factor
6. ARCHIVE HIGH compression (Exadata only), recommended for Archival Data with maximum
Space Saving
For better understanding of all archive method see the following example:
SQL> create table comp_basic compress tablespace FDN_DATA as select * from
txn_data where 1=2;
Table created.
Elapsed: 00:00:00.10
SQL> insert /*+ append */ into comp_basic select * from txn_data
2 where load_date = date '2014-04-17' and rownum < 100000 ;
99999 rows created.
Elapsed: 00:00:06.32
SQL> create table comp_oltp compress for oltp tablespace FDN_DATA as select *
from txn_data where 1=2;
Table created.
Elapsed: 00:00:00.09
SQL> insert /*+ append */ into comp_oltp select * from txn_data
2 where load_date = date '2014-04-17' and rownum < 100000 ;
99999 rows created.
Elapsed: 00:00:06.34
SQL> create table comp_query_low compress for query low tablespace FDN_DATA
as select * from txn_data where 1=2;
Table created.
Elapsed: 00:00:00.09
SQL> insert /*+ append */ into comp_query_low select * from txn_data
2 where load_date = date '2014-04-17' and rownum < 100000 ;
99999 rows created.
Elapsed: 00:00:01.79
SQL> create table comp_query_high compress for query high tablespace FDN_DATA
as select * from txn_data where 1=2;
Table created.
Elapsed: 00:00:00.09
SQL> insert /*+ append */ into comp_query_high select * from txn_data
2 where load_date = date '2014-04-17' and rownum < 100000 ;
99999 rows created.
Elapsed: 00:00:03.37
SQL> create table comp_archive_low compress for archive low tablespace
FDN_DATA as select * from txn_data where 1=2;
Table created.
Elapsed: 00:00:00.09
SQL> insert /*+ append */ into comp_archive_low select * from txn_data
2 where load_date = date '2014-04-17' and rownum < 100000 ;
99999 rows created.
Elapsed: 00:00:06.67
SQL> create table comp_archive_high compress for archive high tablespace
FDN_DATA as select * from txn_data where 1=2;
Table created.
Elapsed: 00:00:00.09
SQL> insert /*+ append */ into comp_archive_high select * from txn_data
2 where load_date = date '2014-04-17' and rownum < 100000 ;
99999 rows created.
Elapsed: 00:00:45.52
SQL> select segment_name,bytes/1024/1024 as mb from user_segments where
segment_name
2
in
('COMP_BASIC','COMP_OLTP','COMP_QUERY_LOW','COMP_QUERY_HIGH','COMP_ARCHIVE_LO
W','COMP_ARCHIVE_HIGH')
3
order by 2;
SEGMENT_NAME
MB
----------------------------------------------------------------------------COMP_ARCHIVE_HIGH
4
COMP_ARCHIVE_LOW
5
COMP_QUERY_HIGH
6
COMP_QUERY_LOW
10
COMP_BASIC
19
COMP_OLTP
21
Except for ARCHIVE HIGH, we have faster Load Times with HCC than with Block Compression. Every HCC
method delivers a better compression ratio than the Block Compression methods.
Now let see the query time:
SQL> select count(*) from COMP_BASIC;
COUNT(*)
---------99999
Elapsed: 00:00:00.44
SQL> select count(*) from COMP_OLTP;
COUNT(*)
---------99999
Elapsed: 00:00:00.43
SQL> select count(*) from COMP_QUERY_LOW;
COUNT(*)
---------99999
Elapsed: 00:00:00.24
SQL> select count(*) from COMP_QUERY_HIGH;
COUNT(*)
---------99999
Elapsed: 00:00:00.18
SQL> select count(*) from COMP_ARCHIVE_LOW;
COUNT(*)
---------99999
Elapsed: 00:00:00.14
SQL> select count(*) from COMP_ARCHIVE_HIGH;
COUNT(*)
---------99999
Elapsed: 00:00:00.16
In above example we can see that query performance is better in HCC than Basic Compression.
Summary - HCC delivers (far) better Compression Ratios than the Block Compression methods. Load
Time increases from QUERY LOW (best) over QUERY HIGH and ARCHIVE LOW (both moderate) to
ARCHIVE HIGH (longest Load Time). Query Performance is also better in HCC.
4. Flash Cache:
The Oracle Exadata is meant to deliver high performance through its smart features. One of its smartly
carved out feature is intelligent and very smart flash cache. The flash cache is a hardware component
configured in the exadata storage cell server which delivers high performance in read and write
operations. There are four flash cards in each of the storage cell and each flash card contains a flash
disk. In total, there are 16 flash disk contained by a single storage cell server.
In Exadata x3 version, the flash cache capacity has been increased by four times, 40 times the response
speed and 100GB/sec scan rates. In X3 version, the Sun flash F40 PCIe cards total upto 22.4 TB of flash
compared to 5.4TB from the X2 version. In addition, they are capable of scanning the data 1.4 times
faster than X2 version. The flash belongs to eMLC category (enterprise grade multi-level cell) which
employs different techniques to improve flash health, endurance and most importantly, accommodate
more write cycles (20k to 30k).