标签: sql-server

在维护工作期间，我试图获取碎片索引的列表。但查询速度极慢，执行时间超过 30 分钟。我认为这是由于对 sys.dm_db_index_physical_stats 的远程扫描。

有什么办法可以加快以下查询的速度：

SELECT
    OBJECT_NAME(i.OBJECT_ID) AS TableName,
    i.name AS TableIndexName
FROM
    sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, 'DETAILED') phystat 
    INNER JOIN sys.indexes i 
        ON i.OBJECT_ID = phystat.OBJECT_ID AND i.index_id = phystat.index_id 
WHERE 
    phystat.avg_fragmentation_in_percent > 20 
    AND OBJECT_NAME(i.OBJECT_ID) IS NOT NULL
ORDER BY phystat.avg_fragmentation_in_percent DESC

我不是 DBA，可能在上面的查询中犯了一个明显的错误，或者可能有一些索引或统计信息会有所帮助？也许这只是数据库的大小（大约 20Gb，大约有 140 个表）。

我问的原因是我们只有一个非常小的夜间维护窗口，而这占用了大部分时间。

作为这个关于提高查询性能的问题的后续，我想知道是否有办法让我的索引默认使用。

此查询在大约 2.5 秒内运行：

SELECT TOP 1000 * FROM [CIA_WIZ].[dbo].[Heartbeats]
WHERE [DateEntered] BETWEEN '2011-08-30' and '2011-08-31';

这个运行在大约 33 毫秒内：

SELECT TOP 1000 * FROM [CIA_WIZ].[dbo].[Heartbeats]
WHERE [DateEntered] BETWEEN '2011-08-30' and '2011-08-31' 
ORDER BY [DateEntered], [DeviceID];

[ID] 字段 (pk) 上有一个聚集索引，[DateEntered],[DeviceID] 上有一个非聚集索引。第一个查询使用聚集索引，第二个查询使用我的非聚集索引。我的问题是两部分：

• 为什么，因为两个查询在 [DateEntered] 字段上都有一个 WHERE 子句，服务器是否在第一个而不是第二个上使用聚集索引？
• 即使没有orderby，如何在此查询中默认使用非聚集索引？（或者为什么我不想要这种行为？）

我是管理员，只需运行以下命令：

 sqllocaldb start v11.0

结果：

 Start of LocalDB instance "v11.0" failed because of the following error:
 Error occurred during LocalDB instance startup: SQL Server process failed to sta
 rt.

事件查看器日志事件 ID：528

Windows API 调用 WaitForMultipleObjects 返回错误代码：575。Windows 系统错误消息是：{Application Error} 应用程序无法正确启动 (0x%lx)。单击确定关闭应用程序。在第 3621 行报告。

我尝试了另一个（用户和管理员）帐户，它们没有问题。

我卸载并重新安装了 2012 版的 SQLLocalDB.msi，但我没有运气。你有什么想法和解决办法吗？

运行我们的企业 ERP (Dynamics AX 2012)，我注意到我们的生产环境似乎比我们的开发系统慢得多。

在运行跟踪的同时在开发和生产环境中执行相同的活动后，我确认与开发相比，SQL 查询在我们的生产环境中的执行速度非常慢（平均慢 10-50 倍）。

起初我将此归因于负载，并在下班时间在生产环境上重新运行相同的活动，并在跟踪中发现相同的结果。

我清除了 SQL Server 中的等待统计信息，然后让服务器在正常生产负载下运行一段时间，然后运行以下查询：

WITH [Waits] AS
    (SELECT
        [wait_type],
        [wait_time_ms] / 1000.0 AS [WaitS],
        ([wait_time_ms] - [signal_wait_time_ms]) / 1000.0 AS [ResourceS],
        [signal_wait_time_ms] / 1000.0 AS [SignalS],
        [waiting_tasks_count] AS [WaitCount],
        100.0 * [wait_time_ms] / SUM ([wait_time_ms]) OVER() AS [Percentage],
        ROW_NUMBER() OVER(ORDER BY [wait_time_ms] DESC) AS [RowNum]
    FROM sys.dm_os_wait_stats
    WHERE [wait_type] NOT IN (
        N'CLR_SEMAPHORE',    N'LAZYWRITER_SLEEP',
        N'RESOURCE_QUEUE',   N'SQLTRACE_BUFFER_FLUSH',
        N'SLEEP_TASK',       N'SLEEP_SYSTEMTASK',
        N'WAITFOR',          N'HADR_FILESTREAM_IOMGR_IOCOMPLETION',
        N'CHECKPOINT_QUEUE', N'REQUEST_FOR_DEADLOCK_SEARCH',
        N'XE_TIMER_EVENT',   N'XE_DISPATCHER_JOIN',
        N'LOGMGR_QUEUE',     N'FT_IFTS_SCHEDULER_IDLE_WAIT',
        N'BROKER_TASK_STOP', N'CLR_MANUAL_EVENT',
        N'CLR_AUTO_EVENT',   N'DISPATCHER_QUEUE_SEMAPHORE', …

我需要将数据库日志文件移动到新分区而不使数据库脱机。

执行此操作的正常方法是分离数据库，移动日志文件，然后重新附加数据库。

是否可以在不使数据库本身离线的情况下执行此操作，如果可以，如何执行？

我们的企业应用程序使用 SQL Server 进行数据存储，主要是一个 OLTP 系统。但是，我们应用程序的一个重要组件会产生大量的 OLAP 工作负载。

我们对 tempdb 的写入延迟约为 100 毫秒。这种趋势发展随着时间的推移，和ALLOW_SNAPSHOT_ISOLATION关断。我们正在对此相关问题进行故障排除，到目前为止我们发现的唯一有趣的事情是有大量散列和排序溢出到 tempdb。我们推测这来自我们的 OLAP 工作负载。

题

泄漏的频率是多少？任何？多少次溢出/秒？我们的初步数据表明我们每秒大约有 2 次哈希溢出和每分钟 25 次排序溢出。

这种溢出频率是否可能是导致 tempdb 写入延迟高的罪魁祸首？

其他信息

我们按照每个内核数的建议为 tempdb 使用多个文件。tempdb 文件位于 RAID 1+0 SAN（具有高性能 SSD）上，但它与主数据库数据和日志文件位于同一设备上。tempdb 文件的大小足够大，它们很少增长。我们不使用跟踪标志 1117 或 1118。另一个变量是此设置为许多不同的数据库共享，这些数据库都经历中到高负载。

我们的 100 毫秒写入延迟远大于我们在 MSDN、SQL Skills 和其他站点上发现的 tempdb 写入延迟的可接受范围。但是，我们其他数据库的写入延迟很好（低于 10 毫秒）。根据其他统计数据，我们确实在大量使用 tempdb，尤其是对于内部对象。因此，我们正在深入研究以找出为什么我们的应用程序如此大量地使用内部对象。

我们的平台确实存在以不同方式表现出来的实际性能问题。我们一直在监控性能计数器、查看 DM 视图并分析我们的应用程序行为，以尝试深入了解我们系统的资源使用特征。我们现在专注于溢出，因为我们已经读到溢出具有巨大的负面影响，因为它们是在磁盘上而不是在内存中执行的。我们似乎有很多泄漏，但我想就人们认为的“高”获得一些意见。

我们的生产环境有这个问题。

Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64) - Windows NT 6.1（内部版本 7601：Service Pack 1）上的企业版（64 位）。

SQL Server 正在删除所有（几乎 100%）旧的执行计划，并在每天夜间（从晚上 11:00 到早上 8:00）重新创建它们。当“自动更新统计信息”处于禁用状态时，甚至会发生这种情况。在过去的 2-3 周内，我们已经开启了“自动更新统计信息”。但它仍在发生。

我们真的不知道是什么触发了这种重新生成计划，但我们确信我们不会手动进行。

唯一真正与计划重新生成时间一致的是我们的数据库维护工作：每日索引重组（碎片为 5-30% 时），以及每日索引重建（碎片超过 30% 时） ） 工作。通常这个日常维护工作只做重组（因为每天的索引碎片永远不会超过 30%）。

影响：

这些新创建的计划使一些 UDF 调用/查询调用（从 UI/网页调用）花费更长的时间（分钟而不是不到 1 秒），因此会话只会堆积起来，使 CPU 接近 90% .

当那些卡住的会话被强行删除（在 DB 端）时，问题就会消失，并且 1）当所有相应的执行计划被手动清除（对于查询）或 2）当 UDF 被更改（对于函数）时。从那一刻起，SQL 服务器创建的任何新计划都会在一天中完美运行，直到第二天早上最终出现相同的问题。此外，这种行为并不是 100% 一致的，我们并不是每天早上都能看到它。但是有一段时间我们已经连续 4-5 天看到它了。

问题发生在工作日的早晨，这似乎是更频繁地访问 UI/网页的时候。

有没有人知道是什么导致了这个问题以及如何解决这个问题？任何帮助将非常感激。

对于 MySQL，我知道数据库是在 SQL 语句中逐表备份的，这会导致锁定，如果在备份时更新列，则最终可能会出现完整性问题。

据我了解，这不适用于 Microsoft SQL Server，但 SQL Server 是如何处理的？是否有一些内部冻结来保持数据库一致？

我还听说备份是单线程的，这意味着它只使用一个核心，假设您备份到单个文件。还假设您有一台多核机器，例如 16 核，或者至少比 1 多得多。

根据我的个人经验，我在备份时从未遇到过问题，既没有锁定也没有开销问题，但我的经验有限。这就是为什么我总是建议在服务器属性中打开备份压缩。

那么当备份作业正在运行时会发生什么？不同版本是否也有显着差异？例如 2008、2012 和 2014（不是许可证）。

这个问题是关于VALUES从这里和这里开始的构造的优化器行为探索的延续。我想问一下VALUES和APPLY这次。

使用CROSS APPLY别名作为需要在查询的各个部分中引用的表达式是常见的模式。例如：

CREATE TABLE #data (N int);
INSERT INTO #data VALUES (5), (4), (3), (2), (1);

SELECT d.N, c.[Square]
FROM #data d
    CROSS APPLY (VALUES (d.N * d.N)) c([Square])
WHERE c.[Square] BETWEEN 1 AND 10
ORDER BY c.[Square];

我自己总是CROSS APPLY在这种情况下使用，但有时我会遇到包裹在 inline-TVF 和OUTER APPLY-ed 中的此类表达式。因此，出于好奇，我换CROSS到OUTER的exampling查询

SELECT d.N, c.[Square]
FROM #data d
    OUTER APPLY (VALUES (d.N * d.N)) c([Square])
WHERE c.[Square] …

假设我正在运行日志备份，并且该日志备份需要 10 分钟才能完成。在这 10 分钟的窗口中，将运行进一步的事务。鉴于以下示例，日志备份实际上包含哪些事务？

1. 事务 A 提交
2. 事务 B 打开
3. 日志备份开始
4. 交易 C 开启
5. 事务 B 提交
6. 日志备份完成
7. 事务 C 提交