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
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.
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
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
Hello Guys/Girls,
I discoverd something "strange" during a Full restore on production.
On Windows server 2016 (+ windows 10) since Spectrum protect (tsm)
version 8.1.x the SystemState restore is not more possible (deprecated)
on the online machine.
Instreat everyone should build a WinPE
Hallo Guys,
We just started to use this useful feature called retention sets in v817,
but see that it lacks flexibility, if we wish to move tsm nodes with valid
retention sets from server A to B.
IBM support says.
"You cannot export retention sets nor retention rules."
So you must rebuild
