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
<almrot_a AT mtncameroon DOT net> 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
|
