Are you using cloud containers? If so, check: http://www-01.ibm.com/support/docview.wss?uid=swg1IT18137
Short term, I'd increase the activelog filesystem, and then increase the activelogsize. It's good that you keep a buffer, filesystem larger than activelogsize. Once the server is stable that way, further investigation may be required, you might need a PMR to look into that. - Thanks, Marc... ________________________________________________________ Marc Lanteigne Accelerated Value Specialist for Spectrum Protect 416.478.0233 | [email protected] Office Hours: Monday to Friday, 7:00 to 16:00 Eastern Follow me on: Twitter, developerWorks, LinkedIn -----Original Message----- From: Remco Post [mailto:[email protected]] Sent: Thursday, November 9, 2017 9:47 AM To: [email protected] Subject: Re: [ADSM-L] log not flushing > On 9 Nov 2017, at 14:22, Marc Lanteigne <[email protected]> wrote: > > > Ok, but how much is actually used when looking at Q LOG? > at this moment over 102,000 MB in use, 28, 000 MB free, of in total 131,072 MB, and yes, still raising. > There could also be background tasks running that do not show up in Q > PROC like reorgs for example. No Spectrum Protect activity is not > always synonym to no database activity.l apparently there is something running, there must be, the log is getting even more full. Unfortunately I have no indication of what it could be. I did search the actlog for reorg processes, and there were some, those have ended. So…. in the end I’ll wind up restarting the instance I guess, to make sure things don’t go wrong during the backup window. > > - > Thanks, > Marc... > ________________________________________________________ > Marc Lanteigne > Accelerated Value Specialist for Spectrum Protect > 416.478.0233 | [email protected] Office Hours: Monday to > Friday, 7:00 to 16:00 Eastern > > Follow me on: Twitter, developerWorks, LinkedIn > > > -----Original Message----- > From: Remco Post [mailto:[email protected]] > Sent: Thursday, November 9, 2017 9:16 AM > To: [email protected] > Subject: Re: [ADSM-L] log not flushing > >> On 9 Nov 2017, at 13:57, Marc Lanteigne <[email protected]> wrote: >> >> >> Hi Remco, >> >> When looking at Q LOG F=D, is it 96 GB in " Used Space on File System > (MB)" >> or " Used Space(MB)"? >> If the former, that's normal. New log files are created as soon as >> old ones are archived. > > I know, so we have 128 GB in use on the filesystem, and about 30 GB > free on disk because apparently now a db backup can copy archived log > files back to the active log directory. > >> If the latter, you may want to revisit the capacity planning to >> assess if >> 128 GB is sufficient for that environment. > > that would make a valid recommendation if the active log was filling > up during the backup window, or for that matter any other activity on > the server. As stated, this server appears to be idle. No sessions, no > processes, no activity whatsoever. So there should be (I guess) also 0 > transactions in progress on the database. > > ( I thought the max was 128 GB, turns out that with 8.1 this has een > raised to 512 GB) > >> >> For a medium size environment, 128 GB is normally sufficient. For >> large implementations, 256 GB is recommended (in some cases larger). >> - >> Thanks, >> Marc... >> ________________________________________________________ >> Marc Lanteigne >> Accelerated Value Specialist for Spectrum Protect >> 416.478.0233 | [email protected] Office Hours: Monday to >> Friday, 7:00 to 16:00 Eastern >> >> Follow me on: Twitter, developerWorks, LinkedIn >> >> >> -----Original Message----- >> From: Remco Post [mailto:[email protected]] >> Sent: Thursday, November 9, 2017 8:47 AM >> To: [email protected] >> Subject: Re: [ADSM-L] log not flushing >> >>> On 9 Nov 2017, at 13:09, Marc Lanteigne <[email protected]> > wrote: >>> >>> >>> Hi Remco, >>> >>> That's normal, that's how active logs work. Only the archive log >>> will be purged after a database backup. >>> >>> The active log includes transactions that are in-flight, that is >>> that they are currently running. The only reason that they go away >>> when you restart the server is that when the server shuts down, it >>> ends all the transactions. No transactions=no active logs. >>> >>> Your server is working normally. Just make sure you have sufficient >>> active log space and that the filesystem/LUN used for the active log >>> is not shared with anything. >> >> Hi Marc, >> >> you are right, my bad. >> >> But, 96 ff-ing GB of active log on an idle TSM server? no processes, >> no sessions, nothing… We have configured 128 GB of active log space >> for these servers, so I guess all I can do is wait until the server > crashes? >> >>> >>> - >>> Thanks, >>> Marc... >>> ________________________________________________________ >>> Marc Lanteigne >>> Accelerated Value Specialist for Spectrum Protect >>> 416.478.0233 | [email protected] Office Hours: Monday to >>> Friday, 7:00 to 16:00 Eastern >>> >>> Follow me on: Twitter, developerWorks, LinkedIn >>> >>> >>> -----Original Message----- >>> From: Remco Post [mailto:[email protected]] >>> Sent: Thursday, November 9, 2017 7:59 AM >>> To: [email protected] >>> Subject: [ADSM-L] log not flushing >>> >>> Hi All, >>> >>> for my current customer we’ve build a number of SP 8.1.1 servers. >>> One thing that is new is that sometimes the server doesn’t empty the >>> DB2 active log after a full database backup. The only way it seems >>> that the log gets flushed is by restarting the TSM server. I’ve seen >>> this now 2 or 3 times in the few months that we’re actively using >>> these servers and it makes me feel uneasy. And no, it’s not like the >>> server is very busy, the server was completely idle as far as I can see. >>> >>> -- >>> >>> Met vriendelijke groeten/Kind Regards, >>> >>> Remco Post >>> [email protected] >>> +31 6 248 21 622 >>> >> >> -- >> >> Met vriendelijke groeten/Kind Regards, >> >> Remco Post >> [email protected] >> +31 6 248 21 622 >> > > -- > > Met vriendelijke groeten/Kind Regards, > > Remco Post > [email protected] > +31 6 248 21 622 > -- Met vriendelijke groeten/Kind Regards, Remco Post [email protected] +31 6 248 21 622
