Question

我知道网络上有很多关于缩小tempdb的帖子，但通常是关于“不重新启动并重新启动修复程序”。

通常，我们的tempdb数据文件位于8M左右。星期五，我正在检查服务器上的空间，并在8G上找到了它。 tempdb日志文件很好。

星期六晚上服务器重新启动了，所以我想我会等待，然后简单地检查一下是否可以释放它所显示的99％的可用空间。

没有。
今天，当网络上没有人时，我做了以下事情。

我曾尝试重新启动过去曾使用过的服务
我尝试缩小数据库和文件（全部显示99％可用）
我已经完成了实例中两个“主”数据库的事务日志完整备份
尝试了DBCC FREEPROCCACHE，DBCC FREESYSTEMCACHE（'ALL'），FREESYSTEMCACHE（'ALL'），FREESESSIONCACHE，DROPCLEANBUFFERS，DBCC SHRINKFILE（N'tempdev'，NOTRUNCATE），DBCC SHRINKFILE（N'tempdev'，0，截断）

SELECT SUM（size）* 1.0 / 128 AS [tempdb大小（以MB为单位）来自tempdb.sys.database_files

给出8108.625

 SELECT
 SUM (user_object_reserved_page_count)*8 as usr_obj_kb,
 SUM (internal_object_reserved_page_count)*8 as internal_obj_kb,
 SUM (version_store_reserved_page_count)*8  as version_store_kb,
 SUM (unallocated_extent_page_count)*8 as freespace_kb,
 SUM (mixed_extent_page_count)*8 as mixedextent_kb
FROM sys.dm_db_file_space_usage

给予

usr_obj_kb internal_obj_kb version_store_kb freespace_kb mixedextent_kb 1088 102848 512 7985216 14272

DBCC SHRINKDATABASE(N'tempdb' )

给出消息 DBCC SHRINKDATABASE：数据库ID 2的文件ID 1被跳过，因为该文件没有足够的可用空间来回收。无法缩小日志文件2（临时日志），因为位于文件末尾的逻辑日志文件位于

中

对不起，如果我缺少明显的内容，我是那些试图自学计算机的人，他们在一家中型公司中担任dba管理员双重职责。

tempdb重新启动后不会释放可用空间

0 个答案: