小编Aas*_*lah的帖子

一个INSERT INTO脚本编写如下。

INSERT INTO tableName (Column1, Column2,....) VALUES (value1, Value2,...), (value1, Value2,...),....

以下是我们在解析上面的插入语句时面临的错误

消息 10738，级别 15，状态 1，第 1007 行 INSERT 语句中的行值表达式的数量超过了 1000 个行值的最大允许数量。

我的简单问题是，我们可以更改 1000 个值限制吗？

我们在 SQL Server 2014 SP1 上有一个活动的 OLTP 40GB 数据库。发现查询缓慢，IO_Completion 等待，磁盘队列长度上升到 900，SQL Server 停止响应。我们尝试了什么：

1. 重新启动实例，一分钟后它开始以相同的方式运行。

2. 第二次重启后，我们更改了每个 tempdb 数据文件的初始大小（创建了 16 个数据文件），它开始正常工作。

注意：我们将表变量用于中间结果集。这些结果集非常小。

一个月内发生了两次。每次我手动向数据文件添加一点空间时，它就会开始正常工作。更有趣的是，我们在 SQL Server 2008 R2 和 SQL Server 2012 上的相同设置（相同的硬件、相同的文件夹和文件设置、相同的工作负载）运行良好。

请帮助我们找到永久解决方案。

所有数据文件的初始大小都是 1000MB，当前每个是 1500MB。都是一样的。每个自动增长是 100MB。在此之前，我们面临 PFS 和 GAM 页面争用，我们增加到 16 个并解决了问题。跟踪标志 1117 和 1118 都已启用。2 个 NUMA 节点上的 24 个内核。所有数据文件都在同一卷上。简单的磁盘，没有 SAN。

实例位于物理机上。带有表变量的查询和带有哈希联接的查询最常产生 IO_Completion 等待。

wBob 的详细回答促使我们进行更详细的搜索。我们之前是怎么错过的：

数据库 'tempdb' 中文件 'templog' 的自动增长被用户取消或在 7704 毫秒后超时。使用 ALTER DATABASE 为此文件设置较小的 FILEGROWTH 值或显式设置新文件大小。

这是我们在发生此类问题时在日志中发现的。我们正在移动 TempDB 以分离快速驱动器。

如果 VARBINARY 数据长度达到 2000，sys.fn_varbintohexstr 工作正常。如果大于 2000，函数 sys.fn_varbintohexstr 返回 NULL 作为结果。我缺少什么？

DECLARE @testvarbinary VARBINARY(MAX)
SELECT  @testvarbinary = 0xFFD8FFE000104A46494600010100000100010000FFDB004300090607080706090807080A0A090B0D160F0D0C0C0D1B14151016201D2222201D1F1F2428342C242631271F1F2D3D2D3135373A3A3A232B3F443F384334393A37FFDB0043010A0A0A0D0C0D1A0F0F1A37251F253737373737373737373737373737373737373737373737373737373737373737373737373737373737373737373737373737FFC0001108007E005C03012200021101031101FFC4001B00000301010101010000000000000000000405060302010007FFC4003A100002010302030407080103050000000001020300041105211231411322516106718191A1B1D11423324252C1E1F03315247243A2D2E2F1FFC4001801000301010000000000000000000000000102030004FFC4001F1100020202020301000000000000000000000102112131034104122251FFDA000C03010002110311003F0096D26DAD2EB4BBBC1646E364000186380727C39FC2A05B218827383E35AC17B728922C7348A24FC60311C5EBACD237918051B9341D195A307C96C64D36D27499EE5FF0777AB31D97D746E97A4A16E39003C232CCC365AABD3AC85C42643C50D9A1FC58EF48454E53E91451B02B2D3ECED8810C4D7328DCB636ACF51BD78BBA63B751FA55B71EEA677921951A2B45FB3DA2F7709F89CF866A7353B66B6004B1852DBAC406E079D4AECA7AD0BEF6E44B8DB881DB0798F6D130D8D9DC420714EAF8DF707E9418B476513721C54C6C1256DE37E3239A9FA1D8D35D681562CBCD1A54FF0019627A6DBE3D54B5A09A26C12411E35FA1C68AD082008F6EF2F41E04797974A5BA9E991CE1C6386451B8E7ED1E345727E81C3B44A6188C926B48D805DCD75240CAC4374D8D0ECC1588C8F7D6AB1927583388851DEF7535D1ED8C8C5C292C7650694440C9270AEFBE6ACF4B8858E9C6E1C0E23B463CFC69E6E9118AB633D3AC3ED320B356C229E295C7C7E9EDA6F74DDB4B1D9DB2948D06000390AE74E84E9FA2F6B201DBCC3888EBBF214D74DB0105AB4B311DAB6ECC7E35CECE840B1DB2C518729961DD894F8D21BBD225BEBB62F9E007BCDD5CFD2AB228CDC66729C2A470C6BE0BFCD3286C91635D86E36DB993D6A6DB2918D91EBE8D3ADAA86C14639DFA5663D1E303A48991C2D8C8E87A57E866D87095C023C3C4560F64ACAF19C77971F434136525049123358B346268D543755C6C1BA8F51FDE95DCDB2B2F0AF351C51127703A827C460FBAAD161CA14FD6A41F261492F20026E3E1C296E21EDC1FEFAEA8883FC3F3DD52139ED00DCECC078D4DC9FE47C83CFC6AFB5CB2E195C22F5181ECC8F854BC964B2396006FCF90ABC1A233BD03E8B6FDADD2AE3CD8F80AB4B5B7FB76A76F6ABFE187BCD8F01CFE9483D1C80C61A4DB8B9EFF0001EFAAFD11560866BACE4B37086F21FD149C92B6371AA563591BB7BD8D3AF1777D7E34F6FA2ED3B2B31B2FE7C780E7F1DA907A384DDEA6D70C3B918E5E7FFC154AF8E29253D7BA0F90E7F1A9B781D2C9922069046ABDDD89F2F01FDF1A38292CB9F1A5F1DC3DAAF69716B2AAB9CF1819029B5ACB14F1C6F1B060C720D4D659D4B11356D872359B3F7D49D803BD17819C30A1E60983D3D7B51780ED500CF188AE4961D5587CA94EA30A8561D158EDE40E7E54E2ECF1C711CE79C648E9E1F3A5D749DBBA2EF97183EBE1A7E8E56B24BEA9171C6CC17246304788FEFC6A52EED1A3B9902120139D9B156F703B4B7CE7018FCC72A437363DBC9C5B02060ED4F1744E684DA70ECEC95B18E3CB7B05502B18748894ECDC238BD6DBFC89A5420FB94893C900A6BA903C10460EEC4B7B3181F0A57B19690EBD17FB8D34CA7F14CE5BD9FD1F1A375BBD92C6D2111A34B2960AA396FD727D64579A7C417B0B755FF181CBCBF9A6325A25DC87B400AA8C2F5A4BAD958C6DE09DB9D6B5A8EE96DD96D431E1EE8E271B8EA718F0F953CB2BB3C28C53B321B0E80EC0E456ADA45A63F0AE7C45613F6513A45100006DF029A4E2F48A45495DBB1D5EDE2A22F06E481B679D25D46FB4F8A45935092490A8FC11F1103D82B4BC950CF0E3903C8D793E97DB44F1A4AE9139058039CEF9FAD2C527B0BBAC1B417F61A8E9F33E9EEA5232090A4F74AF4DFD62BE231340413857CE7CBFA687D1B4DFB0B4D0AE7B29179F0E370303E1F2AD94F02A679E7869A5558219BC89EE515219106E63908DCF81A4174F2097EEC1E1C550DEA94B9BB5D8F112DFBD20C01CCD61582411333478EB9738E9B81464FF0079A84791DD5C03EFFE2B98814310DB90F6EDFCFC2BCE2FF7AF93B81CEB3322A74C7096F2DCB6C48DA8FB07E241BD4E25D715AA42A4E589DBCB63FC53BD31F85064E71492C1D3C237108E1E291B6E805235B888EA0BC6705F2513C05357B81FAB7C50C91DBBB481CA90472CF5A08A340DAB5C5BFDB638EDD959970C573838EB4E218CAC48C84B46C32A7C296358C0854C78CE3761CCFB69ADADC048C28C70A8C628E0D4CE269993209DFA1A5CEE385C83B238F767F9AD354982AB303D29569F722EDAE946E1635EBD467FF5A2B289F2A4A99C5F3715E7AD37F76FF2A9B983472B29C839A757127FBD018EE57F73F5A597E02DC927F300DCBDFF001CD325673CB07CD91328076046287656ED1F6C96C8DBD75B4985556272437BB72298DA409D8971F9188FDEB4B6088B349B9692FE78A418ECC285F31CC9F88AABB1DDCA13B11B5405F3CB6DE91433440FDE479651F98787C2ABF4EBF8EE22574700FCAB4E25B8A411AB5BDD9938ADA72D1E30571B8A1218AE480639FB391464E485F9D39B56ED46

select datalength(@testvarbinary)

SELECT  sys.fn_varbintohexstr(@testvarbinary)

在我们的一个生产服务器日志文件中，每天都会观察到以下消息。这是什么意思？这是一个严重的问题吗？

由于某些数据库维护或重新配置操作，SQL Server 遇到了 1 次“SQL 计划”缓存存储（计划缓存的一部分）的缓存存储刷新。

虽然 DBCC DBINFO() 是无证的，但我们都知道

dbi_crdate：数据库创建
数据时间dbi_dbccLastKnownGood：最后一次“干净”运行 DBCC CHECKDB 的完成时间

对于我的数据库之一，它显示以下输出。

与 dbi_crdate 相比，为什么 DBCC DBINFO() 的输出显示 dbi_dbccLastKnownGood 的值较小。如何在创建数据库之前执行 DBCC CHECKDB？

在 SQL Server 2014 中，内存中 OLTP，如果事务回滚并且不再需要新创建的行版本，会发生什么。垃圾收集器是否有责任删除此类行，或者在事务回滚时会在运行时收集此类垃圾？

在我们的其中一台生产服务器上，SQL Server 2008R2（Service Pack 2）安装有 24 GB 内存和 24 个 CPU 内核，分为两个 NUMA 节点，当我们为我们的一个数据库执行 DBCC CheckDB 时，我们面临着大量的resource_semaphore等待大小为 125 GB。
实例在过去 6 个月内正常运行并且工作正常，但是在数据库大小没有变化并且没有执行配置更改的情况下突然开始。
虽然
硬盘驱动器的性能达到了标准。
但是
我发现奇怪的是“ideal_memory_kb”值，即 DBCC 检查数据库会话的 5299767576 (5TB)

select top 5 ideal_memory_kb,* from sys.dm_exec_query_memory_grants

是 TempDB 问题吗？
内存方面有什么问题吗？

最近我们从一个非常大的生产数据库中归档了一些数据，需要缩小所有数据文件以重新获取磁盘空间。

问题是它花费了太多时间，我们无法确定完成了多少工作，DBCC ShrinkDatabase因此我们可以估计剩余的执行时间。

有什么快速的方法可以获得DBCC ShrinkDatabase任务的完成百分比吗？