Hi This is also possible what you just said, however archives do not have the same flexibility regarding the life time of your data. I would say that ANDY's suggestion is far better. I went through the same thing running Oracle server on an HPUX box sometime ago. (management refused to pay for the TDP) and I tried all kinds of options and ended doing the trick with FREQUENCY setting.
Kind regards Arni Snorri Eggertsson [EMAIL PROTECTED] On Wed, Aug 21, 2002 at 03:50:28PM +0200, Loon, E.J. van - SPLXM wrote: > Hi Andy! > Thanks for filling me in! I forgot to mention this part! :-( > Your management class will have to keep your inactive versions long enough! > What about excluding the files with an exclude.backup? You can than archive > the files when the database is down, not? > Kindest regards, > Eric van Loon > KLM Royal Dutch Airlines > > > -----Original Message----- > From: Andy Raibeck [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, August 21, 2002 15:08 > To: [EMAIL PROTECTED] > Subject: Re: Override include-exclude list in Unix-client for one > session > > > You *can* do this, but you *should not* do this. If you override the > regular include/exclude list, then you will get a backup of your database > files during that backup. However, the next time you run a backup with > your original include/exclude list, any backup versions of the database > files will be expired (because they are excluded). In summary, you should > think of EXCLUDE statements as telling TSM that you *never* want backups > of the specified files. > > You could get the desired effect in this fashion: > > 1) Create a management class whose backup copygroup has a FREQUENCY > setting of 9999. > > 2) Update your include/exclude list to INCLUDE the database files and bind > them to this new management class. > > 3) Shut down the database engine. > > 4) Use the TSM client to back up the database files. They should get bound > to your new management class. > > 5) Restart your database engine. > > Now your regularly scheduled incremental backups won't back up the > database files again because of the FREQUENCY=9999 setting in the > management class. But on those occasions when you want to do a controlled > shutdown of the database engine, you can run SELECTIVE backups of the > database files to back them up. > > An alternative to the above method is to simply register a new node name > with the TSM server, and configure dsm.opt and dsm.sys such that this new > node name will use an include/exclude list that does not exclude your > database files. Then you can perform backups of the database files using > the new node name. Whether you do this manually, or implement some > automated scheme to shut down the database engine/run the backup/restart > the database engine, is up to you. > > Regards, > > Andy > > Andy Raibeck > IBM Software Group > Tivoli Storage Manager Client Development > Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS > Internet e-mail: [EMAIL PROTECTED] (change eye to i to reply) > > The only dumb question is the one that goes unasked. > The command line is your friend. > "Good enough" is the enemy of excellence. > > > Hi there, > > On a machine here, a database that uses files to store the data is > running. > The files used by that database are excluded in the inclexcl.lst file, > because those files shouldn't be backed up when the database is running. > (We use a TDP-client to backup that database while it's running.) > > However, I would like to be able to backup those database-files when the > database isn't running. > > The problem is that those files are excluded in the inclexcl.lst file > that's pointed to by dsm.sys. I don't want to remove that exclusion, > because those files *should* normally be excluded. > > What I'd like is something like "dsmc -inclexcl=other-inclexcl.lst". That > way, I can specify on the commandline that I'd like to override the system > wide inclexcl.lst just for this session. > > Is there a way this can be done cleanly? > > Thanks, > -- > Jurjen Oskam > > PGP Key available at http://www.stupendous.org/ > > > ********************************************************************** > For information, services and offers, please visit our web site: http://www.klm.com. >This e-mail and any attachment may contain confidential and privileged material >intended for the addressee only. If you are not the addressee, you are notified that >no part of the e-mail or any attachment may be disclosed, copied or distributed, and >that any other action related to this e-mail or attachment is strictly prohibited, >and may be unlawful. If you have received this e-mail by error, please notify the >sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart >Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for >the incorrect or incomplete transmission of this e-mail or any attachments, nor >responsible for any delay in receipt. > **********************************************************************
