标签: sql-server-2005
有没有人在实践中使用过 sqlcmd 模式？
SQLServer 2005 引入了称为SQLCMD 模式 msdn 链接的东西 。
乍一看，这种模式从命令行批处理文件中添加了变量替换，还有一些转义到操作系统命令。
此功能是否在您的环境、生产或测试中使用？
推荐指数
解决办法
查看次数
如何更改触发器的触发顺序？
我真的很少使用触发器。所以我第一次遇到了一个问题。我有很多带有触发器的表（每个表有 2 个或更多）。我想知道并更改每个表的触发顺序。是否有可能获得这些信息？
添加：
这是我发现的关于 mssqltips 的一篇很好的文章。
推荐指数
解决办法
查看次数
确定表上的索引未使用
我一直在运行这个脚本来试图找到无关的索引
select o.name as TableName, i.name as IndexName, p.reserved_page_count * 8.0 / 1024 as SpaceInMB, s.*
from sys.dm_db_index_usage_stats s
inner join sys.objects o on s.object_id = o.object_id
inner join sys.indexes i on i.index_id = s.index_id and i.object_id = o.object_id
inner join sys.dm_db_partition_stats p on i.index_id = p.index_id and o.object_id = p.object_id
where o.name = ‘TableName’
我知道当 last_user_seek/scan/lookup 都为空时，自上次重启以来没有用户使用过索引。但我想知道 system_scans/lookups/seeks 是什么？因为在某个表上我发现了 5 个没有用户活动的，但一个在 10 天前有系统活动。有没有人对系统扫描/搜索/查找可能有任何了解？这些表似乎真的过度索引，我想减少脂肪。
推荐指数
解决办法
查看次数
为什么使用 GROUP BY 子句的聚合查询比不使用 GROUP BY 子句要快得多？
我只是很好奇为什么聚合查询使用GROUP BY子句比没有子句运行得更快。
例如，这个查询需要将近 10 秒才能运行
SELECT MIN(CreatedDate)
FROM MyTable
WHERE SomeIndexedValue = 1
虽然这个只需不到一秒钟
SELECT MIN(CreatedDate)
FROM MyTable
WHERE SomeIndexedValue = 1
GROUP BY CreatedDate
CreatedDate在这种情况下只有一个，因此分组查询返回与未分组查询相同的结果。
我注意到两个查询的执行计划是不同的 - 第二个查询使用 Parallelism 而第一个查询没有。
如果 SQL Server 没有 GROUP BY 子句，它以不同的方式评估聚合查询是否正常？在不使用GROUP BY子句的情况下，我可以做些什么来提高第一个查询的性能？
编辑
我刚刚了解到我可以使用OPTION(querytraceon 8649)将并行性的开销开销设置为 0，这使得查询使用一些并行性并将运行时间减少到 2 秒，尽管我不知道使用此查询提示是否有任何缺点。
SELECT MIN(CreatedDate)
FROM MyTable
WHERE SomeIndexedValue = 1
OPTION(querytraceon 8649)
我仍然更喜欢较短的运行时间，因为查询旨在根据用户选择填充一个值，因此理想情况下应该像分组查询一样是即时的。现在我只是结束我的查询，但我知道这并不是一个理想的解决方案。
SELECT Min(CreatedDate)
FROM
(
SELECT Min(CreatedDate) as CreatedDate
FROM MyTable WITH (NOLOCK)
WHERE SomeIndexedValue = 1
GROUP …performance sql-server-2005 aggregate parallelism query-performance
推荐指数
解决办法
查看次数
大内存环境中的 SQL Server TempDB 行为
读完这个问题让我想起了我不久前的一个问题。
我们有一个具有 512GB RAM 的 SQL Server，主数据库是 450GB。我们在 TempDB 中看到了很多动作（好吧，我认为这是“相当多的动作”——可能不是！）。我安装了 RamDisk Plus Server 的演示版，创建了一个 50GB 的 ramdrive，将 TempDB 指向它，但并没有看到性能有任何改善。
写入 TempDB 是否总是导致对磁盘的实际物理写入，或者 TempDB 写入是否由 SQL Server 缓存以便像在 Windows 文件系统缓存中那样延迟写入？
在这种情况下，ramdisk 毫无意义吗？
我知道 SQL Server 6.5 支持 TempDB-In-Ram，但我看到它很久以前就停产了！
推荐指数
解决办法
查看次数
SQL Server 备份失败。错误：3041，严重性：16，状态：1
首先，我对 stackexchange 很陌生，所以请耐心等待。
我正在运行 SQL Server 9.0.4060。
我的问题是：我的 SQL Server 备份在很多数据库上一直失败。
维护计划运行到不同的备份作业：
每天 20:30 进行 DIFF 备份，每周日 20:30 进行 FULL 备份。
对于无法完成备份的每个数据库，我收到这两个错误：
Date 06-11-2012 20:31:06
Log SQL Server (Current - 07-11-2012 11:43:00)
Source Backup
Message
BACKUP failed to complete the command BACKUP DATABASE (dbname) WITH DIFFERENTIAL. Check the backup application log for detailed messages.
Date 06-11-2012 20:31:06
Log SQL Server (Current - 07-11-2012 11:43:00)
Source Backup
Message
Error: 3041, Severity: 16, State: 1.
额外的错误。
Date 06-11-2012 17:53:27
Log SQL Server …推荐指数
解决办法
查看次数
更改为 ARITHABORT ON 的风险
我正在与一家供应商合作，他们提供核心应用程序，只要我不修改核心应用程序，我就可以构建自己的扩展。它内置于连接到 SQL Server 2005 数据库的 ColdFusion 中。
我构建的一些报告依赖于使用从核心表计算的函数的视图，并且随着表变大，报告变得非常缓慢。为了加快报告速度，我想使用索引视图。但是在我的测试环境中创建索引视图后，核心应用程序无法再插入到核心表中（它返回了使用索引视图时ARITHABORT需要的错误消息ON）。
因此，似乎为了使用索引视图，SET ARITHABORT ON每当插入/更新核心表时，我都需要拥有核心应用程序。我在我的测试环境中运行了这个：
ALTER DATABASE MyDatabase SET ARITHABORT ON;
它似乎工作正常。但是我的供应商说，由于应用程序有数千个查询，因此此设置可能会破坏其中一个查询，如果我们将来遇到一些意外的数据库问题，他们会坚持要我恢复默认设置。
是否有实际的查询会被打破SET ARITHABORT ON？有什么情况最好保留它OFF吗？
TL;DR 为了让我的新索引视图工作，我需要ARITHABORT ON为整个数据库设置，但我的供应商警告说，这将由我自己承担风险。真的有风险吗？
sql-server-2005 vendor-support configuration materialized-view
推荐指数
解决办法
查看次数
DMV sys.dm_exec_query_stats 中的 last_worker_time 和 last_elapsed_time 有什么区别？
DMV sys.dm_exec_query_stats中last_worker_time和last_elapsed_time是什么意思，它们之间有什么区别？
当我触发以下查询时
SELECT TOP 20
qs.last_worker_time, qs.last_worker_time/1000000 last_worker_time_in_S,
qs.last_elapsed_time, qs.last_elapsed_time/1000000 last_elapsed_time_in_S
FROM sys.dm_exec_query_stats qs
order by qs.last_worker_time desc
我得到如下结果。
我注意到的事情是两者相等或经过的时间超过工作时间。我想了解两者的重要性，因此它也可能有助于我进行性能调整。
推荐指数
解决办法
查看次数
将 SQL Server 2005 升级到 SQL Server 2012
我有一个测试环境，设置如下：
- 虚拟机 (Hyper-V)
- Windows Server 2008 R2 SP1（x64 位）
- Windows SQL Server 2005 Developer Edition SP4（x64 位）（默认实例名称）
- 1 个带有合并复制的数据库设置... 3 个出版物，每个出版物有 2 个订阅者。
我们正在测试升级到 SQL Server 2012 Developer Edition (sp1) 的过程...
我已经下载了 64 位 SQL Server 2012 Dev 的 iso。(sp1) 来自 MSDN（完整许可副本），并已开始走上升级之路。在开始检查不同标准的最后阶段之一，我们遇到了一个奇怪的问题，如下所述：
Rule "Upgrade architecture mismatch" failed. The CPU architectures of upgrading feature(s) are different. To upgrade these features, Setup architecture must be the same as the features being installed.
此外，在升级日志文件中，我发现了以下（更详细的）输出：
(03) 2012-12-28 14:02:45 Slp: Init rule target object: Microsoft.SqlServer.Configuration.SetupExtension.BlockMixedArchitecture …replication sql-server-2005 sql-server sql-server-2012 merge-replication
推荐指数
解决办法
查看次数
如果 varbinary 数据作为数据长度大于 2000，sys.fn_varbintohexstr 返回 NULL
如果 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-2005 ×10
sql-server ×5
performance ×2
aggregate ×1
backup ×1
dmv ×1
index ×1
parallelism ×1
replication ×1
sqlcmd ×1
ssms ×1
tempdb ×1
trigger ×1