I've been told "Golden Gate will support compressed tables...soon" for literally years now by multiple people at Oracle. My first SR on this was opened on March 29th, 2010, nearly 2 years ago! That SR's resolution was to add me to bugs:
bugdb - 9416239 which tracks SUPPORT of OLTP TABLE COMPRESSION
bugdb - 9428399 which tracks exadata V2 HCC compression
bugdb – 9426065 - SUPPORT ORACLE COMPRESSED TABLES
Mining compressed tables is a necessary requirement for many large databases that use CDC...especially databases in Exadata, where you're all but expected to make use of Hybrid Columnar Ccompression (HCC). Think of all the benefits of compression in your database:
1. Compressed data means smaller datafiles, which means faster restore times, improving your RTO.
2. Your 8k block actually stores more than 8k of data which means you need to read/write fewer blocks. Since the blocks are stored compressed in memory, it also means you increase the amount of data in the same size of your db cache. As the blocks move from memory to disk, it improves your potential IOPS capacity. Ok, not really increasing IOPS capacity, but increasing the amount of data you can move per IO, which has a similar effect.
3. Compression means less storage requirements which in turn mean less storage costs.
In a previous post, I mentioned how, when I first started looking at Golden Gate with Exadata, I found that not only were compressed tables not captured, if GG came across a logged change of a compressed table in the archivelogs or redo, it would abend...even if it was a table that was excluded from capture. We submitted a prio 1 SR and Oracle created a patch for this-so we were able to begin using GG with Exadata...but all tables that used compression were excluded from GG capture because of this limitation-put another way, we were forced to not compress tables that needed to be captured. Those were all the biggest, most compressible tables. This forced my client to use much more storage in their Exadata cells than they anticipated, and today they're preparing to buy additional storage cells, partially because of this limitation.
Imagine the fun they had explaining to their management they need hundreds of thousands of dollars to purchase additional storage from Oracle, ultimately due to an Oracle bug. :) Come to think of it...no wonder it took Oracle 2 years to fix this! :)
Not to get too off track, but for a truly high-performance database, you should really test how advanced compression affects your system performance. Your milage will vary, but based on my testing, I would expect it to improve your performance. See http://otipstricks.blogspot.com/2011/02/exadata-index-dropping-and-compression.html. There are other huge performance improvements 11.2.0.3 offers for Exadata, especially for OLTP environments.
Performance aside, IMHO you should begin to prepare for the upgrade to 11.2.0.3 PB 3 to take advantage of this new GG feature/bug fix, so you're ready to go when the new version of GG is released.
I have no special knowledge from a friend at Oracle this time...I'm gleaning this from a statement in a PDF from Douglas Reid, Oracle GoldenGate product mgmt. GG 11.2.1 will have tighter integration with XStream Out API (Capture), which means GG will be using a call to a procedure already in the Oracle kernel. That internal call will be what handles OLTP and HCC compression, which to this point hasn't been possible. Soooo...based on the schedule in that PDF of the approx March/April release of GG 11.2.1, there must be, prior to that time, a database change to allow that. Since we can't do it in 11.2.0.3 PB2 and its going to happen in the next several weeks...it must be coming in PB3. The release schedule "remains at the discretion of Oracle"...but short of mind reading, this is the best we've got.
So, 11.2.0.3PB3 will be out w/in the next few weeks. Based on the previous release cycles of patch bundles, it will be sooner than that. I would guess sometime this week Exadata 11.2.0.3 PB 3 will be released (it requires Exadata Storage Server 11.2.2.4.) Check Metalink note 888828.1 for updates...by the time you read this, you'll likely see 11.2.0.3 PB3 listed in that note...if not, check back in a few days. (Add that note to your MOS favourites by clicking the little star on it. Its the best source to find what's currently GA.)
To sum it up, when you use GG 11.2.1 with Exadata 11.2.0.3 PB3, you'll be able to FINALLY mine compressed tables in Goldengate.
I could be wrong, but my impression is that a lot of people at different companies are using Goldengate with Exadata. "Extreme Goldengate Performance on Exadata" is one of my most popular posts. Given the cost per GB of storage in Exadata, compression could save you a *huge* amount of money. Once GG 11.2.1 is released, the only reason I can think of NOT to compress everything you can is that your access patterns don't work well with it...assuming the budget that was big enough to buy Exadata is also big enough to license compression. ;)
After ~2 years of waiting for these 3 bugs to be fixed, the wait is finally over.
bugdb - 9416239 which tracks SUPPORT of OLTP TABLE COMPRESSION
bugdb - 9428399 which tracks exadata V2 HCC compression
bugdb – 9426065 - SUPPORT ORACLE COMPRESSED TABLES
Mining compressed tables is a necessary requirement for many large databases that use CDC...especially databases in Exadata, where you're all but expected to make use of Hybrid Columnar Ccompression (HCC). Think of all the benefits of compression in your database:
1. Compressed data means smaller datafiles, which means faster restore times, improving your RTO.
2. Your 8k block actually stores more than 8k of data which means you need to read/write fewer blocks. Since the blocks are stored compressed in memory, it also means you increase the amount of data in the same size of your db cache. As the blocks move from memory to disk, it improves your potential IOPS capacity. Ok, not really increasing IOPS capacity, but increasing the amount of data you can move per IO, which has a similar effect.
3. Compression means less storage requirements which in turn mean less storage costs.
In a previous post, I mentioned how, when I first started looking at Golden Gate with Exadata, I found that not only were compressed tables not captured, if GG came across a logged change of a compressed table in the archivelogs or redo, it would abend...even if it was a table that was excluded from capture. We submitted a prio 1 SR and Oracle created a patch for this-so we were able to begin using GG with Exadata...but all tables that used compression were excluded from GG capture because of this limitation-put another way, we were forced to not compress tables that needed to be captured. Those were all the biggest, most compressible tables. This forced my client to use much more storage in their Exadata cells than they anticipated, and today they're preparing to buy additional storage cells, partially because of this limitation.
Imagine the fun they had explaining to their management they need hundreds of thousands of dollars to purchase additional storage from Oracle, ultimately due to an Oracle bug. :) Come to think of it...no wonder it took Oracle 2 years to fix this! :)
Not to get too off track, but for a truly high-performance database, you should really test how advanced compression affects your system performance. Your milage will vary, but based on my testing, I would expect it to improve your performance. See http://otipstricks.blogspot.com/2011/02/exadata-index-dropping-and-compression.html. There are other huge performance improvements 11.2.0.3 offers for Exadata, especially for OLTP environments.
Performance aside, IMHO you should begin to prepare for the upgrade to 11.2.0.3 PB 3 to take advantage of this new GG feature/bug fix, so you're ready to go when the new version of GG is released.
I have no special knowledge from a friend at Oracle this time...I'm gleaning this from a statement in a PDF from Douglas Reid, Oracle GoldenGate product mgmt. GG 11.2.1 will have tighter integration with XStream Out API (Capture), which means GG will be using a call to a procedure already in the Oracle kernel. That internal call will be what handles OLTP and HCC compression, which to this point hasn't been possible. Soooo...based on the schedule in that PDF of the approx March/April release of GG 11.2.1, there must be, prior to that time, a database change to allow that. Since we can't do it in 11.2.0.3 PB2 and its going to happen in the next several weeks...it must be coming in PB3. The release schedule "remains at the discretion of Oracle"...but short of mind reading, this is the best we've got.
So, 11.2.0.3PB3 will be out w/in the next few weeks. Based on the previous release cycles of patch bundles, it will be sooner than that. I would guess sometime this week Exadata 11.2.0.3 PB 3 will be released (it requires Exadata Storage Server 11.2.2.4.) Check Metalink note 888828.1 for updates...by the time you read this, you'll likely see 11.2.0.3 PB3 listed in that note...if not, check back in a few days. (Add that note to your MOS favourites by clicking the little star on it. Its the best source to find what's currently GA.)
To sum it up, when you use GG 11.2.1 with Exadata 11.2.0.3 PB3, you'll be able to FINALLY mine compressed tables in Goldengate.
I could be wrong, but my impression is that a lot of people at different companies are using Goldengate with Exadata. "Extreme Goldengate Performance on Exadata" is one of my most popular posts. Given the cost per GB of storage in Exadata, compression could save you a *huge* amount of money. Once GG 11.2.1 is released, the only reason I can think of NOT to compress everything you can is that your access patterns don't work well with it...assuming the budget that was big enough to buy Exadata is also big enough to license compression. ;)
After ~2 years of waiting for these 3 bugs to be fixed, the wait is finally over.
It's very nice blog,Thanks for sharing
ReplyDeleteOracle SOA Online Training