数据库事务日志对于数据库恢复至关重要，也是设计高度可用的数据库解决方案的一个重要组成部分。 数据库日志使得从故障中恢复成为可能。它们还可以在 HADR 环境中同步主数据库和备用数据库。 DB2 对每个数据库使用一组独立的日志文件。 所有数据库都有与自己
事务日志对于恢复至关重要，也是设计高度可用的数据库解决方案的一个重要组成部分。 数据库日志使得从故障中恢复成为可能。它们还可以在 hadr 环境中同步主数据库和备用数据库。 db2 对每个数据库使用一组独立的日志文件。 所有数据库都有与自己有关联的日志。这些日志保留数据库变更的记录。如果数据库需要还原到最后一次完整离线备份之前的某个点，日志需要将数据前滚到故障点。db2 数据库支持两种类型的数据库的日志：循环日志和归档日志。
循环日志
循环日志仅支持崩溃恢复，也就是说，如果 DB2 实例因某种原因（比如，电源故障或用户操作错误）而发生崩溃，那么下一次数据库重新启动就会使用日志文件的信息，将数据库带回一致的状态。 在崩溃恢复期间，尚未写入磁盘的所有已结束的、已提交的或中止的事务都会写入到磁盘中。所有打开的、尚未提交的事务都被回滚，以删除部分的变更。 在开发和测试环境中，您可以使用循环日志。在这些环境中，为了简化数据库管理，事务日志不是必需的，可以使用循环日志。
归档日志
选择归档日志的好处是，前滚恢复可以使用归档日志和活动日志，将数据库还原到日志末尾或某个特定的时间点。 可以使用归档日志文件在数据库备份后恢复变更。这种类型的日志与循环日志不同，使用循环日志，只能恢复到备份的时刻，之后所做的所有变更都将丢失。
在数据库创建时，默认的日志类型是循环日志。可以通过更新 logarchmeth1 或 logarchmeth2 数据库配置参数来启用归档日志。在修改参数设置后，需要执行一次离线数据库备份，以便能够访问数据库。
配置事务日志
DB2 支持若干种媒体类型，以便实现日志归档，如 DISK、TSM （即 Tivoli® Storage Manager 支持）、VENDOR （即第三方库支持），或使用 USEREXIT 设置的客户程序。您可以将 logarchmeth1 数据库配置参数设置为任意可能的有效值。不过，logarchmeth2 数据库配置参数只支持 OFF、DISK、TSM 和 VENDOR 值。 OLTP 工作负载的性质对事务日志设备的响应时间和吞吐量提出了很高的要求。为了获得最佳性能和可用性，应将事务日志放在专用的、更快的设备上，并且使用单独的文件系统。为了提高性能，不要与任何其他数据库存储对象（如，表空间）共享事务日志文件系统或 I/O 带宽。 默认情况下，事务日志的目录被设置为数据库目录。通过设置 newlogpath 数据库配置参数，可以修改该目录。 为了防止流氓应用程序占用所有事务日志空间并影响数据库，可以考虑对事务日志使用以下数据库配置参数：
num_log_span 参数指定了是否限制一个事务可以跨越多少个日志文件，该限制是多少。
max_log 参数指定是否有限制一个事务可以消耗的日志空间的百分比，该限制是多少。
blk_log_dsk_ful 参数防止当 DB2 数据库管理器在活动日志路径不能创建新的日志文件时，生成日志空间已满的错误。DB2 数据库管理器不会生成磁盘已满的错误，而是每 5 分钟试图创建一次日志文件，直到成功为止。
您可以使用 IBM InfoSphere Optim™ Performance Manager 中的记录仪表板和警报阈值来监视日志空间利用率，并确定是否需要修改日志空间配置。
镜像日志路径
您可以使用 mirrorlogpath 数据库配置参数为事务日志设置备用路径。如果设置了此参数，数据库管理器将在日志路径和镜像日志路径中都创建活动的日志文件。所有日志数据都被写入这两个路径中，这增加对日志文件的意外丢失的保护。
为了从镜像日志路径获得最大利益，并且不会降低性能，我们建议镜像日志路径使用快速专用设备。如果将镜像日志路径放在与日志路径相同的设备或文件系统上，则有可能导致 I/O 带宽成为瓶颈。此外，它只能在几个场景中保护您，无法保护设备或文件系统全部损失的情况。
为了从镜像日志路径获得最大利益，并且不会降低性能，我们建议镜像日志路径使用快速专用设备。如果将镜像日志路径放在与日志路径相同的设备或文件系统上，则有可能导致 I/O带宽成为瓶颈。此外，它只能在几个场景中保护您，无法保护设备或文件系统全部损失的情况。 如果您想使用镜像日志路径，那么您的需求评估中的某些因素会受到影响。您需要双倍的事务日志存储空间，并增加 I/O 带宽。
数据和索引压缩
数据和索引压缩可能有助于减少事务日志的大小。如果您使用 DB2 压缩功能，作为 INSERT、UPDATE 和 DELETE 活动的结果被写入日志记录中的用户数据就会较小。然而，某些 UPDATE 日志记录在压缩后可能比不使用压缩时更大。 除了压缩之外，您还可以通过其他操作尽量减少日志空间的消耗。将更新得较频繁的列分组在一起，并将它们放在记录定义的末尾或接近末尾的地方，这样做可以最大限度地减少日志空间消耗。即使有一个良好的压缩比，OLTP 工作负载仍无法从更好的事务响应时间或吞吐量中获益。因为数据和索引压缩可以减少表空间 I/O 和日志 I/O，所以可以在压缩后的数据上以相当短的时间完成数据库备份和归档日志等管理任务。
最佳实践
将以下设计最佳实践用于数据库日志：
在生产环境中使用归档日志，以便能够执行许多恢复操作，这些操作包括在线备份、增量备份、在线还原、时间点前滚，以及发出 RECOVER DATABASE 命令。
考虑对增量备份启用 trackmod 数据库配置参数，以便跟踪数据库的修改，这样 BACKUP DATABASE 命令就可以确定哪些数据库页面的子集应包含在数据库备份或表空间备份的备份映像中。
使用镜像日志路径增加高可用性。
配置辅助日志文件，临时提供额外的日志空间。
使用数据和索引压缩来提高数据库和表空间备份等管理任务的性能，因为在压缩数据上执行备份所需的时间较短。
考虑事务日志的 I/O 适配器或总线带宽要求。如果要求不够充分，则可能导致 I/O 使用中出现瓶颈。如果担心高可用性，请查看 I/O 多路径的操作系统级支持。
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至253000106@qq.com举报，一经查实，本站将立刻删除。
发布者：PHP中文网，转转请注明出处：https://www.chuangxiangniao.com/p/1802394.html
