Patty, We do essentially the same thing - although not nearly as often. We refresh our test LPAR every 6 months or so - always on a by-request basis because we also have Oracle sitting on unix that is kept in sync with the databases on the "Z" so it is a big to-do when we refresh. When we refresh the test LPAR, I make sure it is done on a weekend and I use DFDSS full volume using flashcopy=copy.
For our normal backups, we perform a database backup every night before running our batch cycle, using DFDSS flashcopy=nocopy. While the batch cycle is running, we're spinning the flash volumes to tape. Once the batch cycle is done, we do DFDSS flashcopy=nocopy of the entire system then spin the flash volumes off to tape after the operator has left for the night. I just checked RMF from last night and our DS6800 was performing just fine while the early database spin to tape was running. My busiest database pack was pushing 300 I/Os per second thru it with 1 millisecond response time (at a whopping 14% busy!) The backups weren't showing as impressive as numbers, but they were also moving large blocks of data. We upgraded to the DS6800 about 15 months ago from an RVA. Moving from SNAPSHOT to FLASHCOPY was a bit of an adjustment, but we're real happy with the performance of the DS6800 - including the flashcopy. Not to mention seeing the UPS usage drop drastically when we unplugged the old RVA. Rex -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Patty Mabie Sent: Thursday, September 27, 2007 2:12 PM To: [email protected] Subject: Flashcopy on DS6800 We installed a DS6800 to replace our Shark F20 a few weeks ago. We are happy with the change overall and have seen good improvements in batch times. However, we do have an issue with the Flashcopy. On the F20 we did a nightly FDRABR flashcopy with parameter FCOPY=COPY of about 64 3390-9 and about 15 3390-3 volumes. Our tapes are old and slow, and it was time consuming to back this all up for DR, so we did a second flash copy using DFDSS that would invoke flash copy services. Those volumes would remain offline, only being used for backups. We we then did FDRBACKUP of the flashed volumes, and brought them online for our TESTLPAR. We now do a similar process on the DS6800. We do 2 flashes, 1 using FDRFLASH with FCOPY=COPY to make full copies to be used by our TESTLPAR. The second is FDRABR with the FCOPY=COPY and these are used for our FDR disaster backups. The # of drives that are being copied with FCOPY=COPY are equal or less on the DS6800. We saw no performance hit when doing this on the SHARK F20. We are having terrible response on the DS6800 for about 2 hours after the flashcopy completes. After reviewing with IBM, we made a few adjustments when we learned about half the volumes were being copied to targets in the same extent pool as the source. We switched our target volumes to extent pools different from the source volumes, and also validated that the target and source for each flashed volume are managed by the same controller. This seemed to have little effect. What are considering switching to this process: Do 2 flash copies, 1 with FDRFLASH with FCOPY=NOCOPY and a second with FDRABR with FCOPY=NOCOPY. We will then bring the first copy online to the test LPAR and the second will be used just for FDR disaster backups. The first copy will be repeated once a week (or on demnad), all other days during the week we will do just the FDRABR copy for disaster purposes. We are wondering if the same process works differently on the Shark v. the 6800. Does anyone else use flashcopy for TESTLPAR data? If so, are you using FULLCOPY, NOCOPY or incremental flashing. Any comments on the process we are using or the one we propose to change to? Is there any issue in maintaining a flash pair for a week or to without using FCOPY=COPY ? Would appreciate any comments. ---------------------------------------------------------------------- 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
