Hi Helder!
I'm 100% sure reclamation is set to 60% on all storage pools on all
servers.
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
Helder Garcia
Sent: woensdag 12 december 2007 12:43
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Strange difference between Primary and Copypool
Larry, DB backup tapes does not belong to any particular storage pool.
Anyway, your environment shows more acceptable numbers than Eric's. A
little delta (106 to 112) in the number of tapes is always present due
to reclamation running in different moments, incomplete expiration
processes an other factors.
Eric, are you sure you don't have different collocation settings on the
storage pools?
On Dec 11, 2007 8:04 PM, Larry Peifer <Larry.Peifer AT sce DOT com> wrote:
> 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.
>
--
Helder Garcia
**********************************************************************
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
**********************************************************************
|
