Sleeping computers
I have a question. We have quite a few desktops that we backup using TSM. But we have a problem with computers going to sleep after the user leaves for the day. We asked our users to change their power settings to prevent this but power settings are per user and sometimes over the course of time they may log on to another machine for the first time and forget. I asked our domain guy and he says there is no domain or group policy for power settings. I find that hard to believe but anyway I was wondering if anyone else encounters this and how they fixed it. Buddy Howeth Computer Operations Specialist Information Systems Pacific Coast Producers Corporate Offices 631 N. Cluff Ave Lodi, CA 95240-0756 (209) 367-8800 - Main# (209) 367-6288 - Computer Room
DB PiT restore with 6.2.1
Hi, We are new to TSM6 and are testing TSM DB restore using TSM 6.2.1 on AIX 6. Restoring to the most current state works fine. Point in time restore seems to work only to the nearest full or incremental backup, e.g. if we have backups: Full 10:00 Incr 11:00 Incr 12:00 and want to restore to PiT 11:30 with > dsmserv restore db todate=today totime=11:30:00 it restores to 11:00 only. And when restoring it says (among other ANR*I messages): ANR4645I The restore date reflects the most recent backup available up to the specified TODATE (BTW - no W or E ANR messages during the restore!) So I can't restore to exactly 11:30 in the above example, even if all Logs till 12:00 should be in the backup? Is this the way it is supposed to work or what am I doing wrong? My understanding from the Admin Guide (which under "Point-in-time restore" in Chap. 25 p. 773 states "Applies logs from the overflow directory up to specified point in time" as the last action ) was, that a restore to 11:30 in the above example should be possible. TIA Andreas -- -- Andreas Priebe Data Center PROMOS consult Projektmanagement, Organisation und Service GmbH Rungestraße 19 10179 Berlin Telefon: +49(0)30 - 24 31 17 - 613 Mobil: +49(0)151 52 72 89 13 Fax: +49(0)30 - 24 31 17 - 729 andreas.pri...@promos-consult.de www.openpromos.com Bitte denken Sie an die Umwelt, bevor Sie diese E-Mail drucken. - Besuchen Sie uns auf folgenden Veranstaltungen: 8. OpenPromos Anwenderforum 16. - 17.03.2011, Berlin VdW Rheinland Westfalen 10. Forum Wohnungswirtschaft 21. - 22. 06. 2011 in Düsseldorf ImmoCom 2011 08. - 09.09.2011, Berlin 14. SAP-Kongress für die Immobilienwirtschaft 22. - 23.09.2011, Potsdam Verbandstag VdW Rheinland Westfalen 27.-28. 09. in Leverkusen 14. Expo Real 04. - 06.10.2011, München - Für aktuelle Informationen über unsere Neuentwicklungen und Projekte bestellen Sie unseren PROMOS-Newsletter! http://www.openpromos.com/ger/kontakt/newsletter_anmeldung.php - PROMOS consult Projektmanagement, Organisation und Service GmbH Sitz der Gesellschaft: Berlin Amtsgericht Charlottenburg, HRB 108478 B Geschäftsführer: Dipl.-Ing. Jens Kramer, Dipl.-Inf. Volker Schulz
5 out of 9 aint bad
I have 9 LTO-4 drives connected to our TSM server, only 5 of them work at any time after upgrading to a new fiber card. We have tried two different fiber cards (qlogic and emulex) and still only 5 drives. We have Confirmed latest drivers and firmware with IBM support. The old 2gig fiber card still works with all 9 drives, but is considerably slower than 5 drives on an 4g card. The new cards are both multi port cards, but only one port is being used. Multipath drivers are not being used. 9 drives are zoned to one port. IBM support believes it to be hardware since the old card works, so we purchased a second card of different manufacture. Now the problem exists on two fiber cards of different manufacture so I'm real reluctant to think its a hardware problem any more. Interestingly, the 5 good drives vary. I can unload the drivers and reload everything and drives that were previously unavailable work while drives that were working are then unavailable. It seems kind of random. All the dives show up in the OS, and TSMDLST show them all as well. I uninstalled old drivers and reinstalled them exactly as per IBM support instructions, and rebuilt the drive and library paths in tsm during each reload as per IBM support guidelines. Has anyone seen anything like this? I'm absolutely baffled. I'm thinking we are going to have to zone 5 drives to one port and 4 drives to the other, but the SAN admin type is reluctant since all 9 drives work with the original card. My guess is that somewhere in the drivers its smart enough to know that 9 LTO-4's to a single 4g port is silly in the first place. Maybe someone wants 4 LTO-4's so this problem just goes away :) The 5 drives work with fewer problems and better throughput than the 9 drives on the old card. Thanks for reading, Have a great day. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ CONFIDENTIALITY NOTICE: If you have received this email in error, please immediately notify the sender by e-mail at the address shown.This email transmission may contain confidential information.This information is intended only for the use of the individual(s) or entity to whom it is intended even if addressed incorrectly. Please delete it from your files if you are not the intended recipient. Thank you for your compliance.
Re: Installing tsm 6.2.2.0 client on redhat enterprize linux 6
Thanks, David - we ran into this as well here, and this reply was a big help. Looking back the installation instructions for the TSM client for Linux v5.5 and v6.1 show that TIVsm-API.i386.rpm is required for 64-bit systems, so this seems like an error that has crept into the latest documentation. On 2/24/11 7:05 PM, "David Bronder" wrote: >Lee, Gary D. wrote: >> >> Just downloaded the tsm 6.2.2.0 linux86 64 bit client. >> >> Read the readme and lifted the install steps out and ran 1 by one. >> >> Got to the following command and it fails dependencies as shown below. >> >> Since I'm working from IBM's own .tar file, where do I get what it >> wants and doesn't have? >> -- error message - >> >> [root@tsm01 linux86-64]# rpm -U ./TIVsm-API64.i386.rpm >> error: Failed dependencies: >> TIVsm-API = 6.2.2 is needed by TIVsm-API64-6.2.2-0.i586 > >The API64 RPM requires the 32-bit API RPM to also be installed; it should >be included in the tarball. Install the TIVsm-API before you install >TIVsm-API64, and finally install TIVsm-BA (or you can install all three >together). > >(Don't forget to also install the appropriate gskcrypt and gskssl RPMs >as well.) > >The installation instructions do seem to be unclear/misleading/erroneous.
Re: 5 out of 9 aint bad
Hi We use 7-IBM LTO3s and 7-IBM LTO4s directly connected to an IBM 9133-55A w/8-WAY, 64GB of Memory and 4-I/O drawers. Tape drive HBAs and SAN HBAs are P/N 03N5014. Tape Library is an IBM 3584-L32/D32s using LTO3 tapes. Everything works A Ok here -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Laks, Brian Sent: Friday, March 04, 2011 9:32 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] 5 out of 9 aint bad I have 9 LTO-4 drives connected to our TSM server, only 5 of them work at any time after upgrading to a new fiber card. We have tried two different fiber cards (qlogic and emulex) and still only 5 drives. We have Confirmed latest drivers and firmware with IBM support. The old 2gig fiber card still works with all 9 drives, but is considerably slower than 5 drives on an 4g card. The new cards are both multi port cards, but only one port is being used. Multipath drivers are not being used. 9 drives are zoned to one port. IBM support believes it to be hardware since the old card works, so we purchased a second card of different manufacture. Now the problem exists on two fiber cards of different manufacture so I'm real reluctant to think its a hardware problem any more. Interestingly, the 5 good drives vary. I can unload the drivers and reload everything and drives that were previously unavailable work while drives that were working are then unavailable. It seems kind of random. All the dives show up in the OS, and TSMDLST show them all as well. I uninstalled old drivers and reinstalled them exactly as per IBM support instructions, and rebuilt the drive and library paths in tsm during each reload as per IBM support guidelines. Has anyone seen anything like this? I'm absolutely baffled. I'm thinking we are going to have to zone 5 drives to one port and 4 drives to the other, but the SAN admin type is reluctant since all 9 drives work with the original card. My guess is that somewhere in the drivers its smart enough to know that 9 LTO-4's to a single 4g port is silly in the first place. Maybe someone wants 4 LTO-4's so this problem just goes away :) The 5 drives work with fewer problems and better throughput than the 9 drives on the old card. Thanks for reading, Have a great day. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ CONFIDENTIALITY NOTICE: If you have received this email in error, please immediately notify the sender by e-mail at the address shown.This email transmission may contain confidential information.This information is intended only for the use of the individual(s) or entity to whom it is intended even if addressed incorrectly. Please delete it from your files if you are not the intended recipient. Thank you for your compliance.
Update: SQLLiteSpeed backups hanging when moved to TSM server on RHEL5.
An update: We've gathered packet captures, from both client and servers. We've even found some servers running RHEL 5.4 that aren't exhibiting the failure. We're currently checking on the LACP config and NIC firmware. Does anyone have any feedback on gathering strace output for dsmserv under RHEL 5.4? The sysadmins feel like TSM is just not removing the data out of the buffer. I'm hoping to clarify this with strace. Thanks, [RC] - Forwarded by Robert A Clark/OR/USB on 03/04/2011 10:05 AM - From: Robert A Clark/OR/USB To: "ADSM: Dist Stor Manager" Date: 02/15/2011 11:21 AM Subject: SQLLiteSpeed backups hanging when moved to TSM server on RHEL5. We're running into a problem when trying to change SQLLiteSpeed backups clients to point to new TSM servers. The old TSM servers are RHEL4 (on Intel) running TSM server 5.5.5.0 with efix for APAR IC71586. (kernel 2.6.9-89.0.11.ELsmp) The new TSM servers are RHEL5 (on Intel) running TSM server 5.5.5.0 with efix for APAR IC71586. (kernel 2.6.18-164.11.1.el5) We've made sure all the relevant values are set the same on the new servers, as on the old. (Management classes, disk storage pools, maxnummp, and everything displayed in "q opt" output on the TSM server.) The two SQLLiteSpeed clients we've used for testing are: GENERICSYSTEMNAME1 O/S: 2008 SQL version: - 10.0.4000.0 (2008 SP2) SQL litespeed version: - 5.0.2.0 TSM Client: 6.1.3.0 GENERICSYSTEMNAME2 O/S: 2003 SQL version: - 9.00.4207.00 (2005 SP3) SQL litespeed version:- 5.0.2.0 TSM Client: 6.1.3.0 We have gathered client side trace, and it appears to indicate the socket is being closed: 02/09/2011 15:07:51.192 : commtcp.cpp (2525): ANS1006I TCP/IP write error on socket = 9300, errno = 10053, reason : An established connection was aborted by the software in your host machine. 02/09/2011 15:07:51.192 : apisend.cpp (1175): Contents of verb (0x7) Data, length: 32768: 02/09/2011 15:07:51.192 : commtcp.cpp (2525): ANS1006I TCP/IP write error on socket = 4294967295, errno = 10038, reason : An operation was attempted on something that is not a socket. We have also gathered server side trace, but nothing unusual has been noted there. The symptom on the TSM server is that backup session stops making progress after a few minutes, and ultimately must be canceled to be cleaned up. We've opened a case with Tivoli support, and are working with the sysadmins of the TSM server. We're not making much progress. My hope is to jog the memory of the list and see if anyone has seen window size or other stack weirdness with RHEL 5 that is triggered by LiteSpeed backups. Thanks, [RC] U.S. BANCORP made the following annotations - Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation. -
Re: 5 out of 9 aint bad
Would probably be somewhat helpful to know what platform you are running on also, does the OS see the 9 devices or do just 5 appear available any given time? ~Rick -Original Message- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Laks, Brian Sent: Friday, March 04, 2011 10:32 AM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] 5 out of 9 aint bad I have 9 LTO-4 drives connected to our TSM server, only 5 of them work at any time after upgrading to a new fiber card. We have tried two different fiber cards (qlogic and emulex) and still only 5 drives. We have Confirmed latest drivers and firmware with IBM support. The old 2gig fiber card still works with all 9 drives, but is considerably slower than 5 drives on an 4g card. The new cards are both multi port cards, but only one port is being used. Multipath drivers are not being used. 9 drives are zoned to one port. IBM support believes it to be hardware since the old card works, so we purchased a second card of different manufacture. Now the problem exists on two fiber cards of different manufacture so I'm real reluctant to think its a hardware problem any more. Interestingly, the 5 good drives vary. I can unload the drivers and reload everything and drives that were previously unavailable work while drives that were working are then unavailable. It seems kind of random. All the dives show up in the OS, and TSMDLST show them all as well. I uninstalled old drivers and reinstalled them exactly as per IBM support instructions, and rebuilt the drive and library paths in tsm during each reload as per IBM support guidelines. Has anyone seen anything like this? I'm absolutely baffled. I'm thinking we are going to have to zone 5 drives to one port and 4 drives to the other, but the SAN admin type is reluctant since all 9 drives work with the original card. My guess is that somewhere in the drivers its smart enough to know that 9 LTO-4's to a single 4g port is silly in the first place. Maybe someone wants 4 LTO-4's so this problem just goes away :) The 5 drives work with fewer problems and better throughput than the 9 drives on the old card. Thanks for reading, Have a great day. _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ CONFIDENTIALITY NOTICE: If you have received this email in error, please immediately notify the sender by e-mail at the address shown.This email transmission may contain confidential information.This information is intended only for the use of the individual(s) or entity to whom it is intended even if addressed incorrectly. Please delete it from your files if you are not the intended recipient. Thank you for your compliance.
Deletion Backup Client Object with a FileList
We are trying to script the deletion of old RMAN backup objects (we'd use TDPOSync if it wasn't ver 2.x and didn't core dump) so we were going to delete the RMAN objects from the dsmc cmd line then RMAN would do a crosscheck to drop the orphans from the RMAN catalog. When you display the q backup of the RMAN objects they look like /adsmorc//ar.dDIATRNPA.t703456537.s4095.p1 - seems ok, except when you add those files to a list for the dsmc delete -filelise=tst dsmc returns the message Cant find object dsmc is converting the "//" to "/" ** Unsuccessful ** ANS1345E No objects on server match '/adsmorc/ar.dDIATRNPA.t701642117.s3939.p1' This diff is the object listed in the error is missing a / and a space ... In My File List /adsmorc//ar.dDIATRNPA.t703456537.s4095.p1 Whats Displayed as Not Availble /adsmorc/ar.dDIATRNPA.t701642117.s3939.p1 Has anyone dealth with this? I tried encapsulating with quoates but no luck. Thank you Charles Hart This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately.
EXPORT TOSERVER
What are the TSM server version restrictions when doing an EXPORT NODE to another server? I have a client that wants to install a TSM 6.2 server and export some data from their existing 5.3 TSM server. I've been searching and must not have the right combination on keywords, but I'm not finding any requirements or restrictions on this. It would be difficult if we had to use media for this and they only want a few nodes from their existing server. And really don't want to have to put any more effort in to the old box.like upgrades. "Life is not about waiting for the storms to pass... It's about learning how to dance in the rain." - ?? Bill Boyer
Re: 5 out of 9 aint bad
-Brian Laks wrote: - >I have 9 LTO-4 drives connected to our TSM server, only 5 of them >work at any time after upgrading to a new fiber card. > >We have tried two different fiber cards (qlogic and emulex) and still >only 5 drives. > >We have Confirmed latest drivers and firmware with IBM support. The >old 2gig fiber card still works with all 9 drives, but is >considerably slower than 5 drives on an 4g card. > >The new cards are both multi port cards, but only one port is being >used. Multipath drivers are not being used. 9 drives are zoned to >one port. > >IBM support believes it to be hardware since the old card works, so >we purchased a second card of different manufacture. Now the problem >exists on two fiber cards of different manufacture so I'm real >reluctant to think its a hardware problem any more. > >Interestingly, the 5 good drives vary. I can unload the drivers and >reload everything and drives that were previously unavailable work >while drives that were working are then unavailable. It seems kind >of random. All the dives show up in the OS, and TSMDLST show them >all as well. I uninstalled old drivers and reinstalled them exactly >as per IBM support instructions, and rebuilt the drive and library >paths in tsm during each reload as per IBM support guidelines. > >Has anyone seen anything like this? I'm absolutely baffled. I'm >thinking we are going to have to zone 5 drives to one port and 4 >drives to the other, but the SAN admin type is reluctant since all 9 >drives work with the original card. My guess is that somewhere in >the drivers its smart enough to know that 9 LTO-4's to a single 4g >port is silly in the first place. > >Maybe someone wants 4 LTO-4's so this problem just goes away :) The >5 drives work with fewer problems and better throughput than the 9 >drives on the old card. We have seen similar behavior during our last two DR tests. We run our TSM server under mainframe Linux. When we have a DR test we recreate the server at a SunGard hot site, using a mainframe, SAN, and tape library provided by SunGard. During each of the last two tests, we were able to get every tape drive working at one time or another, but never able to get all of them working at the same time. Unfortunately, we do not have a tested fix for the problem, or even a conclusive determination of the underlying cause. Some of our staff suspect that incompatibilities between the SAN configuration and the virtual machine definitions are a factor. Our Linux system runs as a guest under zVM at the hot site. Roughly speaking, zVM is the mainframe analog of VMWare (although I usually think of VMWare as the Intel analog of zVM; zVM and its predecessor products have a history going back decades further than VMWare).
Re: SQLLiteSpeed backups hanging when moved to TSM server on RHEL5.
Hi Andrew, We don't have all the details, but we appear to have a work around. When going through all the TSM servers comparing settings, the servers had no TCPWINDOWSIZE specified. All seervers were defaulted to 63k. (64512) Even though we expect TSM to request 63k tcpwindows when opening the socket, we think we're seeing larger (64k) windows in the failing sessions. (The ones earlier in this thread for example) During troubleshooting, we set the TCPWINDOSIZE to 65536 in dsmserv.opt and restarted dsmserv. But 64512 still showed up in "q opt" output. On the next test, we set TCPWINDOSIZE to "0". This tells dsmserv to use the OS setting, which was 64k. Once we made this change, we have not been able to duplicate the failure. Also, the backups are completing faster, and the amount of wait shown in the "q ses" output has gone down. I'll pass more details back to the list, once we've had a chance to do some more tuning. Thanks, [RC] From: Andrew Raibeck To: ADSM-L@VM.MARIST.EDU Date: 02/17/2011 08:25 AM Subject: Re: [ADSM-L] SQLLiteSpeed backups hanging when moved to TSM server on RHEL5. Sent by: "ADSM: Dist Stor Manager" Robert, I am not an expert on reading packet traces, but a couple of thoughts: - TSM only sets up the window size at the time the session is opened, based on the TCPWINDOWSIZE setting. What are the current TCPWINDOWSIZE settings for your TSM server and TSM clients? Note: for Windows, you should use the default (don't specify a window size); or if you must code something, code TCPWINDOWSIZE 63 (which happens to be the default value). I've seen larger sizes cause the "shrinking window" behavior, which is controlled by the network (once the session is established, TSM does not change the window size). On the TSM server, make sure not to use a TCPWINDOWSIZE greater than 63 unless you are certain that the environment is configured to support RFC 1323. - The socket is not being closed by TSM, but by "the network", probably due to the communications problems. There is probably some kind of timing problem going on, the data coming in too quickly. - On Windows 2003, check if you could be experiencing the issue described in http://www.ibm.com/support/docview.wss?uid=swg21460285, and take the corrective actions described therein. I'm not confident this is the problem, but still worth checking. Best regards, Andy Raibeck IBM Software Group Tivoli Storage Manager Client Product Development Level 3 Team Lead Internal Notes e-mail: Andrew Raibeck/Hartford/IBM@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 "ADSM: Dist Stor Manager" wrote on 2011-02-16 13:14:00: > From: Robert Clark > To: ADSM-L@vm.marist.edu > Date: 2011-02-16 13:18 > Subject: Re: SQLLiteSpeed backups hanging when moved to TSM server on RHEL5. > Sent by: "ADSM: Dist Stor Manager" > > Hi Andy, > > Yes, we did get a pcap file for one of the failed LiteSpeed > backups. This backup was sent to a different TSM server than the text > pasted earlier in this email thread. (TCPPORT on this server is 1500.) The > details of the TSM server are the same as the profile (we have several new > Linux x86_64 servers): TSM 5.5.5.0 with efix for APAR IC71586, on RHEL 5.4 > with the specific kernel mentioned previously. > > At this point in the pcap, we see a "TCP ZeroWindow", and a successful > window update back to a non-zero size: > > No. TimeSourceDestination Protocol > Info > 30778 11.755143 TSM_CLIENT TSM_SERVER TCP 33391 > > 1500 [ACK] Seq=32851627 Ack=2076 Win=65535 Len=1460 > 30779 11.755143 TSM_CLIENT TSM_SERVER TCP 33391 > > 1500 [ACK] Seq=32853087 Ack=2076 Win=65535 Len=1460 > 30780 11.794143 TSM_SERVER TSM_CLIENT TCP [TCP > ZeroWindow] 1500 > 33391 [ACK] Seq=2076 Ack=32854547 Win=0 Len=0 > 30781 11.805144 TSM_SERVER TSM_CLIENT TCP [TCP > Window Update] 1500 > 33391 [ACK] Seq=2076 Ack=32854547 Win=8760 Len=0 > 30782 11.805144 TSM_SERVER TSM_CLIENT TCP [TCP > Window Update] 1500 > 33391 [ACK] Seq=2076 Ack=32854547 Win=35040 Len=0 > 30783 11.806144 TSM_CLIENT TSM_SERVER TCP 33391 > > 1500 [ACK] Seq=32854547 Ack=2076 Win=65535 Len=1460 > 30784 11.806144 TSM_CLIENT TSM_SERVER TCP 33391 > > 1500 [ACK] Seq=32856007 Ack=2076 Win=65535 Len=1460 > > > At the end of the pcap, we see a "TCP ZeroWindow", but to the end of the > text the window stays Zero. The pcap was manually ended where the text > ends, but from talking with the folks that did the test, LiteSpeed > eventually times out at 5000 seconds, with no further backup progress. > > After reviewing the wireshark output this point it appears either network > stack state machine is getting stuck with window size zero, or TSM is > waiting for som
Re: 5 out of 9 aint bad
Hi, not that I have any clue whatsoever but the following info might help: 1- OS, I'm guessing windows or linux 2- Is the OS fully patched? 3- which version of atape/ibmtape are you using? 4- which version of TSM are you using 5- sandiscovery on or off? 6- if on windows, do you have persistent binding enabled? 7- and have you tried using not the most recent driver 8- are your san-switches up to date? On 4 mrt 2011, at 16:32, Laks, Brian wrote: > I have 9 LTO-4 drives connected to our TSM server, only 5 of them work at any > time after upgrading to a new fiber card. > > We have tried two different fiber cards (qlogic and emulex) and still only 5 > drives. > > We have Confirmed latest drivers and firmware with IBM support. The old 2gig > fiber card still works with all 9 drives, but is considerably slower than 5 > drives on an 4g card. > > The new cards are both multi port cards, but only one port is being used. > Multipath drivers are not being used. 9 drives are zoned to one port. > > IBM support believes it to be hardware since the old card works, so we > purchased a second card of different manufacture. Now the problem exists on > two fiber cards of different manufacture so I'm real reluctant to think its a > hardware problem any more. > > Interestingly, the 5 good drives vary. I can unload the drivers and reload > everything and drives that were previously unavailable work while drives that > were working are then unavailable. It seems kind of random. All the dives > show up in the OS, and TSMDLST show them all as well. I uninstalled old > drivers and reinstalled them exactly as per IBM support instructions, and > rebuilt the drive and library paths in tsm during each reload as per IBM > support guidelines. > > Has anyone seen anything like this? I'm absolutely baffled. I'm thinking we > are going to have to zone 5 drives to one port and 4 drives to the other, but > the SAN admin type is reluctant since all 9 drives work with the original > card. My guess is that somewhere in the drivers its smart enough to know > that 9 LTO-4's to a single 4g port is silly in the first place. > > Maybe someone wants 4 LTO-4's so this problem just goes away :) The 5 drives > work with fewer problems and better throughput than the 9 drives on the old > card. > > Thanks for reading, Have a great day. > > _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ > CONFIDENTIALITY NOTICE: If you have received this email in error, please > immediately notify the sender by e-mail at the address shown.This email > transmission may contain confidential information.This information is > intended only for the use of the individual(s) or entity to whom it is > intended even if addressed incorrectly. Please delete it from your files if > you are not the intended recipient. Thank you for your compliance. -- Met vriendelijke groeten/Kind Regards, Remco Post r.p...@plcs.nl +31 6 248 21 622
Re: Deletion Backup Client Object with a FileList
Hello Charles You can see RMAN objects using dsmc, but you can't delete them from there. One option is to use a select on the backups table to get the object id of the item you want to delete and use delete object to perform the deletion. I just did this with an unruly database and it works fine, but you may void your warranty as this is not supported. Another way would be to code calls to the TSM client api, making yourself look like an Oracle TDP client, and querying/deleting that way. It may not be too hard if you use the source of adsmpipe as your starting point. Regards Steve. Steven Harris TSM Admin Paraparaumu, New Zealand On 5/03/2011 8:58 AM, Hart, Charles A wrote: We are trying to script the deletion of old RMAN backup objects (we'd use TDPOSync if it wasn't ver 2.x and didn't core dump) so we were going to delete the RMAN objects from the dsmc cmd line then RMAN would do a crosscheck to drop the orphans from the RMAN catalog. When you display the q backup of the RMAN objects they look like /adsmorc//ar.dDIATRNPA.t703456537.s4095.p1 - seems ok, except when you add those files to a list for the dsmc delete -filelise=tst dsmc returns the message Cant find object dsmc is converting the "//" to "/" ** Unsuccessful ** ANS1345E No objects on server match '/adsmorc/ar.dDIATRNPA.t701642117.s3939.p1' This diff is the object listed in the error is missing a / and a space ... In My File List /adsmorc//ar.dDIATRNPA.t703456537.s4095.p1 Whats Displayed as Not Availble /adsmorc/ar.dDIATRNPA.t701642117.s3939.p1 Has anyone dealth with this? I tried encapsulating with quoates but no luck. Thank you Charles Hart This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately.
