标签: sql-server

我有一个我试图OPENQUERY在 SSRS/SQL Server 2014 上运行的查询，但我不断收到以下错误：

以 [...] 开头的字符串太长。最大长度为 8000。

有什么办法可以解决这个限制吗？

作为参考，我正在尝试通过链接的 MySQL 服务器从 SSRS 运行查询。

什么是 SQL 的“不可提及的词”？

我正在阅读sys.query_store_query_text (Transact-SQL)并且我看到以下内容，所以我谷歌了 {SQL "unmentionable" word}

has_restricted_text
bit
查询文本包含密码或其他不可提及的词。

除了 3 个将我带回到我找到它的位置的链接之外，我没有找到任何似乎显示与密码或 SQL 可能关心的任何关系的内容。

让我说出显而易见的拳头：我完全理解浮点类型不能准确表示十进制值。这不是关于那个！尽管如此，浮点计算应该是确定性的。

既然这已经解决了，让我向您展示我今天观察到的奇怪案例。我有一个浮点值列表，我想总结一下：

CREATE TABLE #someFloats (val float);
INSERT INTO #someFloats (val) VALUES (1), (1), (1.2), (1.2), (1.2), (3), (5);

SELECT STR(SUM(#someFloats.val), 30, 15) FROM #someFloats;

DROP TABLE #someFloats;

-- yields:
--   13.600000000000001

到目前为止，一切都很好 - 这里没有惊喜。我们都知道1.2不能用二进制表示来精确表示，所以“不精确”的结果是意料之中的。

现在，当我左加入另一个表时，会发生以下奇怪的事情：

CREATE TABLE #A (a int);
INSERT INTO #A (a) VALUES (1), (2);

CREATE TABLE #someFloats (val float);
INSERT INTO #someFloats (val) VALUES (1), (1), (1.2), (1.2), (1.2), (3), (5);

SELECT #A.a, STR(SUM(#someFloats.val), 30, 15)
  FROM #someFloats LEFT JOIN …

所以我确定我的 SQL Server 的不稳定行为是因为 .Net SqlClient 数据提供程序的默认设置SET ARITHABORT OFF. 话虽如此，我已经阅读了各种文章，这些文章讨论了实现这一点的最佳方式。对我来说，我只是想要一个简单的方法，因为 SQL Server 正在遭受痛苦，而且我的查询调优还没有完全超越整个应用程序（显然SET在 sp 中添加是行不通的）。

在 Erland Sommarskog关于该主题的精彩文章中，他基本上建议采取安全的方法，通过更改应用程序来发出SET ARITHABORT ON连接。但是，在 dba.stackexchange question 的这个答案中，Solomon Rutzky提供了实例范围和数据库范围的方法。

设置此实例范围内我在这里遗漏了什么后果？正如我所看到的......因为SSMSON默认设置了这个，我认为ON为所有连接设置这个服务器范围没有坏处。归根结底，我只需要这个 SQL Server 来执行高于一切。

Parallel redo is shutdown for database '' with worker pool size [2].

Parallel redo is started for database '' with worker pool size [2].

Starting up database ''

我在客户端 PC 上的 Windows 事件查看器（事件 ID 49930 或 17137）中经常看到这种情况。这是一台普通的 Windows PC，而不是服务器，带有 SQL Server 2017 Express Edition 和 SSMS 的默认实例。

什么是并行重做？

这是错误日志的输出：

2019-05-28 12:23:03.360 spid16s A self-generated certificate was successfully loaded for encryption.
2019-05-28 12:23:03.360 spid16s Server is listening on [ 'any' <ipv6> 1433].
2019-05-28 12:23:03.360 spid16s Server is listening on [ 'any' …

我遇到了一个问题，当我对视图运行查询时，它需要 4 分钟以上的时间。但是，当我运行查询的内容时，它会在 1 秒内完成。

我唯一不确定的是被连接的表都是时态表。

临时查询计划：https : //www.brentozar.com/pastetheplan/?id=BykohB2p4

查看查询计划：https : //www.brentozar.com/pastetheplan/?id=SkIfTHh6E

关于在哪里尝试解决这个问题的任何建议？

查看代码：

ALTER VIEW [dbo].[vwDealHistoryPITA]
AS
SELECT ROW_NUMBER() OVER (PARTITION BY cm.CodeMasterID ORDER BY cm.CodeMasterID, cm.LastUpdateDate) AS Deal_HistoryID,
       cm.CodeMasterID,
       cm.ProjectName,
       cm.[Status],
       d.CompanyID,
       d.DealTypeMasterID,
       cm.[Description],
       d.PassiveInd,
       d.ApproxTPGOwnership,
       d.NumberBoardSeats,
       d.FollowonInvestmentInd,
       d.SocialImpactInd,
       d.EquityInd,
       d.DebtInd,
       d.RealEstateInd,
       d.TargetPctgReturn,
       d.ApproxTotalDealSize,
       cm.CurrencyCode,
       d.ConflictCheck,
       cm.CreatedDate,
       cm.CreatedBy,
       cm.LastUpdateDate,
       cm.LastUpdateBy,
       d.ExpensesExceedThresholdDate,
       d.CurrentTPGCheckSize,
       d.PreferredEquityInd,
       d.ConvertibleDebtInd,
       d.OtherRealAssetsInd,
       d.InitialTPGCheckSize,
       d.DirectLendingInd,
       cm.NameApproved,
       cm.FolderID,
       cm.CodaProcessedDateTime,
       cm.DeadDate,
       d.SectorMasterID,
       d.DTODataCompleteDate,
       cm.ValidFrom AS CodeMasterValidFrom,
       cm.ValidTo   AS CodeMasterValidTo,
       d.validFrom  AS DealValidFrom,
       d.validTo    AS DealValidTo
FROM …

我有一个包含两列的表，我想计算 Col_B 上（由）Col_A 上的不同值。

我的表

Col_A | Col_B 
A     | 1
A     | 1
A     | 2
A     | 2
A     | 2
A     | 3
b     | 4
b     | 4
b     | 5

预期结果

Col_A   | Col_B | Result
A       | 1     | 3
A       | 1     | 3
A       | 2     | 3
A       | 2     | 3
A       | 2     | 3
A       | 3     | 3
b       | 4     | 2
b       | 4     | …

该文档的sys.dm_exec_query_stats状态如下：

如果服务器上当前正在执行工作负载，则对 sys.dm_exec_query_stats 的初始查询可能会产生不准确的结果。可以通过重新运行查询来确定更准确的结果。

我有时会在活动工作负载期间查询该 DMV，并希望获得准确的结果。我不知道如何在实践中应用上述警告。我是否应该始终查询 DMV 两次并使用第二个结果集，因为这样会更准确？这感觉有点牵强。我是否需要了解 DMV 可能不准确的方式，以便我可以将其纳入分析？如果是这样，会出现什么类型的错误：丢失的行、过时的值、不一致的行或其他什么？

sys.dm_exec_query_stats在活动工作负载期间使用时的最佳做法是什么？

我遇到过这样的脚本：

set @sum = sum = (case when somecol1 is null then DATEDIFF(d,[somecol2],somecol3) else 0 end)

我无法理解第二个关键字 sum 后面的等号 (=) 的含义。当我运行查询时，它没有显示任何带有等号和不带等号的错误。

我想知道在关键字后面放一个等号的目的sum。这是错误还是错误？

谢谢

我发现了几个声明 ALTER TABLE ... DROP COLUMN 是仅元数据操作的来源。

来源

怎么会这样？DROP COLUMN 期间的数据是否不需要从底层非聚集索引和聚集索引/堆中清除？

此外，为什么Microsoft Docs暗示它是一个完整记录的操作？

对表所做的修改会被记录下来并且完全可以恢复。影响大表中所有行的更改（例如删除列或在某些版本的 SQL Server 上添加具有默认值的 NOT NULL 列）可能需要很长时间才能完成并生成许多日志记录。以与影响多行的任何 INSERT、UPDATE 或 DELETE 语句相同的方式运行这些 ALTER TABLE 语句。

作为次要问题：如果数据没有从底层页面中删除，引擎如何跟踪删除的列？