ADSM-L

Re: Actlog & the database

2003-07-03 14:48:28
Subject: Re: Actlog & the database
From: Alex Paschal <AlexPaschal AT FREIGHTLINER DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 3 Jul 2003 11:16:35 -0700
I agree with Richard, but instead of q actlog dumps, we use the dsmulog
utility (see the TSM/AIX Admin Ref, Appendix A, IBM Tivoli Storage Manager
Utilities) to capture all stdout from the server into rotating logs.  It
date/time stamps.  We then have scripts that copy the most recent closed
logs into an arc directory.  From that directory, we archive/delete those
logs after 120 days, archiving for 2 years.  To be honest, I don't recall
the last time I did a q actlog.  vi and grep are much more convenient for
me.

Oh, two more benefits of this.

1: I use gresham edt elm.  All the elm messages go to TSM stdout, so they're
captured in my dsmulogs.  It greatly eases troubleshooting of issues that
may be elm related.

2: Sometimes TSM may lose actlog messages, so you might have gaps (the old
too-many-actlog-messages-at-once issue, and sometimes before a crash).  This
way I always have that information.  Hmm...  Now that I think about it, I
don't recall that happening recently, but I know it was an issue in older
versions.  Or maybe I don't look at the actlog anymore, so I don't notice
whether or not it lost messages?  I'll have to keep that in mind.

Alex Paschal
Freightliner, LLC
(503) 745-6850 phone/vmail

-----Original Message-----
From: Ben Bullock [mailto:bbullock AT MICRON DOT COM]
Sent: Thursday, July 03, 2003 7:22 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Actlog & the database


        At our site, we run our TSM servers with a 7 day activity log
retention. However, we run our TSM servers on AIX and when we start them up
we use the nohup command ( nohup dsmserv </dev/null & ). This redirects the
activity log out to a "nohup.out" file.

        The downside to doing it this way is that each entry in the
nohup.out file is not date or time stamped. We compensate for this by
inserting a time into the nohup.out file every 15 minutes with a simple cron
entry. We also rotate out and date the nohup.out file every time we restart
a server.

        We seem to restart our TSM servers every few months, so that keeps
the logs small. 6 months down the road, if I can tell what happened to a
tape within a 15 minute window, that's close enough. It works for us.

Thanks,
Ben

-----Original Message-----
From: Richard Sims [mailto:rbs AT BU DOT EDU]
Sent: Thursday, July 03, 2003 6:21 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Actlog & the database


>I have some ideas about the questions I'm about to ask but I need some
other
>opinions. What is the relationship between the activity log retention
period
>and the size of the TSM database. For example, the production database that
I
>work with has a size of 52 GB and the actlog retention period is 90 days.
Would
>the size of the database noticably decrease if the actlog retention was set
to
>7 days? (Extraneous info: I piped the output from "q actlog
>begindate=01/01/2003" to file and the file is about 500 MB.)

You've answered your own question as to space usage, via the astute 'q
actlog'
experiment.  The Activity Log impact on the database is usually modest,
depending upon how busy your server is.

>Is there a way to "archive" the activity log so that it could be "imported"
>later?

There's no reason to import it - it's just text.  What I - and probably
other
shops - do is leave about 30 days worth in the db for convenience, but via
'q actlog' capture period images, redirected to an OS file, which is then
retained somewhere.  In this way I keep five years of server activity logs
as
individual day files, in HSM.  These I can inspect with customary Unix
commands:
grep, less, etc.

As always, I urge sites to retain activity logs for about as long as your
oldest
still-filled tapes, as your reference for inevitable research into how any
given
tape ended up the way it is.  Your auditors may impose such requirements.

  Richard Sims, BU

<Prev in Thread] Current Thread [Next in Thread>