ADSM-L

Re: [ADSM-L] Active logs taking 4 days to delete in 6.2

2011-07-27 11:18:41
Subject: Re: [ADSM-L] Active logs taking 4 days to delete in 6.2
From: "Prather, Wanda" <wPrather AT ICFI DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 27 Jul 2011 15:03:12 +0000
Well, that's an interesting question, too.
I think the Tivoli estimates point to smaller log sizes often being appropriate.

But my server started out at 6.1.3, and the reason my activelog is at 90G is 
that I did indeed have trouble with the log filling up when reorgs were 
running.  (I've seen it take off and fill active log files as fast as every 2-3 
minutes in 6.1.  Doesn't take long to shut yourself down at that rate.)

The good news, I haven't seen that happen since we upgraded to 6.2.2
The bad news, like some others have reported here, as far as I can tell my 
6.2.2 server isn't running reorgs at all any more.  
So I've left the activelogsize at 90G until I have time to investigate that 
further.


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Paul Fielding
Sent: Wednesday, July 27, 2011 10:39 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Active logs taking 4 days to delete in 6.2

Well, I don't think you're showing any ignorance at all, in fact I believe you 
nailed it on the head.  I should have thought of that.  (btw this server is on 
AIX).  For some reason I seemed to think that my active log filesystem was 
originally less full, but in fact now that you mention it I may have been 
thinking about the archive log fs rather than the active log fs.
 That's a dummy one on my part.

When I go back and look indeed the ACTIVELOGSIZE is set to 40GB, which which
does line up with how much space is used in the active log filesystem.   So
all that being said, it appears it's all working as designed.  Apparently I was 
asking a dummy question myself.  ;)

So, this brings me to a tangent on the active vs. archive logs.  From what I 
can see, it looks like the current Active log in that filesystem is almost
always right at the top of the list.   Given that the active logs are
supposed to be (I thought) for uncommitted transactions, and once an active log 
fills it gets dumped to the archive logs, why on earth do we need such a
large active log filesystem?   Does anyone actually have a TSM server that
manages to write out anywhere from 40-100GB of active logs prior to them 
getting dumped out to the archive log fs?

regards,

Paul


On Wed, Jul 27, 2011 at 8:07 AM, Prather, Wanda <wPrather AT icfi DOT com> 
wrote:

> Well, I'm going to weigh in here and show my ignorance.
>
> Somewhere I missed what platform you're on, but on my TSM 6.2 server 
> on Win2K3, I don't think the active logs files ever get deleted.  I 
> think there are always enough log files to account for the 
> ACTIVELOGSIZE specified in dsmserv.opt.
>
> My understanding is that when all the transactions in an active log 
> file are committed, that active log file is eligible to be copied to 
> the archivelog directory, but the active log file doesn't go away.  It 
> just sits there, and when DB2 has used all the other log files in a 
> round-robin sort of way, it will cycle back and rename the oldest file and 
> reuse it.
>
> In my case ACTIVELOGSIZE is 90G, and depending on what's going on with 
> the TSM server I may have activelog files with timestamps going back 2 
> days or 2 weeks, but it's still 90G.
>
> The archive log files DO get deleted.
>
> W
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
> Of Paul Fielding
> Sent: Tuesday, July 26, 2011 8:50 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] Active logs taking 4 days to delete in 6.2
>
> Hi Kurt,
>
> Ok, this is interesting stuff.  When I do db2pd -db tsmdb1 -logs, I 
> see the
> following:
>
> Database Partition 0 -- Database TSMDB1 -- Active -- Up 77 days 
> 15:59:39 -- Date 07/26/2011 06:41:01
>
> Logs:
> Current Log Number            1327
> Pages Written                 124336
> Cur Commit Disk Log Reads     0
> Cur Commit Total Log Reads    8
> Method 1 Archive Status       Success
> Method 1 Next Log to Archive  1327
> Method 1 First Failure        n/a
> Method 2 Archive Status       n/a
> Method 2 Next Log to Archive  n/a
> Method 2 First Failure        n/a
> Log Chain ID                  0
> Current LSN                   0x000000A6009B090A
>
> Address            StartLSN         State      Size       Pages
>  Filename
> 0x0A00010021E4C4F0 000000A5C2400010 0x00000000 131072     131072
> S0001326.LOG
> 0x0A00010021E46C70 000000A5E2400010 0x00000000 131072     131072
> S0001327.LOG
> .
> [cut out a whole bunch of log files for brevity] .
> 0x0A00010021E55B10 000000AF82400010 0x00000000 131072     131072
> S0001404.LOG
> 0x0A00010021E5D0D0 000000AFA2400010 0x00000000 131072     131072
> S0001405.LOG
>
> As you can see, the current log, according to DB2, is 1326, but it has 
> created logfiles all the way up to 1405 already.  There's 81 logfiles, 
> taking up 40GB of space.  1326 is roughly 4 days old.  It appears that 
> TSM is currently creating it's logfiles roughly 4 days in advance of 
> actually writing to it.
>
> Anyone got ideas as to why this behavior, should I leave it this way, 
> or is there anything I can do to change it?
>
> regards,
>
> Paul
>
>
>
>
>
>
>
> On Tue, Jul 26, 2011 at 4:20 AM, BEYERS Kurt <Kurt.BEYERS AT vrt DOT be> 
> wrote:
>
> > The active log space is preallocated at the file system level, you 
> > can check the current log file (1504)  in use as follows:
> >
> > $ db2pd -db tsmdb1 -logs
> >
> > Database Partition 0 -- Database TSMDB1 -- Active -- Up 6 days
> > 01:53:15 -- Date 07/26/2011 12:16:27
> >
> > Logs:
> > Current Log Number            1504
> > Pages Written                 984
> > Cur Commit Disk Log Reads     0
> > Cur Commit Total Log Reads    0
> > Method 1 Archive Status       Success
> > Method 1 Next Log to Archive  1504
> > Method 1 First Failure        n/a
> > Method 2 Archive Status       n/a
> > Method 2 Next Log to Archive  n/a
> > Method 2 First Failure        n/a
> > Log Chain ID                  6
> > Current LSN                   0x000000BC027D8E23
> >
> > $ ls
> > S0001503.LOG  S0001508.LOG  S0001513.LOG  S0001518.LOG  S0001523.LOG 
> > S0001528.LOG  S0001533.LOG  S0001538.LOG  S0001543.LOG  S0001548.LOG 
> > S0001553.LOG  S0001558.LOG S0001504.LOG  S0001509.LOG  S0001514.LOG 
> > S0001519.LOG  S0001524.LOG  S0001529.LOG  S0001534.LOG  S0001539.LOG 
> > S0001544.LOG  S0001549.LOG  S0001554.LOG  S0001559.LOG S0001505.LOG 
> > S0001510.LOG  S0001515.LOG  S0001520.LOG  S0001525.LOG  S0001530.LOG 
> > S0001535.LOG  S0001540.LOG  S0001545.LOG  S0001550.LOG  S0001555.LOG 
> > S0001560.LOG S0001506.LOG  S0001511.LOG  S0001516.LOG  S0001521.LOG 
> > S0001526.LOG  S0001531.LOG  S0001536.LOG  S0001541.LOG  S0001546.LOG 
> > S0001551.LOG  S0001556.LOG  S0001561.LOG S0001507.LOG  S0001512.LOG 
> > S0001517.LOG  S0001522.LOG  S0001527.LOG  S0001532.LOG  S0001537.LOG 
> > S0001542.LOG  S0001547.LOG  S0001552.LOG  S0001557.LOG  SQLLPATH.TAG
> >
> > If it is full, a new log file is used. When a log file is no longer 
> > active (all sql statements are committed), it is archived:
> >
> > $ db2 get db cfg for tsmdb1 | grep LOGARCH
> >  First log archive method                 (LOGARCHMETH1) =
> > DISK:/tsm1/archlog/archmeth1/
> >
> > So it works as DB2 is supposed to do.
> >
> > Best regards,
> > Kurt
> >
> >
> > -----Oorspronkelijk bericht-----
> > Van: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] Namens 
> > Paul Fielding
> > Verzonden: maandag 25 juli 2011 15:20
> > Aan: ADSM-L AT VM.MARIST DOT EDU
> > Onderwerp: Re: [ADSM-L] Active logs taking 4 days to delete in 6.2
> >
> > Yeah, I am.  The thing that's wierd is the 4 day delay.  Active logs 
> > are getting deleted, but they're waiting 4 days to do so.  And this 
> > is not how the behavior has always been since going to 6.2.  I just 
> > noticed the change one day.  Very bizarre...
> >
> >
> > On Mon, Jul 25, 2011 at 6:59 AM, Zoltan Forray/AC/VCU 
> > <zforray AT vcu DOT edu
> > >wrote:
> >
> > > Are you doing "backup volhist" as well?  IIRC, there was a 
> > > discussion that you needed to do that as well to purge activity 
> > > logs.  Plus it is a requirement to perform DB restores on 6.x servers.
> > >
> > >
> > > Zoltan Forray
> > > TSM Software & Hardware Administrator Virginia Commonwealth 
> > > University UCC/Office of Technology Services zforray AT vcu DOT edu -
> > > 804-828-4807 Don't be a phishing victim - VCU and other reputable 
> > > organizations will never use email to request that you reply with 
> > > your password, social security number or confidential personal 
> > > information. For more details visit 
> > > http://infosecurity.vcu.edu/phishing.html
> > >
> > >
> > >
> > > From:
> > > Paul Fielding <paul AT FIELDING DOT CA>
> > > To:
> > > ADSM-L AT VM.MARIST DOT EDU
> > > Date:
> > > 07/25/2011 08:50 AM
> > > Subject:
> > > [ADSM-L] Active logs taking 4 days to delete in 6.2 Sent by:
> > > "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
> > >
> > >
> > >
> > > So, at one of my client sites I noticed that the Active log 
> > > filesystem is sitting at 82% full.  This is not normal for this 
> > > TSM
> server.  Looking in
> > > the filesystem I saw active logs going back four days.   Checking the
> > > actlog
> > > shows that TSM db backups are still running properly every day, 
> > > but just to be safe I ran two db backups in succession.  No logs 
> > > were removed.
> > >
> > > I decided to keep an eye on it.  What I see happening is that each
> > morning
> > > when I look at it, there are still four days worth of logs, but 
> > > the
> > oldest
> > > logs are moving forward by a day. ie.  when I looked on July 22, 
> > > the oldest log was July 18.  When I looked on July 23, the oldest 
> > > log was July 19.
> > >  Today, July 25, I see the oldest log is July 21.
> > >
> > > This strikes me as a bit bizarre.  Anyone have any ideas?
> > >
> > > regards,
> > >
> > > Paul
> > >
> > *** Disclaimer ***
> > Vlaamse Radio- en Televisieomroeporganisatie Auguste Reyerslaan 52,
> > 1043 Brussel
> >
> > nv van publiek recht
> > BTW BE 0244.142.664
> > RPR Brussel
> > http://www.vrt.be/gebruiksvoorwaarden
> >
>