May 8, 2015 at 10:56 am
We run DBCC CHECKDB as a job in the evening when there is less activities. All the jobs are run with a domain account that have local administrator rights. Recently, CHECKDB suddenly start to fail for certain databases (whether the db is small or large), however, errorlog does not show database is in suspected mode or any other errors. I tried to google the error (see below) we are having but just can't find any matches. All the errors have same pattern as below. Have you seen this? Is there a fix for this?
I've also read a bunch of documents that CHECKDB creates snapshots in order to do it's works. At one point, I thought there is not enough disk space. But it can't be because we have plenty of disk space.
FYI, we use Windows Server 2012 DataCenter (64-bit) and SQL Server 2012 Enterprise Edition (64-bit). All these run under VMWare.
Here is the error I'm talking about:
FCB::Open failed: Could not open file g:\SQLData\mhpprodsrv01\EXP_PROD_WEBFORMS.NDF:MSSQL_DBCC10 for file number 3. OS error: 32(The process cannot access the file because it is being used by another process.).[/b]
Thanks in advance,
Jimmy
May 8, 2015 at 11:49 am
IIRC there was a recent bug fix for a dbcc checkdb snapshot error. Do a search for that and see if it applies to your issue.
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
May 8, 2015 at 12:43 pm
I couldn't find it and that's why I'm asking here.
May 8, 2015 at 12:56 pm
jimmycjen (5/8/2015)
We run DBCC CHECKDB as a job in the evening when there is less activities. All the jobs are run with a domain account that have local administrator rights. Recently, CHECKDB suddenly start to fail for certain databases (whether the db is small or large), however, errorlog does not show database is in suspected mode or any other errors. I tried to google the error (see below) we are having but just can't find any matches. All the errors have same pattern as below. Have you seen this? Is there a fix for this?I've also read a bunch of documents that CHECKDB creates snapshots in order to do it's works. At one point, I thought there is not enough disk space. But it can't be because we have plenty of disk space.
FYI, we use Windows Server 2012 DataCenter (64-bit) and SQL Server 2012 Enterprise Edition (64-bit). All these run under VMWare.
Here is the error I'm talking about:
FCB::Open failed: Could not open file g:\SQLData\mhpprodsrv01\EXP_PROD_WEBFORMS.NDF:MSSQL_DBCC10 for file number 3. OS error: 32(The process cannot access the file because it is being used by another process.).[/b]
Thanks in advance,
Jimmy
Quick questions, what is the build (SELECT @@VERSION)? What are the servers specifications (mem/drives/free space etc.)? Tempdb configs? In fact tell us everything you can apart from the colour of your hair before the problem (we know that by now it's probably gray:-D)
😎
BTW, also the ESX version etc.
May 8, 2015 at 1:39 pm
You got it right on my hair color 🙂
Version:
Microsoft SQL Server 2012 (SP1) - 11.0.3381.0 (X64)
Aug 23 2013 20:08:13
Copyright (c) Microsoft Corporation
Enterprise Edition (64-bit) on Windows NT 6.2 <X64> (Build 9200: ) (Hypervisor)
Memory: 98304 (MB)
Processors: 4
Drive: data drive is allocated 1TB and has 248GB of free space. Log drive is allocated 250GB and has 177GB of free space. Both drives are actually from the same LUN which is carved out from our SAN.
Tempdb: on the same drive as data drive. 15GB reserved and only 125MB are used
ESX version 5.5
May 8, 2015 at 2:41 pm
Another piece of info I'm providing: recently we applied Windows Update to our secondary node (we have Availability Group in a clustered environment) and then applied the same Windows Update to the primary node. Is it possible sqlservr.exe process from the previous owning node has not released the handles to the database files? See item#5 bullet#3 of: https://support.microsoft.com/en-us/kb/2015754 -- but how do we know if handles are released or not?
The process we do the Windows Updates goes like this:
1. apply Windows update on node2 (secondary node) and reboot.
2. failover from node1 to node2. Now node2 becomes the primary.
3. apply Windows update on node1 and reboot.
4. failover from node2 to node1. Now node1 is back as primary.
Is it possible during the failover that handles (to the database files) are not released as mentioned in KB2015754? If this is possible (then it's a bug!), how can we release the handles manually?
Jimmy
May 8, 2015 at 3:00 pm
BTW, our cluster is Windows Cluster and not SQL Cluster.
May 8, 2015 at 3:02 pm
1) There are no shared files on AG - they exist on local storage on separate servers, at least to my knowledge (and unless you are combining a SQL Server Failover Cluster Instance and AGs, and I sure wouldn't want to be there!).
2) you can use process explorer (procexp.exe) from the awesome sysinternals collection to see what processes have what files/volumes open.
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
May 8, 2015 at 3:40 pm
1) I already know.
2) I haven't use this tool before.
Meanwhile I welcome others to comment that had the same errors as I have.
May 9, 2015 at 5:02 am
One more thing, can you run DBCC CheckDB('[database name]') WITH NO_INFOMSGS, ALL_ERRORMSGS and post the full unedited output?
😎
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply