Charles, there's a huge variety of possible reasons for poor performance, unfortunately.
You can try a few things to encircle the problem closer: - Be sure you don't use the option "quiet" in dsm.opt Now you can see which file gets backed up at which time. Do you have poor performance from start to end or is there a huge gap of inactivity? - Is your network interface configured as it should? Check for mixed fullduplex/halfduplex environments. We had cases where it worked fine with numerous machines and one linux client sent 40kb/s instead of 7mb/s until we found the misconfigured NIC. - extend the summary information your client creates after session completion. Put the option "traceflags instr_client_detail" into your option file. In addition to the summary information you usually get after backup you'll find something like this: ------------------------------------------------------------------ Final Detailed Instrumentation statistics Elapsed time: 1502.420 sec Section Total Time(sec) Average Time(msec) Frequency used ------------------------------------------------------------------ Client Setup 15.081 15081.0 1 Process Dirs 331.908 191.4 1734 Solve Tree 0.000 0.0 0 Compute 1.021 0.0 76446 Transaction 43.535 0.2 244347 BeginTxn Verb 0.000 0.0 269 File I/O 733.274 8.2 89169 Compression 0.000 0.0 0 Encryption 0.000 0.0 0 Delta 0.000 0.0 0 Data Verb 474.198 6.2 76446 Confirm Verb 0.251 16.7 15 EndTxn Verb 195.729 727.6 269 Client Cleanup 1.612 1612.0 1 ------------------------------------------------------------------ >From this information you can get an idea where most time gets wasted. Compare the output with that of other machines (that perform better). Good luck! Best regards, Michael Charles Anderson wrote: > > Folks, > > I'm going to try and make what's going on as clear as possible, if I don't, please >ask for elaboration. > > I hope one or more of y'all can lend me some insight as to exactly what is going on >here. I have a node ( NT4.SP6, TSM client 4.2.1 ) which begins backing up during >it's scheduled backup window ( which is 2 hours long ), but doesn't finish until 6 >hours later. This node seems to lie dormant from about 15minutes into its scheduled >startup window until 5 hours later at which point it successfully finishes its daily >incremental. So, this being the case the command "q event * * begindate=-1 >begintime=17:30 enddate=today endtime=08:00 " ( our scheduled backups run from 17:30 >to about 05:00 ) yields a status of either "Failed" or "<?>". But a "q filespace >PROBLEMNODE f=d" Says that the "Last Backup Completion Date/Time : " was this morning. > > Has anyone seen this where the event log and "q filespace NODE f=d" conflict? Any >ideas about this at all? > > Here's some more info you may find helpful. > > TSM Server = Solaris 2.6, TSM Server Version 4.1.4 > > Client Node = NT4 SP6, TSM Client 4.2.1 ( FYI, the node is running Oracle, but we >don't have TDP for Oracle. The machine is making DB Dumps ( from the way that I >understand it ), the dsm.opt/sys file has excluded Oracle's Data Directories, but it >is supposed to have the Dump Files included ). > > The Actlog doesn't have much useful info, it shows the Scheduled Session start, And >then starts the ANE495?I Messsages about how many files backed up, total size of the >backup, etc. > > Our Maxsessions are set at 50, and the maxschedsessions is 25. We have 20 NT nodes >during the aforementioned scheduled startup window, but I haven't seen anything in >the actlog about the maximum number of possible sessions being reached. > > What we've done so far to try and rectify the situation : > 1) Upgraded the TSM client from 4.1.2 to 4.2.1 > 2) Stopped some of the tasks running from the Task Scheduler on the NT machine ( it >was doing an "Expire Blocks" every 15minutes, I hope that means something to you >Oracle folks ) it was my belief at first that this was the process on the box that >was causing the backup to fail/ lie dormant for 5 hours. > 3) Increased the backup window to 2 hours from 1 hour. ( it's now from 23:00 to >01:00 ) > > Sorry to dump all that on you, I'm about to call support and they're usually pretty >good, but the folks on the list have that "real world" experience, you know? > > Thanks a million, > Ed Anderson -- Michael Bartl mailto:[EMAIL PROTECTED] Office of Technology, IT Germany/Austria Tel: +49-89-92699-806 Cable & Wireless Deutschland GmbH. Fax: +49-89-92699-302 Landsberger Str. 155, D-80687 Muenchen http://www.cw.com/de
