Neil, Rob et al, Similarly with MSSQL, particularly during restores of large databases where SQL Server (completely aside from TDPS) goes away and formats its database files leaving the TDPS session open and idle - I tend to recommend an hour (3600) for COMMTIMEOUT for this reason.
Shame we can't have a 'global' COMMTIMEOUT setting which can be overridden by a node, group or domain level COMMTIMEOUT setting - that way I could have all of my 'TDPS_DOMAIN' nodes with a longer timeout that my normal BA client backups... Rgds, David McClelland Shared Infrastructure Development Reuters 85 Fleet Street London EC4P 4AJ -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Neil Rasmussen Sent: 11 May 2005 21:08 To: ADSM-L@VM.MARIST.EDU Subject: Re: ANR0481W and COMMTIMEOUT setting I noticed that the node in your example is a TDP SQL node (if I am reading correctly). It is not uncommon for nodes that are TDPs to require longer timeouts. What happens is that databases will start up a session with the TSM Server and then will go off and collect the information to send - depending on the amount of processing that occurs, which quite often correlates to the size of the database, can take a *very* long time. For instance, I know that with Oracle/TDP Oracle during an incremental of larger databases, Oracle may spend a long time trying to locate changed blocks. I have seen these times take longer than 30 minutes (although not common). The short of it is that you may need a time out of 1800+ to accomodate these databases. Regards, Neil Rasmussen Software Development Data Protection for Oracle Andrew Raibeck/Tucson/[EMAIL PROTECTED] Sent by: "ADSM: Dist Stor Manager" <ADSM-L@VM.MARIST.EDU> 05/11/2005 12:49 PM Please respond to "ADSM: Dist Stor Manager" To ADSM-L@VM.MARIST.EDU cc Subject Re: ANR0481W and COMMTIMEOUT setting 1800 seconds is a *very* long commtimeout setting. Assuming the clients in question are on relatively fast networks (e.g., not dial-up), I would tend to suspect that a problem in the network (though I could not tell you what that problem is), especially if it continues to occur. Regards, Andy Andy Raibeck IBM Software Group Tivoli Storage Manager Client Development Internal Notes e-mail: Andrew Raibeck/Tucson/[EMAIL PROTECTED] Internet e-mail: [EMAIL PROTECTED] 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" <ADSM-L@VM.MARIST.EDU> wrote on 2005-05-11 12:29:27: > Thanks John, appreciate the info. > > John Naylor wrote, on 05/11/05 01:42: > > Robert, > > My commtimeout is set 3600 with no problems Where you are seeing > > hits where you had none before you may want to consider/alleviate > > the cause per the description in Admin Ref > > > > Specifies how long the server waits for an expected client message during > > an > > operation that causes a database update. If the length of time > > exceeds this time-out, the server ends the session with the client. > > You may want to increase the > > time-out > > value to prevent clients from timing out. Clients may time out if there is > > a heavy > > network load in your environment or they are backing up large files > > John > > > > > > > > > > > > robert moulton <[EMAIL PROTECTED]> Sent by: "ADSM: Dist Stor > > Manager" <ADSM-L@vm.marist.edu> > > 10/05/2005 20:07 > > Please respond to > > "ADSM: Dist Stor Manager" <ADSM-L@vm.marist.edu> > > > > > > To > > ADSM-L@vm.marist.edu > > cc > > > > Subject > > ANR0481W and COMMTIMEOUT setting > > > > > > > > > > > > > > Greetings ADSM List - Seeking your advice and/or a nudge toward applicable > > documentation ... > > > > TSM Version 5, Release 2, Level 4.0 > > AIX 5.2 > > > > We're seeing an increasing number of these ANR0481W messages in > > server > > logs: > > > > ANR0481W Session 111138 for node M_SQLSAN01_CL_U (WinNT) terminated > > - client did not respond within 1800 seconds. > > > > As you can see our COMMTIMEOUT setting is 1800 seconds. Are there risks > > involved with boosting it even higher? > > > > Thanks in advance for your advice. > > > > Robert Moulton > > University of Washington > > Computing & Communications > > > > > > > > ******************************************************************** > > ** The information in this E-Mail is confidential and may be legally > > privileged. It may not represent the views of Scottish and Southern > > Energy Group. > > It is intended solely for the addressees. Access to this E-Mail by > > anyone else is unauthorised. If you are not the intended recipient, > > any disclosure, copying, distribution or any action taken or omitted > > to be taken in reliance on it, is prohibited and may be unlawful. > > Any unauthorised recipient should advise the sender immediately of > > the error in transmission. Unless specifically stated otherwise, > > this email (or any attachments to it) is not an offer capable of > > acceptance or acceptance of an offer and it does not form part of a > > binding contractual agreement. > > > > Scottish Hydro-Electric, Southern Electric, SWALEC, S+S and SSE > > Power Distribution are trading names of the Scottish and Southern > Energy Group. > > ******************************************************************** > > ** ----------------------------------------------------------------- Visit our Internet site at http://www.reuters.com To find out more about Reuters Products and Services visit http://www.reuters.com/productinfo Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.
