Howdy Othonas! Hope you are doing well... haven't heard from you in a while... I
think the problem with doing expiration and reclamation of backups made with
SQL-BackTrack for Informix lies in the fact that if you use an older version of
the product, the agent places a long time stamp on the filespace name making
each name UNIQUE. Thus, you are left with a zillion unique filespaces, each
being an ONLY version of a db backup. This truly complicates expiration.... you
basically must go in and erase filespaces manually. With the newer version of
SQL-BackTrack for Informix, it has the ability to delete back generation of a
database. The generations term is used by BMC to distinguish between versions as
each Informix backup is actually unique. It appears you can only retain 9 unique
generations at most; meaning if you backup up daily, the most you can retain,
using the agent is 9 days worth. You can also expire using a date. These
features only became available on V.3... we are testing it now and it is a pain
to install... BMC's directions are not great ;-(. Anyway, I am far from an
expert in these matters but I do have some experience with deleting filesets
which is necessary, even if you put backups into their own management class/copy
group. BTW: I have completed implimenting all the recommendations you made and
just finished documenting the whole mess. During the course of the
documentation, I redid all management classes, copy groups and schedules to make
them work the way we wanted and have everything revolving around our logical
business day as you suggested. The redbook has some good tips on scheduling
stuff so that our admin processes are not overlapping with backups and such.
Thanks- hope my rambling made some sense...
George Lesho
Storage / System Admin
AFC Enterprises
Othonas Xixis <othonas AT US.IBM DOT COM> on 02/13/2001 10:28:39 AM
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
cc: (bcc: George Lesho/Partners/AFC)
Fax to:
Subject: Re: expiring Informix logs ...?
Arnaud hi,
I am a little troubled understanding why you say that "TSM is unable to
expire those logs". If you use a separate mgmt class and copygroup for your
logs, and your copygroup parameters are set properly, TSM will expire your
logs.
Maybe if you want to give us some more details of yr installation...
Cheers.
Othonas
PS: I bet Basel is beautiful this time of the year...
Arnaud Brion <Arnaud.Brion AT PAC.PANMAIL DOT COM>@VM.MARIST.EDU> on 02/13/2001
11:01:42 AM
Please respond to "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: expiring Informix logs ...?
Hi everybody !
I come back on something that seems to be an old subject for *SM'ers :
we're using the Onbar API to ensure the backup of our informix logs, what
works really nicely, except we're facing a huge increasing of the number of
tapes used for this storagepool, due to the fact that TSM is unable to
expire those logs.
We tried to install the onsmsync utility a few month ago, which was
supposed to give us a rid of this problem, but I just saw today that it
isn't working at all !
Does anybody know if Informix or Tivoli found a solution to this problem
(new version of onsmsync ?), or if there is any other way expiring those
#@#@@... logs ?
I saw there is a c programm existing but I have no idea of c language so if
you know something easier, just let me know !
Thanks in advance ! ;-)
Arnaud
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
| Arnaud Brion, Panalpina Management Ltd., IT Group |
| Viaduktstrasse 42, P.O. Box, 4002 Basel - Switzerland |
| Phone: +41 61 226 19 78 / Fax: +41 61 226 17 01 |
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
|
