小编Mag*_*ier的帖子

通过链接服务器查询 sys.master_files，我没有得到任何结果。

为什么？我如何解决这个问题？

我对 Missig 索引 dmv 有疑问。

BOL 说：

sys.dm_db_missing_index_details 返回的信息在查询优化器优化查询时更新，不会持久化。丢失的索引信息只会保留到重新启动 SQL Server。数据库管理员如果想在服务器回收后保留丢失的索引信息，应该定期备份。

我基本上使用以下（稍微简化的）查询来做到这一点：

SELECT <SomeFieldsAndCalculations> FROM sys.dm_db_missing_index_details AS d
INNER JOIN sys.dm_db_missing_index_groups AS g ON d.index_handle = g.index_handle
INNER JOIN sys.dm_db_missing_index_group_stats AS s ON g.index_group_handle = s.group_handle
INNER JOIN Database1.sys.objects o on d.[object_id] = o.[object_id]
INNER JOIN Database1.sys.schemas sch on sch.[schema_id] = o.[schema_id]

结果每天从 10 个 sql 服务器写入一个表（具有正确的分组选项...）。

查看此表，我发现缺失索引的数量变化很大。这些是一行中缺失索引的总数（在多个实例上）：

3091 3133 3090 3135 3131 2506 2750 2028 2032 2195 2274 2269 2272 2373

服务尚未重新启动。

从 BOL 的介绍中，我可以理解一天到一天的细微变化。假设一天出现的缺失索引应该仍然在第二天的 dmv 中，总计数怎么会变化那么大？例如在 24 …

我想在我的索引中添加一些评论。所以我在索引创建脚本中添加了一些额外的信息，希望在我再次打开脚本时再次看到这个评论。但它不见了。

样本：

CREATE NONCLUSTERED INDEX test3
/* 
 Created on ...
 Reason: ... 
 Improvement: 95 - 99,8% ...
*/
ON [dbo].[T] 
(   
/* equal */
[ID], [Nr], [D], 
/* inequal */
[S], [OD])
INCLUDE 
([A], [C] )

SCRIPT => CREATE SCRIPT在 SSMS 中选择后，所有评论都消失了。

有没有人知道让他们活着的解决方案？

我经常使用MERGE语句并且对它非常熟悉。现在我遇到了一些表的IDENTITY列不是主键的情况。在这种情况下，尽管在合并语句的生成脚本中检查了标识列的存在并且identity_insert在合并之前显式地打开了标识列，但脚本还是失败了。然而它仍然失败。

我为演示创建了一个较小的示例，该示例失败并抱怨IDENTITYColumn：

无法更新标识列“援助”。

我希望自从我转身之后Identity_Insert ON，我可以INSERT或我喜欢UPDATE的IDENTITY列的价值。但它不起作用。

这是示例代码：

CREATE TABLE [dbo].[tm2]
(
    [id] [int] NOT NULL,
    [aid] [int] IDENTITY(1,1) NOT NULL,
    [txt] [nchar](10) NULL,

    CONSTRAINT [PK_tm2] 
       PRIMARY KEY CLUSTERED ([id] ASC) 
            WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]
GO

SET IDENTITY_INSERT [dbo].tm2 ON

MERGE INTO [dbo].tm2 AS Target
USING (VALUES
  (1,2,'qdqewqf'),
  (2,3,'#ED7F00') …

我运行了以下查询：

SELECT session_id,CASE transaction_isolation_level 
WHEN 0 THEN 'Unspecified' 
WHEN 1 THEN 'ReadUncommitted' 
WHEN 2 THEN 'ReadCommitted' 
WHEN 3 THEN 'Repeatable' 
WHEN 4 THEN 'Serializable' 
WHEN 5 THEN 'Snapshot' END AS TRANSACTION_ISOLATION_LEVEL 
FROM sys.dm_exec_sessions 
Where transaction_isolation_level = 4 

进而：

DBCC INPUTBUFFER(157)

其中 157 是先前的 session_id 之一，以查看查询编号之一的结果的语句。1.

它显示了以下内容：

(@ID uniqueidentifier) SELECT * FROM PS WITH (NOLOCK) WHERE ID = @ID

如何使用WITH (NOLOCK)隔离级别 Serializable 运行语句？有什么“覆盖”的With (NOLOCK)吗？

在运行Ola 的 IndexOptimize重建所有索引和统计信息后，我立即清除了数据和计划缓存，并运行了一个非常复杂的丑陋查询来获得其性能的基线。查询实际计划显示 ReasonForEarlyTermination=Timeout 和 Est Rows 和 Actual Rows 的偏差（与 est. 相比，实际行因子为 10,000）。

我想知道这种行数的不平衡是否可能是超时的结果 - 我认为在索引和统计信息重建之后应该是合适的？

如果无法更改查询本身，那么优化以 ReasonForEarlyTermination=Timeout 结尾的查询是否有意义？由于我打算做一些索引调整并重新运行查询，所以不是不可能确定可能改进的结果，因为下一个查询计划创建肯定会再次超时，因此可能会有所不同，结果不同?

技术 详细信息：Sql Server 2008 R2 开发。埃德。10.50.6000.34 DB Comp. 80级。

我们将在新硬件/VM 上创建新的 Sql-Servers，并考虑使用哪个 Sql-Server 版本。我们实际上使用的是 Sql Server 2008 R2。我们已经完成了一个项目，用于测试 2008 年和 2014 年之间的所有兼容性问题 - 并修复了应用程序代码以及数据库架构中的所有问题，为 2014 年做好准备。

现在简单地忽略 2014 并直接进入 2016 的问题出现了。我们不确定。

我已经运行了 SQL 2016 升级顾问 - 它说“准备升级（2016）”并针对已弃用的 ntext、text 和 image 列提出了大约 500 条警告。

• 到 2016 年而不是 2014 年有什么特别的额外缺点吗？
• 是否有新的兼容性问题？AFAIKS 2016 年没有新的弃用尚未取代 2014 年......
• 我们需要考虑什么？

我必须将 Sql Server 2008 R2 中的分区表更改为普通表，以使我的数据库与 Sql Server 2016 标准版兼容。

实际上该表有 5 个分区，行数如下：

> boundary, rows 
2009-01-01 00:00:00.000 419 
2010-01-01 00:00:00.000 386031 
2011-01-01 00:00:00.000 1307990 
2012-01-01 00:00:00.000 673183 
NULL                    9743057

该表包含一个 BLOB（图像）列。该表的总大小约为 25 GB。

我已经通读了如何删除表分区的问题，但尽管它已经回答，但没有被接受的答案，而且这些答案并没有完全解决我的问题。

我意识到了ALTER PARTITION FUNCTION MERGE RANGE命令，但我真的不明白会发生什么。数据是否会被合并到现有文件组之一，之后我仍然会有一个分区表？

我是否必须将所有数据复制到具有相同结构的新表中（可能需要很长时间......）？

我将不得不在停机期间执行此操作，因此我需要一个尽可能高效的程序。

我想创建一个与此类似的索引视图（稍微简化）：

Create VIEW dbo._v1
WITH SCHEMABINDING
AS 
    SELECT 
         COUNT_BIG(*) as CB
        ,[ID]
        ,TITLE] 
        ,dbo.getXmlTranslation1(acat.[TITLE], 'de-DE') as T 
    FROM dbo.[ArticleCategory] acat 
    Group by 
         [ID]
        ,[TITLE] 

在此上创建唯一聚集索引失败：

CREATE unique CLUSTERED INDEX __CLIX
ON dbo._v1([ID]);

无法在视图“db._v1T”上创建聚集索引“__CLIX”，因为视图的选择列表包含聚合函数或分组列结果的表达式。考虑从选择列表中删除聚合函数或分组列结果的表达式。

我搜索了解决方案，但找不到。如果我删除 GROUP BY（我在这里真的不需要），我会被告知由于多个 [ID] 结果，无法创建唯一聚集索引。我添加了标量函数调用，以解决索引视图中不允许的 XML 操作。我检查了标量函数是否是确定性的，是什么情况。

我有很多设计类似于以下（稍微简化的）示例的表格。不同服务器上的原始表有 50,000 到 200,000 行（大约 12,000 - 150,000 页）。

CREATE TABLE [dbo].[PWS] (
    [ID]             UNIQUEIDENTIFIER NOT NULL,
    [PWFID]     UNIQUEIDENTIFIER NOT NULL,
    [SuID]         UNIQUEIDENTIFIER NULL,
    [Title]         varchar(500),
    [SITime]     DATETIME         NULL,
    [Status]      INT,
    [ActionUserID]                UNIQUEIDENTIFIER NULL,
 --   […]
    CONSTRAINT [PK_PWS] PRIMARY KEY NONCLUSTERED ([ID] ASC) WITH (FILLFACTOR = 90),
    CONSTRAINT [FK_PWS_PW] FOREIGN KEY ([PWFID]) REFERENCES [dbo].[PW] ([ID]) ON DELETE CASCADE NOT FOR REPLICATION,
    CONSTRAINT [FK_PWS_Status] FOREIGN KEY ([Status]) REFERENCES [dbo].[Status] ([Status]) NOT FOR REPLICATION
);

CREATE CLUSTERED INDEX [IX_Clustered]
    ON [dbo].[PWS]([PWFID] ASC) …

计划为我们的 Sql-Servers 重新创建新的服务帐户，我想知道 - 从安全角度来看 - 每个服务和每个服务器拥有一个域帐户或仅为每个服务创建一个域帐户并重复使用可能更好那些在不同的服务器上？

DOMAIN\Service-SSRS
DOMAIN\Service-SSAS
DOMAIN\Service-SSIS

vs.

DOMAIN\Service-SQL01-SSRS
DOMAIN\Service-SQL01-SSAS
DOMAIN\Service-SQL01-SSIS
DOMAIN\Service-SQL02-SSRS
DOMAIN\Service-SQL02-SSAS
DOMAIN\Service-SQL02-SSIS
etc.

我们这样做是因为我们希望在所有服务器上都有一个统一和一致的配置，而今天还没有到位。我觉得每个服务器都有一个帐户可能会带来更大的灵活性，因此适得其反......

有什么具体的优点/缺点吗？为每台服务器设置单独的服务帐户是否有很多用途？

当我登录到 Sql-Server 操作系统的远程桌面时，无法使用 SSMS 建立本地DAC 连接。第一个原因是 SQL 浏览器服务关闭。后来，我被指出的第二个原因是“DAC 未激活”错误：

“无法在默认端口上建立 DAC 连接。请确保 DAC 已启用”。

我寻找解决方案。我发现的建议解决方案是启用“RemoteDacEnabled”Facet 属性或运行

sp_configure 'remote admin connections', 1 

这让我想知道，为什么我应该启用REMOTE DacEnabled 属性，以防我想从本地系统连接？我这里的 REMOTE 是不是错了？

MSDN 解释说：

"The connection is only allowed from a client running on the server. No network connections are permitted."

If I HAVE TO logon from local server and NOT over the network, what sense does a REMOTE DAC setting ever make?

EDIT/part of the answer: The main reason …

查看性能数据，我意识到在 VMWare 上运行的 Sql Server 2016 SP1 上的页面预期寿命突然下降，消耗 58982 MB 的 64 GB RAM。PLE 的先前值约为 133,000，突然下降到 7,300 秒。

看起来候选人只有一个查询会导致这种情况。我上传了执行计划。

该查询在早上很早就运行，因此看起来系统上几乎没有其他活动。它需要 01:27 m:s 运行时间并导致 600,000 次读取。

为什么这个查询会导致 PLE 的下降？

下降的后果是什么？