What did you have your multiplexing set at ??? If you are only using a single tape drive you will want to really experiment with setting the multiplexing up from one. AND I'd make sure and use some form of compression, either RL_COMPRESSION or straight client compression, once again, experiment. How big is your data base ??? If I were you I'd really look into more drives if your DB is very big. I never count on a single session with the TSM server to move more than about 2 GB/hr of data, now if you use client compression that 2 GB could be as much as 7.6 GB of actual db space... the we get our rates by cranking up multiple concurrent sessions, up to 20-25 to move 40+ GB/hr of compressed data or 152 GB/hr of DB space. Well, that was with the old backint 2.4.25.6, currently I'm working with IBM on a little slow down problem we are seeing with the 3.2.0.11 code... it just refuses to perform as well as the old code :-(
Dwight E. Cook Software Application Engineer III Science Applications International Corporation 509 S. Boston Ave. Suite 220 Tulsa, Oklahoma 74103-4606 Office (918) 732-7109 -----Original Message----- From: Eric Winters [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 09, 2002 3:34 AM To: [EMAIL PROTECTED] Subject: Slow (1 MB a minute) brrestore from LTO Can anyone help speed up my brrestore? TSM Server 4.2.1.7 on AIX 4.3 The SAP server backed up using TDP for R/3 3.2.0.1 over a Gigabit network to an AIX 4.3 TSM Server with single scsi LTO tape drive with a throughput of about 1 GB a minute. (The SAP server and the TSM Server are both on AIX 4.3). I'm now restoring in a DR test. The TSM Server has been installed on the same system as the SAP Server. The TSM database restored successfully and the filesystems were rapidly restored too. The COMMMETHOD was set to TCPIP. We are now trying to perform a brrestore. It works but is very slow, at approx 1-2 MB a minute. I've upgraded the TDP to 3.2.0.12 but this made no difference. I've changed the commmethod to sharedmem but it's made no difference - indeed the session shown in 'q ses' shows a commethod of TCPIP so perhaps this didn't kick in after all. (although commmethod SHAREDMEM is present in dsmserv.opt - and system restarted with this). Both the backup client and TDP for R/3 use the same dsm.sys file. The performance of the LTO drive was fine for restoring filesystems. It's just the brrestore performance that's shocking. It would take several months to restore at this rate. What can it be? I backed up originally with just one session and I'm restoring with just one session. There is only one session displayed in 'q ses' and it's running - but so so slow. The dsm.sys is very ordinary but here it is for good measure. SErvername tsm1 COMMmethod sharedmem TCPServeraddress 10.1.1.9 passwordaccess generate inclexcl /usr/tivoli/tsm/client/ba/bin/dsm.inx schedlogname /usr/tivoli/tsm/client/ba/bin/dsmsched.log schedlogretention 7 passworddir /usr/tivoli/tsm/client/ba/bin I'd be very pleased to hear of any ideas to get a reasonable restore rate - at this rate it will apparently finish in January 2003! Thanks, Eric Winters Sydney Australia
