ADSM-L

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

2011-07-27 11:25:15
Subject: Re: [ADSM-L] Active logs taking 4 days to delete in 6.2
From: "Vandeventer, Harold [BS]" <Harold.Vandeventer AT DA.KS DOT GOV>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 27 Jul 2011 09:52:03 -0500
I think Wanda is correct.  The files always stay there, and get reused over 
time.

I'd opened a PMR on that question a few weeks ago; answer was "TSM reuses the 
files".

------------------------------------------------
Harold Vandeventer

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Prather, Wanda
Sent: Wednesday, July 27, 2011 9:08 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'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
>