标签: sql-server-2014

我正在研究从 MS SQL 2012 升级到 2014 的好处。SQL 2014 的一大卖点是内存优化表，这显然使查询速度超快。

我发现内存优化表有一些限制，例如：

• 没有(max)大小的字段
• 每行最大 ~1KB
• 无timestamp字段
• 没有计算列
• 没有UNIQUE限制

这些都属于麻烦事，但如果我真的想解决这些问题以获得性能优势，我可以制定计划。

真正的问题是您无法运行ALTER TABLE语句，并且每次向索引列表添加字段时都必须经历这些繁琐INCLUDE的过程。此外，您似乎必须将用户拒之门外，才能对实时数据库上的 MO 表进行任何架构更改。

我觉得这简直太离谱了，以至于我实际上无法相信 Microsoft 会在此功能上投入如此多的开发资金，却让其维护起来如此不切实际。这使我得出结论，我一定是拿错了棍子的一端；我一定误解了内存优化表的某些内容，这让我相信维护它们比实际困难得多。

那么，我误解了什么？你用过MO表吗？是否有某种秘密开关或过程使它们易于使用和维护？

右键单击表格并选择“选择前 1000 行”时，出现此错误：

除了明显升级到 SQL Server 2014 之外，还有其他解决方法吗？

我们有一位 SQL 专家建议每周重建我们的表索引。我们目前正在这个星期六晚上进行，它会在重建过程中导致很多超时。如果可能，我想避免超时，那么进行每周索引重建是个好主意吗？

我们正在运行 MS SQL Server 2014。

更新我们在重建过程中收到此错误“System.Data.SqlClient.SqlException：超时已过期。操作完成之前超时时间已过，或者服务器没有响应。”

谢谢！

假设我在表中有以下整数值

32
11
15
123
55
54
23
43
44
44
56
23

好了，名单可以继续了；没关系。现在我想查询这个表，我想返回一定数量的closest records. 假设我想将 10 个最接近的记录匹配返回到数字 32。我可以有效地实现这一目标吗？

它在 SQL Server 2014 中。

我需要为 SSRS 和 Tableau 报告提供实时或几乎实时的数据。我不希望生产 OLTP 系统受到长时间运行的查询的负面影响。在可用性组中的辅助数据库上运行大型查询会影响主数据库中的事务性能吗？

我们有一个大约 1TB 的大型数据库，在强大的服务器上运行 SQL Server 2014。几年来，一切都运行良好。大约 2 周前，我们进行了全面维护，其中包括： 安装所有软件更新；重建所有索引和压缩 DB 文件。但是，我们没想到在某个阶段，在实际负载相同的情况下，DB 的 CPU 使用率会增加超过 100% 到 150%。

经过大量的故障排除，我们将其缩小到一个非常简单的查询，但我们找不到解决方案。查询非常简单：

select top 1 EventID from EventLog with (nolock) order by EventID

它总是需要大约 1.5 秒！但是，使用“desc”的类似查询总是需要大约 0 毫秒：

select top 1 EventID from EventLog with (nolock) order by EventID desc

PTable 大约有 5 亿行；EventID是ASC数据类型为 bigint（身份列）的主聚集索引列（ordered ）。顶部有多个线程向表中插入数据（较大的 EventID），底部有 1 个线程删除数据（较小的 EventID）。

在 SMSS 中，我们验证了两个查询始终使用相同的执行计划：

• 聚集索引扫描；

• 估计行数和实际行数均为1；

• 估计和实际执行次数均为1；

• 估计I/O成本是8500（好像有点高）

• 如果连续运行，则两者的查询成本相同 50%。

我更新了索引统计with fullscan，问题依旧；我再次重建索引，问题似乎消失了半天，但又回来了。

我打开了 IO 统计：

set statistics io on …

我看过这个问题 SSIS 2012 - How to Query Current Running Packages in T-SQL?

它给了我以下脚本：

SELECT
    E.execution_id
,   E.folder_name
,   E.project_name
,   E.package_name
,   E.reference_id
,   E.reference_type
,   E.environment_folder_name
,   E.environment_name
,   E.project_lsn
,   E.executed_as_sid
,   E.executed_as_name
,   E.use32bitruntime
,   E.operation_type
,   E.created_time
,   E.object_type
,   E.object_id
,   E.status
,   E.start_time
,   E.end_time
,   E.caller_sid
,   E.caller_name
,   E.process_id
,   E.stopped_by_sid
,   E.stopped_by_name
,   E.dump_id
,   E.server_name
,   E.machine_name
,   E.total_physical_memory_kb
,   E.available_physical_memory_kb
,   E.total_page_file_kb
,   E.available_page_file_kb
,   E.cpu_count
,   F.folder_id
, …

我在 Windows Server 2012 上使用 SQL Server 2014 - 12.0.2269.0 (X64)，但遇到了一些内存问题。当我运行一个执行相当“繁重”计算的存储过程时，我在大约 10 分钟后收到一个错误：

资源池“默认”中的系统内存不足，无法运行此查询。

我的 SQL Server 有多个数据库（比如 15 个，但它们并不总是同时使用）。我查看了 SQL Server 日志文件（在我得到错误之后），我看到了很多这样的行：

2015-12-17 12:00:37.57 spid19s 由于资源池“default”内存不足，不允许为数据库“Database_Name”分配页面。有关详细信息，请参阅“ http://go.microsoft.com/fwlink/?LinkId=330673 ”。

在日志中生成一个报告，其中包含每个组件使用的内存（我认为）。如果我正确解释了报告，我们可以看到MEMORYCLERK_SQLBUFFERPOOL. 您可以在此处找到该报告：http : //pastebin.com/kgmk9dPH

我还生成了一个带有图表的报告，该图表显示了相同的“结论”：

这可能是另一个有用的报告：

请注意，我还在日志中看到了此错误：

2015-12-17 12:04:52.37 spid70 由于数据库内存压力导致页面分配失败：FAIL_PAGE_ALLOCATION 8

以下是有关服务器内存的一些信息：

• 服务器上的总内存：16 Gb

• 分配给 SQL 服务器的内存：12288 Mb

• 使用中的物理内存（来自sys.dm_os_process_memory）：9287 Mb

如果它可以提供帮助，则该服务器不会托管任何 SharePoint 数据库。

对于一个COUNT(DISTINCT)具有约 10 亿个不同值的查询计划，我得到了一个散列聚合估计只有约 300 万行的查询计划。

为什么会这样？SQL Server 2012 产生了很好的估计，所以这是我应该在 Connect 上报告的 SQL Server 2014 中的错误吗？

查询和差估计

-- Actual rows: 1,011,719,166
-- SQL 2012 estimated rows: 1,079,130,000 (106% of actual)
-- SQL 2014 estimated rows: 2,980,240 (0.29% of actual)
SELECT COUNT(DISTINCT factCol5)
FROM BigFactTable
OPTION (RECOMPILE, QUERYTRACEON 9481) -- Include this line to use SQL 2012 CE

-- Stats for the factCol5 column show that there are ~1 billion distinct values
-- This is a good estimate, and it …

我们有几个数据库，其中创建和删除了大量表。据我们所知，SQL Server 不对系统基表进行任何内部维护，这意味着它们会随着时间的推移变得非常碎片化并变得臃肿。这会给缓冲池带来不必要的压力，也会对计算数据库中所有表的大小等操作的性能产生负面影响。

有没有人建议尽量减少这些核心内部表上的碎片？一个明显的解决方案可以避免创建如此多的表（或在 tempdb 中创建所有临时表），但对于这个问题，我们假设应用程序没有这种灵活性。

编辑：进一步的研究显示了这个悬而未决的问题，它看起来密切相关，并表明某种形式的手动维护ALTER INDEX...REORGANIZE可能是一种选择。

初步研究

可以在以下位置查看有关这些表的元数据sys.dm_db_partition_stats：

-- The system base table that contains one row for every column in the system
SELECT row_count,
    (reserved_page_count * 8 * 1024.0) / row_count AS bytes_per_row, 
    reserved_page_count/128. AS space_mb
FROM sys.dm_db_partition_stats
WHERE object_id = OBJECT_ID('sys.syscolpars')
    AND index_id = 1
-- row_count:       15,600,859
-- bytes_per_row:   278.08
-- space_mb:        4,136

但是，sys.dm_db_index_physical_stats似乎不支持查看这些表的碎片：

-- No fragmentation data is returned by sys.dm_db_index_physical_stats
SELECT *
FROM …