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
|
