That is my take on it. So we plan to take 500GB from the 1TB space
assigned to the ARCHFAILOVERLOG filesystem and expand the ARCHLOG
filesystem with it. If we have any more incidents like this, we will
simply get rid of ARCHFAILOVERLOG and roll with 2TB in ARCHLOG space.
On Thu, May 23, 2019 at 2:20 PM Sefranek, William <wtsef...@buffalo.edu>
wrote:
> That is very odd as we have utilized the failover space a couple times and
> it worked as advertised.
>
> Now you don’t have any confidence the failover space would work in the
> future and I agree with your idea to expand the archive log so you don’t
> run into this same situation going forward.
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager <ADSM-L@VM.MARIST.EDU> On Behalf Of Zoltan
> Forray
> Sent: Thursday, May 23, 2019 12:20 PM
> To: ADSM-L@VM.MARIST.EDU
> Subject: Re: [ADSM-L] Issues with ARCHFAILOVERLOG
>
> Yes it shows/showed proper usage/stats for the filesystem. It showed
> archfailoverlog filesystem at 12% used while archlog was 100% and every ISP
> server based DBBackup would run for a while and fails with:
>
> 5/20/2019 4:30:05 AM ANR2993E The database backup terminated with a log
> problem. DB2 sqlcode: -2428. DB2 sqlerrmc: .
>
> then starts another DBBackup due to the archlog trigger -
> ad-nauseum...never completing/emptying the logs. We tried with
> 10-streams.....5-streams....even 1-stream but still failed.
>
> Only thing that worked was to shut it down and run manually/directly via
> DB2.
>
> On Thu, May 23, 2019 at 10:14 AM Sefranek, William <wtsef...@buffalo.edu>
> wrote:
>
> > Zoltan,
> >
> > We have had our archive log fill 4 or 5 times in the last couple years
> > and in each case the TSM server started using the archive failover
> > space which allowed the database backup time to complete and clear the
> full archive log.
> >
> > We just have ARCHFAILOVERLOGDIR setting in our dsmserv.opt file set
> > with the directory path of our archive failover partition. Also we are
> > running TSM on AIX if that matters.
> >
> > When you run a 'q log f=d' does it list your archive log filesystem
> > and the space stats for that filesystem?
> >
> > Thanks,
> > Bill
> >
> > -----Original Message-----
> > From: ADSM: Dist Stor Manager <ADSM-L@VM.MARIST.EDU> On Behalf Of
> > Zoltan Forray
> > Sent: Wednesday, May 22, 2019 9:08 AM
> > To: ADSM-L@VM.MARIST.EDU
> > Subject: Re: [ADSM-L] Issues with ARCHFAILOVERLOG
> >
> > The problem with doing it within the ISP environment was it kept
> > trying to write additional records to the ARCHLOG filesystem which was
> > at 100% (which makes no sense - what is the purpose of the
> > ARCHFAILOVERLOG filesystem if not to prevent this kind of issue) and
> > therefore the DB backup run as an ISP server process kept failing and
> > re-running due to the ARCHLOG full condition - a virtual loop! The
> > ACTIVE log was only 25% used so that wasn't the problem.
> >
> > Running a DB backup manually from the OS level as a DB2 process - not
> > an ISP process, cleared both ARCHLOG and ARCHFAILOVERLOG filesystems.
> >
> > I consider this either a program flaw/failure/bug or a design failure.
> >
> > On Wed, May 22, 2019 at 1:50 AM Uwe Schreiber
> > <uwe.h.schrei...@t-online.de
> > >
> > wrote:
> >
> > > A native DB2 (without using it as a ISP Instance DB) is capable to
> > > do a backup of archivelogs.
> > >
> > > But if used as ISP Instance DB the archivelogs wirhin the configured
> > > archivelog destination will removed by running a full backup within
> ISP.
> > >
> > > Regards Uwe
> > >
> > > > Am 21.05.2019 um 16:00 schrieb Hans Christian Riksheim <
> > > bull...@gmail.com>:
> > > >
> > > > Does DB2 have the ability to do just an archivelog backup(no full)
> > > > and clear them afterwards like other RDBMs(Oracle/MSSQL)? That
> > > > would be convenient where the log space is filling up too fast for
> > > > a full
> > > > + archivelog to go through. Been in that desparate situation
> > > > + several
> > times.
> > > >
> > > > Hans Chr.
> > > >
> > > >> On Mon, May 20, 2019 at 3:59 PM Zoltan Forray <zfor...@vcu.edu>
> > wrote:
> > > >>
> > > >> ISP 7.1.7.400 RHEL 7
> > > >>
> > > >> Our offsite replica server ran out of archlog space eventhough we
> > > >> have ARCHFAILOVERLOG defined. Both filesystems are 1TB but it
> > > >> barely used
> > > 10% of
> > > >> the failover space while filling up the archlog filesystem to 100%.
> > > >> DB backup kicked in but couldn't finish (3TB) fast enough before
> > > >> archlog filled so it is hung unable to run a normal DB backup
> > > >> ("DIA8312C Disk
> > > was
> > > >> full." errors in db2diag.
> > > >>
> > > >> We have "ARCHLOGUSEDTHRESHOLD 65" set but still didn't help.
> > > >>
> > > >> So what is the value of ARCHFAILOVERLOG if it didn't help in this
> > > >> scenario? Right now I am trying to run a manual DB2 level backup
> > > >> to
> > > clear
> > > >> things out. My thoughts are to forget ARCHFAILOVERLOG and simply
> > > >> expand the primary archlog to the full 2TB of space.
> > > >>
> > > >> --
> > > >> *Zoltan Forray*
> > > >> Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator
> > > >> VMware Administrator Xymon Monitor Administrator Virginia
> > > >> Commonwealth University UCC/Office of Technology Services
> > > >> www.ucc.vcu.edu zfor...@vcu.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://phishing.vcu.edu/
> > > >>
> > >
> >
> >
> > --
> > *Zoltan Forray*
> > Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator VMware
> > Administrator Xymon Monitor Administrator Virginia Commonwealth
> > University UCC/Office of Technology Services www.ucc.vcu.edu
> > zfor...@vcu.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://phishing.vcu.edu/
> >
>
>
> --
> *Zoltan Forray*
> Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator VMware
> Administrator Xymon Monitor Administrator Virginia Commonwealth University
> UCC/Office of Technology Services www.ucc.vcu.edu zfor...@vcu.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://phishing.vcu.edu/
>
--
*Zoltan Forray*
Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator
VMware Administrator
Xymon Monitor Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
www.ucc.vcu.edu
zfor...@vcu.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://phishing.vcu.edu/
