标签: sql-server-2014

我们的一个 SQL Server 出现了我以前从未见过的问题。

SQL Server（企业版）运行的数据库只有 70MB 的数据。但几个小时后，服务器需要 10 GB 或更多内存。几天后，服务器内存不足。我已经在 SSMS 中配置了最大内存参数，但它没有帮助。

你有什么想法怎么做才能找到问题吗？

这是 dbcc memorystatus 结果的链接：https ://drive.google.com/open ? id = 0B2FJAT6lteKJOEJmUFdqb0ZERFU

数据库版本：Microsoft SQL Server 2014 (SP2-CU5) (KB4013098)。企业版。这是一个虚拟机。

我检查了另一个线程，发现了这个查询：

SELECT TOP (21) [type] = COALESCE([type],'Total'), 
  mb = SUM(pages_kb/1024.0)
FROM sys.dm_os_memory_clerks
GROUP BY GROUPING SETS((type),())
ORDER BY mb DESC;

我在 SQL Server 上运行它并得到以下结果：

1. 总计 = 2452,9
2. CACHESTORE_SQLCP = 2141,5
3. MEMORYCLERK_SQLBUFFERPOOL = 160
4. MEMORYCLERK_SOSNODE = 33
5. USERSTORE_SCHEMAMGR = 30.94

cachestore 的值在它只运行了几个小时后就这么高，这是否正常？

运行此查询：

select value_in_use
from sys.configurations
where name = 'max …

我们刚刚从 SQL Server 2008 升级到 2014。除了我们在空间索引上遇到的问题之外，它进行得相当顺利。在这张桌子上，我们收到错误

无法在具有唯一索引“lu_unit__geolocation”的对象“sys.extended_index_1527780600_384000”中插入重复的键行。- 重复键值：(0x20330a3504, 95469304)。

空间索引不能有唯一约束，有问题。

我认为更安全的方法是重建索引。我做了一些实验，我发现在 160 万行上重建索引大约需要 50 秒。生产表大约有 550 万行，由于无法在线构建空间索引，因此在无法访问基表时至少需要 3 分钟。

有没有人有在最短的停机时间内重建空间索引的经验？我们可以用 30 秒但不能用 3 分钟。

我们最近在 SQL Server 2014 HADR 环境中遇到了一个问题，其中一台服务器用完了工作线程。得到消息：

AlwaysOn 可用性组的线程池无法启动新的工作线程，因为没有足够的可用工作线程

虽然我们能够通过将可用性组之一移动到另一台服务器来“解决”问题，但我想知道是否可以查看哪些查询在哪个调度程序（或工作程序或任务）上运行。

通过以下查询，我可以看到有多少工人可用、正在使用和等待资源：

declare @max int
select @max = max_workers_count from sys.dm_os_sys_info

select 
    @max as 'TotalThreads',
    sum(active_Workers_count) as 'CurrentThreads',
    @max - sum(active_Workers_count) as 'AvailableThreads',
    sum(runnable_tasks_count) as 'WorkersWaitingForCpu',
    sum(work_queue_count) as 'RequestWaitingForThreads' ,
    sum(current_workers_count) as 'AssociatedWorkers'
from  
    sys.dm_os_Schedulers where status='VISIBLE ONLINE'

通过以下查询，我可以看到哪些工作人员正在哪个 CPU（核心）上运行：

SELECT *
FROM  sys.dm_os_Schedulers s --> Prozessoren Kerne
JOIN sys.dm_os_workers w ON w.scheduler_address = s.scheduler_address
JOIN sys.dm_os_tasks t ON t.task_address = w.task_address
WHERE s.status = 'VISIBLE ONLINE'
AND s.cpu_id = 2

有什么方法可以找到哪个 …

我有以下查询，我希望老化配置文件显示为新列我的老化配置文件为 0-30、31-60、61-90、91-120、121-180、181-365、365+

我基本上希望结果出现在网络到期时出现在适当的老化支架中。

BU   0-30   31-60   61-90   91-120   121-180   181-365   365+
--------------------------------------------------------------
A    
B
C

询问：

select
 BU,
 Ageing,
 sum(NetDue) as Netdue
 from [dbo].[vw_FACT_CONSOL_CREDITORS]
 where date = @date
 Group by BU, Ageing
Order by BU ;

我是 SQL 的新手，只是想学习所以很抱歉，因为这是基本的东西谢谢

在SQL服务器2014的基数估算白皮书说：

但是，新的 CE 使用更简单的算法，该算法假定大表和小表之间存在一对多连接关联。这假设大表中的每一行都与小表中的一行完全匹配。该算法返回较大输入的估计大小作为连接基数。

但它没有说明 SQL Server 如何确定什么是“大表”和“小表”以进行优化。

这些标准是否记录在任何地方？它是一个简单的阈值（例如“小表”必须低于 10,000 行）、百分比（例如“小表”必须小于“大表”中行的 5%），还是一些更复杂的函数？

此外，是否有跟踪标志或查询提示强制使用此优化进行特定连接？

最后，这个优化是否有一个可以用于进一步谷歌搜索的名称？

我问是因为我希望在主/明细表的连接中使用这种“使用大表的基数”基数估计行为，但是我的“小表”（主）是 1M 行，而我的“大表”（细节）是 22M 行。因此，我正在尝试了解有关此优化的更多信息，以查看是否可以调整我的查询以强制使用它。

我有一个关于这个查询计划的问题。

我们在测试环境中有一个表 Order_Details_Taxes，它有 11,225,799 行。该表有一个列 OrdTax_PLTax_LoadDtl_Key，它在每一行上都是 NULL。此测试环境的配置方式使此列始终为 NULL。此列上有一个索引。

我使用列的 NULL 值对该表运行了一些查询。NULL INNER JOIN 永远不会产生任何结果。

declare @Keys table (KeyValue decimal(15,0))
insert into @Keys (KeyValue) values (null)

select OrdTax_PLTax_LoadDtl_Key
from @Keys
inner join Order_Details_Taxes
    on OrdTax_PLTax_LoadDtl_Key = KeyValue

select *
from @Keys
inner join Order_Details_Taxes
    on OrdTax_PLTax_LoadDtl_Key = KeyValue

这些是查询计划中的第一个查询。第一个select从亿行表开始并连接到@Keys。第二个select从@Keys 开始，但它对这个表进行聚集索引扫描。

我知道在大多数情况下临时@Tables 是有问题的，所以我将查询更改为使用临时 #Table：

if object_id ('tempdb..#Keys') is not null
    drop table #Keys
create table #Keys (KeyValue decimal(15,0))
insert into #Keys (KeyValue) values (null)

select OrdTax_PLTax_LoadDtl_Key …

我正在使用 SentryOne 计划浏览器。

当我右键单击 SSMS 中的执行计划窗格时，第一个选项是

使用 SentryOne 计划浏览器查看

单击它会启动计划资源管理器的实例并打开执行计划。

如果我让计划资源管理器保持打开状态，然后在 SSMS 中运行另一个查询并右键单击“执行计划”窗格并再次单击“使用 SentryOne 计划资源管理器查看”，则不会发生任何事情。我原以为会打开一个新选项卡或 Plan Explorer 的新实例，或者在已经运行的实例中打开一个新选项卡？

我做错了什么还是这是一个功能？

我有一个内部 Web 应用程序正在运行，每次用户转到“搜索”视图时，它都会查询数据库中的三个不同表，以生成视图中三个下拉列表的值。

它基本上运行一个

SELECT DISTINCT (PortName)
FROM Ports
ORDER BY PortName ASC

但是该表包含约 10'000'000 行，并且负载非常重，这意味着页面的加载时间（由于加载数据下拉列表）可能会超过 10-15 秒。

那么，有没有更好的方法来做到这一点，例如以特定时间间隔运行一些脚本并在不同位置创建一个表/视图/任何内容，以便卸载查询大表，只是为了从 10'000 返回 80 行'000 在主表中？

昨天我遇到了一种情况，我的索引被重建，数据库大小增加了一倍（新大小的 50% 未使用）。Sort intempdb设置为 off，我的印象是这种重建导致了它（索引重建不在 中tempdb）。

重建过程是否有理由在完成/潜在故障后保留磁盘空间？

最近我们有一个超过 1 TB 的审计数据库，由于我们有存储问题，管理层正在寻找选择。

我的建议是在每年年底我们进行备份并截断所有表，以保持数据库的可管理性。

拥有存档数据库不会有好处，因为它会再次消耗相同的空间。

我想对我可以向管理层提出的选项提出专家意见，即每年分配更多空间或截断整个数据库。