Mark,
Well, TSM allows for pre-backup and post-backup scripts as well for a given stanza.
But I still think a cron/TSM scheduled job executing a script that will put the tablespaces in backup mode, followed by executing the dsmc client locally, and then putting the tablespaces back in normal is a simple way of doing it. This way, the dsmc scheduler (if using TSM scheduler) will only execute the first script, and then you run a number of manual dsmc sessions in your script backing up the necessary files. Also, this way you will have a good control of what is being backed up. Lets say you have a scenario where the dba adds more data files in a new file system. In your stanza you would have to update the DOMAIN variable manually to have this system added, and restart the dsmc -sched process. But if running the dsmc from the client, you can generate a list of files from Oracle, and then figure out which file systems that needs to be backed up, and change the command-line domain accordingly.
Running the dsmc client you can on the command line change the domain. As long as the node is using its default domain/copygroup your files will end up in the correct pool.
Mind you, I haven't tried this recently, but I believe the concept should still work with TSM 5.2.
/Andreas
Mark Tindall wrote:
Andreas,
this was sort of the way I had thought of but I still have one problem and that is how to take the tablespaces out of backup mode after the backup has finished. With Netbackup there were 2 scripts which were used - one pre backup and one post backup - which made sure tha backups were always started / completed before the tablespaces were placed in / taken out of backup mode. As far as I know TSM will only kick off one script which you must use to do the lot.
Many thanks for your help,
Mark Tindall
On Wed, 9 Mar 2005 10:06:35 +0100, Andreas Almroth <[EMAIL PROTECTED]> wrote:
Hi,
I at least see two ways of doing it;
1) Put tablespaces in backup mode and run the TSM backup on the file systems where the data files are, or 2) Use RMAN (at least for your 8.x.x instances) to disk, and then have TSM to backup the RMAN backup pieces (If you have a lot of extra disk space this is OK)
For most installations #1 would probably the most effective way to do it. There will still be a lot of manual work, and a good backup script. Both ways means you will need to have a good copy group or a dedicated domain in order to keep the backups for the retention period required. Also, using #1 means you will not need to do manual housekeeping in RMAN to synchronise with what you have got in TSM. #1 is also well documented way of doing Oracle backups, and the only thing you will need is to encapsulate those scripts so that they can be called by the TSM scheduler as command.
In command script you would put the database tablespaces in backup mode, generating the list of files to be backed up, doing some grep/sort/sed/awk to figure which file systems to backup, then running the dsmc client on the file systems (don't forget any archive log files), and last put the tablespaces back in normal mode. Or instead of using TSM scheduler, just use a cron scheduled script.
I'm sure there are other ways, perhaps even better ways...
/Andreas
Mark Tindall wrote:
Hi,
I am very new to Tivoli having previously used Veritas Netbackup to perform all the backups of our many databases. Our servers our now being relocated and as such will now have to make use of Tivoli for their backup schedules. As I understand it TSM 5.2 can only be used to backup Oracle databases of versions 8.1.7 and above (via RMAN). This presents a huge problem since we still have a number of production instances that are still on versions 7.3.4 and 8.0.6. Can anyone tell me a way that I can perform backups on these databases with TSM 5.2 ?
Thanks,
Mark Tindall Database Administrator Thomson Scientific Tel: 0207 424 2093 Fax: 0207 424 2815
