I am not an expert in this area, but I think there are several issues involved.
FlashCopy is taking a physical image of the VOLUME(s) involved. The Data Base manager doesn't know you're doing it. SO while it's easy and low cost to do the FlashCopy (it's pretty much an outboard hardware process), it doesn't copy or clear the logs that the DB management system uses. So the real question, as usual, WHAT are your recovery requirements? What are you going to do with that FlashCopy if somebody wants to restore the data base? If what they want is the ability to back out a bad transaction, you can do that with Oracle (for example), by restoring from the last full and then rolling forward from the journal, but you won't necessarily have a copy of the journal if all you have is a FlashCOpy. And Exchange and SQL server (I think) work like the TSM DB, when you take the DB backup, they clear their transaction logs. So you would have to have some way to sync up your logs, if you used FlashCopy instead. SO you gotta work those issues out. FlashCopy certainly is a great option for a DB manager that doesn't HAVE a TDP available, because you can stop your DB for just a few SECONDS and take a FlashCopy, instead of having the DB down for an hour to dump the volume as a flat file. Talk to your DBA about the recovery requirements for your particular DB's. WandaWanda Prather "I/O, I/O, It's all about I/O" -(me) -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Mike Sent: Tuesday, September 14, 2004 11:42 AM To: [EMAIL PROTECTED] Subject: TDP vs. FlashCopy thoughts Given that TSM has TDP for many databases and that TDP can do incremental backups at the record level. What are the thoughts for using TDB vs. using FlashCopy on an ESS/Shark? The FlashCopy must backup the entire database each time, unless the backup database could be mounted to a secondary server that could then start TDP on the backup copy...? Mike
