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
