Eric, I meant collocation. It can be by node, by group, by filespace or no collocation.
On Dec 12, 2007 11:06 AM, Loon, E.J. van - SPLXM <[EMAIL PROTECTED]> wrote: > 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:[EMAIL PROTECTED] On Behalf Of > Helder Garcia > Sent: woensdag 12 december 2007 12:43 > To: ADSM-L@VM.MARIST.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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor > > Manager" <ADSM-L@VM.MARIST.EDU> > > 12/11/2007 09:29 AM > > Please respond to > > "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> > > > > > > To > > ADSM-L@VM.MARIST.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:[EMAIL PROTECTED] On Behalf > > Of Loon, E.J. van - SPLXM > > Sent: Tuesday, December 11, 2007 8:05 AM > > To: ADSM-L@VM.MARIST.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:[EMAIL PROTECTED] On Behalf > > Of Jim Young > > Sent: dinsdag 11 december 2007 14:26 > > To: ADSM-L@VM.MARIST.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 > ********************************************************************** > -- Helder Garcia
