The DDR backup is just first cut recovery. TSM backup is second but these in our case were done with the Oracle database down. As far as table reloads go our Oracle support unit handles them. I'm not sure what their scheme is. They may have other backups in addition to TSM.
-----Original Message----- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Tom Duerbusch Sent: Tuesday, February 01, 2005 5:16 PM To: [email protected] Subject: Re: z/Linux and Oracle The question was, does Linux and Oracle understand Flashcopy or in your case snapshot. >From the Linux side, if a Flash is requested, it would have to flush out all the write cache buffers to disk before the Flash took place. Otherwise, your copy would look like a "crashed" image. With Oracle, Oracle would have to recognize a Flash request, sync up the LUWs with the logs and prepare for the Flash. Otherwise, your copy will backout any inflight LUWs. Which isn't that big of deal, until you need the archive from the "flashed" copy and the logs from the "live" copy to do a roll forward. Unless Oracle understands "flash or snap" there won't be a maker in the logs for you to do a roll forward successfully. I agree, that if you can take down the database and Linux image, flash and snap will work just fine. I just don't know that my applications have that "window" at this point in time (that is, existing workload comming from another system may be put on our mainframe, which causes us to buy a new mainframe, dasd, etc,) If the window is large enought, I don't need flash, and I can just backup to tape. If the window is short, I might be able to take the image down and do the flash. But if the window is really tight, I might need to flash an active system. Hence the questions of if Linux and Oracle support active flashcopy. But the other questions I asked, in which you answered were how others backup Linux/Oracle images. Since you use DDR, how do you handle requests to reload a table from backup and/or roll forward with that reload? Tom Duerbusch THD Consulting >>> [EMAIL PROTECTED] 02/01/05 3:45 PM >>> We have run Oracle data bases (9.2.0.3 and 9.2.0.4). We use STK dasd which has SNAPSHOT capability. We have backed up the whole VM system with the linux guests up (using SNAPSHOT then DDR of snapped volumes). We use ext3 journaling file system. First cut recovery is from the DDR tapes. The dasd is snapped with system up and DDR's are done from the snap copy volumes. We normally shutdown oracle each night and back up using TSM on zOS, then bring oracle back up. We also have TSM backups of the other linux filesystems. But we were surprised to see the linux guests recover as well as they do from the first cut DDR restores (snap done with system up). But like all old timers we're leary of backups done with the system up even though the snap is so quick. I'm curious what problems other folks have seen at recovery time if backups are done from snapped copied volumes of an up and running system. Or are we the only ones crazy enough to try it to see? In any case, there probably is a size limit as to when to go SAN. The databases we have had are not that big (8-20 GIG). Maybe other folks have suggestions. Also, using SNAPSHOT takes up dasd addresses so there is a cost involved. FLASHCOPY may have the same issue. You should shutdown the oracle database before you flashcopy the volumes it resides on. -----Original Message----- From: Linux on 390 Port [mailto:[EMAIL PROTECTED] Behalf Of Tom Duerbusch Sent: Tuesday, February 01, 2005 1:47 PM To: [email protected] Subject: z/Linux and Oracle Apparently we are going to be moving a large set of resources to the mainframe, and will be moving the data to Oracle 10g (note..64 bit). The last time I ran Oracle on the mainframe was Oracle 6, under VM/ESA 1.0 and also, for a brief time, under VSE/SP 4.1 (sure didn't run well there). Anyway, there are some rather large data requirments. But one of them is 128GB. I don't know what 128 GB means in this case. Raw data. The dasd used by the current database platform. The amount of dasd on that server...just what, I don't know. In either case, I expect at least 100 GB of mainframe dasd to be used for this. On the little info I have, I'm expecting a total of 400 GB to be moved to us. 400 GB ends up being a lot more, when we factor in test systems, number of Linux images necessary (8X5 servers, weekend servers, 24X?? servers) as well as the dasd requirements for flashcopy. And the question of the day becomes, does z/Linux (Suse 8.0 or better) and Oracle 10g, support flashcopy of an active, running database. I know I can quiese things and do a flash, but on an active Oracle system, how does Oracle sync the logs to the flash point? Will z/Linux flush out the write cache buffers in prep for the flash? There is a new feature, Flashcopy, copy only, which apparently only copies data that was to be changed, so most of your backup will be done to the origional copy and "copy only" will retain the "before" image of any data that was changed. This would reduce the dasd requirement greatly (from needing 100% for the flash to a few percent). I've only had to deal with a few GB databases (DB2, Oracle, IMS, etc). Where I figure I will have between 7 and 12 databases, the big one, 128 GB has me concerned. Just how do you back that time of thing up? None of our data is currently, true 24X7. And I don't see any great requirement in that area. Worst case, is everyone could accept a few minutes for a "flash" to be done. Best case, is the users go home and leave us to do the job <G>. So what kind of hardware do you backup large databases to? How often? How frequently do you need to shutdown z/Linux or Oracle and for what reasons? Right now, I'm trying to spec out what hardware we need. But I need to know how this all operates in production to determine what hardware and how much is necessary. Thanks Tom Duerbusch THD Consulting ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390 ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
