cancel
Showing results for 
Search instead for 
Did you mean: 

Client read timeout value Function Inquiries.

SuhoKim
Level 1
Partner Accredited

Client read timeout value Function Inquiries.

Below is Veritas technical document related to Client read timeout.
Client read timeout value is summarized in about 4 levels. (15 minutes / 30 minutes / 60 minutes / increase enough value)
However, there is no detailed explanation why increasing the Client read timeout value.
https://www.veritas.com/content/support/en_US/doc/18716246-132504715-0/v40569182-132504715
https://www.veritas.com/content/support/en_US/doc/18716246-129889741-0/v40229750-129889741
https://www.veritas.com/support/en_US/doc/16226893-126541897-0/v 14758024-126541897
https://www.veritas.com/support/en_US/article.000010761

Recovery fails at about 40% of Sybase recovery.
Details confirmed the Client read timeout value error.
Based on the technical document, I set the Client read timeout with a margin of about 60 minutes.
After setting Client read timeout to 60 minutes, Sybase recovery was successfully resolved.

But customers, please contact us.
Will it be affected by Client read timeout value and storage I / O?
Client read timeout Why does it increase by more than 5 minutes?
Client read timeout Why does restoration fail in 5 minutes?
Client read timeout detailed setting value?
- Number of files capacity?
- DB capacity number?

1 REPLY 1

Systems_Team
Level 6
   VIP   

Hi SuhoKim,

You don't say what version of NetBackup you are enquiring about, so this info is from 7.7.x (I'm on 7.7.3) manuals.  There is a small section in the Admin Guide Volume I regarding client read timeout (which you have linked to).  Looking at the Sybase guide for 7.7,  the info is also fairly limited as well. 

Most of the database guides for NetBackup have a section relating to client read timeout, usually in the Troubleshooting section.  For filesystem backups, the client read timeout is rarely an issue (except on very large filesystems).  As you've already discovered, the same is not true for databases.  Many factors, including those you've mentioned come into play with a DB backup/restore, therefore there is not always a one-size-fits-all setting for the client read timeout.

I have an environment with MS-SQL, Oracle, MaxDB, Postgres, MySQL, MS-Exchange and a few others.  My setting is 3600 seconds (60 minutes) and I almost never see an issue related to timeouts.  Mine is set at the Master Server rather than the individual clients.  There is no harm in setting it high, to cope with your larger DB's.

You've linked to most of the available info, but here is a little bit more which comes from the 7.7.2 Admin Guide for MS-SQL: 

About minimizing timeout failures on large SQL Server database restores
A large SQL Server restore may fail with a Client Read Timeout error before any data has been read from the NetBackup media. This error occurs because the SQL Server may need to pre-write the database files before the restore operation begins.  The time that is required for this process is a function of certain factors: the size of the database files and the speed at which your host machine can write to disk. For example, consider that your system can perform disk writes at the rate of 60 megabytes per second and you have a 2.4 terabyte database. Then it takes at least 12 hours for SQL Server to prep the disk before the actual restore can begin. In reality, the delay may be even longer than what you calculate by as much as 20% to 40%.

The timeout problem can be resolved by increasing the NetBackup Client Read Timeout setting. Use the NetBackup Administration Console on the server to change the properties of each client that contains a database you may need to restore. The default for the Client Read Timeout setting is 300 seconds (5 minutes). If you have any clients which contain large SQL Server databases, you may need to set this value much higher.

You can eliminate file initialization during SQL Server restores. See the following topic: See “About NetBackup for SQL performance factors” on page 67.

The above shows that all the other factors you're considering, like DB size, I/O limits, etc, can and do come into play.

Hope this helps,

Steve