Re: virtual copies
Bruce, There are two ways for Shadowimage to split with IO Consistency. One is to use the At-Time split function in BCM, and the other is to use Shadowimage Consistency Groups. The At-Time Split function works the same way as Nanocopy, in that it posts a future time in the controller when you want the Point In Time to be, and when IO arrives with a timestamp greater than or equal to that time it will trigger the suspend. It's a proven, non-disruptive method we have been using to get P-i-T since we introduced Nanocopy on the 7700E. The neat thing about At-Time split is it can create P-i-T consistency across an unlimited number of Controllers and Volumes. There is no communication software or IO suspension required because the DFP timestamps are used. It can also be used for TrueCopy. Shadowimage Consistency Groups can be used when the OS does not support Timestamps (like VSE) or you want to split off a Shadowimage in a Remote CU without stopping TrueCopy. In this case the Controller will block writes at the Storage Port for the volumes in the Shadowimage Consistency Group. Doing this with BCM software makes the duration of the first to last suspend command many, many, many (did I mention many) times faster than using the ANTRQST interface (PPRC, CC and FC). Thus the time to write blockade is shorter. The other advantage of blocking writes at the host port is that it is all managed by the storage. There is no automation or inter-LPAR communication required to get IO Consistency. Personally, I believe if you have BCM then At-Time split is the way to go. Ron -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Black Sent: Saturday, 18 March 2006 12:30 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: virtual copies At Time splits with Shadowimage and/or TrueCopy use Timestamps to initiate the split and create consistency. There is no blockade of writes for a few seconds while all the volumes are split. Ron, you are right, ShadowImage doesn't operate quite the same as IBM FlashCopy and EMC Consistent split/snap. Do you know if the ShadowImage Flashcopy feature operates like the IBM Consistent Flash, in that it does suspend I/O? -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: virtual copies
At Time splits with Shadowimage and/or TrueCopy use Timestamps to initiate the split and create consistency. There is no blockade of writes for a few seconds while all the volumes are split. Ron, you are right, ShadowImage doesn't operate quite the same as IBM FlashCopy and EMC Consistent split/snap. Do you know if the ShadowImage Flashcopy feature operates like the IBM Consistent Flash, in that it does suspend I/O? -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: virtual copies
Bruce, At Time splits with Shadowimage and/or TrueCopy use Timestamps to initiate the split and create consistency. There is no blockade of writes for a few seconds while all the volumes are split. Ron With normal backups, and even with normal instant replication, I/O consistency cannot be guaranteed. However, EMC, HDS, and now IBM have mechanisms for guaranteeing I/O consistency when you use instant replication on a set of volumes. In all cases it involves a way of suspending I/O to all the volumes involved until the replication is complete (a few seconds). -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
virtual copies (was: IXFP ...)
In a recent note, Bruce Black said: Date: Mon, 13 Mar 2006 11:11:16 -0500 Flashcopy has a consistent flash mode that makes it unnecessary to suspend application updates, as long as the application is a logged system doing dependant writes ... I'm unfamiliar with the terms, but it's pretty clear from the context what it must be about. Does DFSMS have a new facility for dependent writes that somehow chains the writes together? Is it as simple as doing all the writes in a single channel program with a guarantee that the perceived updates of the backing store are congruent with the order of the I/O requests? -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: virtual copies
Does DFSMS have a new facility for dependent writes that somehow chains the writes together? Is it as simple as doing all the writes in a single channel program with a guarantee that the perceived updates of the backing store are congruent with the order of the I/O requests? As I use the term dependant writes, it means that the application issues writes in a specific sequence and does not initiate the next one until the previous one is confirmed complete. In database terms, such as DB2, this means that it 1) issues a write to the log to indicate that an update is going to take place 2) issues one or more writes to the database files to accomplish the update 3) issues a write to the log to indicate that the update is complete If this sequence is interrupted, such as by a system failure, power outage, remote link failure, etc, then when DB2 is restarted it can tell that the update was not completed from the log, and can back it out (or sometimes complete it). I am no DB2 expert but I understand that this is the way it works (those who can spell DB2 better than I, feel free to chime in). If you can capture your backups at a point of I/O consistency, then when you restore those backups, the same sort of restart can take place. I/O consistency means that there is no possibility that you have backups of the log and database voliumes where #3 was completed, but #2 was not completed. With normal backups, and even with normal instant replication, I/O consistency cannot be guaranteed. However, EMC, HDS, and now IBM have mechanisms for guaranteeing I/O consistency when you use instant replication on a set of volumes. In all cases it involves a way of suspending I/O to all the volumes involved until the replication is complete (a few seconds). -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
