我知道网络上有很多关于缩小tempdb的帖子,但通常是关于“不重新启动并重新启动修复程序”。
通常,我们的tempdb数据文件位于8M左右。星期五,我正在检查服务器上的空间,并在8G上找到了它。 tempdb日志文件很好。
星期六晚上服务器重新启动了,所以我想我会等待,然后简单地检查一下是否可以释放它所显示的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管理员双重职责。