Pythian Blog: Technical Track

Where is Oracle Block Change Tracking Today?

Update 7-May-2013: Almost 100 people filled in the survey and here are the result: [caption id="attachment_55013" align="alignnone" width="468"] BCT survey results BCT survey results[/caption] Oracle BCT Internals by Alex GorbacheI wrote a presentation on Oracle Block Change Tracking (BCT) internals more than 6 years ago. Back then, it was based on Oracle Database 10g Release 1. I have also written a paper in support of the presentation for Collaborate 2007 (You are coming to COLLABORATE 13 in April. Aren't you?). To the best of my knowledge, the core principles of block change tracking are still the same. In fact, Oracle recently asked me if they could publish this paper in the knowledge base on My Oracle Support. So now it's there -- ORACLE 10G BLOCK CHANGE TRACKING INSIDE OUT [ID 1528510.1]. I guess it means it's still very relevant. This reminded me that Fast Incremental Backups, enabled by Oracle BCT, is a very handy feature. I see lots of use cases that could leverage it, but for some reason don't. Thus, I wanted to run a quick poll to see how the adoption of BCT is amongst the audience of this blog. If the poll embedded below doesn't get displayed, you can follow this link. As a reminder, Block Change Tracking enables Oracle database to keep track of changed fragments of datafiles between incremental backups. Using this log, it's possible to identify the fragments of a datafile that changed after a particular incremental backup and then only read those fragments during the next incremental backup. innovationBlock Change Tracking enabled us to deliver some innovative solutions to our customers. One unconventional use case is incrementally updated standby when you need to replicate a database that changes the same blocks over and over again and that, in doing so, generates so much redo that it's not feasible to transfer that amount of redo to a remote site (like DR site) for replication. Transferring and applying incremental backups often requires much less bandwidth in these cases. Incrementally updated standby is also a way to replicate large data warehouses that are updated in NOLOGGING mode because standard physical standby doesn't capture those NOLOGGING changes, so Data Guard for Data Warehouse is useless if you need to replicate NOLOGGING changes. What are your use cases for block change tracking? Take the poll and feel free to provide more details in the comments section below on how you are using the Block Change Tracking feature or what prevents you from using it.

No Comments Yet

Let us know what you think

Subscribe by email