And, well
Active Log Size is a parameter you can check with q otion in TSM Server and
further modify.
Syntax
>>-ACTIVELOGSize--megabytes------------------------------------><
Parameters
megabytes
Specifies the size of the active log in megabytes. The minimum value is 2048 MB
(2 GB); the maximum is 131072 MB (128 GB). If you specify an odd number, the
value is rounded up to the next even number. The default is 2048 MB.
Kindly,
Carlo.
-----Messaggio originale-----
Da: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] Per conto di
Paul Fielding
Inviato: mercoledì 27 luglio 2011 16.39
A: ADSM-L AT VM.MARIST DOT EDU
Oggetto: 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
> >
>
-----
Ai sensi del D.Lgs. 196/2003 si precisa che le informazioni contenute nel
messaggio e negli eventuali allegati sono riservate al/ai destinatario/i
indicato/i. Nel caso di erroneo recapito, si chiede cortesemente a chi legge di
dare immediata comunicazione al mittente e di cancellare il presente messaggio
e gli eventuali allegati. Si invita ad astenersi dall'effettuare: inoltri,
copie, distribuzioni e divulgazioni non autorizzate del presente messaggio e
degli eventuali allegati.
----------
According to Italian law (D.Lgs 196/2003) information contained in this message
and any attachment contained therein is addressed exclusively to the intended
recipient. If you have received this message in error would you please inform
immediately the sender and delete the message and its attachments. You are also
requested not to make copies, nor to forward the message and its attachments or
disclose their content unless authorised.
|
