Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Concurrency control wikipedia , lookup
Entity–attribute–value model wikipedia , lookup
Microsoft Jet Database Engine wikipedia , lookup
Functional Database Model wikipedia , lookup
Oracle Database wikipedia , lookup
Extensible Storage Engine wikipedia , lookup
Open Database Connectivity wikipedia , lookup
Microsoft SQL Server wikipedia , lookup
Clusterpoint wikipedia , lookup
Relational model wikipedia , lookup
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).