ADSM-L

Re: 2 3494 Tape libraries seem to have very different capacities. Any ideas?

2004-08-24 08:06:13
Subject: Re: 2 3494 Tape libraries seem to have very different capacities. Any ideas?
From: John C Dury <jdury AT DUQLIGHT DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 24 Aug 2004 07:20:53 -0400
Somehow this thread got a little messy so I'll update it with everything I
know and answer everyone's questions (I think).

A recap: We have 2 3494 libraries, one local and one remote. The remote one
is used for backing up the local one only. There is a huge discrepancy
between the number of scratch tapes in the local and remote libraries
although they both appear to have the same amount of data.

Things people suggested I check:
Compression is on for all drives in both libraries. I checked.
I have "reuse delay" set at 0 on both 3494 libraries so no tapes go into
pending on either library. They immediately become scratches after
reclamation.
We run a job nightly that deletes volhistory for database backups. (del
volhist type=dbb todate=today-2).
See immediately below for a possible explanation although I don't
understand why this would cause it. Anyone?

Looks like I'll be caling IBM.
<sigh>
John


 We originally had a combination of 3590J and 3590K tapes in the 3494LOCAL
 library. I moved the data off of the 3590J tapes and then checked them out
 and checked in 3590K volumes that has the same volume labels as the
 original 3590J volume. Essentially I replaced all the 3590J tapes with
 3590K tapes with the same volume labels. The libary manager was updated to
 reflect the new 3590K volumes before they were checked in.  Could this
 have
 caused this problem?
 John


 ----- Forwarded by John C Dury/DLC on 08/23/2004 02:37 PM -----

              John C Dury/DLC

              08/23/2004 02:28                                           To
              PM                        ADSM-L
                                                                         cc

                                                                    Subject
                                        Re: 2 3494 Tape libraries seem to
                                        have very different capacities. Any
                                        ideas?









 Here is the output from that command. It looks pretty similar to me. I
 also
 checked compression for both local and remote libraries. All are on. We
 also run a job every night that deletes the dbb volhistory which allows
 only 2 days of retention. (del volhist type=dbb todate=today-2)

  STGPOOL_NAME: 3494LOCAL
   Unnamed[2]: 38531539
   Unnamed[3]: 11776076.83
   Unnamed[4]: 11886072.01

 STGPOOL_NAME: 3494REMOTE
   Unnamed[2]: 38513745
   Unnamed[3]: 11773755.03
   Unnamed[4]: 11876887.56

 These are all great suggestions which is why I asked here but I'm still at
 a complete loss.
 John

  The output from "select
  stgpool_name,sum(num_files),sum(logical_mb),sum(physical_mb) from
  occupancy group by stgpool_name" should give some indication of whether
  the same amount of stuff is getting to the remote storagepools.

  David

  >>> jdury AT DUQLIGHT DOT COM 8/23/2004 1:26:57 PM >>>
        We have 2 3494 tape libraries. One is local and the other is
  remote.
  The local one (3494LOCAL) receives all the data from the nightly
  backups as
  it gets migrated from disk. The remote one (3494REMOTE) is only used as
  the
  target of backing up the 3494LOCAL storage pool which gets done
  everyday
  during the day. 3494LOCAL has 577 library volumes in it. 3494REMOTE has
  494
  library volumes in it. Both tape libraries only have 3590K tapes in
  them.
        My problem is that 3494LOCAL has 62 scratch tapes available and
  3494REMOTE has 207 scratch tapes in it. Reclamation runs daily and sets
  the
  same percentage (57) for both libraries. How can there be such a huge
  difference in the number of scratch tapes if both libraries should
  roughly
  have the same amount of data? It's making me a little nervous that
  3494REMOTE doesn't have the same data or something somewhere is going
  wrong.
  Any ideas?
  Thanks,
  John