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/
