March 16, 2004 at 1:01 pm
We have SQL Server currently set up to use a NetApp NAS for our logfile and datafile storage. However, in recent days and weeks we have had numerous failures of equipment within our data center causing our SQL Servers to behave irraticly.
Such outages result in sql log messages:
2004-03-03 19:42:32.65 spid1 LogWriter: Operating system error 121(The semaphore timeout period has expired.) encountered.
2004-03-03 19:42:32.65 spid1 Write error during log flush. Shutting down server
2004-03-03 19:42:32.84 spid1 LogWriter: Operating system error 64(The specified network name is no longer available.) encountered.
2004-03-03 19:42:32.84 spid1 Write error during log flush. Shutting down server
2004-03-03 19:42:32.84 spid52 Error: 9001, Severity: 21, State: 4
2004-03-03 19:42:32.84 spid52 The log for database 'msdb' is not available..
2004-03-03 19:42:33.60 logon Login failed for user '***************'.
2004-03-03 19:42:33.85 spid14 Database 'msdb' cannot be opened. It has been marked SUSPECT by recovery. See the SQL Server errorlog for more information.
2004-03-03 19:42:33.85 spid14 Database 'msdb' cannot be opened. It has been marked SUSPECT by recovery. See the SQL Server errorlog for more information.
2004-03-03 19:42:33.85 spid14 Database 'msdb' cannot be opened. It has been marked SUSPECT by recovery. See the SQL Server errorlog for more information.
2004-03-03 19:42:33.85 spid14 Database 'msdb' cannot be opened. It has been marked SUSPECT by recovery. See the SQL Server errorlog for more information.
2004-03-03 19:42:33.91 spid14 fcb::close-flush: Operating system error 64(The specified network name is no longer available.) encountered.
2004-03-03 19:42:33.91 spid14 fcb::close-flush: Operating system error 64(The specified network name is no longer available.) encountered.
2004-03-03 19:42:33.91 spid14 Starting up database 'msdb'.
2004-03-03 19:42:45.92 spid14 udopen: Operating system error 53(The network path was not found.) during the creation/opening of physical device \\example\datafile\msdbdata.mdf.
2004-03-03 19:42:45.93 spid14 FCB:: Open failed: Could not open device \\example\datafile\msdbdata.mdf for virtual device number (VDN) 1.
2004-03-03 19:42:45.93 spid14 Device activation error. The physical file name '\\example\datafile\msdbdata.mdf' may be incorrect.
2004-03-03 19:42:45.93 spid14 Device activation error. The physical file name '\\example\datafile\msdblog.ldf' may be incorrect.
2004-03-03 19:42:45.93 logon Login failed for user '***************'.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I realize that these outages are difficult to avoid if hardware fails, but I
would be interested in learning of other technologies that would more
gracefully handle the outage (iSCSI?), methodologies to either restart the
service until the service is restored successfully, or alert me or someone else
that the service has been terminated. Any ideas, tips or examples of your
implementation of this technology would be appreciated.
Thanks...
Nathan
March 19, 2004 at 8:00 am
This was removed by the editor as SPAM
March 23, 2004 at 3:29 am
We are experiencing the exact same problem with our SQL Server 2k backing onto a NetApp filer
Whenever we reboot our SQL Server box (Windows 2003, SQL 2k with SP3a), the databases which are stored on the Netapp box are marked as suspect
If we re-attach the databases, all is restored, but this is not an acceptable solution for us, we would much prefer an option to do this automatically
Other than writing scripts to automatically re-attach the databases, are there any other options available, and can SQL Server Agent alert on suspect databases.
In regards to changing the timeout value for SQL Server, where is this value kept, and how can it be edited?
Any help would be much appreciated,
Regards,
Chris
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply