syscat.tables & syscat.columns for TSM 6.1
Anybody know where to get a copy of this info for TSM 6.1? Or is there a way we can use db2cmd to get the schema directly from DB2? I've been holding off on tackling this because it was supposed to be fixed in 6.1.2 ( APAR IC60909), but I'm at 6.1.3.1 now, and what you get with select * from syscat.tables/syscat.columns is still wrong. Wanda Prather | Systems Integration Specialist | wprat...@icfi.com | www.jasi.com ICF Jacob & Sundstrom | 401 E. Pratt St, Suite 2214, Baltimore, MD 21202 | 410.539.1135
Re: VCB backup performance
Hi Steve, Been there, done that with VMWare backups. You can parallelize what you are doing now by installing multiple schedulers on your proxy machine. Give it 2 (or more) node names (e.g., PROXYVCB1, PROXYVCB2), install 2 schedulers, 2 dsm.opt files, give them each half the work to do. (Also no reason you can't add more proxy machines.) That will only help the Proxy client drive multiple full backups at once, it won't improve the speed of the VCB fulls, which definitely have performance issues. VMWARE is addressing the VCB performance issue by replacing VCB altogether, so you should be looking ahead to ESX 4.0 or 4.1 for a long-term solution. In VSPHERE (ESX 4.0), VMWare has created a "Storage API" for their own backup utility called VDR, and for 3rd party vendors to write to (VCB is still supported in 4.0 as well). I have a customer using VDR+TSM with success so far. Like most VM backup products, VDR backs up only to disk. But it's part of ESX 4.0 Enterprise, it's supported by VMWare, gives you incremental and fulls, and DEDUPS, so the disk repository doesn't get all that large. It also thoughtfully keeps the sizes of the resulting files in the repository below 2GB, at least as far as we've seen, so we use TSM subfile backup to back up the repository and get stuff out to tape and vaulted. The VMWare world changes VERY fast. I went to a VMWare UG last week, and the VMWare rep said 4.1 will be out this year, and will NOT support VCB at all any longer. Thus my encouragement to move ahead to something that works a different way. TSM 6.2 will be out in March, and will support the VMWare API. I don't have any doc yet explaining exactly what it will do in practical terms, but it won't be VCB. ..and congrats on the new gig.! Wanda -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Steve Harris Sent: Wednesday, March 17, 2010 6:18 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] VCB backup performance Hi All Thanks to all those that responded to my "time travel" query, testing is in progress on that one. One of my customers has an issue with a burgeoning VCB infrastructure. There are two VCB proxies and a lot of VMs being backed up, TSM Server 5.5.3 and client 6.1.2. Most of this is a daily incremental and a monthly full, but there are a couple of big file-servers with lots of small files that get a daily full. VCB backups are single threaded, and we are having trouble getting through them all within the window. TSM doesn't seem to be the problem, we have increased resourceutilization on the proxy without much effect. The bottleneck seems to be the VMWare snapshot/mount/dismount parts of the process, and there is not a lot of visibility of those. 1. Is there any good doc on this process and how to improve its performance? 2. Can the proxy side be effectively parallelized, and if so how? Thanks Steve TSM Admin, Paraparaumu, New Zealand
DB2 Monthlies
Hi Again. I have some DB2 databases that I would like to have different backups treated differently. For example, the normal weekly gets put to one management class, but the first one of the month goes to a management class that goes to tape. In the MSSQL case, this is done by running a COPY backup using a different node name. In the Orace case, we can't use a different node name, but RMAN can tweak the file name that is used, and then an include can be employed to achieve the result. What do we do for DB2? I see the backup command has a "USE TSM OPTIONS @filename" clause, but am not sure how I can use this. Will changing the management class for the DB before the backup with the db configure command and then changing it back afterward work? Thanks Steve.
VCB backup performance
Hi All Thanks to all those that responded to my "time travel" query, testing is in progress on that one. One of my customers has an issue with a burgeoning VCB infrastructure. There are two VCB proxies and a lot of VMs being backed up, TSM Server 5.5.3 and client 6.1.2. Most of this is a daily incremental and a monthly full, but there are a couple of big file-servers with lots of small files that get a daily full. VCB backups are single threaded, and we are having trouble getting through them all within the window. TSM doesn't seem to be the problem, we have increased resourceutilization on the proxy without much effect. The bottleneck seems to be the VMWare snapshot/mount/dismount parts of the process, and there is not a lot of visibility of those. 1. Is there any good doc on this process and how to improve its performance? 2. Can the proxy side be effectively parallelized, and if so how? Thanks Steve TSM Admin, Paraparaumu, New Zealand
Re: Ejecting cleaning cartridges from the TS3500/3584
If the 3584 library is doing the cleanings, the backup software never sees the cleaning cart(s). But one might be able to do this an snmp get command. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Richard Sims Sent: Wednesday, March 17, 2010 2:45 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Ejecting cleaning cartridges from the TS3500/3584 On Mar 17, 2010, at 2:24 PM, Clay Willoughby wrote: > But there is a handy message displayed on the front console telling who ever > walks by to eject a used up cleaning tape,,, that's very handy I don't have a SCSI library, but I should think it would be relatively easy to set up a simple monitor based upon dsmadmc -consolmode to watch for message ANR8915I, and over time to issue Query LIBVolumes Format=Detailed to look for "Cleanings Left" (or Select from LIBVOLUMES, to act on the CLEANINGS_LEFT field) to perform a Checkout when the time was right, accompanied by some message to the operator. Richard Sims
Re: Ejecting cleaning cartridges from the TS3500/3584
Greetings, We have multiple IBM3584s, and have tried both TSM managed tape cleaning, and automatic tape cleaning via ALMS, with 3592 tape drives. With TSM managed tape cleaning, we were having a lot of problems with TSM getting tape errors and failed tape drives. We also found that TSM did not perform a cleaning every time the tape drive asked for one. In other words, TSM did not consistently respond to every cleaning request, which probably accounted for our failed tape drive situation. We turned on ALMS and automatic tape cleaning. Our cleanings went up quite a bit at first, then settled down. The tape drive failures tapered off. I can hardly believe a field service guy from IBM telling Jim he should only clean tape drives "when absolutely necessary". How would Jim decide when it was "absolutely necessary"? When he was trying to recover a production database at 4 am and every tape he mounted was unreadable and he couldn't recover the data? The tape drive firmware automatically detects when it needs to be cleaned. What sense does it make to ignore that functionality and think you can guess for yourself what the drive really needs? The cleaning tapes cost $50. But the data on the tapes might have cost millions to produce. Why take such a risk? Best Regards, John D. Schneider The Computer Coaching Community, LLC Office: (314) 635-5424 / Toll Free: (866) 796-9226 Cell: (314) 750-8721 Original Message Subject: Re: [ADSM-L] Ejecting cleaning cartridges from the TS3500/3584 From: "Prather, Wanda" Date: Wed, March 17, 2010 2:23 pm To: ADSM-L@VM.MARIST.EDU These are TS1130 drives/3592 cartridges, which certainly appear to be cleaning more often than LTO3/4's do. We have the library set to autoclean, which means it inserts the cleaning cart only when the drives request a cleaning. This lib has 4 drives, averaging about 1.5-2 TB migration, + 1.5-2 2 TB backup stgpool, + reclaims daily, ~2000 mounts a day. Using about 1 cleaning cart (50 cleans) a month. Don't know if that's a lot or a little, in terms of cleaning, for TS1130's. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Jim Zajkowski Sent: Wednesday, March 17, 2010 2:57 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Ejecting cleaning cartridges from the TS3500/3584 On 3/17/10 1:18 PM, "Prather, Wanda" wrote: > Is there a way to make the TS3500/3584 do that? ALMS is enabled, > multiple partitions, 3592 carts. I certainly don't have a robot that big, but in seven years we've only cleaned the drives a handful of times. Am I doing something wrong? Our field service guy suggested that we only clean them when absolutely necessary because repeated cleaning can cause the head to fail. --Jim
Re: Tdp for sqlserver question
Thanks to Dell, got the answer. I'll forward to my dbas. Gary Lee Senior System Programmer Ball State University phone: 765-285-1310 -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Del Hoobler Sent: Wednesday, March 17, 2010 3:28 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Tdp for sqlserver question Gary, It is a screen rendering issue. If you look at it rendered correctly, it does say SQL Server 2000. The "4" is a foot note... ... which reads like this: --- 4. SQL Server 2000 must be at Service Pack 4 (or later). In addition, the following software is also required when using SQL Server 2000 with Data Protection for SQL 5.5.0: * Microsoft .NET Framework version 2.0 (or later) * Microsoft Core XML Services (MSXML) 6.0 (or later) * Microsoft SQL Server Native Client * Microsoft SQL Server 2005 Management Objects Collection --- Thanks, Del "ADSM: Dist Stor Manager" wrote on 03/17/2010 03:17:25 PM: > [image removed] > > Tdp for sqlserver question > > Lee, Gary D. > > to: > > ADSM-L > > 03/17/2010 03:18 PM > > Sent by: > > "ADSM: Dist Stor Manager" > > Please respond to "ADSM: Dist Stor Manager" > > Trying to determine which versions of sqlserver are supported by the > 5.5.x version of tdp for sqlserver client. > > Looking in both the html and pdf version of the manual on page 25 > under the table: > > Table 3. Minimum software and operating system requirements for > Legacy Backup and Restore operations > > I see sqlserver 20004 and 2005. > > This may be a "feature" in screen reader rendering, could someone translate? > Specifically, is sqlserver 2000 supported? > > Thanks for the help. > > > > Gary Lee > Senior System Programmer > Ball State University > phone: 765-285-1310 > >
Re: Tdp for sqlserver question
Gary, It is a screen rendering issue. If you look at it rendered correctly, it does say SQL Server 2000. The "4" is a foot note... ... which reads like this: --- 4. SQL Server 2000 must be at Service Pack 4 (or later). In addition, the following software is also required when using SQL Server 2000 with Data Protection for SQL 5.5.0: * Microsoft .NET Framework version 2.0 (or later) * Microsoft Core XML Services (MSXML) 6.0 (or later) * Microsoft SQL Server Native Client * Microsoft SQL Server 2005 Management Objects Collection --- Thanks, Del "ADSM: Dist Stor Manager" wrote on 03/17/2010 03:17:25 PM: > [image removed] > > Tdp for sqlserver question > > Lee, Gary D. > > to: > > ADSM-L > > 03/17/2010 03:18 PM > > Sent by: > > "ADSM: Dist Stor Manager" > > Please respond to "ADSM: Dist Stor Manager" > > Trying to determine which versions of sqlserver are supported by the > 5.5.x version of tdp for sqlserver client. > > Looking in both the html and pdf version of the manual on page 25 > under the table: > > Table 3. Minimum software and operating system requirements for > Legacy Backup and Restore operations > > I see sqlserver 20004 and 2005. > > This may be a "feature" in screen reader rendering, could someone translate? > Specifically, is sqlserver 2000 supported? > > Thanks for the help. > > > > Gary Lee > Senior System Programmer > Ball State University > phone: 765-285-1310 > >
Re: Ejecting cleaning cartridges from the TS3500/3584
These are TS1130 drives/3592 cartridges, which certainly appear to be cleaning more often than LTO3/4's do. We have the library set to autoclean, which means it inserts the cleaning cart only when the drives request a cleaning. This lib has 4 drives, averaging about 1.5-2 TB migration, + 1.5-2 2 TB backup stgpool, + reclaims daily, ~2000 mounts a day. Using about 1 cleaning cart (50 cleans) a month. Don't know if that's a lot or a little, in terms of cleaning, for TS1130's. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Jim Zajkowski Sent: Wednesday, March 17, 2010 2:57 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Ejecting cleaning cartridges from the TS3500/3584 On 3/17/10 1:18 PM, "Prather, Wanda" wrote: > Is there a way to make the TS3500/3584 do that? ALMS is enabled, > multiple partitions, 3592 carts. I certainly don't have a robot that big, but in seven years we've only cleaned the drives a handful of times. Am I doing something wrong? Our field service guy suggested that we only clean them when absolutely necessary because repeated cleaning can cause the head to fail. --Jim
Re: Ejecting cleaning cartridges from the TS3500/3584
We have alms configured, so we let the library do the cleaning. If we have a semi-bad tape drive we can end up going thru a cleaning cart. We have configured the ts3500 to send snmp traps to a server which handles the traps. One of them indicates that a cleaning cart has expired. The trap handler forwards this message to the operations folks who replace the cart. In you cannot set up the trap handler there is a work around. if you have someone moving tapes in and out of your library, the library posts a message on the front panel that a cleaning tape has expired and needs replacing. It spells out which cleaning tape. len -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Remco Post Sent: Wednesday, March 17, 2010 2:51 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Ejecting cleaning cartridges from the TS3500/3584 On 17 mrt 2010, at 19:45, Richard Sims wrote: > On Mar 17, 2010, at 2:24 PM, Clay Willoughby wrote: > >> But there is a handy message displayed on the front console telling who ever >> walks by to eject a used up cleaning tape,,, that's very handy > > I don't have a SCSI library, but I should think it would be relatively easy > to set up a simple monitor based upon dsmadmc -consolmode to watch for > message ANR8915I, and over time to issue Query LIBVolumes Format=Detailed to > look for "Cleanings Left" (or Select from LIBVOLUMES, to act on the > CLEANINGS_LEFT field) to perform a Checkout when the time was right, > accompanied by some message to the operator. > Richard, unfortunately, in most cases the TS3500 will manage the cleaning, and the cleaners will not be visible to TSM. With ALMS, this is basically the only viable option. The only way to find out about worn out cleaners is via either the web interface or the operator panel on the lib itself. The most viable solution is to just put 10 or more in the lib, and check one every three months for any that need replacing, manually > Richard Sims -- Met vriendelijke groeten/Kind Regards, Remco Post r.p...@plcs.nl +31 6 248 21 622
Tdp for sqlserver question
Trying to determine which versions of sqlserver are supported by the 5.5.x version of tdp for sqlserver client. Looking in both the html and pdf version of the manual on page 25 under the table: Table 3. Minimum software and operating system requirements for Legacy Backup and Restore operations I see sqlserver 20004 and 2005. This may be a "feature" in screen reader rendering, could someone translate? Specifically, is sqlserver 2000 supported? Thanks for the help. Gary Lee Senior System Programmer Ball State University phone: 765-285-1310
Re: Ejecting cleaning cartridges from the TS3500/3584
Thanks guys. Library is on a remote hosted floor, no humanoids to walk by and notice the Op panel. I agree with Remco, we'll just load up more cleaners and I'll write myself (yet another) yellow sticky note. (The 3584 WILL give you an SNMP alert about cleans, I think, but this customer doesn't have an SNMP monitor.) W -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Remco Post Sent: Wednesday, March 17, 2010 2:51 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Ejecting cleaning cartridges from the TS3500/3584 On 17 mrt 2010, at 19:45, Richard Sims wrote: > On Mar 17, 2010, at 2:24 PM, Clay Willoughby wrote: > >> But there is a handy message displayed on the front console telling who ever walks by to eject a used up cleaning tape,,, that's very handy > > I don't have a SCSI library, but I should think it would be relatively easy to set up a simple monitor based upon dsmadmc -consolmode to watch for message ANR8915I, and over time to issue Query LIBVolumes Format=Detailed to look for "Cleanings Left" (or Select from LIBVOLUMES, to act on the CLEANINGS_LEFT field) to perform a Checkout when the time was right, accompanied by some message to the operator. > Richard, unfortunately, in most cases the TS3500 will manage the cleaning, and the cleaners will not be visible to TSM. With ALMS, this is basically the only viable option. The only way to find out about worn out cleaners is via either the web interface or the operator panel on the lib itself. The most viable solution is to just put 10 or more in the lib, and check one every three months for any that need replacing, manually > Richard Sims -- Met vriendelijke groeten/Kind Regards, Remco Post r.p...@plcs.nl +31 6 248 21 622
Re: Ejecting cleaning cartridges from the TS3500/3584
On 3/17/10 1:18 PM, "Prather, Wanda" wrote: > Is there a way to make the TS3500/3584 do that? ALMS is enabled, > multiple partitions, 3592 carts. I certainly don't have a robot that big, but in seven years we've only cleaned the drives a handful of times. Am I doing something wrong? Our field service guy suggested that we only clean them when absolutely necessary because repeated cleaning can cause the head to fail. --Jim
Re: Changing attributes
You can also edit the registry keys to fix the name. That is how we handle the problem. Andy Huebner -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Thomas Denier Sent: Tuesday, March 16, 2010 3:18 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Changing attributes -Margaret Clark wrote: - >Fixing the dsm.opt may not be enough. When Windows nodes are cloned >with the TSM client in place, the registry will cause this >interesting behavior even after the dsm.opt is updated. >I've found I have to deinstall the TSM client and then delete the >ADSM subkey HKEY_LOCAL_MACHINE\SOFTWARE\IBM\ADSM (from both >controlset instances) before reinstalling. Windows adminsitrators at our site occasionally rename existing Windows systems. We almost never specify node names in dsm.opt files for Windows client; we let the client use the machine name as the node name. When a Windows client is renamed the client scheduler service continues to use the old node name, presumably because the node name was recorded in the registry when the service was created. We have always been able to clean this up by removing and recreating the service. We did not need to deinstall the client software or manually remove registry keys. 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.
Re: Ejecting cleaning cartridges from the TS3500/3584
On 17 mrt 2010, at 19:45, Richard Sims wrote: > On Mar 17, 2010, at 2:24 PM, Clay Willoughby wrote: > >> But there is a handy message displayed on the front console telling who ever >> walks by to eject a used up cleaning tape,,, that's very handy > > I don't have a SCSI library, but I should think it would be relatively easy > to set up a simple monitor based upon dsmadmc -consolmode to watch for > message ANR8915I, and over time to issue Query LIBVolumes Format=Detailed to > look for "Cleanings Left" (or Select from LIBVOLUMES, to act on the > CLEANINGS_LEFT field) to perform a Checkout when the time was right, > accompanied by some message to the operator. > Richard, unfortunately, in most cases the TS3500 will manage the cleaning, and the cleaners will not be visible to TSM. With ALMS, this is basically the only viable option. The only way to find out about worn out cleaners is via either the web interface or the operator panel on the lib itself. The most viable solution is to just put 10 or more in the lib, and check one every three months for any that need replacing, manually > Richard Sims -- Met vriendelijke groeten/Kind Regards, Remco Post r.p...@plcs.nl +31 6 248 21 622
Re: Ejecting cleaning cartridges from the TS3500/3584
On Mar 17, 2010, at 2:24 PM, Clay Willoughby wrote: > But there is a handy message displayed on the front console telling who ever > walks by to eject a used up cleaning tape,,, that's very handy I don't have a SCSI library, but I should think it would be relatively easy to set up a simple monitor based upon dsmadmc -consolmode to watch for message ANR8915I, and over time to issue Query LIBVolumes Format=Detailed to look for "Cleanings Left" (or Select from LIBVOLUMES, to act on the CLEANINGS_LEFT field) to perform a Checkout when the time was right, accompanied by some message to the operator. Richard Sims
Re: NDMP file level restore
Sam, I came across that particular issue in the past. If you are using the GUI to perform your file-level NDMP restore then that's your problem!!! If you want to have restore performance similar to that of your backup then perform the restore via the CLI. It'll be a LOT faster. You may create virtualfsmap using the appropriate paths as destination then perform the restore operation. Good luck. BERTAUT TCHUISE TSM/NetApp Storage Engineer Legg Mason Technology Services *410-580-7032 btchu...@leggmason.com -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Sam Sheppard Sent: Wednesday, March 17, 2010 2:02 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] NDMP file level restore We are testing NDMP/TOC in TSM 6.1.3.1. Backup is very fast and appears to work very well. Restore of and individual file is a different story altogether. We restored one 90MB file out of a backup of a 120GB volume with no differentials. The restore took about 30 minutes. I'm trying to figure out why such poor performance on file level restore. My initial assumption is that since the backup is at the block level and the NAS file system is write-anywhere, the blocks for an individual file could be scattered all over the tape (TS1120). Anyone have any experience/suggestions with file-level NDMP restore? Thanks Sam Sheppard San Diego Data Processing Corp. (858)-581-9668 IMPORTANT: E-mail sent through the Internet is not secure. Legg Mason therefore recommends that you do not send any confidential or sensitive information to us via electronic mail, including social security numbers, account numbers, or personal identification numbers. Delivery, and or timely delivery of Internet mail is not guaranteed. Legg Mason therefore recommends that you do not send time sensitive or action-oriented messages to us via electronic mail. This message is intended for the addressee only and may contain privileged or confidential information. Unless you are the intended recipient, you may not use, copy or disclose to anyone any information contained in this message. If you have received this message in error, please notify the author by replying to this message and then kindly delete the message. Thank you.
Re: Ejecting cleaning cartridges from the TS3500/3584
But there is a handy message displayed on the front console telling who ever walks by to eject a used up cleaning tape,,, that's very handy >>> "Prather, Wanda" 3/17/2010 12:18 PM >>> I seem to recall that the 3494 ejects cleaning cartridges automatically when they are used up. Is there a way to make the TS3500/3584 do that? ALMS is enabled, multiple partitions, 3592 carts. Wanda Prather | Systems Integration Specialist | wprat...@icfi.com | www.jasi.com ICF Jacob & Sundstrom | 401 E. Pratt St, Suite 2214, Baltimore, MD 21202 | 410.539.1135
Re: NDMP file level restore
Sam: out of interest, what is your NAS box here? /DMc -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Sam Sheppard Sent: 17 March 2010 18:02 To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] NDMP file level restore We are testing NDMP/TOC in TSM 6.1.3.1. Backup is very fast and appears to work very well. Restore of and individual file is a different story altogether. We restored one 90MB file out of a backup of a 120GB volume with no differentials. The restore took about 30 minutes. I'm trying to figure out why such poor performance on file level restore. My initial assumption is that since the backup is at the block level and the NAS file system is write-anywhere, the blocks for an individual file could be scattered all over the tape (TS1120). Anyone have any experience/suggestions with file-level NDMP restore? Thanks Sam Sheppard San Diego Data Processing Corp. (858)-581-9668
NDMP file level restore
We are testing NDMP/TOC in TSM 6.1.3.1. Backup is very fast and appears to work very well. Restore of and individual file is a different story altogether. We restored one 90MB file out of a backup of a 120GB volume with no differentials. The restore took about 30 minutes. I'm trying to figure out why such poor performance on file level restore. My initial assumption is that since the backup is at the block level and the NAS file system is write-anywhere, the blocks for an individual file could be scattered all over the tape (TS1120). Anyone have any experience/suggestions with file-level NDMP restore? Thanks Sam Sheppard San Diego Data Processing Corp. (858)-581-9668
Re: Ejecting cleaning cartridges from the TS3500/3584
On 17 mrt 2010, at 18:18, Prather, Wanda wrote: > I seem to recall that the 3494 ejects cleaning cartridges automatically > when they are used up. > > Is there a way to make the TS3500/3584 do that? TS3500 is a glorified midrange library, so an operator is needed to eject cartridges, even worthless cleaners. -- Met vriendelijke groeten/Kind regards, Remco Post r.p...@plcs.nl
Re: Ejecting cleaning cartridges from the TS3500/3584
Another step backward in tape robotics. -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Prather, Wanda Sent: Wednesday, March 17, 2010 12:19 PM To: ADSM-L@vm.marist.edu Subject: [ADSM-L] Ejecting cleaning cartridges from the TS3500/3584 I seem to recall that the 3494 ejects cleaning cartridges automatically when they are used up. Is there a way to make the TS3500/3584 do that? ALMS is enabled, multiple partitions, 3592 carts. Wanda Prather | Systems Integration Specialist | wprat...@icfi.com | www.jasi.com ICF Jacob & Sundstrom | 401 E. Pratt St, Suite 2214, Baltimore, MD 21202 | 410.539.1135
Ejecting cleaning cartridges from the TS3500/3584
I seem to recall that the 3494 ejects cleaning cartridges automatically when they are used up. Is there a way to make the TS3500/3584 do that? ALMS is enabled, multiple partitions, 3592 carts. Wanda Prather | Systems Integration Specialist | wprat...@icfi.com | www.jasi.com ICF Jacob & Sundstrom | 401 E. Pratt St, Suite 2214, Baltimore, MD 21202 | 410.539.1135
Re: 5.5 -> 6.2
On 7 mrt 2010, at 23:37, Xav Paice wrote: > > > Most people with larger databases cannot cope with the downtime, measured in > days, that it takes to import the database. I fully agree with you on this one. Having a larger than recommended database is now a challenge to these customers. ---8<--- > Mostly I'm finding now that people don't just want to migrate to a new server > if they have a massive database - they want to combine that action with > splitting into more instances to reduce the db size. Export/import is a good > way to achieve that. > I partly agree. Splitting the database makes a lot of sense in the TSM 5 era, with TSM 6, there is less reason to do so, provided that IBM will never ever make us go through such an upgrade again. > I'd be keen to try to do a full backup of nodes to the new server, so long as > the client can complete that within a reasonable time. If it takes 3 days to > make a full backup then the node has no valid backup for 3 days. Typically > the client is the slow point rather than the server. I'd be concerned if the > amount of time taken to migrate the node data to a new server using 'export > node' is too long - that's a background process which can be done in advance > of moving the node, but note that it should take only a bit longer than the > restore of that node. If it takes a week to restore a node that would be > well outside of SLA would it not? > A full backup and a full restore of a node should ideally take about the same amount of time. With a restore, there is of course a bit more tape-handling going on. An export, OTOH, needs to crawl through all active and inactive objects, rather than only the active objects. This may take quite some extra time. You are right, one could run a partial export and incrementally export a node if an export takes to long. > The other issue with just doing full backups to the new server is the > historical data that still lives on the old server. If it takes a year (or > more) for that old data to expire, then surely that means keeping old > instances of TSM hanging around for history? Backup data retention of more than a few months is a problem. I know a lot of people have a hard time convincing customers that this data should most likely be archived, and I know that such retentions exists. And yes, in such cases, one would need either to export/import or keep the data around in the old server for such a long period. > Many clients also don't want that as they must return hardware for lease > expiry, trade-in, etc. let alone having to maintain yet another box. Not a > problem if your RETONLY is 10 days and archives are only kept for a month, > but if your archives are there for 7 years you have no choice but to move > stuff around somehow. so, export the archive data (usually, if you're smart that's just a small bit), and restart your backups. > > The result is that you must pick the migration method on a per node basis - > there are many factors to decide which method is chosen, none of which are > ideal. I prefer to do a 5.4 to 5.5 upgrade over anything to do with 6.1... -- Met vriendelijke groeten/Kind regards, Remco Post r.p...@plcs.nl
Re: Long running backup pinning log
Well, in this situation, we discovered the dreaded "retrying 150GB file backup" as the problem. Ignoring the fact that the 150GB file is names as a "log" of some kind, once we added CHANGINGRETRIES 0, the backups have dropped in both time and size, no longer causing the pinning problem. I don't have the authority to tell the app owner to look into why their "log" is 150GB! We just send them the bill ;---) Zoltan Forray TSM Software & Hardware Administrator Virginia Commonwealth University UCC/Office of Technology Services zfor...@vcu.edu - 804-828-4807 Don't be a phishing victim - VCU and other reputable organizations will never use email to request that you reply with your password, social security number or confidential personal information. For more details visit http://infosecurity.vcu.edu/phishing.html From: "Loon, EJ van - SPLXM" To: ADSM-L@VM.MARIST.EDU Date: 03/17/2010 09:29 AM Subject: Re: [ADSM-L] Long running backup pinning log Sent by: "ADSM: Dist Stor Manager" Hi Zoltan! We were experiencing a lot of logpinning about a month ago which all seem related to a handful of clients. Investigation showed that nearly all of them were running with a half-duplex connection instead of a full duplex fixed rate. As soon as this was fixed by the client owner, backups were performing as expected and logpinning was gone too. Just an thought... Kind regards, Eric van Loon KLM Royal Dutch Airlines -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Zoltan Forray/AC/VCU Sent: maandag 8 maart 2010 15:53 To: ADSM-L@VM.MARIST.EDU Subject: Re: Long running backup pinning log Thanks for the heads-up. Unfortunately, from reading the APAR, this box does not seem to have the symptoms. There is no significant gap in backing up each component of systemstate, unless this is hidden because of QUIET. We have changed this to VERBOSE to get more details on where it is slogging. >From what I see in the dsmsched log, this is what the last backup that finished (todays is still running), says: 01:43 - Backup started 01:47 - Systemstate backup finished 12:21 - d$ drive backup finished 12:25 - c$ drive backup finished Total objects examined - 72,395 Total objects backed up - 1,725 Total data backed-up (to paraphase) - 93.82Gb I did note the "Object compressed by" is 87%. Which brings me to the question - Is the "total amount backed up" after compression? My guess it lots of time spent in compression (IBM - how about some compression algorithm controls (low - medium - high). Haven't ruled out "retries" - will see when verbose is on. I don't see journaling making that much of a difference. The server has 2GB RAM of which 900M was free when I checked it this morning, so it doesn't seem to be constrained. The backup is currently running and the dsm service was using 10-20% CPU. Zoltan Forray TSM Software & Hardware Administrator Virginia Commonwealth University UCC/Office of Technology Services zfor...@vcu.edu - 804-828-4807 Don't be a phishing victim - VCU and other reputable organizations will never use email to request that you reply with your password, social security number or confidential personal information. For more details visit http://infosecurity.vcu.edu/phishing.html From: Andrew Raibeck To: ADSM-L@VM.MARIST.EDU Date: 03/05/2010 04:32 PM Subject: Re: [ADSM-L] Long running backup pinning log Sent by: "ADSM: Dist Stor Manager" Hi Zoltan, Is the long-running backup working on system state? I haven't found a direct cause --> effect relationship to client APAR IC63094, but take a look at that APAR and see if, after applying the fix, the problem you are seeing goes away. I should mention to all: IC63094 describes a problem with long-running system state backups. This APAR may be of interest to you. Best regards, Andy Andy Raibeck IBM Software Group Tivoli Storage Manager Client Product Development Level 3 Team Lead Internal Notes e-mail: Andrew Raibeck/Hartford/i...@ibmus Internet e-mail: stor...@us.ibm.com IBM Tivoli Storage Manager support web page: http://www.ibm.com/support/entry/portal/Overview/Software/Tivoli/Tivoli_ Storage_Manager The only dumb question is the one that goes unasked. The command line is your friend. "Good enough" is the enemy of excellence. "ADSM: Dist Stor Manager" wrote on 2010-03-05 16:26:01: > [image removed] > > Long running backup pinning log > > Zoltan Forray/AC/VCU > > to: > > ADSM-L > > 2010-03-05 16:26 > > Sent by: > > "ADSM: Dist Stor Manager" > > Please respond to "ADSM: Dist Stor Manager" > > I recently started having issues with my log going over 80% (5.5.3). Doing > a "show logpinned" usually points to a long (18-hours) running backup > session for one particular node. > > This is starting to happen more and more frequently. > > Once I kill the session, the log utilization drops to almost nothing since > there has been a DB backup run earlier in the day. > > Any suggestions on how to handle this bes
Re: Long running backup pinning log
Hi Zoltan! We were experiencing a lot of logpinning about a month ago which all seem related to a handful of clients. Investigation showed that nearly all of them were running with a half-duplex connection instead of a full duplex fixed rate. As soon as this was fixed by the client owner, backups were performing as expected and logpinning was gone too. Just an thought... Kind regards, Eric van Loon KLM Royal Dutch Airlines -Original Message- From: ADSM: Dist Stor Manager [mailto:ads...@vm.marist.edu] On Behalf Of Zoltan Forray/AC/VCU Sent: maandag 8 maart 2010 15:53 To: ADSM-L@VM.MARIST.EDU Subject: Re: Long running backup pinning log Thanks for the heads-up. Unfortunately, from reading the APAR, this box does not seem to have the symptoms. There is no significant gap in backing up each component of systemstate, unless this is hidden because of QUIET. We have changed this to VERBOSE to get more details on where it is slogging. From what I see in the dsmsched log, this is what the last backup that finished (todays is still running), says: 01:43 - Backup started 01:47 - Systemstate backup finished 12:21 - d$ drive backup finished 12:25 - c$ drive backup finished Total objects examined - 72,395 Total objects backed up - 1,725 Total data backed-up (to paraphase) - 93.82Gb I did note the "Object compressed by" is 87%. Which brings me to the question - Is the "total amount backed up" after compression? My guess it lots of time spent in compression (IBM - how about some compression algorithm controls (low - medium - high). Haven't ruled out "retries" - will see when verbose is on. I don't see journaling making that much of a difference. The server has 2GB RAM of which 900M was free when I checked it this morning, so it doesn't seem to be constrained. The backup is currently running and the dsm service was using 10-20% CPU. Zoltan Forray TSM Software & Hardware Administrator Virginia Commonwealth University UCC/Office of Technology Services zfor...@vcu.edu - 804-828-4807 Don't be a phishing victim - VCU and other reputable organizations will never use email to request that you reply with your password, social security number or confidential personal information. For more details visit http://infosecurity.vcu.edu/phishing.html From: Andrew Raibeck To: ADSM-L@VM.MARIST.EDU Date: 03/05/2010 04:32 PM Subject: Re: [ADSM-L] Long running backup pinning log Sent by: "ADSM: Dist Stor Manager" Hi Zoltan, Is the long-running backup working on system state? I haven't found a direct cause --> effect relationship to client APAR IC63094, but take a look at that APAR and see if, after applying the fix, the problem you are seeing goes away. I should mention to all: IC63094 describes a problem with long-running system state backups. This APAR may be of interest to you. Best regards, Andy Andy Raibeck IBM Software Group Tivoli Storage Manager Client Product Development Level 3 Team Lead Internal Notes e-mail: Andrew Raibeck/Hartford/i...@ibmus Internet e-mail: stor...@us.ibm.com IBM Tivoli Storage Manager support web page: http://www.ibm.com/support/entry/portal/Overview/Software/Tivoli/Tivoli_ Storage_Manager The only dumb question is the one that goes unasked. The command line is your friend. "Good enough" is the enemy of excellence. "ADSM: Dist Stor Manager" wrote on 2010-03-05 16:26:01: > [image removed] > > Long running backup pinning log > > Zoltan Forray/AC/VCU > > to: > > ADSM-L > > 2010-03-05 16:26 > > Sent by: > > "ADSM: Dist Stor Manager" > > Please respond to "ADSM: Dist Stor Manager" > > I recently started having issues with my log going over 80% (5.5.3). Doing > a "show logpinned" usually points to a long (18-hours) running backup > session for one particular node. > > This is starting to happen more and more frequently. > > Once I kill the session, the log utilization drops to almost nothing since > there has been a DB backup run earlier in the day. > > Any suggestions on how to handle this besides killing the session? The > node is a standard 2K3 box using the 6.1.2.0 client. It is just a very > slow/busy box. The long backups (times vary from 11-19 hours) often dump > 120GB of data. > Zoltan Forray > TSM Software & Hardware Administrator > Virginia Commonwealth University > UCC/Office of Technology Services > zfor...@vcu.edu - 804-828-4807 > Don't be a phishing victim - VCU and other reputable organizations will > never use email to request that you reply with your password, social > security number or confidential personal information. For more details > visit http://infosecurity.vcu.edu/phishing.html ** 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 disclos
