标签: sql-server-2012

我正在将数据库的兼容模式从 90 (SQL Server 2005) 更改为 110 (SQL 2012)，我想知道在什么时候我会看到中断更改导致的错误（如果有的话）。

我运行了 Upgrade Advisor 2012，它发现了几个需要更新的存储过程。一个例子是：

“在 SQL Server 2005 或更高版本中，ORDER BY 子句中的列别名不能以表别名为前缀。”

但是，当我在 SQL 2012 中运行这个存储过程（没有做任何更改）时，它没有显示任何错误。此外，当我将数据库兼容性级别从 90 更改为 110 时，也没有错误。当我恢复数据库时也没有。

如果我没有在任何地方看到错误，我希望升级顾问能捕获所有内容。还有其他方法可以检查兼容性错误吗？

此外，即使升级顾问告诉我它会失败，这个存储过程怎么可能成功运行？谢谢 ：）

我有一个数据库备份作业设置为每天使用一次带有仅复制选项的完整备份。仅复制是因为从我读过的内容来看，这是备份连接到可用性组的数据库的唯一方法。我在同一个 AG 上使用相同的选项每 20 分钟进行一次日志备份。在这些备份运行后截断事务日志的最佳做法是什么。完整备份不会被截断，因为它只使用与日志备份相同的副本。他们越来越失控。我知道我可以使用 DBCC SHRINKFILE，但我读的越多，它看起来就越危险。有没有其他方法或最佳实践？

任何建议表示赞赏。

我正在尝试在属于可用性组的 SQL Server 2012 数据库上启用 Service Broker 并不断收到此错误消息：

无法对数据库“dbname”执行该操作，因为它涉及数据库镜像会话或可用性组。不允许对参与数据库镜像会话或可用性组的数据库执行某些操作。
ALTER DATABASE 语句失败。（Microsoft SQL Server，错误：1468）

即使尝试Trustworthy在数据库上启用也会产生相同的错误。根据这篇文章，似乎可以在为 AG 配置的数据库上启用 Service Broker。我可能会错过什么？

侦听器已配置，使用公共权限创建的端点，目标引用侦听器名称。当我尝试启用服务代理或Trustworthy通过管理控制台或 T-SQL 进行设置时发生错误。

我想补充一点，该数据库是从具有现有 Service Broker 实现的 SQL Server 2005 版本还原的。

我正在尝试在 VM 环境中配置可用性组，以便可以运行一些测试。

我想我已经正确创建了组，我可以在两台服务器上看到 Always on 组。但是，当我查看该组的仪表板时，它出现以下错误

可用性副本已断开连接
此次要副本未连接到主要副本。连接状态为 DISCONNECTED。

我已经检查了两台服务器上的端点，它们看起来是正确的。没有防火墙在运行，两台服务器都可以看到对方。调试此类错误的最佳方法是什么？

下面是我用来设置所有这些的 TSQL

主服务器

CREATE ENDPOINT dbm_endpoint
    STATE=STARTED 
    AS TCP (LISTENER_PORT=7022) 
    FOR DATABASE_MIRRORING (ROLE=ALL)
GO

辅助服务器

CREATE ENDPOINT dbm_endpoint
    STATE=STARTED 
    AS TCP (LISTENER_PORT=5022) 
    FOR DATABASE_MIRRORING (ROLE=ALL)
GO

主服务器

CREATE AVAILABILITY GROUP AG1
    FOR
        DATABASE TestDb
    REPLICA ON
        'SQL1' WITH
            (
                ENDPOINT_URL = 'TCP://sql1.sql.sandbox.net:7022',
                PRIMARY_ROLE ( ALLOW_CONNECTIONS = READ_WRITE),
                SECONDARY_ROLE (ALLOW_CONNECTIONS=READ_ONLY),
                AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
                FAILOVER_MODE = MANUAL
            ),
        'SQL2' WITH
            (
                ENDPOINT_URL = 'TCP://sql2.sql.sandbox.net:5022',
                PRIMARY_ROLE ( ALLOW_CONNECTIONS = READ_WRITE),
                SECONDARY_ROLE (ALLOW_CONNECTIONS=READ_ONLY), …

参考这个 StackOverflow 问题：https ://stackoverflow.com/questions/13307485/sql-server-clearing-cache-has-no-effect-on-io-stats

我使用了当时正确禁用预读功能的跟踪标志 652。

我回到了它，它不再这样做了。

询问：

DBCC DROPCLEANBUFFERS
DBCC TRACEON(652,-1)
select a.JDID,a.JDDESC from t1 a with (Index = ccsi) JOIN t2 b on a.manager = b.JDID JOIN t3 c on a.department = c.jdid

统计数据：

Table 't1'. Scan count 4, logical reads 5884, physical reads 364, read-ahead reads 13679, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

执行计划：

<?xml version="1.0" encoding="utf-16"?>
<ShowPlanXML xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" Version="1.2" Build="11.0.2218.0" xmlns="http://schemas.microsoft.com/sqlserver/2004/07/showplan">
  <BatchSequence>
    <Batch>
      <Statements>
        <StmtSimple StatementCompId="1" StatementEstRows="566392" StatementId="1" …

最近我们正在做一个 POC 来实现 Always on work 并且碰巧在 BOL 中看到了这篇文章

http://technet.microsoft.com/en-us/library/ms366279.aspx

这篇文章表明，我们在处理同步模式时也会存在逻辑上的不一致，但事实真的会如此吗？

例如，考虑事务正在运行的数据库 A 和 B，A 处于高安全模式并且 B 没有镜像。A 的日志必须转到镜像数据库，然后主数据库提交最终两阶段提交（B 上的事务）成功，但文章建议首先不会传输日志并导致 B 上的提交，这是矛盾的。请帮助我理解上述文章中建议的陈述是否属实。如果是的话怎么可能:)。

PS：如果我需要提供有关此的更多信息，请告诉我。

显然，此功能在以前的版本中可用，但现在已被删除。

有哪些替代方案？

我使用了下面来自 Kevin Kline 的著名查询来检查未使用的索引。在外键上创建的几个索引不返回读取统计信息，只返回写入。

删除这些索引是否 100% 安全？或者它们是否可以被优化器用于插入或删除，并且不会在 DMV 中注册任何统计信息？？如果是这样，如何判断它们是 100% 安全去除的？

我已经让服务器运行了 2 个月，所以我确信我已经涵盖了我们每月的工作负载周期。

    SELECT o.name
    , indexname=i.name
    , i.index_id   
    , reads=user_seeks + user_scans + user_lookups   
    , writes =  user_updates   
    , rows = (SELECT SUM(p.rows) FROM sys.partitions p WHERE p.index_id = s.index_id AND s.object_id = p.object_id)
    , CASE
        WHEN s.user_updates < 1 THEN 100
        ELSE 1.00 * (s.user_seeks + s.user_scans + s.user_lookups) / s.user_updates
      END AS reads_per_write
    , 'DROP INDEX ' + QUOTENAME(i.name) + ' ON ' + QUOTENAME(c.name) + …

我需要对 AlwaysOn 进行一些基准测试，无论是否启用 TDE。我看到的所有说明都涉及将加密数据库添加到可用性组，但我没有提到为 AG 中已有的数据库启用加密。

我可以将服务器证书恢复到所有节点，然后从主节点启用 TDE 吗？我希望我不需要从 AG 中删除数据库，对其进行加密，然后重新初始化所有节点，因为数据库大约为 100 GB。如果需要，我们可以这样做，但这肯定会减慢我们的测试速度。

更新

我只是在一些实验室虚拟机上尝试过这个。我能够在主节点上创建一个证书，在所有辅助节点上恢复它，然后使用这个证书在主节点上创建一个数据库加密密钥。之后我所要做的就是ALTER DATABASE AdventureWorks SET ENCRYPTION ON在主服务器上，一两分钟后，sys.dm_database_encryption_keys 在所有节点上都显示了 encryption_state = 3。

那么，后续问题：是否有任何理由认为我不应该使用此程序？SQL Server 似乎对结果很满意，但我还没有看到任何地方讨论过这种方法。在处理加密和高可用性问题时，我不想让事情碰运气。

所以我有一个我正在尝试调整的查询，但遇到了一个我无法理解的问题。首先是我正在使用的查询。

SELECT  
    si.LoanNbr AS [LoanNumber],
    fi.[SvcClientNbr] AS ClientID,
    si.LoanMasterID,
    si.LoanSrcCode AS [LoanSourceCode],
    fi.LoanPurpCode,
    fi.[PropState] AS [Property State],
    im.ImagedocumentID AS [Image Document ID],
    -- im.requestID AS [Request ID],
    CONVERT(VARCHAR(10),im.[ImageDate],101) AS ImageDate,
    im.[PageCount],
    im.[SignatureInd]
FROM dbo.NotMybaseTable Si
INNER JOIN dbo.NotMyTableName fi
    ON si.LoanMasterID = fi.LoanMasterID
INNER JOIN [dbo].[ImagedDocument] im
    ON si.loanmasterid = im.loanmasterid
    AND im.[DocTypeCode] = '10112'
WHERE CASE WHEN si.loansrccode = 'CORE' AND  Im.[SignatureInd] IN ('Y') THEN 1
        WHEN si.FundingSysCode = 'LIS' and CASE WHEN si.loansrccode = 'CORE' THEN 0 ELSE …