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

Helder,

In our case we always direct the DB backup to a particular tape library by
design.

backup db type=full devclass=ltoclass7

where ltoclass7 only has one device in it; which is in our DR alternate
site, online electronic tape vault.

Larry





Helder Garcia <helder.garcia AT GMAIL DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
12/12/2007 03:42 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






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