赞
踩
官网:
-
- Exec sp_spaceused;
-
-
- ALTER DATABASE HKMNewsDB MODIFY FILE ( NAME = N'HKMNewsDB', SIZE = 310390MB );
-
- DBCC SHRINKDATABASE(tempdb,1) ;
- DBCC SHRINKFILE(1,TRUNCATEONLY);
- DBCC SHRINKFILE(1,238238);
-
-
- select * from sys.database_files;
-
-
- SELECT name ,size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS int)/128.0 AS AvailableSpaceInMB
- FROM sys.database_files;

SQLServer 数据库通常都不建议进行 SHRINKFILE 操作,因为 SHRINKFILE 不当会造成一定的性能问题。
但是当进行了某些操作 ( 例如某个超大的日志类型表转成分区表切换了数据文件 ) ,数据库某个文件组中的剩余空间占了整个磁盘的很大一部分,而且磁盘空间已经吃紧的情况下,你也许会考虑收缩一下某个数据文件。
收缩数据文件时,可以每次收缩一点点(例如每次 5GB )来进行。
然而博主最近对某个数据库进行数据库收缩时碰到了标题所示的困扰。在 DBCC SHRINKFILE (db_name , target_size) 执行了几次之后。
DBCC SHRINKFILE (db_name , target_size)
莫名出现了如下错误:
不能收缩 ID 为 6 的数据库中 ID 为 1 的文件,因为它正由其他进程收缩或为空。
据网上的经验,备份之后仍然不变,重启也无效,尝试重建某些表的索引,也无效。
但博主在尝试将数据库文件增加 10MB ,然后再次收缩数据库的时候这个错误消失了。
ALTER DATABASE db_name MODIFY FILE ( NAME = file_name, SIZE = target_size )
后来从官方社区找到了答案:应该是我在进行 DBCC SHRINKFILE 的时候正好同时进行了备份操作(定时日志备份)。
官方给的解决方法就是将要收缩的数据文件增加一点点,哪怕 1MB 。
参考相关文档:
https://msdn.microsoft.com/zh-cn/library/ms189493.aspx
SQL 复制
DBCC SHRINKDATABASE ( database_name | database_id | 0 [ , target_percent ] [ , { NOTRUNCATE | TRUNCATEONLY } ] ) [ WITH NO_INFOMSGS ]
database_name | database_id | 0
要收缩的数据库名称或 ID。 0 指定使用当前数据库。
target_percent
数据库收缩后的数据库文件中所需的剩余可用空间百分比。
NOTRUNCATE
将分配的页面从文件的末尾移动到文件前面的未分配页面。 此操作会压缩文件中的数据。 target_percent 是可选的。 Azure SQL 数据仓库不支持此选项。
文件末尾的可用空间不会返回给操作系统,并且文件的物理大小也不会更改。 因此,指定 NOTRUNCATE 时,数据库似乎不会收缩。
NOTRUNCATE 只适用于数据文件。 NONTRUNCATE 不会影响日志文件。
TRUNCATEONLY
将文件末尾的所有可用空间释放给操作系统。 不移动文件内的任何页面。 数据文件仅收缩到最后指定的盘区。 如果使用 TRUNCATEONLY 指定,则会忽略 target_percent 。 Azure SQL 数据仓库不支持此选项。
TRUNCATEONLY 将影响日志文件。 若要仅截断数据文件,请使用 DBCC SHRINKFILE。
WITH NO_INFOMSGS
取消严重级别从 0 到 10 的所有信息性消息。
下表对结果集中的列进行了说明。
列名 | 描述 |
---|---|
DbId | 数据库引擎 试图收缩的文件的数据库标识号。 |
FileId | 数据库引擎 尝试收缩的文件的文件标识号。 |
CurrentSize | 文件当前占用的 8 KB 页数。 |
MinimumSize | 文件最低可以占用的 8 KB 页数。 此值与文件的最小大小或最初创建时的大小相对应。 |
UsedPages | 文件当前使用的 8 KB 页数。 |
EstimatedPages | 数据库引擎 估计文件能够收缩到的 8 KB 页数。 |
备注
数据库引擎 不显示未收缩的文件的行。
备注
当前,Azure SQL 数据仓库不支持 DBCC SHRINKDATABASE。 不建议运行此命令,因为这是 I/O 密集型操作,可能会使数据仓库离线。 此外,运行此命令后,还会对数据仓库快照产生成本影响。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。