Suspect Database - OS error 32

Question

Suspect Database - OS error 32

Shirley McArdle

Valued Member

Points: 70
More actions
March 28, 2005 at 3:32 pm

#87880

I am having a problem with a database going suspect.
After my Veritas backups complete, I automatically execute a script to start sql server.
During startup of the database I receive the following errors;
udopen: operating system error 32 (the process cannot access the file because it is being used by another process) durin ghte creation/opening of physical device e:\....................mdf
FCB Open failed; Could not open device e:\.................mdf for virtuaol device number (VDN) 1.
Device activation error. The physical file name 'E:\............mdf' may be incorrect

According to the logs the backups have completed and there is no anti virus software executing.
What else could have the database locked? It just started doing it this a couple of weeks ago.

Viewing 12 posts - 1 through 11 (of 11 total)

You must be logged in to reply to this topic. Login to reply

ram4tech Hall of Fame Points: 3140 More actions · Answer 1

A database gets the suspect status when the database runs out of disk space on the drive where the data files reside.

You can try to reset the status and create some disk space. Here is the topic on BOL that would help to solve your problem "Resetting the Suspect Status"

Shirley McArdle Valued Member Points: 70 More actions · Answer 2

Shirley McArdle

Valued Member

Points: 70

March 28, 2005 at 3:39 pm

#549212

I have plenty of disk space. 2TB

Shirley McArdle Valued Member Points: 70 More actions · Answer 3

The reason the database is going suspect is that .......

"one or more database files are not available."

What I don't know is why? How can I determine what is locking the database.

The veritas logs show that the database backup completed successfully and then the script to start sql server was started, then the database failed because to open because it was in use.

I have checked my antivirus job and it doesn't show that it was executing at the time.

What else can cause this problem?

Ford Fairlane SSCertifiable Points: 7664 More actions · Answer 4

Is it possible one of your datafiles or log file has reached its max size ?

If so :

Execute sp_resetstatus.
Use ALTER DATABASE to add a data file or log file to the database.
Stop and restart SQL Server.
With the extra space provided by the new data file or log file, SQL Server should be able to complete recovery of the database.
Free disk space and rerun recovery.

Good luck.

Hope this helps...

Ford Fairlane
Rock and Roll Detective

athurgar SSCrazy Points: 2816 More actions · Answer 5

Is it possible that the Veritas backup is still doing some cleanup activity - writing logs or doing verification. Can you delay the start of SQL by a minute or two?

Johnny Doyle Right there with Babe Points: 745 More actions · Answer 6

Do you have the 'auto close' option set for your databases. Try taking this option off, and see if you still get suspsect databases.

chad heffner Newbie Points: 5 More actions · Answer 7

Check if your virus scanning software if checking the file at the time the db goes suspect.

Rudyx - the Doctor SSC-Forever Points: 43695 More actions · Answer 8

We have run into this issue with other applications after Veritas backups (not once on SQL Server). Occasionally Veritas does not 'clean up' after itself leaving 'file handles' on files it has touched for backup. To find out the offending process and files go to Winterls and download the 'Winternals Process Viewer' (it's free). Then you'll be able to determine which file is still held by a Veritas 'file handle' and release it. Once you have determined that Veritas is the culprit, I'd check to make sure your backup software is uo to date and inquire about a patch.

We do not run into this issue on SQL Server because the database server is always up. We backup the databases to disk and have Veritas pick things up later. Just curious as to why you are backing up everything ? We backup all local disk drives, the registry and then we exclude the following:

pagefile.sys

*.mdf files

*.ndf files

*.ldf files

FTDATA directory

REPLDATA directory

This has made outr Backup Admin very happy for a number of reasions:

1) no longer gets errors onopen files.

2) the backup set size is smaller.

3) the backup execution time has gona down.

RegardsRudy KomacsarSenior Database Administrator"Ave Caesar! - Morituri te salutamus."

Shirley McArdle Valued Member Points: 70 More actions · Answer 9

Thanks for all of the comments. I will check into it.

I am inclined to believe it has something to do with Veritas and the database.

Because I have two other servers also using Veritas that are not having the same problem.

sswords SSCrazy Eights Points: 8207 More actions · Answer 10

We've had similar problems using another product (Legato) where for whatever reason, the backup process gets hung. Like Rudy, we don't shut down SQL Server or native backups during the tape backup process, but lockups can still occur. What has worked for us in the past is either stopping the backup process on the server or restarting the server after which backups continue normally. I'd also second the recommendation of using a process or file monitor program to discover what's keeping the file open. Hope this helps.

My hovercraft is full of eels.

PGangwar SSC Enthusiast Points: 109 More actions · Answer 11

1. I checked disk space everything was good.

2. Executed following procedure

use master

go

exec sp_resetstatus DAPS

=======Output=========

Prior to updating sysdatabases entry for database 'DAPS', mode = 0 and status = 1077936153 (status suspect_bit = 0).

No row in sysdatabases was updated because mode and status are already correctly reset. No error and no changes made.

=================

3. I just took database offline and then online again, it works for me.