Re: New guide for optimizing Tivoli Storage Manager performance
Has anyone had any experience with varying the NTFS cluster size from the default 4Kb for either DB2 (database/logs) or TSM volumes (disk/file)? Did it make a difference? I know there's a strong steer towards 64Kb when using other RDBs, but I haven't seen anything documented for either DB2 or TSM. Regards Neil Schofield Technical Leader Yorkshire Water Spotted a leak? If you spot a leak please report it immediately. Call us on 0800 57 3553 or go to http://www.yorkshirewater.com/leaks Get a free water saving pack Don't forget to request your free water and energy saving pack, it could save you money on your utility bills and help you conserve water. http://www.yorkshirewater.com/savewater The information in this e-mail is confidential and may also be legally privileged. The contents are intended for recipient only and are subject to the legal notice available at http://www.keldagroup.com/email.htm Yorkshire Water Services Limited Registered Office Western House, Halifax Road, Bradford, BD6 2SZ Registered in England and Wales No 2366682
Re: New guide for optimizing Tivoli Storage Manager performance
Thank you Andy, This redbook is definitely a light reading compared to the rest of the TSM rebooks. :) Thank you for all the fine tuning information being placed in once place. I wanted to ask is anyone on the list using Dedup technology with an 8 LUN database backend as recommended in the article. Is there any readily available data to show the performance enhancements? I'm currently setup with 4 folders under one LUN, with multiple paths to the SAN. I have yet to see any negative performance or IO bottlenecks. E:\Database\Server01\DB001 E:\Database\Server01\DB002 E:\Database\Server01\DB003 E:\Database\Server01\DB004 Assuming the benefits are huge, a database backup and restore with a dir input file is the only clean way to split it up over multiple luns instead of folders. Thanks for any feedback, -Nick Nick Marouf | Systems Administrator Consultant PA Department of Transportation | Bureau of Infrastructure and Operations 1400A North Cameron St | Harrisburg PA 17103 Phone: 717.346.5547 | Fax: 717.346.5530 www.dot.state.pa.us -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Andrew Raibeck Sent: Tuesday, April 16, 2013 3:54 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] New guide for optimizing Tivoli Storage Manager performance Hello TSM community, I would like to draw your attention to a newly published guide for optimizing Tivoli Storage Manager performance. This guide is oriented toward TSM version 6.3 and 6.4, and supersedes the previous performance tuning guides. The guide features a whole new approach to: * Configuration best practices for the server database, storage pools, clients, and more * Guidance for identifying performance bottlenecks in the environment * Flowcharts and graphics that illustrate key processes and practices This blog post from one of our senior Information Development leads provides a nice introduction and link to the new guide: https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Tivoli%20Storage%20Manager/page/Optimizing%20performance%20for%20servers%20and%20clients We hope you find this useful. - Andy Andrew Raibeck | Tivoli Storage Manager Level 3 Technical Lead | stor...@us.ibm.com IBM Tivoli Storage Manager links: Product support: http://www.ibm.com/support/entry/portal/Overview/Software/Tivoli/Tivoli_Storage_Manager Online documentation: https://www.ibm.com/developerworks/mydeveloperworks/wikis/home/wiki/Tivoli Documentation Central/page/Tivoli Storage Manager Product Wiki: https://www.ibm.com/developerworks/mydeveloperworks/wikis/home/wiki/Tivoli +Storage+Manager/page/Home
Equating current 3494 configuration to TS3500
Slight tangent, Wanda's volume location comment spurred this: We upgraded our SCSI 3584 offsite lib to ALMS, no problems...but the onsite ALMS install went horribly wrong...(maint windows are rare, we did several things). Afterwards the lib couldn't reliably find a particular tape with both (robot) hands. Some days it could find some vols, other days those had slid out and it would forget others -- and not just a few, but 60 to 100 of them (10-25% of the lib)!...NO extraordinary measures (like emptying frames and re-inserting) resolved the problem. Our OEM maintenance could not find the problem and shrugged and walked off after a couple of months, intimating it was OUR problem and would not bring in IBM. A lot of time was spent looking through all 3 frames for a particular volume that was needed; reclamation couldn't find volumes either. We took outages, powered down the lib...lib and server...the problem persisted. It was ugly, VERY ugly. Oddly, no regular pub (TSM books, IBM hardware/operator manuals, device manuals or stuff online) told you where the *hardware* stores the volume locations...I stumbled on an obscure 4-5 page blurb from a tape plant engineer with that magic sentence: the volume physical location information is stored in the robot's node cards!! That was the key! We resolved the problem by killing it deadpowered it down (nicely), pulled the physical power, then pulled the (?9V?) battery from the robot to clear the CMOS, waited awhile for all memory to die, and powered everything back up. Of course it was a blithering idiot...all upgrades were lost. (We were delayed a bit because of the upgrade keys -- the lib was shipped with the capacity expansion feature but the plant didn't put a code sticker in the lib or on any documents...after confirming a key was required, I finally found a nice guy in Mexico who could still generate the code!). Does ALMS change the node cards' function? I suspect not but don't know for sure. For some reason I haven't screwed up the courage to reinstall ALMS, but may do so -- we recently went back to IBM maintenance.:) - Susie - The virtual I/O slots only get involved when you put cartridges in through the 16/32 slot physical I/O door. For the initial library load, just open the BIG doors and put the tapes directly into the slots yourself. Then for a SCSI library, the syntax for CHECKIN is slightly different than for your 3494. checkin libv bubba search=yes status=scratch checklabel=barcode waitt=0 volrange=TS1000,TS1999 checkin libv bubba search=bulk status=scratch checklabel=barcode waitt=0 Search=YES tells TSM to checkin from the INSIDE library slots. Search=bulk tells TSM to checkin what's in the I/O door (with ALMS, it's a virtual I/O door, but TSM doesn't know that.) FWIW: For the 3494, TSM just tells the 3494 what it wants done, and doesn't know or care where in the library tapes are located. All the inventory management is done outboard by the 3494. If TSM tells the 3494 to mount a cartridge, he doesn't need to know where the cartridge is, that's handled by the 3494 For a SCSI library, including the TS3500 doing business as a 3584, TSM has to figure out what tapes are in what slots at checkin time, and saves the slot numbers in devconfig so he can send the appropriate commands for cartridge movement. (e.g., take cartridge from slot 1024, load in drive position 6). That's why the checkin commands are different.
Re: Equating current 3494 configuration to TS3500
We had a ugly incident with both of our 3584 libraries. Symptom: The robot picker was getting stuck. When it tried to grab a tape from a slot or put a tape into a drive (or put a tape back into a slot), it would get stuck with the tape partially in the slot/drive and the robot picker. This pinned the robot so it couldn't move. IBM replaced multiple picker assemblies. After a replacement it would work for a while, then start having the problems again, and would get progressively worse. We were getting multiple events per day! The library error log showed many more errors than just then ones that caused the robot to hang. These other errors it was able to recover from. Long story short . . . As tapes were inserted removed from and inserted into cells, the cells were creating a dust which was causing ware on the picker. This is a known issue with some plastic cells from a certain date/time of manufacture. IBM replaced all the plastic cells in the library. Yup . . .on an outage IBM opened up the the frames, removed all the tapes, removed the plastic cells, installed new cells, put the tapes back in. When done we inventoried the library and all was good. Rick From: Stout, Susie (NIH/CIT) [E] sto...@mail.nih.gov To: ADSM-L@VM.MARIST.EDU Date: 04/26/2013 10:00 AM Subject:Equating current 3494 configuration to TS3500 Sent by:ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU Slight tangent, Wanda's volume location comment spurred this: We upgraded our SCSI 3584 offsite lib to ALMS, no problems...but the onsite ALMS install went horribly wrong...(maint windows are rare, we did several things). Afterwards the lib couldn't reliably find a particular tape with both (robot) hands. Some days it could find some vols, other days those had slid out and it would forget others -- and not just a few, but 60 to 100 of them (10-25% of the lib)!...NO extraordinary measures (like emptying frames and re-inserting) resolved the problem. Our OEM maintenance could not find the problem and shrugged and walked off after a couple of months, intimating it was OUR problem and would not bring in IBM. A lot of time was spent looking through all 3 frames for a particular volume that was needed; reclamation couldn't find volumes either. We took outages, powered down the lib...lib and server...the problem persisted. It was ugly, VERY ugly. Oddly, no regular pub (TSM books, IBM hardware/operator manuals, device manuals or stuff online) told you where the *hardware* stores the volume locations...I stumbled on an obscure 4-5 page blurb from a tape plant engineer with that magic sentence: the volume physical location information is stored in the robot's node cards!! That was the key! We resolved the problem by killing it deadpowered it down (nicely), pulled the physical power, then pulled the (?9V?) battery from the robot to clear the CMOS, waited awhile for all memory to die, and powered everything back up. Of course it was a blithering idiot...all upgrades were lost. (We were delayed a bit because of the upgrade keys -- the lib was shipped with the capacity expansion feature but the plant didn't put a code sticker in the lib or on any documents...after confirming a key was required, I finally found a nice guy in Mexico who could still generate the code!). Does ALMS change the node cards' function? I suspect not but don't know for sure. For some reason I haven't screwed up the courage to reinstall ALMS, but may do so -- we recently went back to IBM maintenance.:) - Susie - The virtual I/O slots only get involved when you put cartridges in through the 16/32 slot physical I/O door. For the initial library load, just open the BIG doors and put the tapes directly into the slots yourself. Then for a SCSI library, the syntax for CHECKIN is slightly different than for your 3494. checkin libv bubba search=yes status=scratch checklabel=barcode waitt=0 volrange=TS1000,TS1999 checkin libv bubba search=bulk status=scratch checklabel=barcode waitt=0 Search=YES tells TSM to checkin from the INSIDE library slots. Search=bulk tells TSM to checkin what's in the I/O door (with ALMS, it's a virtual I/O door, but TSM doesn't know that.) FWIW: For the 3494, TSM just tells the 3494 what it wants done, and doesn't know or care where in the library tapes are located. All the inventory management is done outboard by the 3494. If TSM tells the 3494 to mount a cartridge, he doesn't need to know where the cartridge is, that's handled by the 3494 For a SCSI library, including the TS3500 doing business as a 3584, TSM has to figure out what tapes are in what slots at checkin time, and saves the slot numbers in devconfig so he can send the appropriate commands for cartridge movement. (e.g., take cartridge from slot 1024, load in drive position 6). That's why the checkin commands are different. - The information contained in this message is
Restore failing - ANS0361I DIAG: fioGetAttrib
Windows 2012 server - 6.4.0.1 client A user deleted an entire folder this morning. Attempts to restore the files keep failing with messages like this: 04/26/2013 11:27:51 ANS0361I DIAG: fioGetAttrib(\\rose.adm.adp.vcu.edu\ots\Purchasing\Reports\ARMICS\Procurement Services\2013 Testing\Insurance Services\Final\IRM - Insuring Vehicles-final.docx) failed. 04/26/2013 11:27:52 ANS4007E Error processing '\\rose.adm.adp.vcu.edu\ots\Purchasing\Reports\ARMICS\Procurement Services\2013 Testing\Insurance Services\Final\IRM - Insuring Vehicles-final.docx': access to the object is denied Digging back through the dsmerror.log file, I found this message during last nights backups: 04/25/2013 22:15:26 ANS0361I DIAG: Error reading http request. 04/25/2013 22:18:15 ANS0361I DIAG: sessRecvVerb(): Invalid verb received. 04/25/2013 22:18:15 ANS0361I DIAG: sessRecvVerb(): length=4745, verb=54,magic=20 04/25/2013 22:19:17 ANS0361I DIAG: sessRecvVerb(): Invalid verb received. 04/25/2013 22:19:17 ANS0361I DIAG: sessRecvVerb(): length=4845, verb=4c,magic=50 04/25/2013 22:19:47 ANS0361I DIAG: sessRecvVerb(): Invalid verb received. 04/25/2013 22:19:47 ANS0361I DIAG: sessRecvVerb(): length=0500, verb=0b,magic=03 04/25/2013 22:20:04 ANS0361I DIAG: Error opening input file login.html 04/25/2013 22:20:23 ANS0361I DIAG: Error opening input file login.htm [snippage] 04/25/2013 22:35:10 ANS0361I DIAG: isFileNameValid: Relative path specified, but not allowed. 04/25/2013 22:35:10 ANS0361I DIAG: isFileNameValid: Relative path specified, but not allowed. and lots more errors like this. However, the backup continued to run and finished around 04:00am. Suggestions? Thoughts? I checked the apars for 6.4.0.4 but nothing in there (mostly VM stuff) applies to this situation. I told the server tech to try restarting the scheduler/CAD and try the restore again as well as sending me the dsmwebcl.log file and dsmsched.log file. -- *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
Exchange scheduler and backup issues
Hi, This was dumped on me last night and I was looking for some advice having no experience with Exchange. Since I do not have access to log in to this cluster I'm relying on responses from an administrator. If anyone has some clues I can pass on I'd appreciate it. I'm told the cluster is set up with services that TSM kicks off which are .cmd files. Initially I was told it was running fine from one node but when it failed to the other it stopped working. The services are started by a specific user and are set up through the cluster. I'm also told they use that same account to log in to the systems and can run a manual backup just fine, which means if that is true the error below makes no sense. Also, I'm told now that even though they failed the resources back to the working node it also fails. I'm wondering if there is more than one issue going on here. I know that if the initial connection on a node is not made before the services are installed and started they will not start because the password was never authenticated with the server. I've seen this with the baclient but not sure if it applies here. The permissions doesn't make sense unless what I'm being told is not what is really happening when they log in but right now I have no reason to doubt them. There are a couple of errors they are getting, Initially I was sent this one: ANR2579E Schedule blah bah blah for node LONS08_EXCH_DAILY failed (return code -1073741819). Today they sent me this one and when I queried them on permissions I was told this doesn't seem to be correct because they just logged in with that same user starting the services and the backup worked. 03/24/2013 14:56:50 ANS1577I The Windows console event handler received a 'Shutdown' console event. 03/24/2013 14:56:50 ANS2820E An interrupt has occurred. The current operation will end and the client will shut down. 03/24/2013 14:56:50 ANS1520E Failure writing to the Tivoli Storage Manager error log: errno = 13, Permission denied 04/20/2013 01:23:02 ANS1909E The scheduled command failed. 04/20/2013 01:23:02 ANS1512E Scheduled event 'MAN_WIN_DBWA_EXC_FULL_2200_0' failed. Return code = 402. 04/24/2013 22:31:18 ANS1909E The scheduled command failed. 04/24/2013 22:31:18 ANS1512E Scheduled event 'MAN_WIN_DBWA_EXC_FULL_2200_1' failed. Return code = 402. Thank You Geoff Gill
Baltimore, Wash DC, NoVa TSM User Group meets May 15
Mark your calendar for the next TSMUG on Wednesday, May 15! We're looking forward to this meeting, which will include: Ken Bury, with information about the TSM roadmap (Yes, it's that time again!) Colin Dawson and company with more on the upcoming Operations Center and its roadmap as well, as it gets closer to first release And as usual, lots more! Please register ASAP, and please forward this announcement to anyone in your organization who may be interested. Registration instructions below. DATE: Wednesday, May 15, 2013 TIME: 8:30AM - 2:30PM LOCATION: CAS Severn 6201 Chevy Chase Drive Laurel MD 20707 REGISTRATION: Meetings are free. However, you must register in advance. To register send an email to tsmug.dcme...@gmail.commailto:tsmug.dcme...@gmail.com with your name, company, a current phone number and the title registration. That's all it takes. * If there are seats available, you will receive a confirmation email within a few days, a notice of the Final Agenda, and a reminder notice before the meeting. * When seats are filled, we will maintain a waiting list. * CUTOFF for registration is 5pm Thursday, May 9, 2013, or when we run out of seats, whichever comes first. * We have a limited number of seats, and registration can fill up quickly. If you need to get approval from your management to attend, we suggest you register now, and cancel if you can't get approval. * If you register and find out later you can't attend, someone can attend in your place without notifying us. * If no one will attend in your place, please remember to cancel so that someone else can have your seat. ATTENDANCE POLICY: Recruiting is not allowed at TSMUG meetings. Business partners are welcome to participate as long as they identify themselves as such. REFRESHMENTS: Morning coffee and lunch will be provided. QUESTIONS? If you have questions, please send an email to tsmug.dcme...@gmail.commailto:tsmug.dcme...@gmail.com.
