ADSM-L

Re: [ADSM-L] Strange difference between Primary and Copypool

2007-12-12 13:25:31
Subject: Re: [ADSM-L] Strange difference between Primary and Copypool
From: Larry Peifer <Larry.Peifer AT SCE DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 12 Dec 2007 10:24:03 -0800
Eric -

It looks like your system is storing about the same amount of data,  26TB
/ 27TB, as our system is but I notice that you are using over 300 more
LTO2 tapes to store it on.  Is that correct?

Are you using collocation?  What does 'q collocgroup' show?

Also, what format are you using for the tape device class?   q devclass

I find these queries helpful to monitor on a daily basis now that I'm
tracking tape issues for IBM PMRs related to our particular issue.

select stgpool_name,status,count(*) TOTAL from volumes where scratch='YES'
group by stgpool_name, status

STGPOOL_NAME           STATUS                       TOTAL
TAPEPOOL6              FILLING                  5
TAPEPOOL6              FULL                     95
TAPEPOOL6              PENDING                  8
TAPEPOOL7              FILLING                  5
TAPEPOOL7              FULL                     102
TAPEPOOL7              PENDING                  6

select library_name, last_use, status, count(status) from libvolumes group
by library_name,last_use,status

LIBRARY_NAME           LAST_USE       STATUS          Unnamed[4]
LTOLIB6                         Scratch                 20
LTOLIB6         Data            Private                108
LTOLIB7                         Scratch                 11
LTOLIB7         Data            Private                114
LTOLIB7         DbBackup        Private                  3

Larry






"Loon, E.J. van - SPLXM" <Eric-van.Loon AT KLM DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
12/12/2007 05:05 AM
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>


To
ADSM-L AT VM.MARIST DOT EDU
cc

Subject
Re: [ADSM-L] Strange difference between Primary and Copypool






Hi Larry!
We are using EMC DL700 disk libraries which emulate several 3584
libraries with LTO2 tapes.
Personally, I find the difference between primary and copy pool tape
count in your shop not as shocking as mine though...
Kindest regards,
Eric van Loon
KLM Royal Dutch Airlines


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Larry Peifer
Sent: dinsdag 11 december 2007 23:04
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Strange difference between Primary and Copypool

Eric,

I'm interested in learning more about the particulars of your
environment.
 We have been experiencing some odd behavior with our tape pools after
recently upgrading the TSM server to 5.4.0 and the Clients (Windows and
Unix) to 5.4.1 clients.  We also have a primary tape pool library with a
copy pool tape library as an electronic vault.

Also,  what tape library hardware and tape media are you using?

We have IBM 3584 libraries with LTO2 drives and LTO2 tapes using
Ultrium2C device type.

Our usage is similar to you:

Storagepool                                           MB
TAPEPOOL6                                    29154145.05        Primary
TAPEPOOL7                                    28563583.89        Copy

Seq. Stg. Pool         Volumes in Use
TAPEPOOL6                         106
TAPEPOOL7                         112  (includes 4 DBBackup tapes)

We have several PMR's (3584 h/w and TSM s/w) open with IBM regarding a
large increase in # of tapes used to hold our data after making the
upgrade.





Andy Huebner <Andy.Huebner AT ALCONLABS DOT COM> Sent by: "ADSM: Dist Stor
Manager" <ADSM-L AT VM.MARIST DOT EDU>
12/11/2007 09:29 AM
Please respond to
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>


To
ADSM-L AT VM.MARIST DOT EDU
cc

Subject
Re: [ADSM-L] Strange difference between Primary and Copypool






I would say it is normal to have a little more data in the primary pool
due to on-going backups.  We have backups running all the time.
Since the primary and copy tapes are created differently I am not
surprised that there is a different number of tapes.  Has there always
been more copy than primary tapes?  I would think the tape count could
swing the other way.

Andy Huebner
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Loon, E.J. van - SPLXM
Sent: Tuesday, December 11, 2007 8:05 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Strange difference between Primary and Copypool

Hi Jim!
My copy pool is an online copy pool. Tapes (in fact virtual tapes) are
not checked out, nor removed from the (virtual) library.
I didn't state that my copy pool is larger than the primary pool (hence
my line "although the copy pool (DL_LBU3_CPY_1) contains less data, it
uses more tapes!!!") and I also stated that both storage pools are
reclaimed at 60%... On a daily bases..
Kindest regards,
Eric van Loon
KLM Royal Dutch Airlines


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Jim Young
Sent: dinsdag 11 december 2007 14:26
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Strange difference between Primary and Copypool

Hi

My theory works if the following is true.

1) the copy pool is offsite.
2) your statement that the copy pool is larger than the primary pool was
incorrect. Its the other way round looing at the numbers given.

Original sizings
Storagepool MB
------------------ ---------------------------------
DL_LBU3_CPY_1 26489427.98
DL_LBU3_PRI_1 27658559.10

As the tapes onsite (in the library) can be mounted over and over again
putting new data at the end of the volume until full, you have a
non-tape wasting process,

BUT

The offsite tapes are created and then shipped offsite. The offsite
tapes can only be recreated from onsite data and as such, unless they
trigger the 60% free reclamation they will sit there until 40% utilized,
never defraging, just taking up lots of your lovely tapes.  Additional
waste can be caused by collocation as well. Not knowing if that is used
for nodes in this pool i cannot comment.  Plus we don't know the size of
files you are backing up against the size of the tapes. ie. a 36Gb
database file on a 40Gb DLT holds 90% of the tape.

I find this SQL useful for identifying tapes that get stuck and not
reclaimed.

    select volume_name, stgpool_name,pct_utilized, status from volumes -
    where pct_utilized < 40 and stgpool_name <>'DISKPOOL' -
    order by pct_utilized, stgpool_name, volume_name

Cheers

Jim


Cattles plc Registered in England No: 543610 Kingston House, Centre 27
Business Park, Woodhead Road, Birstall, Batley, WF179TD.

The views and opinions expressed herein are those of the author and not
of Cattles plc or any of its subsidiaries.The content of this e-mail is
confidential, may contain privileged material and is intended solely for
the recipient(s) named above.

If you receive this in error, please notify the sender immediately and
delete this e-mail.

Please note that neither Cattles plc nor the sender accepts any
responsibility for viruses and it is your responsibility to scan the
email and attachments(if any). No contracts or agreements may be
concluded on behalf of Cattles plc or its subsidiaries by means of email
communications.

This message has been scanned for Viruses by Cattles and Sophos
Puremessage scanning service.
**********************************************************************
For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain
confidential and privileged material intended for the addressee only. If
you are not the addressee, you are notified that no part of the e-mail
or any attachment may be disclosed, copied or distributed, and that any
other action related to this e-mail or attachment is strictly
prohibited, and may be unlawful. If you have received this e-mail by
error, please notify the sender immediately by return e-mail, and delete
this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or
its employees shall not be liable for the incorrect or incomplete
transmission of this e-mail or any attachments, nor responsible for any
delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch
Airlines) is registered in Amstelveen, The Netherlands, with registered
number 33014286
**********************************************************************


This e-mail (including any attachments) is confidential and may be
legally privileged. If you are not an intended recipient or an
authorized representative of an intended recipient, you are prohibited
from using, copying or distributing the information in this e-mail or
its attachments.
If you have received this e-mail in error, please notify the sender
immediately by return e-mail and delete all copies of this message and
any attachments.
Thank you.
**********************************************************************
For information, services and offers, please visit our web site:
http://www.klm.com. This e-mail and any attachment may contain
confidential and privileged material intended for the addressee
only. If you are not the addressee, you are notified that no part
of the e-mail or any attachment may be disclosed, copied or
distributed, and that any other action related to this e-mail or
attachment is strictly prohibited, and may be unlawful. If you have
received this e-mail by error, please notify the sender immediately
by return e-mail, and delete this message.

Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries
and/or its employees shall not be liable for the incorrect or
incomplete transmission of this e-mail or any attachments, nor
responsible for any delay in receipt.
Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal
Dutch Airlines) is registered in Amstelveen, The Netherlands, with
registered number 33014286
**********************************************************************