问题标签 [recoverymodel]

我读了一些关于恢复/备份的在线书籍，一个愚蠢的问题，如果我使用完整数据库备份/完整恢复模式，对于备份操作本身，它会为源数据库服务器生成任何额外的事务日志吗？完全恢复操作会为目标数据库生成额外的事务日志吗？

我对 SQL Server 恢复和批量恢复模式有 2 个困惑。

1. 恢复过程本身是否会生成事务日志（这里我的意思是日志是恢复过程生成的日志——如果有，而不是由正常的数据库 DML/DDL 操作生成）？为什么？

2. 在批量恢复模式下，对A或B的理解是否正确（如果都不正确，请帮助纠正我，这是我的2个不同的理解，让我感到困惑）

A. 对产品数据库进行正常的DML/DLL批量操作（不是恢复操作）会产生最小量的日志，由于日志是最小的，利用日志的恢复过程，不能恢复批量操作中间的任何点；B. 对产品数据库正常的DML/DLL批量操作仍然会产生正常的大量日志（与非批量日志恢复模式相同），但恢复过程会将事务日志中的批量操作作为一个单元进行恢复，从而产生恢复过程本身的最少日志；

问候，乔治

数据库的恢复模型会影响 tempdb.mdf 的大小吗？

我们有一个涉及大量处理和批量插入的数据库。我们遇到了 tempdb 文件增长到非常大（超过 70 GB）的问题。有问题的数据库设置为完全恢复。将其更改为简单恢复（在具有所有事务而不是 tempdb 的数据库上）会阻止它在这些大型插入和批量加载上使用 tempdb？

我们的产品包含多个包含自定义应用程序安全信息的表格。在某些情况下，这些 securityinfo 表可能包含大量行（在一种情况下为 1300 万行），这些表用于加快查询速度，并且可能从头开始重建，但这在时间/处理能力等方面代价高昂。

应用程序的设计方式，更有效（在程序运行期间）删除安全部分的记录，然后插入新记录，而不是识别要保留/更新的记录并插入不存在的记录.

不幸的是，当数据库恢复模式设置为完整时，此过程会生成大量事务日志。

在 SQL 2005+ 中是否有可能在具有完整恢复模式的数据库中拥有一个未记录的表（简单恢复模式）？

我们可以在 Web 应用程序/数据库首次启动时重建 securityinfo 表以防恢复。

或者，具有简单恢复模型的并行数据库是最佳解决方案。

干杯蒂姆

假设我想在这种情况下恢复数据库：一方面没有备份，另一方面 - 所有更改都存储在日志文件中。我可以将数据库从日志文件恢复到特定的日期和时间吗？

SQL Anywhere 中的简单/完全恢复模式等效于什么？如何在恢复模式之间切换？我有一个数据库，我想在升级期间将其更改为简单恢复模式，这样日志文件就不会炸毁、淹没我们的写入缓存等。

我已经尝试过寻找这个，但也许我使用了错误的措辞，并且 SQL Anywhere 中不存在恢复模型。

提前致谢！

我们有一个生产服务器，大约有。50 个客户生产数据库正在运行，我们正在审查恢复模型，并想知道您对使用哪种恢复模型的所有建议。

我一直在做一些研究，但对于哪种模型最好，反应不一。

服务器场景是；

• 每天执行一次完整服务器备份（由云提供商执行）
• 目前没有定期备份所有数据库（因为它们在大约 6 个月前使用过）
• 存储在这些数据库中的信息/数据量因每个客户的需求而异 - 每个数据库

当前所有数据库都设置为简单恢复模式，这是在日志文件开始过度增长时决定的，这开始导致硬盘问题/空间有限并且无法建立与数据库的连接。自从更改为 SIMPLE 以来，它已经停止了 HDD 问题，但现在我们必须考虑如果发生灾难，数据库的恢复将是什么。

我期待您的回复/建议！

先感谢您

我们有一个处于完全恢复模式的生产数据库。

此数据库正在复制到另一台服务器。（事务复制）

我们在周五晚上运行维护工作，其中包括重建索引。

完成此维护工作后，事务日志备份文件非常庞大。

因此，我正在考虑在维护工作开始之前将恢复模型更改为简单，并在维护工作之后将其更改回完整。

这种方法会影响复制吗？

我知道复制可以与任何恢复模型一起使用，但不确定将恢复模型完全切换到简单然后简单到完全是否会对复制产生任何影响？

任何帮助/指导将不胜感激。谢谢。

数据库处于完全恢复模式，事务日志备份作业每 15 分钟运行一次。

以下操作序列是否会导致事务日志备份出现问题？

1. 禁用事务日志备份
2. 进行完整备份
3. 将恢复模式更改为简单
4. 执行维护工作，如索引重建、更新统计信息等...
5. 将恢复模式更改为完全
6. 启用事务日志备份

或者我应该在第 5 步之后进行完整备份以使事务日志备份正常工作？

谢谢。

We are using full recovery model in SQL Server. We have a job which merges from a staging table to the final table. The staging table is holding millions of rows. The final table is also huge with millions of rows. We are merging in batches of 10,000 rows.

The pseudo code is given for a single batch below:

The problem is, the batch operation is getting slower, for every new batch. When we restart the server, the batches are getting faster again. The transactions are not getting written to disk also and taking very long time to insert to disk. We suspect it to be problem with transaction log. When we reduce the batch size, more transactions are happening and batches are slowing down even more.

Is there a way to improve the performance of this kind of batched delete & merge operation? Do you recommend to use CHECKPOINT to force in full recovery model?