标签: sql-server

假设我有两个查询，在 SSMS 中的两个单独会话中运行：

第一节：

UPDATE Person
SET Name='Jonny', Surname='Cage'
WHERE Id=42

第二场：

SELECT Name, Surname
FROM Person WITH(NOLOCK)
WHERE Id > 30

SELECT语句是否有可能读取半更新的行，例如带有Name = 'Jonny'和的行Surname = 'Goody'？

查询几乎在不同的会话中同时执行。

当我查看时sys.sql_logins，我看到一个名为is_policy_checked. 我可以相信我的密码策略已经针对此列值所在的所有登录名进行了检查1吗？

我听说（我很确定）Developer Edition 是免费的，下载它不需要注册。但是当我今天开始寻找它时，我找不到从哪里得到它。我的理解是对还是错？抱歉，我没有在这里找到类似的问题。有任何想法吗？

我们拥有庞大的生产数据库，其大小约为 300GB。有什么方法可以提高删除查询的性能？现在删除速度在每分钟1-10k之间，对我们来说非常慢。

我想将数据库中可用的特定表备份到一个.bak文件中，所有这些都应该使用 T-SQL 脚本来完成。

我最近遇到了这个问题，在网上找不到任何讨论。

下面的查询

DECLARE @S VARCHAR(1) = '';

WITH T
     AS (SELECT name + @S AS name2,
                *
         FROM   master..spt_values)
SELECT *
FROM   T T1
       INNER JOIN T T2
         ON T1.name2 = T2.name2;

总是得到一个嵌套循环计划

尝试使用INNER HASH JOIN或INNER MERGE JOIN提示强制问题会产生以下错误。

由于此查询中定义的提示，查询处理器无法生成查询计划。在不指定任何提示且不使用 SET FORCEPLAN 的情况下重新提交查询。

我找到了一种允许使用散列或合并连接的解决方法 - 将变量包装在聚合中。生成的计划成本显着降低（19.2025 与 0.261987）

DECLARE @S2 VARCHAR(1) = '';

WITH T
     AS (SELECT name + (SELECT MAX(@S2)) AS name2,
                *
         FROM   spt_values)
SELECT *
FROM   T T1
       INNER JOIN T T2 …

是否有必要后重新启动SQL服务器DBCC SHRINKFILE上tempdb.mdf或有任何其他方法，以减少大小tempdb.mdf，无需重新启动SQL服务器？

请帮忙，因为我需要这个用于生产服务器，我希望在没有任何停机时间的情况下进行收缩。

查看Kalen Delaney 撰写的“SQL Server 2008 Internals” ¹，第 13 页，它说明了以下内容：

“生成这样一个计划的第一步是规范化每个查询，这可能会将单个查询分解为多个细粒度的查询。查询优化器在规范化一个查询之后对其进行优化，这意味着它确定了一个计划执行该查询。”

另一位 DBA 向我建议，可以通过将WHERE子句谓词移动到FROM子句中来提高某些查询的性能，例如：

SELECT *
FROM dbo.table1 t1
    INNER JOIN dbo.table3 t3 ON t1.ID = t3.ID
    LEFT OUTER JOIN dbo.table2 t2 ON t1.ID = t2.ID
WHERE t1.CreateDate >= '2015-07-31 00:00:00';

会成为：

SELECT *
FROM dbo.table1 t1
    INNER JOIN dbo.table3 t3 ON t1.ID = t3.ID
        AND t1.CreateDate >= '2015-07-31 00:00:00'
    LEFT OUTER JOIN dbo.table2 t2 ON t1.ID = t2.ID;

显然，第一个示例的含义是查询优化器将执行第JOIN一个， …

我最近将一个数据库恢复到它从（SQL Server 2008 R2 Enterprise）备份的同一个实例，发现我无法访问数据库属性。

我做了以下工作：

• 使用sp_helpdb.检查数据库所有者设置是否正确。
• 将数据库所有者更改为sa. 不是修复。
• 将数据库所有者改回我的sysadmin用户。不是修复。
• DBCC updateusage针对受影响的数据库发出。不是修复。
• DBCC CheckDB在恢复的副本上运行到另一个实例。没有发现腐败。访问数据库属性窗口时，恢复的副本（来自同一个备份文件）没有抛出任何错误。

任何人都可以帮忙吗？

尝试查看属性时收到的错误消息是：

无法显示请求的对话框。(SqlMgmt)
属性大小不可用于数据库“[DBNAME]”。
此对象可能不存在此属性，或者可能由于访问权限不足而无法检索。(Microsoft.SqlServer.Smo)

我是sysadmin这个实例的一个。

更新：按照建议，我创建了一个新用户，将其设为 sysadmin 并将数据库所有者更改为它。不幸的是不是修复。我将查看探查器跟踪是否会产生任何有用的信息。

更新：Aaron - 原始数据库已重命名并脱机，但仍在该实例上。然后使用原始名称恢复该数据库的备份。新数据库文件的文件名与原始文件名不同，因为它们与原始 mdf/ldf 位于同一文件夹中。恢复的数据库目前正在正常驱动我们的关键应用程序。

我有一个查询，它连接了几个表并且执行得非常糟糕 - 行估计偏离了（1000 次）并且选择了嵌套循环连接，从而导致多个表扫描。查询的形状相当简单，看起来像这样：

SELECT t1.id
FROM t1
INNER JOIN t2 ON t1.id = t2.t1_id
LEFT OUTER JOIN t3 ON t2.id = t3.t2_id
LEFT OUTER JOIN t4 ON t3.t4_id = t4.id 
WHERE t4.id = some_GUID

玩弄查询时，我注意到当我提示它对其中一个连接使用合并连接时，它的运行速度要快很多倍。这我可以理解 - 合并连接是连接数据的更好选择，但 SQL Server 只是没有正确选择嵌套循环。

我不完全理解的是为什么这个连接提示会改变所有计划运营商的所有估计？通过阅读不同的文章和书籍，我假设基数估计是在构建计划之前执行的，因此使用提示不会改变估计，而是明确告诉 SQL Server 使用特定的物理连接实现。

然而，我看到的是合并提示使所有估计变得非常完美。为什么会发生这种情况，是否有任何通用技术可以使查询优化器在没有提示的情况下做出更好的估计 - 考虑到统计数据显然允许这样做？

UPD：匿名执行计划可以在这里找到：https ://www.dropbox.com/s/hchfuru35qqj89s/merge_join.sqlplan?dl =0 https://www.dropbox.com/s/38sjtv0t7vjjfdp/no_hints_join.sqlplan?dl =0

我使用 TF 3604、9292 和 9204 检查了这两个查询使用的统计数据，它们是相同的。然而，被扫描/搜索的索引在查询之间是不同的。

除此之外，我尝试运行查询OPTION (FORCE ORDER)- 它比使用合并联接运行得更快，为每个联接选择 HASH MATCH。