小编J.D*_*.D.的帖子

我通读了 Microsoft 的“ SQL Server 2017 的版本和支持的功能”文档，以比较企业版和标准版之间的功能差异。

标准版中没有引起我注意的两件事是：

1. 在线索引

2. 在线模式更改

这是否意味着您不能在不先使数据库脱机的情况下创建和修改索引或表（以及其他对象？），或者 Microsoft 是否意味着只有特定的操作您不能执行，如果是这样，我在哪里可以了解更多信息哪些操作需要使数据库脱机？

我有一个 AD 组，它在我的 SQL Server 上设置为 Windows Authenticated SQL 登录名。在DatabaseA它具有db_datareader和public角色。所以这个 AD 组的用户对数据库中的实体只有读访问权限。

在DatabaseA我内部有一个存储过程dbo.Proc1，我授予execute了同一个 AD 组的权限。

当该 AD 组的用户连接到此服务器时，他们看不到实体dbo.Proc1。

我是否需要向缺少的 Windows 身份验证 SQL 登录（AD 组）提供任何其他权限？

我确实看到，如果我查看 的属性DatabaseA，就会发现execute该级别的权限尚未授予。

（注意：我只希望该 AD 组的用户能够执行dbo.Proc1。我不希望他们能够执行任何不被视为“只读”类型的操作。）

如果我有一批两个不同的SELECT语句，是否可以并行执行它们（如果 SQL 优化器认为它是最有效的执行方法）？

如果第一个SELECT语句选择到临时表中，SELECT然后第二个语句插入到同一个临时表中，这是否会阻止两个语句并行运行？

（我猜答案是肯定的，是的 :)。

我遇到了“传递给 LEFT 或 SUBSTRING 函数的长度参数无效”错误，但是当我包含要传递给这些函数的列时，它会消失并且查询有效，有什么线索吗？

不起作用：

SELECT 
  SQT.QUOTATIONID, 
  UPPER(LEFT(Email.LOCATOR, CHARINDEX('@', Email.Locator) - 1)) AS Manager
  --, Email.LOCATOR
FROM SALESQUOTATIONTABLE AS SQT
INNER JOIN HCMWORKER AS H
    ON SQT.WORKERSALESRESPONSIBLE = H.RECID
INNER JOIN DIRPARTYTABLE AS D
    ON H.PERSON = D.RECID
INNER JOIN LOGISTICSELECTRONICADDRESS AS Email
    ON D.PRIMARYCONTACTEMAIL = Email.RECID

传递给 LEFT 或 SUBSTRING 函数的长度参数无效

作品：

SELECT 
  SQT.QUOTATIONID, 
  UPPER(LEFT(Email.LOCATOR, CHARINDEX('@', Email.Locator) - 1)) AS Manager 
  , Email.LOCATOR
FROM SALESQUOTATIONTABLE AS SQT
INNER JOIN HCMWORKER AS H
    ON SQT.WORKERSALESRESPONSIBLE = H.RECID
INNER JOIN …

我不确定我从哪里开始，但是有没有办法查看优化器为查询生成查询计划花费了多长时间？它是否存储在任何 DMV 或某个统计数据的一部分中？或者，如果我包含实时统计数据或实际执行计划，我可以以某种方式计算它吗？也许在查询存储中？

当它们所属的事务被回滚时，所有​​数据修改都被撤消是真的吗？

例如，如果一个游标只执行了 100 次在每次迭代中更新表的存储过程，所有这些更新都会回滚吗？

DDL 语句会回滚吗？...例如 DROP TABLE 或 CREATE VIEW？DROP DATABASE 呢？

我知道某些语句仍然执行，尽管像 PRINT“MESSAGE”。

我只是想了解仍然会发生哪些类型的事件。

执行任何 DMV 还是有另一种方法来公开重做队列中正在同步到辅助副本的数据类型？（例如，它是表数据和哪个表，还是索引更改和哪些索引等？）

有没有一种简单的方法可以从另一个会话的临时表中选择数据？我需要专门这样做来调试一个我在其他方面的可见性有限的问题。例如，如果我有权访问 TEMPDB，是否可以访问表对象本身？

我看到 Paul White 的这篇文章介绍了一种方法，但它比我希望的要复杂得多：查看另一个会话的临时表

我无法将代码切换为使用全局临时表进行调试。

最近，我们将一台生产服务器从 SQL Server 2016 升级到 SQL Server 2019 (CU 15)。这对我来说是一个在我们的主应用程序数据库上启用查询存储的绝佳机会。它已经运行了几天，这是总体资源消耗报告显示的内容：

在屏幕截图中，我精心挑选了一些看起来很疯狂的数字（查询存储启用的第一天），并将它们标准化为更容易讨论的度量单位。诸如逻辑读取消耗约 183 TB的数据，或内存消耗约 5 TB的数据之类的事情，在这台服务器上似乎几乎是不可能的。

该数据库是数据库中的 John Smith，数据文件大小仅为100 GB ，日志文件大小为200 GB 。全天最多可能有 100 个不同的用户连接到它，并且一天内不会创建大量交易。服务器本身仅为其配置了32 GB内存。要消耗5 TB内存，一天中分配的内存需要被填满150 多次。

我可以考虑添加的唯一其他可能相关的信息是升级后，我们立即将此数据库的“兼容性级别”设置为 150 (SQL Server 2019) 并保留“旧基数估计”设置。我知道这并不理想，最好在收集基线指标时让尘埃落定，但升级的部分原因是为了解决一些紧急的性能问题，从我们的测试来看，这些设置组合实际上最有效（并且仍然看起来）工作得很好）。

我们之前遇到的一些性能问题是由于疯狂的基数估计造成的，如果查询存储使用估计数据点，那么我实际上可以看到此报告的数字是相关的，但我不得不想象该报告是使用实际数据点？不过，如果这是我的生产服务器/数据库在我不断征服基数估计问题时的配置方式存在根本错误的另一个迹象，那将会很有趣。

我是否读错了这些数字，查询存储是否出问题了，或者我的服务器是否正常？

我们有多个 SQL Server，每个 SQL Server 拥有数十个数据库 - 每个客户端一个（在这种情况下，客户端意味着一个客户组织）。这些数据库是通过应用程序访问的，但该应用程序当前使用单个 Windows 登录。因此，这会产生安全风险，即如果存在某些应用程序漏洞，理论上可以访问“其他”客户端的数据库。

处理这种情况的最佳方法是什么？

我们是否应该为每个客户端创建单独的登录名并让应用程序使用单独的登录凭据进行连接？这将降低安全风险，但会产生大量的管理开销（这可能是值得的）。

后续问题是：在这种情况下我们应该使用 Windows AD 安全性还是 SQL Server 身份验证。

我很感激任何建议！