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:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Neil Rasmussen
Sent: 11 May 2005 21:08
To: ADSM-L AT VM.MARIST DOT 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/IBM@IBMUS
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
05/11/2005 12:49 PM
Please respond to
"ADSM: Dist Stor Manager"
To
ADSM-L AT VM.MARIST DOT 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/IBM@IBMUS Internet e-mail: storman AT us.ibm DOT com
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 AT VM.MARIST DOT 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 <rmoulton AT u.washington DOT edu> Sent by: "ADSM: Dist Stor
> > Manager" <ADSM-L AT vm.marist DOT edu>
> > 10/05/2005 20:07
> > Please respond to
> > "ADSM: Dist Stor Manager" <ADSM-L AT vm.marist DOT edu>
> >
> >
> > To
> > ADSM-L AT vm.marist DOT 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.
|
