标签: sql-server-2019

我试图从 MDF 文件中附加一个数据库，导致服务器崩溃并且永远找不到 LDF。我在 2019 年的 MS SQL Server 上。我正在按照此页面的说明进行操作。我已经创建了数据库，将其脱机并交换了我的 MDF 并删除了创建的 LDF。然后重新上线。当我运行以下命令时，我得到以下信息：

UPDATE sysdatabases
SET status = 32768
WHERE name = 'MyDB'

Ad hoc updates to system catalogs are not allowed.

我运行上一个命令没有问题

USE MASTER
GO
sp_CONFIGURE 'allow updates', 1
RECONFIGURE WITH OVERRIDE
GO

Configuration option 'allow updates' changed from 0 to 1. Run the RECONFIGURE statement to install.

此外，如果我运行下一个命令，我会得到以下信息：

DBCC TRACEON (3604)
DBCC REBUILD_LOG(Database_Name, 'g:\Program Files\Microsoft SQL Server\MSSQL15.AUS\MSSQL\Data\MyDB.ldf')
GO

DBCC execution completed. If DBCC printed error messages, …

我正在阅读 Carter 的“Pro SQL Server 2019 Administration”一书，在详细介绍 HA 和 DR 选项时，没有提到“复制”：

为什么省略？复制会很快被弃用吗？

我需要帮助了解我的选择。鉴于：

• 由 DBA 维护的 SQL 服务器集群设置。
• 系统尚未投入生产（未交付给客户）。
• 最初的大量数据推送，几天没有中断
• 我可以随时停止和开始推送数据并更改数据库。基本上我可以停止所有输入。

我建议我们的 DBA 切换到简单模式，因为我们在活动监视器中看到一堆处于等待状态的查询，这最终会导致应用服务器出错。

我以前从未遇到过这个问题，在消除过程中，我看到我们处于完全恢复模式而不是简单模式。

我要求我们从 FULL 切换到 SIMPLE，这是我得到的答复。是否还有其他选项可能是 DBA 不知道的？

我能提供什么帮助？

“我们无法在 SQL 中使用 AlwaysOn 切换到简单。”

我可以在初始加载阶段关闭 AlwaysOn 还是我运气不好？

- - 添加 - -

我有两个关于MS-SQL-Server 2019的索引管理的问题

1. 如果在执行计划中出现了“表扫描”这个词，是否是“全表扫描”的指示，也就是说这里没有使用索引？

2. 我不确定 MS-SQL 是否会使用我的索引。但我也不知道如何找出它实际使用的索引。

对于这个连接，我在 F_Skonto 表上创建了一个索引，其中包含 gueltig_ab、gueltig_bis 和 CD_Kunde 三个列。那是对的吗？

LEFT OUTER JOIN dbo.F_Skonto 
    ON S631_BSA.SPTAG >= dbo.F_Skonto.gueltig_ab 
    AND S631_BSA.SPTAG <= dbo.F_Skonto.gueltig_bis 
    AND S631_BSA.PKUNRG = dbo.F_Skonto.CD_Kunde

对于这个连接，我在表 F_Umstellkosten 上创建了一个包含 Monat 和 CD_Kunde 两列的索引。那是对的吗？

LEFT OUTER JOIN F_Umstellkosten AS u1 
    ON CONVERT(varchar(6), v1.Tag, 112) = u1.Monat 
    AND v1.CD_Kunde = u1.CD_Kunde

假设我有以下情况：

事务 1 使用 WHERE 子句执行 UPDATE，但尚未提交。

UPDATE TBL SET VAL1=10 WHERE VAL2=100

事务 2 尝试 SELECT 不属于上述 WHERE 子句的行。假设存在索引，并且数据库引擎决定对表、页采用 IX 锁，对属于 WHERE 子句的行采用 X 锁，则该查询将起作用。

现在，假设事务 2 是对不属于 SELECT 查询的 WHERE 子句的行的 UPDATE 查询。

UPDATE TBL SET VAL2=100 WHERE VAL1=500

当上面的查询运行时，假设如上所述持有相同的锁，则会导致更多行满足 VAL2=100 条件（这也是第一次 UPDATE 中的 WHERE 子句）。SQL如何处理这种情况呢？

例如，当sql server看到事务2的更新时，它是否意识到这一点并将事务1的锁升级为表锁，并且不允许事务2的更新发生？

在本地，我们在READ_COMMITTED隔离级别下使用 SQL Server 2019 标准版，我想测试一个数据库的执行情况READ_COMMITTED_SNAPSHOT（Azure 默认值）。

查询存储已启用。

我想记录READ_COMMITED一周的一些指标（CPU 使用情况、tempdb 使用情况、IO），然后使用READ_COMMITTED_SNAPSHOT. 然后，如果性能更好（这是我所期望的），则计划如何（如果）扩展资源以激活所有数据库的隔离级别。

我们有记录 CPU 使用情况的工具，但没有记录 tempdb 的工具。我想知道是否有一个查询或实用程序可以用来获取当前 tempdb 使用情况（例如给定时刻的 20-50-70%）并创建此类日志？

我对 tempdb 很感兴趣，因为行版本将存储在那里，并且我担心一些遗留代码和繁重/长时间运行的更新，我可能需要首先重写这些更新才能切换隔离级别。

我正在寻找这些数据，因为有很多遗留代码执行速度很慢并且会阻止其他查询。我有以毫秒为单位执行的新代码，但有时，由于长时间运行的 CRUD 操作和阻塞，它会执行 25 秒以上，这很糟糕。我正在重写此类遗留代码，但有时特定情况会花费我几天的时间，有时甚至几个月。当然，客户不愿意等待......

完整的实际计划在这里。

在执行计划之前（因为我正在调试一个运行不佳的计划），我有这个变量赋值块：

DECLARE @Days INT = 180
DECLARE @DateRangeFrom DateTime = DATEADD(d, -@Days, getDate())
DECLARE @DateRangeTo DateTime = getDate()
DECLARE @FacilityID INT = 1010
DECLARE @Answer0 INT = 1879
DECLARE @Answer1 INT = 1949
DECLARE @Answer1SetID INT = 1607
DECLARE @Answer2 INT = 1907
DECLARE @Answer2SetID INT = 1593

我的第一个问题是在 IRItemAnswer_Info 表（节点 ID 19）上执行的查找。它溢出到 Tempdb，它已经以错误的方式开始查询。它引用IRItemAnswerInfo_DGItemID_AnswerSourceID索引，这是正确的索引，因为我正在匹配DGItemID和AnswerSourceID，然后返回IncidentID。索引创建为

CREATE NONCLUSTERED INDEX IRItemAnswerInfo_DGItemID_AnswerSourceID
ON dbo.IRItemAnswer_Info (DGItemID, AnswerSourceID) 
INCLUDE([IncidentID], [AnswerBoolean])

但是，查询的估计行数为 53,459，实际行数为 969,812。

我刚刚完成强制通过新的统计数据UPDATE STATISTICS IRItemAnswer_Info …

我正在尝试将工作中 SQL Server 实例上的小型数据库的结构和内容复制到我家用计算机上的实例。看起来这应该是一个简单的、两分钟的操作，但是当我按照手册所说的去做时，九个表中只有四个实际上在我的家用计算机上恢复了。至于为什么其他五个表被排除在外，没有明显的规律或理由。这是一个入门数据库项目，暂时没有什么花哨的东西——只有九个简单的表，甚至还没有应用任何约束或触发器。

我不是一个经验丰富的 DBA。我想我以前做过这件事，没有发生任何事故，但我不太记得了。这种事情不是我的正常工作。我是否可能会犯任何新手错误——我需要重写任何无意义的默认 SSMS 设置才能使所有 DBA 任务中最基本的任务真正发挥作用？

AdventureWorks2019数据库查询：

SELECT * FROM HumanResources.Department D INNER JOIN HumanResources.EmployeeDepartmentHistory E ON D.DepartmentID = E.DepartmentID

问题：为什么以下查询没有返回任何数据。我期望它为我的上述测试查询返回至少一行。我在这里可能遗漏或误解了什么？

select 
    query_text_id, 
    query_sql_text as query_sql_text 
from sys.query_store_query_text where query_sql_text like '%SELECT * FROM HumanResources.Department D INNER JOIN HumanResources.EmployeeDepartmentHistory E ON D.DepartmentID = E.DepartmentID%'

参考：sys.query_store_query_text

查询存储在默认配置下打开。

我在查询存储中强制执行了一个计划，如下所示

EXEC sys.sp_query_store_force_plan @query_id = 113366, @plan_id = 3687662

但是当我再次运行查询时，查询不使用该计划，也不显示failure_force_reason

以下查询显示该计划已被强制，并表明上次运行时强制没有失败

SELECT  plan_id,
        query_id,
        is_forced_plan,
        last_force_failure_reason_desc
FROM    sys.query_store_plan
WHERE   is_forced_plan = 1

以下查询显示了相关查询的最后一次运行时间，这向我证实，我确实重新运行了这个查询，并且它使用了与我强制执行的计划不同的计划：

SELECT  TOP 1
        q.query_id,
        p.plan_id,
        s.last_execution_time,
        SYSDATETIMEOFFSET() AS CurrentTime
FROM    sys.query_store_query q
        JOIN sys.query_store_plan p
            ON q.query_id = p.query_id
        JOIN sys.query_store_runtime_stats s
            ON s.plan_id = p.plan_id
WHERE   q.query_id = 113366
ORDER BY s.last_execution_time DESC

为什么查询存储似乎忽略了这个计划的力量？我可以利用任何扩展事件或其他故障排除工具来了解吗？