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.
