Dwight is quite correct about the include/exclude... if you do that, you'll wind up expiring files you've just backed up. There are several ways to handle this, and the topic has been discussed here several times.
Briefly, you could do the "archive the database, backup everything else" method as Dwight suggested. Others have defined a separate client node for the database. We handle it by dynamically creating a dsm.opt file on the daily backups that lists all filespaces that are NOT database table spaces (a domain list). This is done via a shell script. In this way the daily backup never considers the tablespace filesystems for backup, yet they do not get expired. For the weekly "full" backup, we simply do not have a domain list, so all filesystems get included by default. Robin Sharpe Berlex Labs "Cook, Dwight E (SAIC)" <[EMAIL PROTECTED] To: [EMAIL PROTECTED] M> cc: (bcc: Robin Sharpe/WA/USR/SHG) Subject: 12/19/01 Re: Help with scheduling 02:30 PM Please respond to "ADSM: Dist Stor Manager" I would use backups (nightly incrementals) to cover op system, application code (the installed oracle code, etc...) and I would use "archives" to save all the oracle .dbf files... This way (as you said) all the open/active oracle files are excluded from nightly incremental processing. OH, the TDP product is specifically written to do all this but if you don't want to spend the money for that you may either maintain a list yourself of all the .dbf files (and anything else you might need) or write some scripts that issue oracle queries to list all the files associated with tablespaces and go from there... you can't really yoyo the include/exclude list like that because as soon as you exclude those files from backup and run one of your weekday backups, any/all excluded files are expired if they exist ! hope this helps DWight -----Original Message----- From: Tony Sinclair [mailto:[EMAIL PROTECTED]] Sent: Wednesday, December 19, 2001 1:05 PM To: [EMAIL PROTECTED] Subject: Re: Help with scheduling I would like some input from the group on how I could accomplish the following with the least amount of user intervention/maintenance. The following is my dilemma: There are two sets of backups on the client server. One is the system backup and the other is the database backup (not yet implemented). The system backup needs to exclude the Oracle database data files. Since this backup is done when the database is open, there is no point in backing up these files because they're useless in a restore/recovery situation. The attached file is a list of files that need to be excluded from the system backup. The database backup needs to be run on Sunday's, starting around 11:00 am. It needs to exclude the files backed up in the system backup. This backup needs to be done when the database is in a shutdown state. The file in /oradata/jobs/bkup/scripts/tsm/backup2.cmd(which is executed via the OPTION section on the schedule) is set up to include all the appropriate files. Now since the TSM client uses the same DSM.SYS file how can I resolve this dilemma? How can I keep the DSMSCHED.LOG's seperate? Or how would you handle this situation? Tony Sinclair TSM ADMIN/STOR. Manager [EMAIL PROTECTED] =========================================================================== IMPORTANT NOTICE: This communication, including any attachment, contains information that may be confidential or privileged, and is intended solely for the entity or individual to whom it is addressed. If you are not the intended recipient, you should delete this message and are hereby notified that any disclosure, copying, or distribution of this message is strictly prohibited. Nothing in this email, including any attachment, is intended to be a legally binding signature.