select task_state,count(*)
from sys.dm_os_tasks
group by task_state

我在 SQL Server 实例上运行上述语句，发现它有大约 633,000 条记录。

task_state     
-------------- -----------
RUNNABLE       2
RUNNING        32
DONE           633115
SUSPENDED      99

如何关闭/杀死无用的任务？

MDW 数据收集器每次在 tempdb 中分配大约 4000 页。

这会导致服务器繁忙时的 IO 压力。

这是生产服务器，我们不想重启服务。版本号是 11.0.3000。

The Max Worker Count is :1216
CPU Count:48
Hyperthread ratio:12
MaxDop: 8

Scheduler_Id 为 0 - 47，行数为平均值。和其他列为空。

在数据库项目的项目设置中，我可以从我的数据层应用程序中设置版本号，但是手动设置它有点低效。我想自动增加内部版本号，就像其他 VS 项目一样。如何才能做到这一点 ？同时我想在生成的dacpac文件中看到这个版本号。

在 Microsoft Windows Server 2008 中使用 MS SQL Server 2012。

我对 Windows 7 和 Windows Server 2008 R2虚拟 Windows 帐户（[NT SERVICE]\<SERVICENAME>如 NT SERVICE\MSSQLSERVERNT SERVICE\SQLSERVERAGENT等）可用的新帐户类型感到有些困惑。

例如，是否敢于向 [NT Service\SQLSERVERAGENT]' 授予访问共享资源（或本地文件或目录）的权限？
而且，如何做到这一点？
例如，要将权限赋予 Windows 文件共享以运行psexec？

在浏览（或按下按钮 Find< 或将组和用户添加到文件共享）时，域和/或本地/远程计算机中可用的帐户，没有可用的帐户，手动输入会出现错误：

“无法找到具有以下内容的对象（用户或内置安全主体）...”

引发此问题的相关（尽管不同）问题：如何将 bak 文件复制到远程共享（不涉及 AD/域帐户）？

更新，回答@Jon-Siegel 对我删除的答案的评论： 我的屏幕截图中没有错误，有时会检测到虚拟帐户，有时会失败。真的是过去 2 天我无法重现它。

可以解释一下我没有适当的权限吗？
当我尝试打开 SQL Sever 配置管理器时，我总是得到：

--------------------------- 
SQL Server Configuration Manager
 --------------------------- 
Cannot connect to WMI provider.   
You do not have permission or …

是否有任何边缘情况建议在存储过程开始时显式检查、删除和创建临时表，而不是仅仅创建它们？

同样，是否存在在存储过程结束时显式删除它们比让 SQL Server 清理它们更可取的情况？

我很感激以下方面的一些帮助，我已经做了一些谷歌搜索，但还没有解决这个问题。

我一直在 SQL 日志中收到一条消息“分配页面失败：FAIL_PAGE_ALLOCATION 540”，然后是一个转储，我将把它添加到这个问题的末尾。

供您参考，构建是：

• 在 vCenter 上运行的虚拟服务器
• Windows Server 2008 R2 64 位 SQL
• Server 2012 SP1 Enterprise (11.0.2100) 8GB RAM SQL Server 最大和最小内存设置为 6144 MB

服务器是 2 节点可用性组的一部分，这是当前的主节点。

此实例托管 Microsoft SharePoint 的数据库

我运行了 24 小时的 Perfmon 跟踪，它只显示 PLE 在一次转储后下降，然后又上升。其他没有什么特别奇怪的。

SQL Server 仍在运行。

从 SQL 日志中提取：

10/03/2014 09:59:52,spid866,Unknown,CACHESTORE_XMLDBELEMENT (node 0)                 KB<nl/>---------------------------------------- ----------<nl/>VM Reserved                                       0<nl/>VM Committed                                      0<nl/>Locked Pages Allocated                            0<nl/>SM Reserved                                       0<nl/>SM Committed                                      0<nl/>Pages Allocated                                   8
10/03/2014 09:59:52,spid866,Unknown,CACHESTORE_XMLDBTYPE (node 0)                    KB<nl/>---------------------------------------- ----------<nl/>VM Reserved                                       0<nl/>VM Committed                                      0<nl/>Locked Pages Allocated                            0<nl/>SM …

我发现您可以使用子句（示例here和here）high performance updates对varchar(max),nvarchar(max),varbinary(max)列进行操作。不幸的是，官方文档中没有提到性能优化。.WRITE

谁能告诉有任何优化吗？有人做过性能测试吗？此外，如果有优化，我想它也只会影响特定情况。

我们有一个将数据插入表中的应用程序。不幸的是，我们遇到了死锁，而且死锁仅来自插入。我们看到插入在非聚集索引上以不同的顺序获取键锁，这导致了问题。

为什么插入会这样，我们应该怎么做才能缓解死锁？任何帮助或见解表示赞赏。

在下面的示例中，只涉及两个插入，但我们在死锁中涉及多达 4 个不同的插入。

这是死锁图：

    <deadlock>
    <victim-list>
        <victimProcess id="process3ab355868" />
    </victim-list>
    <process-list>
        <process id="process3ab355868" taskpriority="0" logused="1184" waitresource="KEY: 5:72057594043629568 (6234ed5bf036)" waittime="7493" ownerId="92332106" transactionname="implicit_transaction" lasttranstarted="2014-10-13T12:37:43.060" XDES="0x123699668" lockMode="X" schedulerid="3" kpid="3540" status="suspended" spid="89" sbid="0" ecid="0" priority="0" trancount="2" lastbatchstarted="2014-10-13T12:37:44.333" lastbatchcompleted="2014-10-13T12:37:44.333" lastattention="1900-01-01T00:00:00.333" clientapp="Microsoft JDBC Driver for SQL Server" hostname="" hostpid="0" loginname="" isolationlevel="read committed (2)" xactid="92332106" currentdb="5" lockTimeout="4294967295" clientoption1="671088672" clientoption2="128058">
            <executionStack>
                <frame procname="adhoc" line="1" stmtstart="278" stmtend="818" sqlhandle="0x0200000053a65d302154b91e9fee55234669030a42479c050000000000000000000000000000000000000000">
                    INSERT INTO table (col1, col2, col3, col4, col5, col6, col7, col8, col9) VALUES (@P0, @P1, @P2, @P3, @P4, @P5, …

我有一个production运行 SQL Server的高可用性服务器。它不断被数百名用户读/写。

我在testing服务器上有数据库的精确副本，并在该环境中进行所有开发。每隔几周，就会对前端应用程序和数据库本身进行重大更改（例如，新存储过程、新列、新表）。

因为production服务器上的数据总是最新的，所以当我想对数据库架构进行更改时，我不想丢失这些数据。当前部署变更的流程是：

1. 备份production服务器并暂停它
2. 将其恢复到testing服务器中
3. 在testing服务器中进行所有数据库更改
4. 备份testing服务器
5. 将新版本恢复到production服务器并取消暂停

这些步骤看起来很复杂，导致生产服务器出现不必要的停机。我想做的是production在后台更新服务器数据库，同时仍然允许用户继续读/写数据库。

到目前为止，我可以看到您可以使用复制数据库向导或使用脚本进行更改，但他们似乎想要在production服务器上删除/创建数据库以进行更改。我怎样才能实现更新production服务器数据库的不太严重的方法？

如果您参考 MSDN 文档中的Synchronous-Commit Availability Mode，您可以阅读：

在同步提交可用性模式（synchronous-commit mode）下，从库加入可用性组后，会赶上对应的主库，进入SYNCHRONIZED状态。只要数据同步继续，辅助数据库就会保持同步。这保证了在给定主数据库上提交的每个事务也已在相应的辅助数据库上提交。当给定辅助副本上的每个辅助数据库同步时，整个辅助副本的同步健康状态为 HEALTHY。

假设我有一个三节点可用性组，其中有一个处于同步HEALTHY状态的数据库。所有副本都使用同步提交模式。

另外假设，我已经配置了只读路由，以便请求ApplicationIntent=Read-Only连接到辅助副本。

如果我通过读写连接提交更改，那么很快，使用ApplicationIntent=Read-Only连接通过另一个连接选择更改的记录，我是否可以期望每次都从两个副本返回一致的结果？

编辑 - 支持已接受答案的更多信息。

在 Microsoft 技术论文“AlwaysOn: Offloading Read-Only Workloads to Secondary Replicas（Sunil Agarwal，2012 年 7 月）”中，标题数据延迟下的部分读取（强调我的）。

在辅助副本上运行的报告工作负载会产生一些数据延迟，通常为几秒到几分钟，具体取决于主要工作负载和网络延迟。即使您已将辅助副本配置为同步模式，数据延迟仍然存在。虽然同步副本确实通过在向主服务器发送 ACK 之前强化已提交事务的事务日志记录来帮助保证在理想条件下（即 RPO = 0）不会丢失数据，但它并不能保证 REDO 线程在辅助副本上确实已将关联的日志记录应用到数据库页面. 所以有一些数据延迟。您可能想知道在异步模式下配置辅助副本时是否更可能出现这种数据延迟。这是一个更难回答的问题。如果主副本和次副本之间的网络无法跟上事务日志流量（即，如果没有足够的带宽），异步副本可能会进一步落后，从而导致更高的数据延迟。在同步副本的情况下，网络带宽不足不会导致次要数据延迟更高，但会减慢主要工作负载的事务响应时间和吞吐量。

如果您的报告工作负载不能容忍任何数据延迟，您必须在主副本上运行它。好消息是，通常大多数报告工作负载都可以容忍一些数据延迟，因此可以安全地迁移到辅助副本。

虽然 Microsoft 文档的广度并不矛盾，但我觉得它可以更明确。“同步”并不意味着ACID首字母缩写词中使用的原子性和一致性。

我正在一台新的 Windows 8.1 机器上安装 SQL Server 2012 SP1。

在安装过程中，我收到此错误：（类似于此问题的屏幕截图）

标题：Microsoft SQL Server 2012 Service Pack 1 安装程序

发生了以下错误：

等待数据库引擎恢复句柄失败。检查 SQL Server 错误日志以了解潜在原因。

如需帮助，请单击：http : //go.microsoft.com/fwlink?LinkID=20476&ProdName=Microsoft%20SQL%20Server&EvtSrc=setup.rll&EvtID=50000&ProdVer=11.0.3128.0&EvtType=0xD15B4EB2%2625405BA100000000000000000

当我单击“确定”时 - 它会继续安装，但不会实际安装数据库引擎服务、报告服务 - 本机、数据质量服务或全文和语义提取。其余部分被勾选为绿色。

我尝试了各种解决方案（例如在配置管理器中使用 SQL Server 下的“登录身份”选项；关闭防火墙等），但还没有任何效果。您的帮助表示赞赏。

完整日志如下：

    Overall summary:
      Final result:                  Failed: see details below
      Exit code (Decimal):           -2061893606
      Start time:                    2014-12-17 00:10:05
      End time:                      2014-12-17 00:44:12
      Requested action:              Install

    Setup completed with required actions for features.
    Troubleshooting information for those features:
      Next step for RS:              Use the following …