>What is a V2X2? V2X2 is StorageTek (now Sun-Storagetek) disk array. General reference name is SVA (Shared Virtual Array) and the various models over the years have been: IceBerg 9393 9500 V960 V2X V2X2 V2X4 (and V2X4f for FICON attached)
We've gone through every model except the V960 at some point over the last seven years. >I think STK calls it: Log Structured Array. >To me, its description sounded like 'virtual DASD'. I believe they (the WinTel world folks) call it thin provisioning these days. Works great. I have only 2.8TB of physical raw disk in my V2X4f, yet I present 23.1 TB of usable space. Split three ways, I've got 7.7 TB presented to my production LPAR, another 7.7 TB for BCP snapshot copies, and another 7.7TB that is snapshot copied daily and used as a sandbox LPAR. If I was to go and buy disk from some other vendors and duplicate the functionality I have today, I would have to be asking for that 23.1 TB of actual physical disk. >It's very important to keep the >time window when the volumes are >actually copied as small as possible. I snap 926 volumes (almost all 3390-9) in about 1.4 minutes. We dynamically create the snap JCL each morning right before our syncpoint with a rexx routine wrapped around a dcollect report. This way name and allocation changes are automatically picked up (one less possible human error potential). With the automated IMS/DB2/TSO/etc down and up processes, the whole syncpoint runs about 2.5 minutes. > PPRC or XRC are not options due to cost > PPRC need not to be expensive. Obviously it > requires two dasd boxes and link, but gives > you much better RTO and RPO. We just replaced our tape based backups (which were taking about 3.5-4.5 hours with 9840's, HSDM, and ExHPDM) with a PPRC solution. HUGE reduction in RTO as the 1-2 days it was going to take to ship the tapes to the hot site was simply eliminated. The 4-5 hour restore from tape time was also eliminated as the data is sitting on another V2X4f at the hotsite ready to go. Last DR test we were IPL'ed in under an hour after arriving at the local recovery center. The RPO only lost a few hours (the difference between the time it took to create the tapes verses push the data across the PPRC link) and is still about 24 hours since we only take one syncpoint a day (after batch), but we are looking at adding another in the pre-batch lull time. We'll probably take a hard look (I'm hoping) at a GDPS solution as well since it would be the next logical step.. but I fear the costs may simply be too high for management to bear - even with the promise of zero down time. Most expensive ongoing cost of the PPRC solution was the link cost. But we manage to do it with a tiny DS3 by snapping the BCP sets throughout the day and sending changes across the link. That way, when it comes to syncpoint time, the amount of change data is very small and the DR set at the remote site is set and stable and ready for recovery just 10-15 minutes after the snaps (keeping the RPO close to that 24 hours) Jeffrey Deaver, Engineer Systems Engineering [EMAIL PROTECTED] 651-665-4231(v) 651-610-7670(p) ---------------------------------------------------------------------- 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