10.07.2015 Views

Expert Oracle Exadata - Parent Directory

Expert Oracle Exadata - Parent Directory

Expert Oracle Exadata - Parent Directory

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

CHAPTER 3 HYBRID COLUMNAR COMPRESSIONSerial Direct Path Reads are enabled based on a calculation that depends on the size of the object beingscanned relative to the available buffer cache. In simplistic terms, only large objects will be consideredfor Serial Direct Path Reads. HCC’s effectiveness can actually work against it here. Since the compressionreduces the size of the objects so drastically, it can cause statements that would normally benefit from aSmart Scan to use the standard read mechanism, disabling many of <strong>Exadata</strong>’s optimizations. This isgenerally not a huge problem, because the number of blocks is considerably reduced by HCC and thedatabase is making this decision at run time. The problem comes in, though, when an object ispartitioned. The calculation is based on the size of the object being scanned; in the case of a partitionedobject this means the size of the partition. So in cases where partitioning is used with HCC, we often seesome partitions using Smart Scans and some unable to use Smart Scans. Keep in mind that this alsomeans decompression cannot be done at the storage layer, as this capability is enabled only whenperforming Smart Scans.■ Kevin Says: Compression also has a lot to do with the often-overlooked In-Memory Parallel Query feature of<strong>Oracle</strong> Database 11g. Very effective compression combined with modern large memory servers makes In-MemoryParallel Query a usable feature for production purposes. Customers would do well to consider the bestcompression technology that suits their DML processing requirements while potentially exploiting the power of In-Memory Parallel Query.Locking IssuesThe <strong>Exadata</strong> documentation says that updating a single row of a table compressed with HCC locks theentire compression unit containing the row. This can cause extreme contention issues for OLTP-typesystems. This is the main reason that HCC is not recommended for tables (or partitions) where the datawill be updated. Here’s a demonstration of the locking behavior:KSO@SANDBOX1> select rowid, old_rowid(rowid) old_rowid , pk_col from kso.skew_hcc32 where rownum < 10;ROWID OLD_ROWID PK_COL------------------ ------------------------------ ----------AAATCBAAHAAMkyXAAA 7.3296407.0 27999409AAATCBAAHAAMkyXAAB 7.3296407.1 27999408AAATCBAAHAAMkyXAAC 7.3296407.2 27999407AAATCBAAHAAMkyXAAD 7.3296407.3 27999406AAATCBAAHAAMkyXAAE 7.3296407.4 27999405AAATCBAAHAAMkyXAAF 7.3296407.5 27999404AAATCBAAHAAMkyXAAG 7.3296407.6 27999403AAATCBAAHAAMkyXAAH 7.3296407.7 27999402AAATCBAAHAAMkyXAAI 7.3296407.8 279994019 rows selected.KSO@SANDBOX1> update kso.skew set col1=col1 where pk_col = 27999409;1 row updated.101

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!