我们配置了完整备份和日志备份。
在恢复过程中,我们应用完整备份和后续日志备份。
我知道,如果我进行手动完整备份(非仅复制模式),那么它将破坏差异链。但在本例中没有差异备份。然而,存在事务日志链。由于仅非复制完整备份,该链是否会受到负面影响?
按 LastName、FirstName、MiddleName 的顺序设置单个非集群。
SELECT * FROM PERSON
WHERE FirstName='xyz'
Run Code Online (Sandbox Code Playgroud)
为什么执行计划使用索引而不直接扫表?我问是因为名字是索引的第二个成员,因此没有排序,那么为什么 SQL Server 决定查询非聚集索引?
我正在将 sql server 从 2016 年迁移到 2019 年。我了解,默认情况下,迁移后数据库将保留现有的兼容性级别。升级兼容性级别可启用新功能。
Microsoft 建议采用以下方法来升级兼容性级别以避免回归:
兼容性级别升级是否会导致任何破坏结果?或者查询回归(我认为这意味着由于错误的执行计划选择而导致查询比平时花费更多的时间)是兼容性升级的唯一负面影响吗?
当我们进行完整数据备份(使用 SSMS UI)时,在窗口底部,我们可以选择将目标指定为磁盘,也可以添加多个文件。
我的问题是 - 添加多个文件是否会创建完整备份的重复副本?或者它是否创建了一个分割备份——即将完整备份分割成指定的文件?
这个问题纯粹是由于锁资源导致的死锁。
我正在阅读这篇文章:使用聚集索引解决 SQL Server 死锁问题
他们解释了如何添加非聚集索引或聚集索引解决死锁问题。
一般的想法是 - UPDATE 查询不会因为索引查找而阻塞,这将导致只有少数行被锁定。
然而,SQL Server 的工作方式是 - 引擎在任何时刻(例如在 5000 个行级锁之后 [来源:https ://www.youtube.com/watch ?v=EqfAPZGKifA at 30:25])决定提升lock 为页级锁或表级锁,从而锁定整个对象(例如表)。那么本文给出的解决方案——添加聚集索引是解决死锁的办法——可靠吗?
假设我将 SQL\xc2\xa0Server 内存限制为 100\xc2\xa0GB。
\n这是否仅将缓冲区限制为 100\xc2\xa0GB 还是也限制了查询内存授予?
\n假设数据文件位于 D: 且日志文件位于 E:
假设 E 驱动器崩溃并且日志文件 (.ldf) 丢失。我将一个新的空磁盘附加到 E: 并启动 sql server。
启动时,SQL Server 将意识到 .mdf 文件存在,但日志文件不存在。由于丢失日志文件,SQL Server 将无法执行任何撤消/重做恢复步骤,并将数据库置于可疑位置。
注意:我尝试了此操作并注意到数据库进入可疑模式。这里的最佳实践是使用备份(完整+tlog)来恢复数据库。在我的情况下,我有上午 12 点的完整备份,但没有 tlog 备份。如果我从凌晨 12 点的备份中恢复,那么我会丢失一整天的数据(假设崩溃发生在中午)。我正在尝试思考如何利用现有的数据文件来处理这种情况。
假设 dbcc checkdb 在一页上显示损坏。
假设我想通过仅恢复损坏的页面来修复此问题。
所以我进入恢复页面用户界面,单击按钮找到损坏的页面,输入完整和日志备份文件并恢复。
我的问题是 - sql 服务器检查给定完整备份中页面是否损坏的方式是什么?
我正在查看dm_exec_sessions并请求生产服务器上的 DMV。有些查询的状态为“已暂停”,持续时间为 12 分钟,等待类型为ASYNC_NETWORK_IO。
我理解这是因为客户端应用程序获取数据的速度不够快(或者结果太大以至于客户端程序需要时间来消耗它)。
这样的查询(由于正在进行的查询而暂停ASYNC_NETWORK_IO)是否会导致该表阻塞?
该查询是 a SELECT,我看不到该查询阻止任何其他查询。因此我要问的问题是它是否有可能阻止任何东西。
例如:是否ASYNC_NETWORK_IO意味着执行正在进行或执行已完成并且客户端应用程序正在提取数据?在后一种情况下,我不明白为什么这个查询可能会阻止其他查询,因为它已经产生了结果。
查询持有的锁如下:
SIS