有两个原因促使我提出这个问题：
tSQLt当存在具有非默认排序规则的列时，
T-SQL 测试框架 tSQLt 将其视为“高严重性”问题。测试的作者陈述如下：
我并不是建议每个字符串列都应该有一个与数据库的默认排序规则相匹配的排序规则。相反，我建议当它不同时，应该有一个很好的理由。
然而，如前所述，失败测试的严重性被认为是高的。
Octopus Deploy
在配置 Octopus Deploy Server 时，在 OctopusServer-instance 初始化期间设置失败并出现致命错误。与错误消息相关的文章没有解释为什么这是一个要求，而只是说明它将是未来部署的要求，从并包括 Octopus 版本 3.8。
作为旁注，RedGate 的 CI 工具包DLM 自动化套件支持具有不同排序规则的部署，而不会引起任何抱怨。
将所有列排序规则保留为数据库默认值的建议对我来说更像是指导方针或最佳实践。为什么有些人认为这是一个如此严重的错误？
我正在尝试构建 TSQL 查询来替代 SQL Server Management Studio 提供的各种 GUI 工具。这些工具之一是Job Activity Monitor，可通过Object Explorer窗口访问。
我们当前的数据库环境包括一个具有 3 个节点（一个主节点和两个只读副本）的集群，以及一个位于集群旁边的独立服务器。
为简洁起见，我将节点称为N1、N2 和 N3，以及独立服务器S1。
最近，我们Multi-Server Job Administration为我们的服务器配置，使用 S1 作为 MSX（主）服务器，N1、N2 和 N3 作为 TSX（目标）服务器。
这意味着在集群节点上运行的 SQL 代理作业是从 S1 创建和管理的。
TSX 服务器向 MSX 服务器报告它们的状态、结果等，可以使用Job Activity Monitor. 从 中Job Activity Monitor，可以通过选择访问每个登记服务器 (TSX) 的作业历史记录View history：
这将我们带到这个窗口：
这是我在 MSX 服务器上使用 TSQL 查询尝试重新创建的信息。我想查看所有已登记服务器的作业结果和历史记录，类似于 GUI 窗口显示的内容。
我试过挖掘与工作相关的表和msdb数据库的视图，但没有成功。MSX 服务器上的msdb.dbo.sysjobhistory表不包含已登记服务器的历史记录，而且我似乎找不到任何关于我将如何收集它的好文档。这些数据甚至可以通过 TSQL 访问吗？非常感谢任何相关资源。
问题：在 SQL Server 2016 中，将列更新为相同的值（例如，将列从更新'john'为'john'）是否会产生与将列更新为不同值时相同数量的事务日志记录？阅读下文了解更多详情。
我们有几个按计划运行的 SQL 代理作业。这些作业从源表（复制数据、链接服务器）中选择数据，对其进行转换，然后相应地插入/更新/删除本地目标表的行。
在尝试找到实现这一目标的最佳方法时，我们已经通过各种策略。我们试过了
现在，我只是一个初级 DBD，我对事务日志如何工作的理解非常有限。话虽如此，我的前辈们得出的结论是，我们不能使用 MERGE 或 UPDATE 语句，其中所有列都在同一语句中处理，因为它会产生过多的日志记录。这样做的理由是，当您UPDATE在 SQL Server 中执行语句时，当您设置一个列值并且新值等于旧值时，它仍然在事务日志中标记为更新。当您执行大量无意义的 SET 操作时，这显然会变得代价高昂。
在以下示例中，我们使用源表中的值更新目标表的first_name和，并由 连接。last_nameid
-- create source- and target-table
CREATE TABLE [#tgt] (
[id] Int PRIMARY KEY,
[first_name] NVarchar(10),
[last_name] NVarchar(10)
)
CREATE TABLE [#src] (
[id] Int PRIMARY KEY,
[first_name] NVarchar(10),
[last_name] NVarchar(10)
)
-- fill some dummy-data
INSERT INTO [#tgt]([id], [first_name], [last_name])VALUES(1, 'john', 'lennon')
INSERT INTO [#src]([id], [first_name], [last_name])VALUES(1, 'john', 'cena')
-- update target-table with values from source-table
UPDATE
[T]
SET
[T].[first_name] = [S].[first_name],
[T].[last_name] = [S].[last_name]
FROM
[#tgt] AS [T]
JOIN [#src] AS [S] ON [S].[id] = [T].[id]
DROP TABLE [#tgt]
DROP TABLE [#src]
此示例不检查是否有任何值实际更改。如果我们暂时忽略NULL-checking 和 sane fallbacks，这可以通过以下方式之一进行检查：
-- Example #1: updates all rows where first-name or last-name has changed
UPDATE ..
SET ..
FROM ..
WHERE [T].[first_name] <> [S].[first_name] OR [T].[last_name] <> [S].[last_name]
-- Example #2: updates all rows, sets target-value to source-value if value has changed
UPDATE ..
SET
ISNULL(NULLIF([S].[first_name], [T].[first_name]), [T].[first_name]),
ISNULL(NULLIF([S].[last_name], [T].[last_name]), [T].[last_name])
FROM ..
在示例 #1 中，SET 操作将更新所有列，即使只有 1 列已更改。
在示例 #2 中，SET 操作将更新所有行的所有列，如果值未更改则回退到旧值。
在这两个示例中，所有列都被 SET 操作击中，并且根据我的前辈的说法，这会在频繁执行时创建不必要/有问题的事务日志记录量。
这同样适用于MERGE- 语句。即使您检查匹配行的更改，所有列都会被更新命中。
MERGE [#tgt] AS tgt
USING [#src] AS src
ON (tgt.id = src.id)
WHEN MATCHED AND ([tgt].[first_name] <> [src].[first_name] OR [tgt].[last_name] <> [src].[last_name])
THEN UPDATE SET
[tgt].[first_name] = [src].[first_name],
[tgt].[last_name] = [src].[last_name];
那么我们该怎么办？对我们希望更新的每一列使用单个 UPDATE 语句。在这种情况下：
-- first_name
UPDATE [T]
SET [T].[first_name] = [S].[first_name]
FROM
[#tgt] AS [T]
JOIN [#src] AS [S] ON [S].[id] = [T].[id]
WHERE [T].[first_name] <> [S].[first_name]
-- last_name
UPDATE [T]
SET [T].[last_name] = [S].[last_name]
FROM
[#tgt] AS [T]
JOIN [#src] AS [S] ON [S].[id] = [T].[id]
WHERE [T].[last_name] <> [S].[last_name]
现在，这种方法有几个缺点：
感觉必须有更聪明的方法来解决这个问题，我将不胜感激对这篇文章中所做陈述的任何澄清和更正。如前所述，我只是尽力理解为什么必须这样。
为冗长的帖子道歉，并提前致谢。
我正在经历一些THROW我无法理解的行为。考虑以下存储过程：
CREATE PROCEDURE usp_division_err AS
SET NOCOUNT ON;
BEGIN TRY
EXEC('select 1/0')
END TRY
BEGIN CATCH
THROW;
END CATCH
执行该过程时，会出现以下错误：
消息 8134，级别 16，状态 1，第 1 行
除以零时遇到错误。
请注意，不包含有关在哪个过程中引发错误的信息。那是因为错误的动态 SQL 是在另一个范围内执行的，这很好。但是，将CATCH-block 更改为如下所示
BEGIN CATCH
THROW 50000, 'An error occurred.', 1;
END CATCH
并且该过程的执行将引发此错误：
消息 50000，级别 16，状态 1，过程 usp_division_err，第 7 行 [批起始行 0]
发生错误。
执行动态SQL时仍然遇到错误，但是当我手动指定错误号和错误信息（ 的第一个和第二个参数THROW）时，执行过程的过程名称莫名其妙地出现了。
为什么过程名称出现在第二条错误消息中而不是第一条错误消息中？
我正在通过源服务器上的视图从链接服务器查询数据。视图必须包含几个标准化的列，例如和Created，但在这种情况下，源服务器上的表没有任何合适的信息。因此，这些列被显式地转换为它们各自的类型。我更新了视图，将一列从ModifiedDeleted
NULL AS Modified
至
CAST(NULL as DateTime) as Modified
但是，执行此更新后，视图会触发以下错误消息：
消息 7341，级别 16，状态 2，行 3 无法从链接服务器“”的 OLE DB 提供程序“SQLNCLI11”获取列“（用户生成的表达式）.Expr1002”的当前行值。
我们已经完成了这种“显式转换”——通常在源服务器上进行更改而不用担心，我怀疑这个问题可能与所涉及的服务器的版本有关。我们真的不需要应用这个演员表，但感觉更干净。现在我只是好奇为什么会这样。
服务器版本（来源）：
Microsoft SQL Server 2012 - 11.0.5058.0 (X64) 2014 年 5 月 14 日 18:34:29 版权所有 (c) Microsoft Corporation Enterprise Edition (64-bit) on Windows NT 6.1 (Build 7601: Service Pack 1) (Hypervisor)
服务器版本（链接）：
Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64) 2011 年 6 月 17 日 00:54:03 版权所有 (c) Microsoft Corporation Enterprise Edition (64-bit) on Windows NT 6.1 (Build 7601: Service Pack 1) (Hypervisor )
编辑
我刚刚意识到我犯了一个错误，没有发布所有有问题的专栏，我必须为遗漏一个重要细节而道歉。我不知道我怎么没有早点注意到这一点。不过，问题仍然存在。
转换为 DateTime 时不会发生错误转换，而是将列转换为 UniqueIdentifier。
这是罪魁祸首：
CAST(NULL AS UniqueIdentifier) AS [GUID]
SQL Server 2008 R2 支持 UniqueIdentifiers，正如评论中提到的，视图执行的查询在链接服务器上运行良好。
我正在尝试创建一个用于将事件存储到company-object 的日志表，恐怕我可能走错了路。我得出的结论是我应该在同一列中记录不同的数据类型，但感觉不对。我将用 2 个表解释基本用例；company和user。
company
- id int
- name nvarchar
- description
user
- id int
- name nvarchar
- company int (references company.id)
现在，假设我想在company-object 上记录不同类型的事件。我会创建一个名为的日志表company_log并将company_log_type事件存储在那里。这些表看起来像这样：
company_log
- id int
- old_value nvarchar
- new_value nvarchar
- log_type int (references company_log_type.id)
company_log_type
- id int
- name
有趣事件的例子是
对于前两个事件，我将存储事件类型、旧值和新值。只要我停在这里，它就可以正常工作。但是，如果我想记录 2 个以前的事件，我需要能够在同一列中存储不同的数据类型。更改看起来像这样：
old_value new_value log_type
----------------------------------------------
Acme PiedPiper CompanyNameChanged
NULL 132 UserAdded
97 NULL UserRemoved
在这一点上，我需要存储公司名称的文本旧/新值，以及最近添加的用户的 ID。你可能会看到我已经走错了方向，这就是我寻求帮助。我有两个问题：
我应该只使用sql_variant-datatype，还是如果这被认为是糟糕的设计，那么存储这些日志事件的明智方法是什么？
提前致谢。
我一直盯着自己看。它开始是一个更复杂的过程，但我已经将它剥离到裸露的骨头上，试图让它运行。这是当前代码：
DECLARE @sql NVarchar(MAX) = '
CREATE PROCEDURE dbo.Test
AS
BEGIN
SELECT 1, @num;
END'
EXEC [sp_executesql] @sql, N'@num int', @num = 1;
它只是拒绝。值得一提的是，如果我在没有参数部分（@sql作为函数的唯一参数sp_executesql）的情况下运行代码，它运行良好。我尝试过其他语法替代方案，例如
EXEC [sp_executesql] @sql, N'@num int', 1;
和
DECLARE @params NVarchar(1000) = '@num int';
EXEC [sp_executesql] @sql, @params, 1;
我的参数规范有什么问题？
编辑 1：包含错误消息
Msg 156, Level 15, State 1, Line 2
Incorrect syntax near the keyword 'PROCEDURE'.
ALTER TABLE <source> SWITCH INTO <target>我们有几个表，我们通过在暂存表中重建它们来经常“刷新”它们，然后使用该语句执行到生产表的元数据切换。
这些操作导致大量日志记录，我们不确定如何处理。现在我们只是使用恢复模型将这些表和操作移动到一个新数据库SIMPLE，但我很想听听这个问题的替代解决方案。
您建议我们如何处理由于频繁的表重建而产生的大量日志？
我目前有一个相当大的表（5-7 百万行）。ALTER TABLE .. SWITCH TO ..该表通过在临时表中构建数据的过程定期重建，然后使用语句将数据切换到生产表中。
例子：
BEGIN TRAN;
-- Rebuild indexes
ALTER INDEX IX_NC_GroupEvent_staging_GroupName on [dbo].[GroupEvent_staging]
REBUILD;
ALTER INDEX IX_NC_GroupEvent_staging_Created ON [dbo].[GroupEvent_staging]
REBUILD;
-- Empty production table
TRUNCATE TABLE [dbo].[GroupEvent];
-- Switch data from staging-table into production table
ALTER TABLE [dbo].[GroupEvent_staging] SWITCH TO [dbo].[GroupEvent]
COMMIT;
执行此操作时，索引的当前状态（或索引数据，如果您愿意的话）是否也会切换？我问是因为两个原因：
1）为了执行一个SWITCH TO语句，一个要求是源表和目标表都必须包含相同的索引。这让我相信索引数据也可能被切换，但我不知道如何验证这一点。
2) 以这种方式构建表的主要好处是避免在使用时对生产表执行过多的工作。当然，如果我能够在临时表上重建索引并将重建的索引与表一起切换到生产索引，那我会非常高兴。
在编写程序时，我偶尔会遇到想要中止程序的情况，即使这种情况不一定会触发错误。
比方说，如果我不想让 John 能够运行这个过程，我会做这样的事情：
IF @UserName = 'John'
BEGIN
RAISERROR('John, get out', 16, 1);
RETURN 1;
END
我真的没有理由返回 1，它主要是 shell 脚本的残余，我愿意寻找更好的方法来做到这一点。
有没有更好的方法来返回错误消息并将控制权返回给调用者，以应对严格来说不是错误的意外情况？我对减少字符或代码行的数量不感兴趣。我只是有一种直觉说“这可能不是解决这个问题的最佳方法”，我很好奇是否有更聪明的方法来做到这一点。
一种替代方法是始终使用TRY/CATCH，因为RAISERROR严重性为 1-19 会将控制权交给 catch 子句。
例子：
BEGIN TRY
PRINT 'Before RAISERROR';
RAISERROR('Time for errors', 16, 1);
PRINT 'After RAISERROR'
END TRY
BEGIN CATCH
DECLARE @Msg NVARCHAR(255) = ERROR_MESSAGE()
PRINT 'Inside CATCH'
RAISERROR(@Msg, 16, 1)
END CATCH
输出：
Before RAISERROR
Inside CATCH
Msg 50000, Level 16, State 1, Line 13
Time for errors
缺点：需要TRY/CATCH块的存在。
我们有一个稍微重的表，它半频繁地（每约 5 分钟）由一个过程重新创建。我想知道是否可以做些什么来最大程度地减少表重建期间的停机时间，并且到目前为止已经想到了两种可能性（让我们称表为“设备”）：
选项 A
1) 在过程中创建新表，将其Device_new
命名 2) 将旧表重命名Device为Device_old
3) 将新表重命名Device_new为Device
选项 B
与选项 A 相同，只是使用分区切换。
警告：分区切换的设置要复杂得多，并且对使用有相当严格的要求。
这些选项是糟糕的解决方案吗？如果是，您将如何解决这个用例？谢谢你。
我最近编写了一个 T-SQL 脚本来对 3 个不同的表执行一些更新和插入操作。我希望它在单个事务中完成，因此我阅读了有关如何使用 try/catch 的显式事务的 Microsoft 文档。
根据文档，可以这样做：
BEGIN TRANSACTION;
BEGIN TRY
-- Generate a constraint violation error.
DELETE FROM Production.Product
WHERE ProductID = 980;
END TRY
BEGIN CATCH
SELECT
ERROR_NUMBER() AS ErrorNumber
,ERROR_SEVERITY() AS ErrorSeverity
,ERROR_STATE() AS ErrorState
,ERROR_PROCEDURE() AS ErrorProcedure
,ERROR_LINE() AS ErrorLine
,ERROR_MESSAGE() AS ErrorMessage;
IF @@TRANCOUNT > 0
ROLLBACK TRANSACTION;
END CATCH;
IF @@TRANCOUNT > 0
COMMIT TRANSACTION;
GO
所以我实现了这个模式并将我所有的更新和插入都放在了 TRY 子句中。问题是，代码在查询完成后设法留下了一个打开的事务，我不知道这是怎么发生的。不管在 TRY 子句中做了什么工作，有哪些可能的场景会导致这样的查询使事务保持打开状态？
我的 SSIS 包的控制流未按预期运行。
我想要达到的目标：
测试是否在 SQL Server 上启用了 CLR
SELECT value
FROM sys.configurations
WHERE name = 'clr enabled'
value == 0，尝试启用 CLR 并显示消息Server is configured.
value == 1，显示消息Server is configured.
此流程按预期工作。不过，我想，如果value == 0，之后继续MessageBox Enable CLR on Server。
我尝试将控制流更改为此
现在，发生的事情是这样的：
value == 0[CLR Enabled on Server] 将控制权交给[Enable CLR on Server]，完成并退出。value == 1[CLR Enabled on Server] 完成并退出。[MessageBox- Server is Configured] 永远无法到达。
任何人都可以帮助我理解这一点，和/或向我指出有关 SSIS 条件控制流的良好资源吗？