Welcome! » Log In » Create A New Profile

Issues with ARCHFAILOVERLOG

Posted by Zoltan Forray 
Zoltan Forray
Issues with ARCHFAILOVERLOG
May 20, 2019 07:59AM
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
zforray@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/
This message was imported via the External PhorumMail Module
Hans Christian Riksheim
Re: Issues with ARCHFAILOVERLOG
May 21, 2019 07:59AM
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 <zforray@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
> zforray@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/
>
This message was imported via the External PhorumMail Module
Uwe Schreiber
Re: Issues with ARCHFAILOVERLOG
May 21, 2019 10:59PM
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 <bullhcr@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 <zforray@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
>> zforray@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/
>>
This message was imported via the External PhorumMail Module
Zoltan Forray
Re: Issues with ARCHFAILOVERLOG
May 22, 2019 06:59AM
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.schreiber@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 <
> bullhcr@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 <zforray@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
> >> zforray@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
zforray@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/
This message was imported via the External PhorumMail Module
Sefranek, William
Re: Issues with ARCHFAILOVERLOG
May 23, 2019 07:59AM
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.schreiber@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 <
> bullhcr@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 <zforray@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 zforray@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 zforray@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/
This message was imported via the External PhorumMail Module
Zoltan Forray
Re: Issues with ARCHFAILOVERLOG
May 23, 2019 09:59AM
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 <wtsefran@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.schreiber@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 <
> > bullhcr@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 <zforray@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 zforray@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 zforray@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
zforray@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/
This message was imported via the External PhorumMail Module
Sefranek, William
Re: Issues with ARCHFAILOVERLOG
May 23, 2019 11:59AM
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 <wtsefran@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.schreiber@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 <
> > bullhcr@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 <zforray@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 zforray@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
> zforray@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 zforray@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/
This message was imported via the External PhorumMail Module
Zoltan Forray
Re: Issues with ARCHFAILOVERLOG
May 23, 2019 11:59AM
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 <wtsefran@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 <wtsefran@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.schreiber@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 <
> > > bullhcr@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 <zforray@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 zforray@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
> > zforray@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 zforray@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
zforray@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/
This message was imported via the External PhorumMail Module
Sorry, only registered users may post in this forum.

Click here to login