|
|
|
SSC-Enthusiastic
      
Group: General Forum Members
Last Login: Today @ 7:38 AM
Points: 146,
Visits: 552
|
|
Testing and Production db's have lost connection to the translog 2 days in a row now. Today, my prod db was marked suspect after the issue - SCARY. The other db's did not lose connection. Possibly because there was no activity at that moment.
No errors in SQL log, only windows. Server Resources were not necessarily be hammered. I will be scouring the web, but wanted to reach out to all of you as well. See info and errors below.
Plenty of available drive space for Log, db, and tempdb partitions. 144gb RAM SQL Server 2008 SP1; Enterprise (64-bit) OS: Win Server 2008 R2 Enterprise
Win app logs: error1- LogWriter: Operating system error 21(The device is not ready.) encountered. error2 - The log for database (testing) is not available. Check the event log for related error messages. Resolve any errors and restart the database.
info mess3- Database was shutdown due to error 9001 in routine 'XdesRMFull::Commit'. Restart for non-snapshot databases will be attempted after all connections to the database are aborted.
2 seconds later prod db goes down: error4- The log for database is not available. Check the event log for related error messages. Resolve any errors and restart the database.
error5 - During undoing of a logged operation in database, an error occurred at log record ID (86400:39070:17). Typically, the specific failure is logged previously as an error in the Windows Event Log service. Restore the database or file from a backup, or repair the database.
error6 - fcb::close-flush: Operating system error (null) encountered.
error7 - An error occurred during recovery, preventing the database (PRODUCTION ) from restarting. Diagnose the recovery errors and fix them, or restore from a known good backup. If errors are not corrected or expected, contact Technical Support.
info mess8 -CHECKDB for database finished without errors on 2011-03-14 12:12:41.503 (local time). This is an informational message only; no user action is required.
|
|
|
|
|
SSC-Dedicated
           
Group: General Forum Members
Last Login: Today @ 3:28 PM
Points: 37,730,
Visits: 29,996
|
|
Looks like a hardware issue. Server is losing contact with the underlying drives.
SAN storage?
Gail Shaw Microsoft Certified Master: SQL Server 2008, MVP SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
We walk in the dark places no others will enter We stand on the bridge and no one may pass
|
|
|
|
|
SSC-Dedicated
           
Group: General Forum Members
Last Login: Today @ 3:28 PM
Points: 37,730,
Visits: 29,996
|
|
p.s. If I were you, I'd be doing checkDB more often than once in 2 months.
Gail Shaw Microsoft Certified Master: SQL Server 2008, MVP SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
We walk in the dark places no others will enter We stand on the bridge and no one may pass
|
|
|
|
|
SSC-Enthusiastic
      
Group: General Forum Members
Last Login: Today @ 7:38 AM
Points: 146,
Visits: 552
|
|
Yes, SAN storage. Just found out the tempdb partition and translog partition share the same physical drive. I can move the tempdb file to the larger database drive immediately - well late tonight.
Could this disk contention be causing the hardware error?
It's been running this way for a while now, but being hit harder lately. FYI - I will schedule CHECKDB's weekly, maybe daily now.
|
|
|
|
|
SSC-Enthusiastic
      
Group: General Forum Members
Last Login: Today @ 7:38 AM
Points: 146,
Visits: 552
|
|
Just stumbled into a VERY similar thread on this site: http://www.sqlservercentral.com/Forums/Topic355924-5-1.aspx#bm482958
|
|
|
|
|
SSC-Dedicated
           
Group: General Forum Members
Last Login: Today @ 3:28 PM
Points: 37,730,
Visits: 29,996
|
|
I wouldn't say disk contention (but I'm not a SAN expert). Check the physical connections, switch, anything between the server and SAN. From the Windows error log, the OS can't see the disk at points.
Moving the DB will help, but you still need to find the root cause.
Gail Shaw Microsoft Certified Master: SQL Server 2008, MVP SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
We walk in the dark places no others will enter We stand on the bridge and no one may pass
|
|
|
|
|
Grasshopper
      
Group: General Forum Members
Last Login: Tuesday, January 29, 2013 12:57 PM
Points: 18,
Visits: 97
|
|
FYI: There is a VMWare issue that is associated with getting this error having to do with using the Paravirtual SCSI drivers. See the following KB: [url=http://support.microsoft.com/kb/2519834][/url]
Greg
|
|
|
|
|
SSC-Enthusiastic
      
Group: General Forum Members
Last Login: Today @ 7:38 AM
Points: 146,
Visits: 552
|
|
Greg Swanson (6/1/2011) FYI: There is a VMWare issue that is associated with getting this error having to do with using the Paravirtual SCSI drivers. See the following KB: [url=http://support.microsoft.com/kb/2519834][/url]
Greg
Not running WMWare on that system, but thanks for the info/update!
|
|
|
|
|
Grasshopper
      
Group: General Forum Members
Last Login: Yesterday @ 10:30 PM
Points: 17,
Visits: 279
|
|
Hi I know this is an old post but I had the same problem and we run a SAN an VMware so I thought it's related to that but then I found another post telling me to bring the db offline and online again and that actually worked. Very simple in the end.
|
|
|
|
|
Forum Newbie
      
Group: General Forum Members
Last Login: Tuesday, March 19, 2013 1:51 AM
Points: 1,
Visits: 0
|
|
Restart the sql service, and it will start working. The same thing happened for me also. and i did the same.. Now its working fine.
|
|
|
|