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/
