DBCC CheckDB遇到a database snapshot could not be created

在备份一个客户的数据库时(数据库版本为SQL 2005 Express版本),做DBCC CHECKDB时遇到了下面错误信息:

dbcc checkdb(‘DB_NAME‘);

消息 5030,级别 16,状态 12,第 1 行

The database could not be exclusively locked to perform the operation.

消息 7926,级别 16,状态 1,第 1 行

Check statement aborted. The database could not be checked as a database snapshot could not be created and the database or table could not be locked. See Books Online for details of when this behavior is expected and what workarounds exist. Also see previous errors for more details.

一般导致创建数据库快照失败的原因有两个:

1:数据库有只读的文件组。

2:没有支持稀疏文件(Parse file)的文件系统

英文原文如下

No Parse file support by the file system.

A. Parse file is not supported in FAT32 check the file system of the datafiles. If you use FAT32   use DBCC CheckDB with Tablock Option

B. To get the volume information of file system in which we have the datafiles we use  !GetVolumeInformation API.

This API would fail if SQLServer startup account do not have full permission on Volume in which the data file is located.

Grant full permission for the startup account of SQLServer on the root volume of all the datafies.

我检查了数据库发现没有设定为只读的文件组,这台PC是Window Xp,文件系统系统确实为FAT32,使用DBCC CHECKDB(‘db_name‘) WITH  TABLOCK 依然报错,其实当文件系统为FAT32时,DBCC CHECKDB只能在单用户模式才能成功。所以我在该数据库做DBCC CHECKDB时会遇到这个错误,为此,我特意在测试环境测试了一下,如下所示:

测试FAT32文件系统下的DBCC CHECKDB问题:

1:新建的数据库TEST的文件位于FAT32磁盘上。如果没有会话访问数据库TEST(相当于单用户模式),DBCC CHECKDB成功,如果在新开一个窗口访问TEST,然后再另外一个窗口执行DBCC CHECKDB(‘TEST‘)则会报如下错误,另外DBCC CHECKDB(‘db_name‘) WITH  TABLOCK也需要在单用户模式下才能成功。

参考资料:

http://blogs.msdn.com/b/karthick_pk/archive/2010/03/07/dbcc-checkdb-fails-the-database-could-not-be-checked-as-a-database-snapshot-could-not-be-created-and-the-database-or-table-could-not-be-locked.aspx

https://support.microsoft.com/en-us/kb/928518

https://ask.sqlservercentral.com/questions/51856/dbcc-checkdb-with-fat32-file-system.html

时间: 2024-12-11 14:41:03

DBCC CheckDB遇到a database snapshot could not be created的相关文章

DBCC CHECKDB用法 手工修复数据库

快速修复DBCC CHECKDB ('数据库名', REPAIR_FAST)      重建索引并修复DBCC CHECKDB ('数据库名', REPAIR_REBUILD)如果必要允许丢失数据修复DBCC CHECKDB ('数据库名'', REPAIR_ALLOW_DATA_LOSS) 如果出现错误:未处理修复语句.数据库需处于单用户模式下. 可以先启用单用户模式,方法如下执行存储过程: Use mastergosp_dboption 数据库名, single, true --更改成单用户

DBCC CheckDB command 用法

DBCC CheckDB command 的使用分为三步 1,verify AUTO_UPDATE_STATISTICS_ASYNC option 关闭 --verify the AUTO_UPDATE_STATISTICS_ASYNC option is set to OFF select db.name, db.is_auto_update_stats_async_on from sys.databases db 2 设置DB 处于single user 访问模式 --set single

MS SqlServer DBCC CHECKDB 数据库/表修复

MS Sql Server 提供了很多数据库修复的命令,当数据库质疑或是有的无法完成读取时可以尝试这些修复命令. 1. DBCC CHECKDB  重启服务器后,在没有进行任何操作的情况下,在SQL查询分析器中执行以下SQL进行数据库的修复,修复数据库存在的一致性错误与分配错误. use master declare @databasename varchar(255) set @databasename='需要修复的数据库实体的名称' exec sp_dboption @databasenam

MS Sql Server 数据库或表修复(DBCC CHECKDB)

MS Sql Server 提供了很多数据库修复的命令,当数据库质疑或是有的无法完成读取时可以尝试这些修复命令.  1. DBCC CHECKDB  重启服务器后,在没有进行任何操作的情况下,在SQL查询分析器中执行以下SQL进行数据库的修复,修复数据库存在的一致性错误与分配错误. use master declare @databasename varchar(255) set @databasename='需要修复的数据库实体的名称' exec sp_dboption @databasena

SQL Server 修复数据库 相关 脚本 之 DBCC CHECKDB 用法 来自同事分享

DBCC CHECKDB 用法详解, 手工修复数据库 1. 快速修复 DBCC CHECKDB ('数据库名',REPAIR_FAST) 2.重建索引并修复 DBCC CHECKDB ('数据库名',REPAIR_REBUILD) 3.如果必要允许丢失数据库修复 DBCC CHECKDB ('数据库名',REPAIR_ALLOW_DATA_LOSS) 如果出现错误: 未处理修复语句,数据库需要处于单用户模式下. 可以先启用单用户模式, 方法如下执行存储过程: Use master go sp_d

SQL Server ->> Database Snapshot(数据块快照)

Comming soon!!! 参考文献: View the Size of the Sparse File of a Database Snapshot 数据库快照 (SQL Server) 创建数据库快照 (Transact-SQL)

DBCC CHECKDB

DBCC CHECKDB 算是管理员们最常用的命令也是必须要知道的命令了.定期的检查及问题的修复都是比较重要的!!下面介绍一下 DBCC CHECKDB 的一些基本用法. DBCC CHECKDB 完成两项任务: 检查数据库里有没有损坏发生. 尽力修复数据库损坏,使数据库能够被重新正常访问. DBCC CHECK 做了些什么: 检查一些关键的系统表 对数据库运行DBCC CHECKALLOC 对数据库运行DBCC CHECKCATALOG 验证数据库中每个索引视图的内容 验证数据库中servic

Database snapshot

Database Snapshot 是数据库某一个时间点的一个read-only副本,这个read-only副本占用的存储空间不一定很大.如果Source DB的某一个page修改了,那么在这个Page被修改之前,数据库会先copy一份数据,存放在Database Snapshot 的数据库Files中,即保留这个page的copy.SourceDB中的数据会修改,但是Database Snapshot的数据不会修改. The actual space needed for each snaps

SQL Server 影响dbcc checkdb的 8 种因素

第一种: 数据库的大小. 第二种: IO系统的速度. 第三种: 当前CPU的负荷. 第四种: 当前数据库的并发修改量.因为并发修改量越大维护数据库快照的成本就越高,dbcc 的过程中要创建快照,所以. 第五种: 存放tempdb数据库硬盘的速度.dbcc 的过程中会有一些中间结果,而这些结果全放在内存里是不合适也是不可能的.所以有 用到tempdb的空间. 第六种: 数据库中对象的类型,不同类型的对象检查时要的时间也是不一样的.费时的有非聚集索引,计算列,off_row_lob,Server_b