lio*_*ori 6 sql-server transaction-log development
我正在寻找有关如何为开发团队使用的数据库设置事务日志的建议。这些数据库是短暂的,因为我们从不关心硬件/软件故障时的数据恢复。相反,每次开发人员开始一项任务时,他们都会创建一个新数据库并从头开始填充数据,因此他们也会在硬件出现故障时这样做。另一个用例是自动化测试,其中为每次测试运行创建一个新数据库。
目前,由于开发人员的使用模式(测试不同类型的查询,频繁的数据批量加载),日志增长了很多,而且更多的是障碍而不是帮助。我们已经看到这样的情况:在开发人员的工作仅一个小时后,日志就开始占用 0.5 TB,迫使他们手动截断日志。由于我们不想在自动化测试期间手动截断日志,我们需要为它们分配更大的机器。我怀疑需要更多 I/O,从而减慢操作速度。
我可以在 SQL Server 文档和其他材料中找到的任何建议都适用于生产服务器并专注于数据恢复,这与我正在寻找的完全相反。
当数据恢复无关紧要,而不是操作的难易性、资源使用和原始速度更受关注时,有关配置 SQL Server 的事务日志的一些好的做法是什么?
简单恢复模型并不意味着不使用事务日志。
这只是意味着 SQL Server 可以清空日志(也就是“截断”日志),而不必自己安排定期事务日志备份。即,日志需要空间用于最大/最早打开的事务,因为日志不能在最旧的事务之后被截断 - 无论恢复模式如何。
然而,简单确实意味着某些操作可以以最少记录的形式执行。这包括创建/更改/删除索引、SELECT INTO、批量加载数据以及如果星星正确对齐还 INSERT ... SELECT。
因此,如果 simple 不能为您解决空间使用问题,那么您必须研究操作是如何完成的 - 即,如我上面提到的,对开发人员进行最少日志记录的教育。
至于速度,最低限度的日志记录也会有所帮助,因为您的 I/O 较少。较大的事务(出于某种原因)意味着对 LDF 文件的同步 I/O 较少。从纯粹的配置方面来看,我想 ldf 文件的一些 RAM 磁盘选项可能会有所帮助 - 但如果您需要大型 ldf 文件,这可能不可行。
问题: “当数据恢复无关紧要,而不是操作的难易性、资源使用和原始速度更受关注时,有关配置 SQL Server 事务日志的一些好的做法是什么?”
恕我直言:
ALTER DATABASE ... SET DELAYED_DURABILITY = FORCED
Run Code Online (Sandbox Code Playgroud)
如何控制事务持久性
数据库级控制
作为 DBA,您可以使用以下语句控制用户是否可以在数据库上使用延迟事务持久性。您必须使用 ALTER DATABASE 设置延迟持久性设置。
ALTER DATABASE ... SET DELAYED_DURABILITY = { DISABLED | ALLOWED | FORCED }
Run Code Online (Sandbox Code Playgroud)
禁用 [默认] 使用此设置,在数据库上提交的所有事务都是完全持久的,无论提交级别设置如何 (DELAYED_DURABILITY=[ON | OFF])。无需更改和重新编译存储过程。这使您可以确保延迟的持久性不会使任何数据面临风险。
ALLOWED 使用此设置,每个事务的持久性在事务级别确定 - DELAYED_DURABILITY = { OFF | 在 }。有关详细信息,请参阅原子块级别控制 - 本机编译存储过程和提交级别控制 -Transact-SQL。
FORCED 使用此设置,在数据库上提交的每个事务都是延迟持久的。无论事务指定完全持久(DELAYED_DURABILITY = OFF)还是不指定,事务都是延迟持久的。当延迟事务持久性对数据库有用并且您不想更改任何应用程序代码时,此设置很有用。
听起来像是简单恢复模型的一个很好的候选者。
自动回收日志空间以保持较小的空间需求,从根本上消除了管理事务日志空间的需要。
这是一篇很好的文章,讨论了不同恢复模型的使用,然后讨论了收缩操作。一般来说,我不建议在 SQL Server 实例中收缩,但在您的场景中,磁盘空间至关重要,数据库使用情况是临时的,而且可能是多种多样的,因为听起来您做了很多测试,那么也许这是一个用例对于运行收缩操作是可接受的。
传统上,建议不要进行收缩,因为这是一项繁重的操作,运行起来通常会造成浪费,因为事务日志无论如何都会重新增长到所需的大小(并且增长操作也不是那么轻)。但在您的情况下,听起来您定期扩展新数据库并进行各种测试,在维护窗口期间缩小以回收一些磁盘空间可能是有意义的。
此外,您可以考虑在数据库上启用自动收缩,但强烈建议不要这样做,因为它会影响开发人员工作时全天的性能。在我看来,如果你要缩小规模,它应该是一个受控和计划的操作,在维护窗口期间完成,对开发人员的干扰最小。这是另一篇文章,介绍了自动收缩的工作原理。最后但并非最不重要的一点是,这里有一篇关于自动收缩的缺点的Brent Ozar好文章。
| 归档时间: |
|
| 查看次数: |
361 次 |
| 最近记录: |