标签: sql-server-2012

当我运行以下查询时收到错误：

SELECT (
        SELECT 1
        FROM dbo.AccountEntry AE
        WHERE AE.Account = P.Account
        )
FROM dbo.Proposal P
WHERE P.id = @Id

当通过 ADO.NET 运行时，它给出：

警告：致命错误 3624 发生在 2016 年 6 月 20 日凌晨 2:28。记下错误和时间，并联系您的系统管理员。当前命令发生严重错误。结果，如果有的话，应该被丢弃。

在 SSMS 中运行时，它会给出

位置：statutil.cpp:4128
表达式：iKey < m_statBlob.GetHeader()->GetKeyCount()
SPID：59 进程 ID：1732
消息 3624，级别 20，状态 1，第 1 行
系统断言检查失败。有关详细信息，请查看 SQL Server 错误日志。通常，断言失败是由软件错误或数据损坏引起的。要检查数据库损坏，请考虑运行 DBCC CHECKDB。如果您同意在安装过程中向 Microsoft 发送转储，则会向 Microsoft 发送一个小型转储。Microsoft 可能提供最新 Service Pack 中的更新或技术支持的 QFE。
Msg 0, Level 20, State 0, Line 0
当前命令发生严重错误。结果，如果有的话，应该被丢弃。

有趣的是，当将@Account 设置为 P.Account 时，此代码有效：

select 1 from …

我想在扩展事件中创建一个新会话来跟踪使用大量 CPU_Time 的查询，但是 CPU_TIME 的单位是什么？多发性硬化症？微秒？...

持续时间似乎是微秒，但我真的不知道 CPU_TIME 并且找不到关于此的任何信息......

谢谢，吉姆

我有一个包含 850GB MDF 文件的数据库。在 20 个月的过程中，应用程序中的日志记录机制创建了各种巨大的表。原本只应该在任何时候保留一周数据的维护脚本没有正确执行（现在是），所以我们不得不手动清理。

我们实际上清除了大约 600GB 的数据。我想释放一些空间，因为它所在的驱动器接近极限。数据文件永远不会再变得这么大，所以它只是浪费了空间。

我打算使用 SHRINK-FILE 来处理这个问题。我已经对数据库的克隆进行了测试，大约需要 3 个小时。数据库上似乎没有任何性能下降。是的，之后索引非常碎片化，但我可以对它们进行排序。

我的问题是这样的：

应用程序需要在整个过程中保持“正常运行”，因为它至关重要。我知道 SHRINKFILE 操作是一个完全在线的操作，还是我错了？

数据库几乎每秒都会发生大量写入活动。

SHRINKFILE 操作导致的 I/O 增加会影响这些写入吗？

反过来说，连续写入是否会影响 SHRINKFILE 操作，即使其完成更慢？

最后，有没有更好的方法来做到这一点？

更新

仅供阅读本文的任何人使用 - 我运行 SHRINKFILE 并监控 I/O 和 CPU。我的高每秒写入数的数据库在这两个方面都略有上升，但完全没有延迟问题。在 1.5 小时的 SHRINK 操作过程中，它一直保持正常运行、稳定且无故障。

之后索引非常碎片化，这让应用程序的报告端有点难过（图形在客户端应用程序上呈现速度很慢），但稍后重建在线索引，一切都恢复正常。

给定一个表格...

create table dbo.FilterIDXTest ( 
    id int not null identity primary key clustered,
    _bigint bigint,
    _varchar10 varchar(10),
    _varchar20 varchar(20),
    _guid uniqueidentifier
);

go

create unique index uq_FilterIDXTest
    on dbo.FilterIDXTest ( _varchar10, _varchar20 ) 
    include ( _guid )
    where _bigint is not null 
        and id > 5;

go

...在什么（如果有）目录视图（或其他格式良好的参考对象）中可以WHERE定位和严格识别子句中的列名称？

sys.indexes可以查看提醒我们的filter_definition是([_bigint] IS NOT NULL AND [id]>(5))。

sys.index_columns可以查看ON和INCLUDE列，但仅列出原始CREATE INDEX命令中的 5 列中的 3 列。filter_predicate此处未找到这些列。

我必须假设filter_predicate在某个阶段对依赖项进行了严格检查，因为sp_rename …

我一直在 Pluralsights 上观看Paul Randal撰写的SQL Server：高级损坏恢复技术。在第 4 单元中，他讨论了一个事实，即如果您丢失了日志文件，那么了解数据库是否完全关闭是很重要的。这将决定 SQL Server 是否会运行崩溃恢复。

他继续提到，这个标志可以在数据库引导页面中找到（1:9 是我基于课程材料的假设，并通过microsoft 上的这个链接备份）。但是，我在页面内没有看到任何明显的标志 -

DBCC TRACEON (3604);
DBCC PAGE ('stack',1, 9, 2) WITH TABLERESULTS;
DBCC TRACEOFF (3604);

在网上查找时，我找不到有关引导页面 (1:9) 的信息。我能够找到sys.databases一列is_cleanly_shutdown代表：

1 = 数据库完全关闭；启动时无需恢复

0 = 数据库没有完全关闭；启动时需要恢复

但是，我想跟随课程，有人可以告诉我在引导页面中寻找什么吗？另外，如何让数据库显示它已完全关闭或执行此操作的正确步骤？

我正在运行 SQL Server 2012。

我的公司有一个用于 LANDesk 的小型 SQL 环境，他们希望将所有服务器迁移到每个区域的单个 SQL 集群。我想知道的是，我如何确定这种场景的容量？我已经获得了每台服务器（All Landesk）的数据库增长，我可以将这些数据作为整合到单个 SQL 集群的粗略估计吗？Windows 团队告诉我，来自这些服务器的数据有点不稳定，可能无法给出他们想要的准确结果。

有问题的新集群已经有几个数据库，但还没有达到最大容量。一旦他们开始添加来自服务器的剩余数据，它应该达到其全部容量。我已经运行 Perfmon 一段时间了，为了检查数据库增长，我使用了 sqlskills.com 中的以下 TSQL 代码

SELECT
[database_name] AS "Database",
DATEPART(month,[backup_start_date]) AS "Month",
AVG([backup_size]/1024/1024) AS "Backup Size MB",
AVG([compressed_backup_size]/1024/1024) AS "Compressed Backup Size MB",
AVG([backup_size]/[compressed_backup_size]) AS "Compression Ratio"
FROM msdb.dbo.backupset
WHERE [database_name] = N'AdventureWorks'
AND [type] = 'D'
GROUP BY [database_name],DATEPART(mm,[backup_start_date]);

我能做些什么来获得准确的结果吗？LANDesk 团队不希望我使用旧服务器，我唯一的选择是使用他们计划迁移所有数据的新集群，而我只有 6 个月的数据。我应该问他们这个新集群的使用年数之类的问题吗？等等...

谢谢大家的答案。这是我从 PAL 工具中得到的

我使用 PAL 工具来确定 perfmon 数据，这些是它给出的一些警告
1) 响应时间大于 25 毫秒 2) 空闲时间少于 10% - 磁盘队列在 90% 的时间内至少有 1 个未完成的 I/O 3) …

考虑以下设置。涉及三个表#CCP_DETAILS_TEMP，Period并且ACTUALS_DETAILS

#CCP_DETAILS_TEMP会有50000记录，ACTUALS_DETAILS可以有5000000记录，period表会有2000记录

指数详情：

CREATE UNIQUE CLUSTERED INDEX IX_CCP_DETAILS_TEMP
  ON #CCP_DETAILS_TEMP (CCP_DETAILS_SID)

CREATE NONCLUSTERED INDEX IXN_ACTUALS_DETAILS_PERIOD_SID_RS_MODEL_SID_CCP_DETAILS_SID_QUANTITY_INCLUSION
  ON ACTUALS_DETAILS (PERIOD_SID, CCP_DETAILS_SID, RS_MODEL_SID, QUANTITY_INCLUSION)
  INCLUDE( SALES, QUANTITY, DISCOUNT) 

CREATE UNIQUE CLUSTERED INDEX IX_PERIOD
  ON PERIOD (PERIOD_SID)

我有一个要求，我为此编写了三种不同的方法来实现结果。现在我想知道哪个更好。

所有三个查询都或多或少地同时运行。我需要一些专家的建议，以了解哪一个会表现得更好。任何一种方法都有什么缺点吗

方法一： Outer Apply

花的时间： 4615 Milli Seconds

SELECT c.CCP_DETAILS_SID,
       A.PERIOD_SID,
       SALES,
       QUANTITY
FROM   #CCP_DETAILS_TEMP c
       CROSS JOIN (SELECT PERIOD_SID
                   FROM   BPIGTN_GAL_APP_DEV_ARM..PERIOD
                   WHERE  PERIOD_SID BETWEEN 577 AND 624)A
       OUTER apply …

在解决为什么我在 SQL Server 2012 中看到与我们内部使用的数据库之一的这么多连接时。

我在网上找到的一个对我有帮助的查询是这样的：

 SELECT DB_NAME(sP.dbid) AS the_database
         , COUNT(sP.spid) AS total_database_connections
 FROM sys.sysprocesses sP
 GROUP BY DB_NAME(sP.dbid)
 ORDER BY 1;

但是，尽管在解决问题后，我看到与我们自己的自定义数据库的连接恢复到正常水平，但我始终看到与master数据库的连接数始终超过 30 个连接。

这对于 SQL Server 2012 是否正常？master运行此查询时，还有其他人获得 30 个或更多连接吗？

我目前正在使用此灾难通过读取system_health扩展事件环形缓冲区来定位最近的死锁。

select top 2000000000
      XEvent.value('@timestamp', 'datetime2(3)') as CreationDateUtc,
      --
      -- Extract the <deadlock>...</deadlock> tag from within the event
      -- Todo: Surely there is a better (xml) way to do this.
      --
      substring(convert(varchar(max), XEvent.query('.')), 
          -- start
          patindex('%<deadlock%', convert(varchar(max), XEvent.query('.'))),          
          -- end
          patindex('%</deadlock%', convert(varchar(max), XEvent.query('.'))) -
              patindex('%<deadlock%', convert(varchar(max), XEvent.query('.'))) + 11 -- 11 to include for '</deadlock>'
          ) AS XdlFile
 from 
    (
      select cast (target_data as xml) as TargetData
        from sys.dm_xe_session_targets st with (nolock)
        join sys.dm_xe_sessions s with (nolock)
          on …

我正在构建的视图每周都变得越来越复杂和大。它的想法是拥有多个管理报告的来源，包括其中一些人进行的临时查询（会计师 - 我能说什么）。我不担心服务器上的负载 - 这个服务器专门用于此，所以需要一段时间才能使用任何重要的资源。但是在它上面做任何事情都需要越来越长的时间。

它大约有 30% 的计算字段，目前有 25 个连接，我可以删除其中的 8 个，但在某些时候会添加更多。无法对其进行索引，因为它跨越 4 个不同的数据库（目前），因此性能充其量只是龟龟。

所以我想按计划将视图的内容转储到表中，问题是：有没有更好的方法？如果没有，需要注意哪些障碍？

编辑：数据过时：直到前一天。数据范围：所有行，不幸的是，当前计数为 320 万。此外，还有开发阶段的问题——现在我们正在研究我们需要、想要和想要的东西，所以性能调整是毫无意义的 ATT。索引将是一个好的开始，但不是现在这个观点。拆分为多个视图/查询听起来不错，但不会从任何有意义的意义上减少执行时间（减少 20 分钟听起来很棒，直到您意识到起点是 75 分钟）。

我正在使用的数据已通过 SSIS 包从其他数据库（和服务器）复制。对其进行改造以将数据整合到一个数据库中可能是可行的，但这不是我的权限。这可能涉及财务成本，并且在所有开发工作完成之前将被管理层拒绝。

我只知道我需要大大加快速度。可能很脏。除非我会花更多的时间等待查询执行而不是适当的开发。