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
>
|
