Re: TSM performance very poor, Recovery log is being pinned
Thanks for all input guys, Firstly sorry for lack of detail. TSM is installed on Solaris 10, No I did not do any benchmarking, as we were not replacing any existing setup just adding more, I have 6 LTO drives already installed and about 17TB of SAN storage which is Primary Random, I have since added 4 new LTO 3 drives (with different Device classes) and they run better than the LTO 1 drives, when server is not logpinning. And the new 15 TB of SATA, now approx 1 TB of the DISK is Primary Random storage and the remainder is SEQ file and its all FS not RAW, I have had heavy discussion over RAW vs FS and I have not been able to find definitive answer Clients I don;t think are causing the issue any TSM processes can pin the log from migrations DB backups and clients sessions. Once the server starts getting busy. Currently (sorry not in front of installation) but I guess of the 15TB I have about 60 sequential volumes across 4 Stgpools, and I have still more to define. I have not had clients utilize this new storage yet, all I have done is start to migrate data into these STGPools to release some of the legacy STGpools The Transport to DB and Recovery Log is SAN, however yesterday I created local copy and this did not improve things. The STGpools are on WMS SAN and AMS500 SAN. Both SATA disk. All across Fibre!! The SAN engineer when installing the Disk's saw expected performance out of the DISK's. I also don't see it being maxsessions because I can Pin the log with 3 or 4 sessions and 3 processes! I think its safe to say its configuration somewhere, because now I think about it its not taking much load to pin the log. Load in which TSM normally copes ok!! Next step may be to remove the New DISK's now will I need to just unmount the FS or will i Need to migrate data off new storage and delete volumes and New STGpools? Thanks On 7/28/07, Lawrence Clark <[EMAIL PROTECTED]> wrote: > > Assuming the SATA are on AIX, were the logical volumes set up to hold > the volumes > defined as JFS2? > > >>> [EMAIL PROTECTED] 07/27/2007 2:30:54 PM >>> > Do the client backup sessions pin the log? What is the throughput on > the > actual client session and are these backups direct to disk? If the > sessions are cancelled does the system come back to life? > > 15 TB of SATA sounds like a lot of storage. how has this been > added/configured- What raw throughput do you get on these disks outside > of > TSM itself? > > You say the LTO3 drives are new. Do you have existing LTO3 drives? > Have > you configured them correctly with new device class etc if you are > mixing > LTO generations in the library? > > I have seen this type of pinning/dramatic slow down before. I saw > itself > manifest by the server hitting the maxsessions limit as all the > sessions > were running so slowly to the disk pool. > > Lots of questions i know, but as you have made multiple changes at the > same time- its going to be difficult to nail down without additional > info. > > Ian Smith > --- > Core Engineering - Storage > > > > > > Robert Clark <[EMAIL PROTECTED]> > Sent by: "ADSM: Dist Stor Manager" > 27/07/2007 18:01 > Please respond to > "ADSM: Dist Stor Manager" > > > To > ADSM-L@VM.MARIST.EDU > cc > > Subject > Re: [ADSM-L] TSM performance very poor, Recovery log is being pinned > > > > > > > Is the SATA setup as disk storage pools? Is it filesystem or raw > logical volumes? > > What is the OS? vmstat or top/topas may give some ideas. > > What is the network transport? Fast ethernet? > > [RC] > > On Jul 27, 2007, at 2:49 AM, Craig Ross wrote: > > > 10 days ago I Recently added 15TB of SATA storage and a new Fabric > > with 4 > > new LTO drives to our 3584 library, > > The DB is approx 90GB TSM > > > > Few days ago I noticed processing had ground to halt, after digging > > around I > > have found as soon as server gets busy maybe 4 processes 8 or so > > sessions > > the recovery log begins "sh logpinned" to pin and the Database gets > > locks. > > Shown by running "sh locks" > > And as result the server suffers! > > Now today I have stopped using the new Tech LTO 3 and SATA and > > things are > > coping better but still worse than previous as soon as load is > > increased Log > > pins and processing slows drastically. > > > > Are there any steps I can take which will help my scenario. > > Would a DB UNLOAD RELOAD help that much? > > > > Reference: Recovery log has heaps of room DB has heaps of room 90Gb > > DB with > > 100GB of room. > > > > Any advice is much appreciated. > > > > --- > > This e-mail may contain confidential and/or privileged information. If > you are not the intended recipient (or have received this e-mail in > error) please notify the sender immediately and delete this e-mail. Any > unauthorized copying, disclosure or distribution of the material in this > e-mail is strictly forbidden. > > Please refer to http://www.db.com/en/content/eu_disclosures.htm for > addition
Re: TSM vs. Legato Networker Comparison
John, In your comparison, you may want to include option #3 - tar (unix) and backup (Windows). The software cost is incredibly low and there should be zero compatibility issues with the installed operating systems :-) Have fun rock hunting. Neil -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Schneider, John Sent: Friday, July 27, 2007 2:06 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM vs. Legato Networker Comparison Kelly, Thank you for your post. There is no reason to say we are unhappy with TSM. Since I inherited this environment about a year ago, due to lots of hardware and software version upgrades, and help from the Windows and AIX teams, our daily backup completion status (neither missed nor failed)has gone from 95% to 99%. That is less than 10 out of the ~1000 clients daily, which is quite good by industry standards. No, according to management, cost is the driving factor. The proposals between IBM and it's closest competitor are, over a total three year cost, umpteen thousand dollars apart (I won't say the exact figure). It is enough to make everybody take notice. Of course, no one has figured in the cost of conversion, both in software and manpower. That will be huge. Not to mention the huge distraction and lost opportunity cost and risk of outages that could result.\I agree that IBM ought to go back and sharpen their pencil, and bargain away this threat to their territory. Best Regards, John D. Schneider Email: [EMAIL PROTECTED] -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Kelly Lipp Sent: Wednesday, July 25, 2007 1:01 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM vs. Legato Networker Comparison And besides cost, is there any apparent technical reason to undertake such a thing in the first place? I.e., are you or your management in some way unhappy with the backup processing? Again, except for the cost? I also think there is a golden opportunity to work with your current backup vendor to get the cost for you inline with what the proposed competition is offering. Doing this may forestall the entire rock fetch you've been asked to undertake. The real funny thing is that at the end of the day, the cost (when done over a period of years rather than a single purchase) will be nearly identical no matter which vendor you choose. But you will have been through the rock fetch, and perhaps a painful migration only to learn this simple fact. If only management (who should know better than to waste valuable time and money) understood this before sending us poor technical slobs on the mission... Kelly J. Lipp VP Manufacturing & CTO STORServer, Inc. 485-B Elkton Drive Colorado Springs, CO 80907 719-266-8777 [EMAIL PROTECTED] -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Bell, Charles (Chip) Sent: Wednesday, July 25, 2007 11:18 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM vs. Legato Networker Comparison Interesting. We are doing the same thing, but with multiple vendors, for the EXACT same reason you are. We are generating a single RFI that we will send to each vendor, and get our comparison that way. Not done yet, and I'm not looking forward to it. I like TSM as a product, and I'm not looking forward to a possible migration, 'cause like you said, there will be a cost associated with it (more media/drives?, hardware, fill in the blank). We are supposed to be talking with EMC soon, and have already talked to CommVault, BakBone, Syncsort, and Symantec. Good luck with that. :) -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Schneider, John Sent: Wednesday, July 25, 2007 11:55 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM vs. Legato Networker Comparison Greetings, We have been a TSM shop for many years, but EMC came to our management with a proposal to replace our TSM licenses with Legato Networker, at a better price than what we are paying for TSM today. This came right on the heels of paying our large TSM license bill, and so it got management's attention. We have an infrastructure of 15 TSM servers and about 1000 clients, so this would be a large and painful migration. It would also require a great deal of new hardware and consultant costs during the migration, which would detract from the cost savings. So instead of jumping from one backup product to another based on price alone, we have been asked to do an evaluation between the two products. Do any of you have any feature comparisons between the two products that would give me a head start? Best Regards, John D. Schneider Email: [EMAIL PROTECTED] - Confidentiality Notice: The information contained in this email message is privileged and confidential information and intended only for the use of
Re: TSM vs. Legato Networker Comparison
Stuart, Thanks for your excellent point. One thing that frequently determines the reputation of a backup product within a company is the quality of the hardware it is running on, and the skillset of the people managing it. We had one remote location with an old LTO1 tape library, running TSM 5.1 on a 700MHz Pentium II Win2K box with a 10/100 card, and the people supporting it hated TSM because "this TSM server is always having problems". We have since upgraded it to a new IBM LTO3 library and a CDL 210, running TSM 5.3.4.2 on a new Win2003 server with dual 3.2Ghz Xeons w/GigE, and all the problems have gone away. Now the people who monitor it have nothing to complain about, so they complain about our Exchange servers instead! Time to upgrade those next, I guess. Best Regards, John D. Schneider Email: [EMAIL PROTECTED] -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Stuart Lamble Sent: Wednesday, July 25, 2007 5:57 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM vs. Legato Networker Comparison On 26/07/2007, at 2:54 AM, Schneider, John wrote: > Greetings, > We have been a TSM shop for many years, but EMC came to our > management with a proposal to replace our TSM licenses with Legato > Networker, at a better price than what we are paying for TSM today. > This came right on the heels of paying our large TSM license bill, and > so it got management's attention. > We have an infrastructure of 15 TSM servers and about 1000 clients, > so this would be a large and painful migration. It would also > require a great deal of new hardware and consultant costs during the > migration, which would detract from the cost savings. > So instead of jumping from one backup product to another based > on price alone, we have been asked to do an evaluation between the two > products. Do any of you have any feature comparisons between the two > products that would give me a head start? Funny you say this. Monash was a Legato (now owned by EMC) shop until the TSM migration around 3-4 years ago; I suspect that a large number of the problems that were perceived to be Networker's fault were actually the fault of the aging DLT silos and drives that underlay Networker. I still have fond memories of those silos; they gave me a great deal of callout pay every time they had a stuck cartridge or similar. :-) I also suspect that the greater reliability we've had since putting in TSM is more because we also got in new tape silos (LTO2, now half LTO2 and half LTO3, and soon to be half LTO3 and half LTO4) - if we'd stuck with the DLT silos, we'd still be in a world of pain, regardless of the software. There are plusses and minuses to both products. Some points to consider: * Networker uses the traditional "full plus incrementals, or dump levels" system. Monash used a pattern of "full once a month; incremental every other day; and a dump level interwoven" - so, for example, it might go "full, incremental, level 8, incremental, level 7, incremental, level 9, level 2, incremental, level 8, incremental, etc." - the idea being to minimise the number of backups needed to restore a system. * Networker indexes are somewhat analogous to the TSM database. In theory, you can scan each tape to rebuild the indexes if they're lost; in practice, if you lose the indexes, you're pretty much dead - there's just too much data to scan if the system is more than moderately sized. Yes, Networker backs up the indexes each day. :) * At least the versions of Networker (up to 7.x) we used doesn't support the idea of staging to disk - everything goes directly to tape. However, data streams from multiple clients are multiplexed onto tape to get the write speeds up. This is good for backups, but does make recovery slower (since the data read will include a lot of data for other clients.) * No more reclamation or copy pools to deal with (because of the traditional full/incremental/dump level system). So the burden placed on the tape drives is probably going to be significantly lower (although you will be backing up more data each night than you would with TSM.) * I don't think Networker has anything analogous to TSM's scratch pool: volumes belong to a pool of tapes, and there's no shuffling between the pool. So if the "standard" pool has a hundred tapes available for use, but the "database" pool is out of tapes and needs one more, you need to manually intervene. This *may* have been because of the way we configured Networker, though, and it may also have changed in the interim. Note that you *have* to have a separate pool of tapes for index backups. My honest assessment mirrors that of the other people who have replied: use this as an opportunity to negotiate better pricing from IBM, and point out to the powers that be that there are risks involved with moving to a different backup product. There's nothing wrong with Networker, it's a good syste
FW: Gargoyle Parallel: Clustered TSM Backups
The Windows people are trying to set up a clustered SQL node. The TDP is going fine, but the Window boxes are having problems. The defined cluster runs for hours and then disappears, not even leaving a "connection lost" message in the ActLog. The individual machines both completed Tuesday's backup, but this is the result of last night's: . 07/27/2007 06:38:24 findAbortState: Unknown abort #237 from the server 07/27/2007 06:38:24 findAbortState: Unknown abort #237 from the server 07/27/2007 06:38:24 ANS0343E An invalid operation was attempted on a group leader or group member. 07/27/2007 06:38:24 ANS1512E Scheduled event 'SYSSERV-WIN-PM' failed. Return code = 12. The messages manual isn't very helpful here: User response: Retry a valid operation. Server level is 5.4.0.3 and all clients are 5.4.0.2
Re: TSM vs. Legato Networker Comparison
Kelly, Thank you for your post. There is no reason to say we are unhappy with TSM. Since I inherited this environment about a year ago, due to lots of hardware and software version upgrades, and help from the Windows and AIX teams, our daily backup completion status (neither missed nor failed)has gone from 95% to 99%. That is less than 10 out of the ~1000 clients daily, which is quite good by industry standards. No, according to management, cost is the driving factor. The proposals between IBM and it's closest competitor are, over a total three year cost, umpteen thousand dollars apart (I won't say the exact figure). It is enough to make everybody take notice. Of course, no one has figured in the cost of conversion, both in software and manpower. That will be huge. Not to mention the huge distraction and lost opportunity cost and risk of outages that could result.\I agree that IBM ought to go back and sharpen their pencil, and bargain away this threat to their territory. Best Regards, John D. Schneider Email: [EMAIL PROTECTED] -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Kelly Lipp Sent: Wednesday, July 25, 2007 1:01 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM vs. Legato Networker Comparison And besides cost, is there any apparent technical reason to undertake such a thing in the first place? I.e., are you or your management in some way unhappy with the backup processing? Again, except for the cost? I also think there is a golden opportunity to work with your current backup vendor to get the cost for you inline with what the proposed competition is offering. Doing this may forestall the entire rock fetch you've been asked to undertake. The real funny thing is that at the end of the day, the cost (when done over a period of years rather than a single purchase) will be nearly identical no matter which vendor you choose. But you will have been through the rock fetch, and perhaps a painful migration only to learn this simple fact. If only management (who should know better than to waste valuable time and money) understood this before sending us poor technical slobs on the mission... Kelly J. Lipp VP Manufacturing & CTO STORServer, Inc. 485-B Elkton Drive Colorado Springs, CO 80907 719-266-8777 [EMAIL PROTECTED] -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Bell, Charles (Chip) Sent: Wednesday, July 25, 2007 11:18 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM vs. Legato Networker Comparison Interesting. We are doing the same thing, but with multiple vendors, for the EXACT same reason you are. We are generating a single RFI that we will send to each vendor, and get our comparison that way. Not done yet, and I'm not looking forward to it. I like TSM as a product, and I'm not looking forward to a possible migration, 'cause like you said, there will be a cost associated with it (more media/drives?, hardware, fill in the blank). We are supposed to be talking with EMC soon, and have already talked to CommVault, BakBone, Syncsort, and Symantec. Good luck with that. :) -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Schneider, John Sent: Wednesday, July 25, 2007 11:55 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM vs. Legato Networker Comparison Greetings, We have been a TSM shop for many years, but EMC came to our management with a proposal to replace our TSM licenses with Legato Networker, at a better price than what we are paying for TSM today. This came right on the heels of paying our large TSM license bill, and so it got management's attention. We have an infrastructure of 15 TSM servers and about 1000 clients, so this would be a large and painful migration. It would also require a great deal of new hardware and consultant costs during the migration, which would detract from the cost savings. So instead of jumping from one backup product to another based on price alone, we have been asked to do an evaluation between the two products. Do any of you have any feature comparisons between the two products that would give me a head start? Best Regards, John D. Schneider Email: [EMAIL PROTECTED] - Confidentiality Notice: The information contained in this email message is privileged and confidential information and intended only for the use of the individual or entity named in the address. If you are not the intended recipient, you are hereby notified that any dissemination, distribution, or copying of this information is strictly prohibited. If you received this information in error, please notify the sender and delete this information from your computer and retain no copies of any of this information.
Re: TSM performance very poor, Recovery log is being pinned
Do the client backup sessions pin the log? What is the throughput on the actual client session and are these backups direct to disk? If the sessions are cancelled does the system come back to life? 15 TB of SATA sounds like a lot of storage. how has this been added/configured- What raw throughput do you get on these disks outside of TSM itself? You say the LTO3 drives are new. Do you have existing LTO3 drives? Have you configured them correctly with new device class etc if you are mixing LTO generations in the library? I have seen this type of pinning/dramatic slow down before. I saw itself manifest by the server hitting the maxsessions limit as all the sessions were running so slowly to the disk pool. Lots of questions i know, but as you have made multiple changes at the same time- its going to be difficult to nail down without additional info. Ian Smith --- Core Engineering - Storage Robert Clark <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" 27/07/2007 18:01 Please respond to "ADSM: Dist Stor Manager" To ADSM-L@VM.MARIST.EDU cc Subject Re: [ADSM-L] TSM performance very poor, Recovery log is being pinned Is the SATA setup as disk storage pools? Is it filesystem or raw logical volumes? What is the OS? vmstat or top/topas may give some ideas. What is the network transport? Fast ethernet? [RC] On Jul 27, 2007, at 2:49 AM, Craig Ross wrote: > 10 days ago I Recently added 15TB of SATA storage and a new Fabric > with 4 > new LTO drives to our 3584 library, > The DB is approx 90GB TSM > > Few days ago I noticed processing had ground to halt, after digging > around I > have found as soon as server gets busy maybe 4 processes 8 or so > sessions > the recovery log begins "sh logpinned" to pin and the Database gets > locks. > Shown by running "sh locks" > And as result the server suffers! > Now today I have stopped using the new Tech LTO 3 and SATA and > things are > coping better but still worse than previous as soon as load is > increased Log > pins and processing slows drastically. > > Are there any steps I can take which will help my scenario. > Would a DB UNLOAD RELOAD help that much? > > Reference: Recovery log has heaps of room DB has heaps of room 90Gb > DB with > 100GB of room. > > Any advice is much appreciated. --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures.
Re: TSM performance very poor, Recovery log is being pinned
Assuming the SATA are on AIX, were the logical volumes set up to hold the volumes defined as JFS2? >>> [EMAIL PROTECTED] 07/27/2007 2:30:54 PM >>> Do the client backup sessions pin the log? What is the throughput on the actual client session and are these backups direct to disk? If the sessions are cancelled does the system come back to life? 15 TB of SATA sounds like a lot of storage. how has this been added/configured- What raw throughput do you get on these disks outside of TSM itself? You say the LTO3 drives are new. Do you have existing LTO3 drives? Have you configured them correctly with new device class etc if you are mixing LTO generations in the library? I have seen this type of pinning/dramatic slow down before. I saw itself manifest by the server hitting the maxsessions limit as all the sessions were running so slowly to the disk pool. Lots of questions i know, but as you have made multiple changes at the same time- its going to be difficult to nail down without additional info. Ian Smith --- Core Engineering - Storage Robert Clark <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" 27/07/2007 18:01 Please respond to "ADSM: Dist Stor Manager" To ADSM-L@VM.MARIST.EDU cc Subject Re: [ADSM-L] TSM performance very poor, Recovery log is being pinned Is the SATA setup as disk storage pools? Is it filesystem or raw logical volumes? What is the OS? vmstat or top/topas may give some ideas. What is the network transport? Fast ethernet? [RC] On Jul 27, 2007, at 2:49 AM, Craig Ross wrote: > 10 days ago I Recently added 15TB of SATA storage and a new Fabric > with 4 > new LTO drives to our 3584 library, > The DB is approx 90GB TSM > > Few days ago I noticed processing had ground to halt, after digging > around I > have found as soon as server gets busy maybe 4 processes 8 or so > sessions > the recovery log begins "sh logpinned" to pin and the Database gets > locks. > Shown by running "sh locks" > And as result the server suffers! > Now today I have stopped using the new Tech LTO 3 and SATA and > things are > coping better but still worse than previous as soon as load is > increased Log > pins and processing slows drastically. > > Are there any steps I can take which will help my scenario. > Would a DB UNLOAD RELOAD help that much? > > Reference: Recovery log has heaps of room DB has heaps of room 90Gb > DB with > 100GB of room. > > Any advice is much appreciated. --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain information that is confidential, privileged, and/or otherwise exempt from disclosure under applicable law. If this electronic message is from an attorney or someone in the Legal Department, it may also contain confidential attorney-client communications which may be privileged and protected from disclosure. If you are not the intended recipient, be advised that you have received this message in error and that any use, dissemination, forwarding, printing, or copying is strictly prohibited. Please notify the New York State Thruway Authority immediately by either responding to this e-mail or calling (518) 436-2700, and destroy all copies of this message and any attachments.
Re: TSM performance very poor, Recovery log is being pinned
Is the SATA setup as disk storage pools? Is it filesystem or raw logical volumes? What is the OS? vmstat or top/topas may give some ideas. What is the network transport? Fast ethernet? [RC] On Jul 27, 2007, at 2:49 AM, Craig Ross wrote: 10 days ago I Recently added 15TB of SATA storage and a new Fabric with 4 new LTO drives to our 3584 library, The DB is approx 90GB TSM Few days ago I noticed processing had ground to halt, after digging around I have found as soon as server gets busy maybe 4 processes 8 or so sessions the recovery log begins "sh logpinned" to pin and the Database gets locks. Shown by running "sh locks" And as result the server suffers! Now today I have stopped using the new Tech LTO 3 and SATA and things are coping better but still worse than previous as soon as load is increased Log pins and processing slows drastically. Are there any steps I can take which will help my scenario. Would a DB UNLOAD RELOAD help that much? Reference: Recovery log has heaps of room DB has heaps of room 90Gb DB with 100GB of room. Any advice is much appreciated.
Re: New policy domain
It depends of the name of management class in the new domain. For backup copy groups, if TSM find a mgmt class with the same name in the new domain (and with a backup copy group within...), it will rebind objects to the new policies If not, it will rebind object to the default mgmt class I think it's the same for archive copy groups but check that to be sure... Pierre Cayé > -Message d'origine- > De : ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] De > la part de Wayne Prasek > Envoyé : vendredi 27 juillet 2007 17:56 > À : ADSM-L@VM.MARIST.EDU > Objet : [ADSM-L] New policy domain > > Hi everyone, > > I have a few quick question regarding changing policy > domains. I looked through the admin guide but it didn't > clear all my questions up. We are still running 5.2 (soon to be 5.3). > > We need to change a few clients to start using a completely > new policy domain which includes a new storage pool and > retention periods.. etc etc. Once we change the clients > policy domain what exactly happens to the existing data in > the old policy domain? Will remain active and expire as > usual? What will happen the next time the clients get backed > up? Will it do a full incremental backup? > > > *** > Wayne Prasek > Sr IT Support Analyst (Server) > 204-985-1694 > [EMAIL PROTECTED] > *** >
New policy domain
Hi everyone, I have a few quick question regarding changing policy domains. I looked through the admin guide but it didn't clear all my questions up. We are still running 5.2 (soon to be 5.3). We need to change a few clients to start using a completely new policy domain which includes a new storage pool and retention periods.. etc etc. Once we change the clients policy domain what exactly happens to the existing data in the old policy domain? Will remain active and expire as usual? What will happen the next time the clients get backed up? Will it do a full incremental backup? *** Wayne Prasek Sr IT Support Analyst (Server) 204-985-1694 [EMAIL PROTECTED] ***
Re: TSM DB backup question
OK, thanks for the information > -Message d'origine- > De : ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] De > la part de Nicholas Rodolfich > Envoyé : vendredi 27 juillet 2007 17:17 > À : ADSM-L@VM.MARIST.EDU > Objet : Re: [ADSM-L] TSM DB backup question > > Sorry for the confusion here all. > > I have sent out a reponse to this post earlier this AM, but > it is taking a while to post. Looks like you responded to it > below. I am not sure why this is not included in the post. I > will try posting it again. > > FYI, the file system is a large file enabled JFS2 and > filesize is set to unlimited. I created a file larger than > 64Gb with AIX on the filesystem with no problems. IBM says > this is a TSM limitation not an AIX one and they have an APAR > associated with it (see link below) > > --- > Again im sorry, this was my mistake, I miss understood what > my colleague had told me. Indeed AIX its self will work with > file spaces larger than 64g BUT As per the APAR I linked you... > > http://www-1.ibm.com/support/docview.wss?uid=swg1IC50581 > > The 64g is a known limitation of TSM on AIX systems. As such > TSM will only recognize up to 64g of space on a FILE type > space. I have found further information confirming this in > another PMR. As shown on the bottom of the APAR, this problem > will be fixed in a future release. > > Does this answer your question? is there anything else I can > help you with? > > Phil > --- > > > Nicholas Rodolfich > TSM/AIX Administrator > East Jefferson General Hospital > Fidelity Information Systems > 504-883-6955 (office) > 228-223-6777 (mobile) > [EMAIL PROTECTED] > > > >>> [EMAIL PROTECTED] 7/27/2007 9:45 AM >>> > On Jul 27, 2007, at 10:10 AM, Nicholas Rodolfich wrote: > > > Well it seems that this is a TSM limitationnot a file system > > limitation per IBM. > > We still don't have pertinent details on this problem. What > is your AIX operating system bitmode, and your file system > type? Those factors may impose architectural limits on the > file size you may utilize. > >Richard Sims > > > IMPORTANT NOTICE: This message and any included attachments > are from East Jefferson General Hospital, and is intended > only for the addressee(s), and may include Protected Health > (PHI) or other confidential information. If you are the > intended recipient, you are obligated to maintain it in a > secure and confidential manner and re-disclosure without > additional consent or as permitted by law is prohibited. If > you are not the intended recipient, use of this information > is strictly prohibited and may be unlawful. Please promptly > reply to the sender by email and delete this message from > your computer. East Jefferson General Hospital greatly > appreciates your cooperation. >
Re: TSM vs. Legato Networker Comparison
I'm not familiar with Networker except in it's old i-just-do-full-dumps form. How does it deal with mixed retention requirements? Can you set up one directory to be retained for 7 years and another to be retained for 90 days like you can with TSM/ > On 26/07/2007, at 2:54 AM, Schneider, John wrote: > >> Greetings, >> We have been a TSM shop for many years, but EMC came to our >> management with a proposal to replace our TSM licenses with Legato >> Networker, at a better price than what we are paying for TSM today. >> This came right on the heels of paying our large TSM license bill, and >> so it got management's attention. >> We have an infrastructure of 15 TSM servers and about 1000 >> clients, so this would be a large and painful migration. It would >> also >> require a great deal of new hardware and consultant costs during the >> migration, which would detract from the cost savings. >> So instead of jumping from one backup product to another based >> on price alone, we have been asked to do an evaluation between the two >> products. Do any of you have any feature comparisons between the two >> products that would give me a head start? > > Funny you say this. Monash was a Legato (now owned by EMC) shop until > the TSM migration around 3-4 years ago; I suspect that a large number > of the problems that were perceived to be Networker's fault were > actually the fault of the aging DLT silos and drives that underlay > Networker. I still have fond memories of those silos; they gave me a > great deal of callout pay every time they had a stuck cartridge or > similar. :-) > > I also suspect that the greater reliability we've had since putting > in TSM is more because we also got in new tape silos (LTO2, now half > LTO2 and half LTO3, and soon to be half LTO3 and half LTO4) - if we'd > stuck with the DLT silos, we'd still be in a world of pain, > regardless of the software. > > There are plusses and minuses to both products. Some points to consider: > >* Networker uses the traditional "full plus incrementals, or dump > levels" system. Monash used a pattern of "full once a month; > incremental every other day; and a dump level interwoven" - so, for > example, it might go "full, incremental, level 8, incremental, level > 7, incremental, level 9, level 2, incremental, level 8, incremental, > etc." - the idea being to minimise the number of backups needed to > restore a system. >* Networker indexes are somewhat analogous to the TSM database. In > theory, you can scan each tape to rebuild the indexes if they're > lost; in practice, if you lose the indexes, you're pretty much dead - > there's just too much data to scan if the system is more than > moderately sized. Yes, Networker backs up the indexes each day. :) >* At least the versions of Networker (up to 7.x) we used doesn't > support the idea of staging to disk - everything goes directly to > tape. However, data streams from multiple clients are multiplexed > onto tape to get the write speeds up. This is good for backups, but > does make recovery slower (since the data read will include a lot of > data for other clients.) >* No more reclamation or copy pools to deal with (because of the > traditional full/incremental/dump level system). So the burden placed > on the tape drives is probably going to be significantly lower > (although you will be backing up more data each night than you would > with TSM.) >* I don't think Networker has anything analogous to TSM's scratch > pool: volumes belong to a pool of tapes, and there's no shuffling > between the pool. So if the "standard" pool has a hundred tapes > available for use, but the "database" pool is out of tapes and needs > one more, you need to manually intervene. This *may* have been > because of the way we configured Networker, though, and it may also > have changed in the interim. Note that you *have* to have a separate > pool of tapes for index backups. > > My honest assessment mirrors that of the other people who have > replied: use this as an opportunity to negotiate better pricing from > IBM, and point out to the powers that be that there are risks > involved with moving to a different backup product. There's nothing > wrong with Networker, it's a good system, but you aren't familiar > with it; it takes time with any new product to learn the tricks of > the trade. It's only in the past year or two that we've started to > feel more competent with TSM, as we've found and dealt with problems > in the production system which never showed up (and would never show > up) in the smaller scale proof of concept. > > You also should note that it took Monash a couple of years to finish > the migration from Networker to TSM; I would expect a migration in > the other direction would take at least a year. I definitely would > not advise a dramatic cut-over - do a small number of servers at a > time to make sure you're not pushing the server too hard (and > besides, you want to stagg
Re: TSM DB backup question
Sorry for the confusion here all. I have sent out a reponse to this post earlier this AM, but it is taking a while to post. Looks like you responded to it below. I am not sure why this is not included in the post. I will try posting it again. FYI, the file system is a large file enabled JFS2 and filesize is set to unlimited. I created a file larger than 64Gb with AIX on the filesystem with no problems. IBM says this is a TSM limitation not an AIX one and they have an APAR associated with it (see link below) --- Again im sorry, this was my mistake, I miss understood what my colleague had told me. Indeed AIX its self will work with file spaces larger than 64g BUT As per the APAR I linked you... http://www-1.ibm.com/support/docview.wss?uid=swg1IC50581 The 64g is a known limitation of TSM on AIX systems. As such TSM will only recognize up to 64g of space on a FILE type space. I have found further information confirming this in another PMR. As shown on the bottom of the APAR, this problem will be fixed in a future release. Does this answer your question? is there anything else I can help you with? Phil --- Nicholas Rodolfich TSM/AIX Administrator East Jefferson General Hospital Fidelity Information Systems 504-883-6955 (office) 228-223-6777 (mobile) [EMAIL PROTECTED] >>> [EMAIL PROTECTED] 7/27/2007 9:45 AM >>> On Jul 27, 2007, at 10:10 AM, Nicholas Rodolfich wrote: > Well it seems that this is a TSM limitationnot a file system > limitation > per IBM. We still don't have pertinent details on this problem. What is your AIX operating system bitmode, and your file system type? Those factors may impose architectural limits on the file size you may utilize. Richard Sims IMPORTANT NOTICE: This message and any included attachments are from East Jefferson General Hospital, and is intended only for the addressee(s), and may include Protected Health (PHI) or other confidential information. If you are the intended recipient, you are obligated to maintain it in a secure and confidential manner and re-disclosure without additional consent or as permitted by law is prohibited. If you are not the intended recipient, use of this information is strictly prohibited and may be unlawful. Please promptly reply to the sender by email and delete this message from your computer. East Jefferson General Hospital greatly appreciates your cooperation.
Re: TSM DB backup question
JFS2 solve lots of files size problems and give more performance. > -Message d'origine- > De : ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] De > la part de Ian-IT Smith > Envoyé : vendredi 27 juillet 2007 16:52 > À : ADSM-L@VM.MARIST.EDU > Objet : Re: [ADSM-L] TSM DB backup question > > An old gotcha on AIX was the ulimits file. Limiting the > filesize any user could create. Also if the filesystem was > large file enabled for files over > 2 GB. > > These are quite old issues though. > > Ian Smith > > > > > Richard Sims <[EMAIL PROTECTED]> > Sent by: "ADSM: Dist Stor Manager" > 27/07/2007 15:45 > Please respond to > "ADSM: Dist Stor Manager" > > > To > ADSM-L@VM.MARIST.EDU > cc > > Subject > Re: [ADSM-L] TSM DB backup question > > > > > > > On Jul 27, 2007, at 10:10 AM, Nicholas Rodolfich wrote: > > > Well it seems that this is a TSM limitationnot a file system > > limitation per IBM. > > We still don't have pertinent details on this problem. What > is your AIX operating system bitmode, and your file system > type? Those factors may impose architectural limits on the > file size you may utilize. > >Richard Sims > > > > --- > > This e-mail may contain confidential and/or privileged > information. If you are not the intended recipient (or have > received this e-mail in error) please notify the sender > immediately and delete this e-mail. Any unauthorized copying, > disclosure or distribution of the material in this e-mail is > strictly forbidden. > > Please refer to > http://www.db.com/en/content/eu_disclosures.htm for > additional EU corporate and regulatory disclosures. >
Re: TSM DB backup question
An old gotcha on AIX was the ulimits file. Limiting the filesize any user could create. Also if the filesystem was large file enabled for files over 2 GB. These are quite old issues though. Ian Smith Richard Sims <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" 27/07/2007 15:45 Please respond to "ADSM: Dist Stor Manager" To ADSM-L@VM.MARIST.EDU cc Subject Re: [ADSM-L] TSM DB backup question On Jul 27, 2007, at 10:10 AM, Nicholas Rodolfich wrote: > Well it seems that this is a TSM limitationnot a file system > limitation > per IBM. We still don't have pertinent details on this problem. What is your AIX operating system bitmode, and your file system type? Those factors may impose architectural limits on the file size you may utilize. Richard Sims --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. Please refer to http://www.db.com/en/content/eu_disclosures.htm for additional EU corporate and regulatory disclosures.
Re: TSM DB backup question
On Jul 27, 2007, at 10:10 AM, Nicholas Rodolfich wrote: Well it seems that this is a TSM limitationnot a file system limitation per IBM. We still don't have pertinent details on this problem. What is your AIX operating system bitmode, and your file system type? Those factors may impose architectural limits on the file size you may utilize. Richard Sims
Re: TSM DB backup question
To come back to the original problem... Is it a problem to have two files but one for your db backup ? > -Message d'origine- > De : ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] De > la part de Nicholas Rodolfich > Envoyé : vendredi 27 juillet 2007 16:10 > À : ADSM-L@VM.MARIST.EDU > Objet : Re: [ADSM-L] TSM DB backup question > > Well it seems that this is a TSM limitationnot a file system > limitation per IBM. > --- > >Again im sorry, this was my mistake, I miss understood what my > colleague had told me. Indeed AIX its self will work with > file spaces larger than 64g >BUT As per the APAR I linked you... > > http://www-1.ibm.com/support/docview.wss?uid=swg1IC50581 > > >The 64g is a known limitation of TSM on AIX systems. As such TSM will > only recognize up to 64g of space on a FILE type space. I > have found further >information confirming this in another > PMR. As shown on the bottom of the APAR, this problem will be > fixed in a future release. > > >Does this answer your question? is there anything else I can help you > with? > > >Phil > --- > > Nicholas Rodolfich > TSM/AIX Administrator > East Jefferson General Hospital > Fidelity Information Systems > 504-883-6955 (office) > 228-223-6777 (mobile) > [EMAIL PROTECTED] > > > >>> [EMAIL PROTECTED] 7/26/2007 3:42 PM >>> > On Jul 26, 2007, at 3:10 PM, Nicholas Rodolfich wrote: > > > File size is already set to unlimited. > > You need to provide more information than that. I'm not > aware of any file system which allows a file of infinite size. > > A file system characteristically limits file size according > to file system architecture and the current operating system > instance bitmode. For example, JFS in a 32-bit AIX kernel > limits file size to > 64 MB. And, naturally, a smaller partition size will impose > a lesser ceiling. > > You need to take a look at your OS/fs configuration there, as > the TSM manual says. > > Richard Sims > > > IMPORTANT NOTICE: This message and any included attachments > are from East Jefferson General Hospital, and is intended > only for the addressee(s), and may include Protected Health > (PHI) or other confidential information. If you are the > intended recipient, you are obligated to maintain it in a > secure and confidential manner and re-disclosure without > additional consent or as permitted by law is prohibited. If > you are not the intended recipient, use of this information > is strictly prohibited and may be unlawful. Please promptly > reply to the sender by email and delete this message from > your computer. East Jefferson General Hospital greatly > appreciates your cooperation. >
Re: TSM performance very poor, Recovery log is being pinned
You might also check your diskpool volume count. If its low, assuming your doing raw logical volumes, you might want to try decreasing the size of your volumes and thereby increasing the count of your volumes . A small number of large volumes does not allow several clients or processes to stream data to the storage pools efficiently. Joy Hanna Enterprise Storage Group I.T. Computer Operations (503)745-7748 [EMAIL PROTECTED] -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Craig Ross Sent: Friday, July 27, 2007 2:49 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM performance very poor, Recovery log is being pinned 10 days ago I Recently added 15TB of SATA storage and a new Fabric with 4 new LTO drives to our 3584 library, The DB is approx 90GB TSM Few days ago I noticed processing had ground to halt, after digging around I have found as soon as server gets busy maybe 4 processes 8 or so sessions the recovery log begins "sh logpinned" to pin and the Database gets locks. Shown by running "sh locks" And as result the server suffers! Now today I have stopped using the new Tech LTO 3 and SATA and things are coping better but still worse than previous as soon as load is increased Log pins and processing slows drastically. Are there any steps I can take which will help my scenario. Would a DB UNLOAD RELOAD help that much? Reference: Recovery log has heaps of room DB has heaps of room 90Gb DB with 100GB of room. Any advice is much appreciated.
Re: TSM DB backup question
Well it seems that this is a TSM limitationnot a file system limitation per IBM. --- >Again im sorry, this was my mistake, I miss understood what my colleague had told me. Indeed AIX its self will work with file spaces larger than 64g >BUT As per the APAR I linked you... http://www-1.ibm.com/support/docview.wss?uid=swg1IC50581 >The 64g is a known limitation of TSM on AIX systems. As such TSM will only recognize up to 64g of space on a FILE type space. I have found further >information confirming this in another PMR. As shown on the bottom of the APAR, this problem will be fixed in a future release. >Does this answer your question? is there anything else I can help you with? >Phil --- Nicholas Rodolfich TSM/AIX Administrator East Jefferson General Hospital Fidelity Information Systems 504-883-6955 (office) 228-223-6777 (mobile) [EMAIL PROTECTED] >>> [EMAIL PROTECTED] 7/26/2007 3:42 PM >>> On Jul 26, 2007, at 3:10 PM, Nicholas Rodolfich wrote: > File size is already set to unlimited. You need to provide more information than that. I'm not aware of any file system which allows a file of infinite size. A file system characteristically limits file size according to file system architecture and the current operating system instance bitmode. For example, JFS in a 32-bit AIX kernel limits file size to 64 MB. And, naturally, a smaller partition size will impose a lesser ceiling. You need to take a look at your OS/fs configuration there, as the TSM manual says. Richard Sims IMPORTANT NOTICE: This message and any included attachments are from East Jefferson General Hospital, and is intended only for the addressee(s), and may include Protected Health (PHI) or other confidential information. If you are the intended recipient, you are obligated to maintain it in a secure and confidential manner and re-disclosure without additional consent or as permitted by law is prohibited. If you are not the intended recipient, use of this information is strictly prohibited and may be unlawful. Please promptly reply to the sender by email and delete this message from your computer. East Jefferson General Hospital greatly appreciates your cooperation.
Re: upgrade of 200 GB DB
Yep, I'm actually waiting for a copy job to finish so that we can put that version on our problem server this morning. Fingers crossed... _ Kathleen Hallahan Freddie Mac Peter Jones <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" 07/27/2007 09:34 AM Please respond to "ADSM: Dist Stor Manager" To ADSM-L@VM.MARIST.EDU cc Subject Re: upgrade of 200 GB DB Hi, > I had a client that I upgraded to 5.4 and consistently one of the TDP > for SQL instances refuses to terminate ... > Kathleen M Hallahan wrote: > > We are seeing > > behavior that suggests that it's not always releasing network > > communications properly, but not all the time and not for all > > communications. Search for PK43462 as fixed in 5.4.1.0 at: http://www.ibm.com/software/support/ The problems you are both experiencing sound very similar. Hope this helps, Pete -- Peter Jones Oxford University Computing Services TSM Symposium 2007 Tivoli Storage Manager : Preparing the Path 25-27 September 2007http://tsm-symposium.oucs.ox.ac.uk/
Re: upgrade of 200 GB DB
Hi, > I had a client that I upgraded to 5.4 and consistently one of the TDP > for SQL instances refuses to terminate ... > Kathleen M Hallahan wrote: > > We are seeing > > behavior that suggests that it's not always releasing network > > communications properly, but not all the time and not for all > > communications. Search for PK43462 as fixed in 5.4.1.0 at: http://www.ibm.com/software/support/ The problems you are both experiencing sound very similar. Hope this helps, Pete -- Peter Jones Oxford University Computing Services TSM Symposium 2007 Tivoli Storage Manager : Preparing the Path 25-27 September 2007http://tsm-symposium.oucs.ox.ac.uk/
Re: 6 vs 8 character LTO2 volser - do I care ?
The AIX servers are the ones I am moving away from and don't have the updated atape/atldd drivers. I have stopped them from creating new LTO2 volumes and am just going to purge the existing ones and rebuild them (offsite copies only). At this point, I am simply letting the new LM reinitialize the scratch LTO2 tapes as 8-characters, when it first uses them. David Longo <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" 07/26/2007 05:59 PM Please respond to "ADSM: Dist Stor Manager" To ADSM-L@VM.MARIST.EDU cc Subject Re: [ADSM-L] 6 vs 8 character LTO2 volser - do I care ? With TSM server on an AIX platform with LTO, there is an option at AIX level in smit - devices that allows you to specify 6 char for LTO1/LTO2 tapes, and the LTO3 will still report as 8 char. Not sure if this can be done somehow on other platforms. David Longo >>> Zoltan Forray/AC/VCU <[EMAIL PROTECTED]> 7/26/2007 4:30 PM >>> Thats kinda what I gleened from other sources. Thanks for the confirmation. These 3583 libraries are so problematic, we only use them for offsite copies. All of the real, primary pools are 3592-E05 drives. "Stapleton, Mark" <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" 07/26/2007 04:19 PM Please respond to "ADSM: Dist Stor Manager" To ADSM-L@VM.MARIST.EDU cc Subject Re: [ADSM-L] 6 vs 8 character LTO2 volser - do I care ? From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Zoltan Forray/AC/VCU > In reference to my previous posting, I am moving my 3583 LTO libraries > from AIX ownership to Linux ownership (as well as the newest 5.4.1 server > level). > > I just checked in some scratch tapes to the Linux system and the tapes > came up as 8-characters (09L2 vs 09). > > Do I care ? Is this going to cause any conflicts or other problems ? Is > this going to require relabeling ? Can I set it back to 6-characters ? I > read that LTO3 requires 8-chars but these are LTO2 only. No plans to buy > any more drives and we certainly wouldn't mix them if we did ! As long as you're not putting previously labeled tapes into the new library, you should be good to go. If you're putting in previously labeled tapes with no data on them (scratch tapes), you'll need to force a relabel. If the tapes have data on them, you're in for a hell of a time; you cannot force a relabel without rendering the data unreachable. -- Mark Stapleton Berbee (a CDW company) System engineer 7145 Boone Avenue North, Suite 140 Brooklyn Park MN 55428-1511 763-592-5963 www.berbee.com
Re: TSM DB backup question
make sure your file is set to large file enabled. >>> [EMAIL PROTECTED] 07/27/2007 10:05:08 AM >>> Nicholas, Are you refering to the Operating System filesystem configuration or the TSM setting? Cheers, Neil -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Nicholas Rodolfich Sent: Thursday, July 26, 2007 3:10 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM DB backup question File size is already set to unlimited. Nicholas Rodolfich TSM/AIX Administrator East Jefferson General Hospital Fidelity Information Systems 504-883-6955 (office) 228-223-6777 (mobile) [EMAIL PROTECTED] >>> [EMAIL PROTECTED] 7/26/2007 12:08 PM >>> Help on UPDATE DEVCLASS -- FILE says about MAXCAPacity: "The value specified should be less than or equal to the maximum supported size of a file on the target file system." Check whether this condition is met... Regards, Rama -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Nicholas Rodolfich Sent: Thursday, July 26, 2007 11:56 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM DB backup question Hi All, Thanks for your help!! In my daily maintenance schedule I am doing a database backup to disk with the following call and using the following device class. When the backup runs it writes a second file apparently after it completes the DB backup. I wouldn't be concerned except the extra file shows up in my volume history as seen below (which I did not expect). Notice the entry for the second file has the same Backup Series as the first file. It looks like TSM is writing a second volume since the Volume Sequence is 2, but I dont know why! NOW I SEE IT! The Est/Max Capacity (MB): 61,440.0 is getting me. I created this device class and I don't remember putting a size on it but I guess I did. Anyway, when I try to change it to 8Mb TSM tells me: --- ANR2017I Administrator ADMIN issued command: UPDATE DEVCLASS DBBTOFILE MOUNTL=20 DIRECTORY=/tsmdbb MAXCAPACITY=8M SHARED=NO ANR8366E UPDATE DEVCLASS: Invalid value for MAXCAPACITY parameter. --- I tried to schnge the mount limit to 1 instead of 20 and got the same thing --- ANR2017I Administrator ADMIN issued command: UPDATE DEVCLASS DBBTOFILE MOUNTL=1 DIRECTORY=/tsmdbb MAXCAPACITY=8M SHARED=NO ANR8366E UPDATE DEVCLASS: Invalid value for MAXCAPACITY parameter. --- Anyone know why. I tried it from command line and the ISC ang get the same message in the ACTLOG. === ba db dev=dbbtofile t=f w=y - Device Class Name: DBBTOFILE Device Access Strategy: Sequential Storage Pool Count: 0 Device Type: FILE Format: DRIVE Est/Max Capacity (MB): 61,440.0 Mount Limit: 20 Mount Wait (min): Mount Retention (min): Label Prefix: Library: Directory: /tsmdbb Server Name: Retry Period: Retry Interval: Shared: High-level Address: Minimum Capacity: WORM: No Scaled Capacity: Last Update by (administrator): NICHOLAS Last Update Date/Time: 06/06/07 13:11:01 # ls -al -rw--- 1 root system 64424509440 Jul 25 11:17 85377768.dbb -rw--- 1 root system 2755842268 Jul 25 11:19 85380236.dbb --- tsm> q volh t=dbb Date/Time: 07/25/07 10:36:07 Volume Type: BACKUPFULL Backup Series: 1,780 Backup Operation: 0 Volume Seq: 1 Device Class: DBBTOFILE Volume Name: /tsmdbb/85377768.DBB Volume Location: Command: Date/Time: 07/25/07 10:36:07 Volume Type: BACKUPFULL Backup Series: 1,780 Backup Operation: 0 Volume Seq: 2 Device Class: DBBTOFILE Volume Name: /tsmdbb/85380236.DBB Volume Location: Command: Nicholas Rodolfich TSM/AIX Administrator East Jefferson General Hospital Fidelity Information Systems 504-883-6955 (office) 228-223-6777 (mobile) [EMAIL PROTECTED] IMPORTANT NOTICE: This message and any included attachments are from East Jefferson General Hospital, and is intended only for the addressee(s), and may include Protected Health (PHI) or other confidential information. If you are the intended recipient, you are obligated to maintain it in a secure and confidential manner and re-disclosure without additional consent or as permitted by law is prohibited. If you are not the intended recipient, use of this information is strictly prohibited and may be unlawful. Please pro
Re: 6 vs 8 character LTO2 volser - do I care ?
Thanks for the tip. Since I really needed to get moving on this, I am simply letting the new Library Manager server reinitialize the tapes as 8-chars as needed. This way I will recreate the offsite pool, fresh, and avoid the long list of reclaims that are constantly waiting due to lack of drives/time. Since these are only offsite copypool tapes, they aren't very critical (at least not for me). CAYE PIERRE <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" 07/27/2007 07:55 AM Please respond to "ADSM: Dist Stor Manager" To ADSM-L@VM.MARIST.EDU cc Subject Re: [ADSM-L] 6 vs 8 character LTO2 volser - do I care ? You can adjust the volser reporting on the Library, which is the safer way to control volser reporting. On the main menu => more => Setup => Library => MEDIA The you choose the volser reporting 8 char or 6 char. After that, you will never bother with volser mode, and you don't have to manage it through special files of your OS Then you will have to re label all that tapes originally labeled with 8 char labels. I hope some are not already used... Pierre Cayé > -Message d'origine- > De : ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] De > la part de David Longo > Envoyé : jeudi 26 juillet 2007 23:01 > À : ADSM-L@VM.MARIST.EDU > Objet : Re: [ADSM-L] 6 vs 8 character LTO2 volser - do I care ? > > With TSM server on an AIX platform with LTO, there is an > option at AIX level in smit - devices that allows you to > specify 6 char for > LTO1/LTO2 tapes, and the LTO3 will still report as 8 char. > > Not sure if this can be done somehow on other platforms. > > David Longo > > >>> Zoltan Forray/AC/VCU <[EMAIL PROTECTED]> 7/26/2007 4:30 PM >>> > Thats kinda what I gleened from other sources. Thanks for the > confirmation. > > These 3583 libraries are so problematic, we only use them for > offsite copies. All of the real, primary pools are 3592-E05 drives. > > > > > "Stapleton, Mark" <[EMAIL PROTECTED]> Sent by: "ADSM: > Dist Stor Manager" > 07/26/2007 04:19 PM > Please respond to > "ADSM: Dist Stor Manager" > > > To > ADSM-L@VM.MARIST.EDU > cc > > Subject > Re: [ADSM-L] 6 vs 8 character LTO2 volser - do I care ? > > > > > > > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] > On Behalf Of Zoltan Forray/AC/VCU > > In reference to my previous posting, I am moving my 3583 > LTO libraries > > from AIX ownership to Linux ownership (as well as the newest 5.4.1 > server > > level). > > > > I just checked in some scratch tapes to the Linux system > and the tapes > > came up as 8-characters (09L2 vs 09). > > > > Do I care ? Is this going to cause any conflicts or other > problems ? > Is > > this going to require relabeling ? Can I set it back to > 6-characters ? > I > > read that LTO3 requires 8-chars but these are LTO2 only. No plans to > buy > > any more drives and we certainly wouldn't mix them if we did ! > > As long as you're not putting previously labeled tapes into > the new library, you should be good to go. If you're putting > in previously labeled tapes with no data on them (scratch > tapes), you'll need to force a relabel. If the tapes have > data on them, you're in for a hell of a time; you cannot > force a relabel without rendering the data unreachable. > > -- > Mark Stapleton > Berbee (a CDW company) > System engineer > 7145 Boone Avenue North, Suite 140 > Brooklyn Park MN 55428-1511 > 763-592-5963 > www.berbee.com >
Re: Sharing a 3583 library
No, that is not what I meant. I realize I will eventually need to reconfigure all of the TSM servers. I just wanted to reconfigure in an optimal way or was hoping to not have to drag drives from one library manager to another and possibly back and forth, if needed. As I mentioned, I was hoping for some "smart" sharing of devices since TSM does manage the drive usage. As for the 6/8 volsers, I am just letting the new LM server reinitialize the tapes as 8-chars. Stuart Lamble <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor Manager" 07/26/2007 08:13 PM Please respond to "ADSM: Dist Stor Manager" To ADSM-L@VM.MARIST.EDU cc Subject Re: [ADSM-L] Sharing a 3583 library On 27/07/2007, at 1:43 AM, Zoltan Forray/AC/VCU wrote: > Thanks for the reply. I already have things configured like this. > > What I was hoping for was zOS/MVS sysplex sharing smarts (for you > mainframe folks). With a properly configured sysplex, the drives are > configured and online to all systems at the same time and the OS > figures > out which drive is in use by which system and which drives are > available > and choses acordingly, not stepping on any other system. I was > hoping the > SAN type libraries were smarter and that multiple TSM library > managers > could just figure out what drives are available and use them > accordingly. > > I wanted to avoid an all-or-nothing reconfiguration since I need to > move > library management/ownership to my new TSM server (phasing out the > old AIX > server currently owning the 3583's) and having to reconfigure all TSM > servers that currently share the libraries. So if I understand you correctly, you will eventually be moving the library management completely to the new server, but you want to avoid reconfiguring all the existing TSM instances? I've just completed moving two library managers from one TSM instance to another (the "new" manager is dedicated solely to library and configuration management, where the "old" managers also served backup duties.) It turned out to be remarkably easy: * Delete the old paths, drive definitions and library definition on the old library manager (and the new library manager if it's currently a library client). * Define the library, drives, and paths on the new library manager (setting the drives to offline, so no tapes are accessed until you're finished.) * Checkin the libvols on the new library manager (CHECKIN LIBVOL X search=yes stat=scratch checkl=barcode) * Update the old library clients (UPDATE LIBRARY X PRIM=new_lib_manager on all instances) * Create a library definition on the old library managed (of type shared, pointing at the new library manager.) * Run an AUDIT LIBRARY on the library clients (including the old library manager). * Set the drives to online, and you're away. The audit on each client will set tapes with data to private status, owned by the relevant client. If you're paranoid about this, check them in as private, owned by the new library manager, and make a note of the scratch volumes known by the old library manager before deleting the library definition (query libvol). The audit will update the ownership to the correct node, you can manually update the remaining volumes to be scratch, and chase up the remaining volumes owned by the new library manager (assuming it didn't own any volumes beforehand) as potentially orphaned - we found some 30 tapes that should have been returned to scratch by the clients, but the library manager hadn't updated them for some reason so they were still marked as being private. As for the 6/8 character volume label: I can't speak for a 3583, but we're using a pair of 3584 libraries. In the web-based management system, there's a section for "Library", "Logical Libraries"; have a look at the "modify volser reporting" option - it might help. Note that this will likely affect *all* volumes, so if you have data stored on volumes with a mix of 8/6 volume serial numbers, you're in trouble ... Hope this helps.
Re: TSM DB backup question
Nicholas, Are you refering to the Operating System filesystem configuration or the TSM setting? Cheers, Neil -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Nicholas Rodolfich Sent: Thursday, July 26, 2007 3:10 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] TSM DB backup question File size is already set to unlimited. Nicholas Rodolfich TSM/AIX Administrator East Jefferson General Hospital Fidelity Information Systems 504-883-6955 (office) 228-223-6777 (mobile) [EMAIL PROTECTED] >>> [EMAIL PROTECTED] 7/26/2007 12:08 PM >>> Help on UPDATE DEVCLASS -- FILE says about MAXCAPacity: "The value specified should be less than or equal to the maximum supported size of a file on the target file system." Check whether this condition is met... Regards, Rama -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Nicholas Rodolfich Sent: Thursday, July 26, 2007 11:56 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] TSM DB backup question Hi All, Thanks for your help!! In my daily maintenance schedule I am doing a database backup to disk with the following call and using the following device class. When the backup runs it writes a second file apparently after it completes the DB backup. I wouldn't be concerned except the extra file shows up in my volume history as seen below (which I did not expect). Notice the entry for the second file has the same Backup Series as the first file. It looks like TSM is writing a second volume since the Volume Sequence is 2, but I dont know why! NOW I SEE IT! The Est/Max Capacity (MB): 61,440.0 is getting me. I created this device class and I don't remember putting a size on it but I guess I did. Anyway, when I try to change it to 8Mb TSM tells me: --- ANR2017I Administrator ADMIN issued command: UPDATE DEVCLASS DBBTOFILE MOUNTL=20 DIRECTORY=/tsmdbb MAXCAPACITY=8M SHARED=NO ANR8366E UPDATE DEVCLASS: Invalid value for MAXCAPACITY parameter. --- I tried to schnge the mount limit to 1 instead of 20 and got the same thing --- ANR2017I Administrator ADMIN issued command: UPDATE DEVCLASS DBBTOFILE MOUNTL=1 DIRECTORY=/tsmdbb MAXCAPACITY=8M SHARED=NO ANR8366E UPDATE DEVCLASS: Invalid value for MAXCAPACITY parameter. --- Anyone know why. I tried it from command line and the ISC ang get the same message in the ACTLOG. === ba db dev=dbbtofile t=f w=y - Device Class Name: DBBTOFILE Device Access Strategy: Sequential Storage Pool Count: 0 Device Type: FILE Format: DRIVE Est/Max Capacity (MB): 61,440.0 Mount Limit: 20 Mount Wait (min): Mount Retention (min): Label Prefix: Library: Directory: /tsmdbb Server Name: Retry Period: Retry Interval: Shared: High-level Address: Minimum Capacity: WORM: No Scaled Capacity: Last Update by (administrator): NICHOLAS Last Update Date/Time: 06/06/07 13:11:01 # ls -al -rw--- 1 root system 64424509440 Jul 25 11:17 85377768.dbb -rw--- 1 root system 2755842268 Jul 25 11:19 85380236.dbb --- tsm> q volh t=dbb Date/Time: 07/25/07 10:36:07 Volume Type: BACKUPFULL Backup Series: 1,780 Backup Operation: 0 Volume Seq: 1 Device Class: DBBTOFILE Volume Name: /tsmdbb/85377768.DBB Volume Location: Command: Date/Time: 07/25/07 10:36:07 Volume Type: BACKUPFULL Backup Series: 1,780 Backup Operation: 0 Volume Seq: 2 Device Class: DBBTOFILE Volume Name: /tsmdbb/85380236.DBB Volume Location: Command: Nicholas Rodolfich TSM/AIX Administrator East Jefferson General Hospital Fidelity Information Systems 504-883-6955 (office) 228-223-6777 (mobile) [EMAIL PROTECTED] IMPORTANT NOTICE: This message and any included attachments are from East Jefferson General Hospital, and is intended only for the addressee(s), and may include Protected Health (PHI) or other confidential information. If you are the intended recipient, you are obligated to maintain it in a secure and confidential manner and re-disclosure without additional consent or as permitted by law is prohibited. If you are not the intended recipient, use of this information is strictly prohibited and may be unlawful. Please promptly reply to the sender by email and delete this message from your computer. East Jefferson Gener
Re: 6 vs 8 character LTO2 volser - do I care ?
You can adjust the volser reporting on the Library, which is the safer way to control volser reporting. On the main menu => more => Setup => Library => MEDIA The you choose the volser reporting 8 char or 6 char. After that, you will never bother with volser mode, and you don't have to manage it through special files of your OS Then you will have to re label all that tapes originally labeled with 8 char labels. I hope some are not already used... Pierre Cayé > -Message d'origine- > De : ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] De > la part de David Longo > Envoyé : jeudi 26 juillet 2007 23:01 > À : ADSM-L@VM.MARIST.EDU > Objet : Re: [ADSM-L] 6 vs 8 character LTO2 volser - do I care ? > > With TSM server on an AIX platform with LTO, there is an > option at AIX level in smit - devices that allows you to > specify 6 char for > LTO1/LTO2 tapes, and the LTO3 will still report as 8 char. > > Not sure if this can be done somehow on other platforms. > > David Longo > > >>> Zoltan Forray/AC/VCU <[EMAIL PROTECTED]> 7/26/2007 4:30 PM >>> > Thats kinda what I gleened from other sources. Thanks for the > confirmation. > > These 3583 libraries are so problematic, we only use them for > offsite copies. All of the real, primary pools are 3592-E05 drives. > > > > > "Stapleton, Mark" <[EMAIL PROTECTED]> Sent by: "ADSM: > Dist Stor Manager" > 07/26/2007 04:19 PM > Please respond to > "ADSM: Dist Stor Manager" > > > To > ADSM-L@VM.MARIST.EDU > cc > > Subject > Re: [ADSM-L] 6 vs 8 character LTO2 volser - do I care ? > > > > > > > From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] > On Behalf Of Zoltan Forray/AC/VCU > > In reference to my previous posting, I am moving my 3583 > LTO libraries > > from AIX ownership to Linux ownership (as well as the newest 5.4.1 > server > > level). > > > > I just checked in some scratch tapes to the Linux system > and the tapes > > came up as 8-characters (09L2 vs 09). > > > > Do I care ? Is this going to cause any conflicts or other > problems ? > Is > > this going to require relabeling ? Can I set it back to > 6-characters ? > I > > read that LTO3 requires 8-chars but these are LTO2 only. No plans to > buy > > any more drives and we certainly wouldn't mix them if we did ! > > As long as you're not putting previously labeled tapes into > the new library, you should be good to go. If you're putting > in previously labeled tapes with no data on them (scratch > tapes), you'll need to force a relabel. If the tapes have > data on them, you're in for a hell of a time; you cannot > force a relabel without rendering the data unreachable. > > -- > Mark Stapleton > Berbee (a CDW company) > System engineer > 7145 Boone Avenue North, Suite 140 > Brooklyn Park MN 55428-1511 > 763-592-5963 > www.berbee.com >
TDP for Exchange - poor performance during online backup
I'm running Exchange Version 6.5.7638.1 under W2k3 Sever with TDP for Exchange 5.3.3. Running an online backup it starts with a data rate of aprx. 10 MB/sec. After some minutes this rate slows down to aprx. 1 MB/sec. The effect of this is, that a backup of aprx. 90 GB of data will last aprx. 30 hours. Does any body have an idea what's the reason for that strange behavior. Thanks Ron
Re: TSM performance very poor, Recovery log is being pinned
Craig - You need to perform analysis to identify problem cause, where the TSM Problem Determination Guide and Performance Tuning Guide will help. Log pinning is due to prolonged transactions, and is aggravated by sluggish networking and sluggish TSM servicing of transactions (often due to underlying disk/tape issues). You can quickly see if your TSM server is "behind" in its rate of servicing incoming client data by inspecting the TCP receive queue packets backlog. In AIX that can be done via the command: netstat | head -2 ; netstat | grep -vi dns | grep tcp If the various entries show a large receive queue value, then it is likely that your networking is good, but that TSM is not keeping up with the incoming, as may be caused by the underlying disk, tape, and I/O path technology that it is using. If your clients have recently started backing up very large files (digital movies is a stereotypical case), then that would certainly contribute to what you're seeing. A quick look at TSM accounting data or ANE Activity Log messages would give a sense of that, and Query CONTent with a negative Count value on the collocated tape volumes that the clients are doing will show biggies. Query SESSion during client activity will also help identify consumptive sessions. Before you gave TSM the new LTO 3 and SATA hardware, I would hope that you benchmarked it first, to assure that it was providing the performance you would need in production, and thus uncover any issues with it beforehand. A bad RAID choice in disk implementation will also slow throughput. Old microcode may have performance-impairing defects. A mismatched device driver can cause operational delays. Don't waste your time or jeopardize your server in doing a TSM db unload/reload. You may want to confer with your operating system people to have them help narrow down the problem area, where they are familiar with all the specifics of your environment. Richard Sims
TSM performance very poor, Recovery log is being pinned
10 days ago I Recently added 15TB of SATA storage and a new Fabric with 4 new LTO drives to our 3584 library, The DB is approx 90GB TSM Few days ago I noticed processing had ground to halt, after digging around I have found as soon as server gets busy maybe 4 processes 8 or so sessions the recovery log begins "sh logpinned" to pin and the Database gets locks. Shown by running "sh locks" And as result the server suffers! Now today I have stopped using the new Tech LTO 3 and SATA and things are coping better but still worse than previous as soon as load is increased Log pins and processing slows drastically. Are there any steps I can take which will help my scenario. Would a DB UNLOAD RELOAD help that much? Reference: Recovery log has heaps of room DB has heaps of room 90Gb DB with 100GB of room. Any advice is much appreciated.
