我有一个包含 12 个月以上数据的表格。我备份表然后删除所有行，只保留上个月插入的行。但是表大小不会缩小，底层物理文件也不会缩小。

dbcc showcontig ('mytable') with tableresults;

ObjectName  ObjectId    IndexName   IndexId Level   Pages   Rows    MinimumRecordSize   MaximumRecordSize   AverageRecordSize   ForwardedRecords    Extents ExtentSwitches  AverageFreeBytes    AveragePageDensity  ScanDensity BestCount   ActualCount LogicalFragmentation    ExtentFragmentation
mytable 478624748   PK_Log  1   0   21344   467392  94  8033    237 0   2675    12918   2862,346    64,6361996540647    20,6517532316743    2668    12919   77,8392053973013    71,7757009345794


exec sp_spaceused 'mytable', @updateusage = 'TRUE'

name    rows    reserved    data    index_size  unused
LogTrace    467392      8984976 KB  8930056 KB  21984 KB    32936 KB

这些值意味着表的每一行大约是 19MB！

我尝试在没有更改的情况下重建索引：ALTER INDEX PK_myindex ON mytable REBUILD

我尝试过的其他事情：

select …

我有处于可疑模式的 SQL Server 2008 R2 数据库。我试图修复它运行此查询：

EXEC sp_resetstatus ‘yourDBname’;
ALTER DATABASE yourDBname SET EMERGENCY
DBCC checkdb(’yourDBname’)
ALTER DATABASE yourDBname SET SINGLE_USER WITH ROLLBACK IMMEDIATE
DBCC CheckDB (’yourDBname’, REPAIR_ALLOW_DATA_LOSS)
ALTER DATABASE yourDBname SET MULTI_USER

但修复输出是这条消息：

Warning: You must recover this database prior to access.
Msg 8921, Level 16, State 1, Line 5
Check terminated. A failure was detected while collecting facts. Possibly tempdb out of space or a system table is inconsistent. Check previous errors.
Warning: The log for database 'ServeDB' …

我们正在释放 SQL Server 2008 R2 数据库中的大量空间 - 太棒了！足以关心-（我们丢弃了大量不必要的数据）。但数据库文件会保留其文件大小。我们想重新获得它。

我多次听说使用DBCC SHRINKDATABASE会降低数据库的性能 - 据我所知，因为“...收缩操作不会保留数据库中索引的碎片状态，并且通常会将碎片增加到学位” [MSDN]

所以我打算使用DBCC SHRINKDATABASE然后重建我们的索引。

不使用DBCC SHRINKDATABASE来重新获得磁盘空间还有另一个性能原因吗？

我的问题是，我应该定期运行一个或两个收缩命令，

DBCC 收缩数据库

或者

DBCC 收缩文件

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

背景

Sql Server：数据库为 200 gigs，日志为 150 gigs。

运行这个命令

SELECT name ,size/128.0 - 
CAST(FILEPROPERTY(name, 'SpaceUsed') AS int) / 128.0 
AS AvailableSpaceInMB FROM sys.database_files;`

产生这个输出..

MyDB：159.812500 MB 可用空间

MyDB_Log：149476.390625 MB 可用空间

所以似乎有一些可用空间。

我们的备份时间表如下：

1. 交易日志每小时一次
2. 每周两次完全备份
3. 每周 5 次差异备份

我试图找出我为验证备份和执行 DBCC 检查而采购的新硬件上可以承受的峰值负载。我一直在使用 Crystal Diskmark 来获取吞吐量统计信息，这有助于我对复制/恢复任务的顺序 I/O 进行基准测试。我无法衡量 DBCC 检查可以维持多少随机 I/OI。我正在考虑使用 iometer 和 sqliosim，但想知道配置最适合模拟 DBCC 检查。

我正在测试的硬件包括一台 R720，配备双 E5-2609 8 核、32 GB RAM、Windows 2008 R2 Standard、SQL Server 2008 R2 Standard with SP2，以及配备 24 个 15k SAS 轴的 PowerVault 3620f 连接到两个双核R720 上的端口 HBA。我一直在试验 4、8 和 12 轴 RAID 0 组（我可以承受失去容错能力，因为作为测试过程的一部分，DB 的预期寿命为几分钟）。

我想我可以使用上述硬件同时运行多个 DBCC 检查而不会出现磁盘争用。我可以选择将 RAM 升级到 64 GB，将 O/S 升级到 Enterprise，但由于许可成本，可能无法将 SQL 升级到 Enterprise。

关于如何使用 iometer、sqliosim 或其他实用程序确定 DBCC 的最大随机 I/O 的任何建议将不胜感激。

MSDN关于命令“DBCC CHECKDB”的文章在语法部分解释了三种执行数据库修复的方法：

- REPAIR_ALLOW_DATA_LOSS
- REPAIR_FAST
- REPAIR_REBUILD

但是当我在寻找如何修复嫌疑人（我在执行这些步骤时置于此模式下）数据库时发现以下语句，我无法理解它是三种模式中的哪一种：

DBCC CHECKDB（数据库名称，修复）

我执行了该语句，它运行良好。我很困惑，因为在没有用“_allow_data_loss”、“_fast”或“_rebuild”结束单词的情况下，没有单独提到“修复”参数。

如果我尝试在处于紧急状态的数据库上运行“DBCC CHECKDB ( databaseName , repair_rebuild )”，我会收到一条错误消息，指出我无法在数据库处于紧急状态时执行该级别的修复。所以，我放弃了“修复”本身就是“修复重建”。

该语句是我发现的脚本中的第三行：

1. ALTER DATABASE databaseName SET EMERGENCY;
2. ALTER DATABASE 数据库名称 SET SINGLE_USER;
3. DBCC CHECKDB（数据库名称，修复）ALL_ERRORMSGS
4. ALTER DATABASE databaseName SET MULTI_USER;
5. ALTER DATABASE databaseName SET ONLINE;

如果我阅读第三个语句执行的输出，我会看到有关该过程的信息，但与修复中使用的级别无关。

提前致谢，

我有以下脚本：

-- available space in each of the database files

PRINT @@SERVERNAME
--SQLDWDEV01
USE [BodenStage]
GO
SELECT name 
,(CAST(ROUND((size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS int)/128.0),2) AS NUMERIC(18,2))) AS AvailableSpaceInMB  
,(CAST(ROUND((size/128.0 - FILEPROPERTY(name, 'SpaceUsed')/128.0)/1024.00,2) AS NUMERIC(18,2))) AS AvailableSpaceInGB 
FROM sys.database_files;  
GO

尽管我不喜欢既不收缩数据也不收缩日志文件，但有时需要这样做。不是我的错。

有方法，以缩小数据文件，而无须描述累积碎片在这里：

仅截断

将文件末尾的所有可用空间释放给操作系统，但不会在文件内执行任何页面移动。数据文件仅收缩到最后分配的范围。

如何将DBCC SHRINKFILE的结果保存到表中？

请参见下文，这是将DBCC SQLPERF的结果保存到表中的一种方法。

select @@servername as [Server]
       ,db_name() as [database]
go

SET NOCOUNT ON

begin try
  drop table #radhe
end try
begin catch
end catch


create table #radhe …

我有一个非常大的表，有 5 亿行和一个文本列，我将删除它。在我的开发环境中，我已经删除了列并开始了回收过程，但我不确定“DBCC CLEANTABLE (MyDb,'dbo.LargeTbl, 100000)”语句中的批处理大小实际上是什么。

我尝试将其设置为 5，希望它检查前 5 行并结束。“DBCC CLEANTABLE (MyDb,'dbo.LargeTbl, 5)”，耗时 28 小时。所以我恢复了数据库，将其设置为 100,000，花了 4 个小时

实际问题：批处理大小是否告诉 dbcc cleantable 一次要执行多少行，并一次连续运行 100K 直到它通过所有 500 百万行？或者一旦我运行了 100,000 行，我是否必须再次运行它直到我完成所有 5 亿行？

在我的第二次测试中，（运行 100K 一次）我能够回收 30GB。然后我对所有索引运行了索引重组并回收了额外的 60GB ..

我在我们的一台生产服务器上的 SQL Server 内存缓存中看到了一些令人担忧的行为。我们使用的是 SQL Server 2014 SP2 企业版，16 核，400GB RAM（300GB 专用于 SQL Server）。

使用此查询（归功于Glenn Berry）：

SELECT TOP(10) mc.[type] AS [Memory Clerk Type], 
       CAST((SUM(mc.pages_kb)/1024.0) AS DECIMAL (15,2)) AS [Memory Usage (MB)] 
FROM sys.dm_os_memory_clerks AS mc WITH (NOLOCK)
GROUP BY mc.[type]  
ORDER BY SUM(mc.pages_kb) DESC OPTION (RECOMPILE);

我发现了一个问题。这些USERSTORE_TOKENPERM值增长到似乎超过缓存的程度，因此，几乎所有计划都被编译并且没有被缓存。也就是说CACHESTORE_SQLCP，CACHESTORE_OBJCP每个大约 200 MB，而USERSTORE_TOKENPERM缓存高达 11 GB。存储了超过 168,000 个令牌，大约有 100 个并发/600 个用户，连接数为 3000-5000。这些数字似乎相差甚远。

不幸的是，提供此应用程序的供应商没有“系统要求”文档之类的疯狂内容，并且他们不会承诺在未经测试的 Service Pack/CU 上支持该应用程序。所以我的手被束缚在 SQL Server 2014 SP2 上，因为我读过的其他线程建议升级到 SQL Server …

用户数据库上的 DBCC CHECKDB 返回此错误

Msg 8992, Level 16, State 1, Line 1
Check Catalog Msg 3851, State 1: An invalid row (class=128,depid=65536,depsubid=0) was found in the system table sys.syssingleobjrefs (class=128).

此错误出现在用户数据库中，而不是出现在master! 当人们尝试检查在不同服务器上恢复的主数据库时，互联网上充满了专门讨论此错误的文章。事实并非如此。

我尝试了所有常用的魔法，但没有成功。

DBCC CHECKDB WITH ALL_ERRORMSGS, NO_INFOMSGS
--error

ALTER DATABASE DBCopy SET SINGLE_USER WITH ROLLBACK IMMEDIATE

DBCC CHECKDB (DBCopy, REPAIR_ALLOW_DATA_LOSS) 
--output reports the same error

DBCC CHECKDB WITH ALL_ERRORMSGS, NO_INFOMSGS
--error

--no hope but just in case
ALTER DATABASE DBCopy SET EMERGENCY

DBCC CHECKDB (DBCopy, REPAIR_ALLOW_DATA_LOSS) 
--the …