Quicksearch

Disclaimer

The individual owning this blog works for Oracle in Germany. The opinions expressed here are his own, are not necessarily reviewed in advance by anyone but the individual author, and neither Oracle nor any other party necessarily agrees with them.

Saturday, April 26. 2008

The mechanism of dependent copies was introduce to get rid of this initial sync, as there are circumstances where this initial copy would pose to much load to the system.

The dependent copy uses the bitmap a little bit different. The shadow disk doesnīt contain all the data, it just contains the changed data. The bitmap is used to keep track of the block on the masters which have a copy on the shadow.

Deeper dive

The dependent copy is one of the two mechanisms in AVS using the concept of the virtual shadow. Thus the model is a little more complex. Letīs assume you create an dependent copy. The initialisation is simple. You move no data. You just initialize the data. When an user or application access the virtual shadow volume, it checks in the bitmap if the blocks has changed. If the bitmap signals no change, it just delivers the original block of the master volume.

When you change some data on the master volume, AVS starts to copy data. It copies the original content of the block onto the physical shadow volume at the same logical position in the volume. This is the reason, why master and shadow volumes have to have the same size when using dependent copies. Futhermore AVS logs in the bitmap that there is data on the shadow volumes, the block is dirty in the bitmap. When you access the virtual shadow volume now, the bitmap is checked again. But for blocks declared dirty in the bitmap, the data is delivered from the copy on the physical shadow volume, for all other "clean" blocks the data comes from the master volume.

Resyncing the shadow to the master is easy. Just reinitializing the bitmap. Now all data comes from the master volume again, until you change some data on it.

Advantages and Disadvantages

The advantage of this method is itīs short time of initialisation and syncing from master to the shadow. Itīs virtually zero. But you loose the advantages of the independent copy. The dependent copy can only used in conjunction with the original data. This has two main effects. You canīt export the copied volume to a different server and you canīt use is as an copy for disaster recovery when your master volume has failed.

Furthermore the master and the slave volume still have to be the same size. But the next method for making an point-in-time copy was derived from the dependent copy exactly to circumvent this problem.

Less known Solaris Features: Point-in-time copy with AVS
Okay, the next installment of the "Less known Solaris Features" series is online. This time i will discuss the feature Point in time copies with AVS. As i have to go through some theory at first, itīs a quite long tutorial. Itīs the longest so far. Point-