跳至主要內容

事务日志文件类型

正如在持久化数据库I/O页面中所解释的，每当将持久化数据写入数据库时，SmartEDB磁盘管理器会自动执行数据库日志文件更新。在发生硬件或软件故障时，运行时可以利用此日志恢复数据库。日志文件更新显然不会影响读性能，但会影响写性能，因为每个数据库事务都需要对文件系统进行一次写操作。

应用程序可以通过设置数据库打开参数LogType来确定日志文件的格式。以下是可供选择的日志类型：

- NoLog：非事务模式；禁用日志文件更新
- RedoLog：标准预写日志（WAL），通常也称为延迟修改日志，适用于有限大小的事务
- UndoLog：立即修改日志，记录即时更改

当创建数据库和日志文件时，应用程序必须选择一个LogType，并在整个数据库生命周期内继续使用相同的LogType（除非选择了NoLog，请参见下文）。这是因为不同的日志文件格式是不可互换的，且每种日志类型都有特定的参数配置。

下面的小节将详细介绍每种模式的具体实现。有关更多信息，请参阅持久化数据库I/O页面。下表提供了指向描述用于设置日志类型的特定本机语言API的页面链接。

非事务模式（NoLog）

请注意，这种模式存在一定的风险。如果选择此选项，日志文件更新将被关闭，并且不会创建日志文件。这将显著提高更新性能，但应用程序在发生崩溃时将无法恢复数据库，且事务回滚功能也不可用。当应用程序需要快速填充数据库文件时，此模式非常有用。然而，我们不建议在其他情况下使用此选项。

请注意，一旦创建了数据库文件，您可以使用下面描述的任何一种事务模式重新打开数据库。

提前写日志或延迟修改算法（RedoLog）实现
预写日志（Write Ahead Logging，WAL）是事务日志的一种标准方法。（有关RedoLog策略的详细讨论，请参阅持久化数据库I/O页面。）

当使用RedoLog策略时，所有由事务修改的页面都会“固定”在内存中。因此，事务大小受到页面池大小的限制。这个限制通常会阻止应用程序（包括xSQL）执行诸如创建表或索引等操作。实际上，事务大小受限于可用内存。

这里讨论的优化措施使得在许多情况下可以处理比页面池更大的事务。这些优化的核心思想是：新分配的页面可以直接写入数据库文件，而不是写入日志文件（必要时）。这些页面不会破坏数据库的一致性，因为所有对新页的引用（例如包含索引头的根页、位图页）在事务提交之前仍然保存在内存中。在提交过程中，数据库文件首先被更新（提交）到存储介质上。这确保了所有新页面都已保存到介质上。然后，RedoLog提交按正常流程进行；即，修改后的页面被写入日志，日志被提交（刷新），最后修改后的页面再写入数据库。

这种优化有其优点和缺点：优点是新页面只需写入磁盘一次，而不是像默认版本那样两次（仅更新数据库文件）；缺点是在事务提交期间，必须调用flush()两次，因为数据库文件和日志文件都需要提交到存储介质。

从这种优化中受益的场景包括创建新表和创建新索引（如SQL中的CREATE TABLE和CREATE INDEX操作）。但是，当索引非常大时，头页仍然需要固定在缓存中。同样，当执行大规模修改时（例如，在SQL中更新一个大表的所有记录，如UPDATE T SET x = x + 1），这种优化并不会带来明显的好处。

在内部，当需要开始替换页面池中的页面时，此机制总是启用；也就是说，当新的页面被无条件地推送到数据库文件时。在C应用程序中，通过设置mode_mask标志MCO_DB_REDO_LOG_OPTIMIZATION来启用这种优化。（默认情况下不启用）

对于xSQL，可以通过配置文件设置mode_mask标志。默认情况下，这种优化是关闭的。

日志文件大小控制与重做日志模式

当使用REDO模式时，通过参数redo_log_limit限制日志文件的大小。这是log_params结构的一个字段——dbparams的一部分。

该参数有一个对应的xSQL.cfg选项：

    # Log settings (mco_db_params_t::log_params)
    log_params: {
    ...
        # mco_log_params_t::redo_log_limit, unsigned
        redo_log_limit : 16m,
    ...

默认限制是16Mb。被截断时的实际文件大小是redo_log_limit的2倍，因此默认值是实际磁盘文件大小的32M。

即时修改日志记录（UndoLog策略）

正如在持久化数据库I/O页面中所解释的，当使用UndoLog策略时，日志文件包含允许取消当前事务更新的条目。

使用Undo Logging的优点是该算法永远不会耗尽内存，并且提供简单有效的恢复。然而，这种策略的性能通常比RedoLog慢，因为当提交到持久介质时，所有更新都被写入数据库文件（通常是随机访问的），因此比写入日志文件要慢。

选择日志文件类型

除了在持久化数据库I/O页面中提供的选择适当日志策略的指导方针之外，以下是为特定应用程序确定最佳日志文件类型的进一步建议。考虑以下两种常见的应用程序类别可能会有所帮助：

类型1：长事务应用

- 长期运行的事务
- 提交时对性能要求不高
- 空间受限的事务环境

类型2：短事务应用

- 短事务（如OLTP系统）
- 快速提交，适用于对吞吐量和延迟敏感的应用程序

一般来说，类型1的应用程序更适合使用UndoLog日志记录，而类型2的应用程序则更适合使用RedoLog日志记录。尽管日志文件类型的选择确实会影响性能，但RedoLog通常会提供更快的速度。然而，更直接影响应用程序性能的是何时将数据刷新到持久介质，这由事务提交策略决定。有关详细信息，请参阅持久化数据库I/O页面中的解释。首先，了解什么是数据库事务以及如何管理它们是非常重要的。

设置日志文件类型和参数

设置日志文件类型和参数的 API 与所使用的编程语言相关。请使用以下链接查看您开发环境的详细说明和示例：

开发语言说明
C / C++在C / C++语言中设置日志文件类型和参数
Java在Java 语言中设置日志文件类型和参数
Python在Python 语言中设置日志文件类型和参数
C#在C# 语言中设置日志文件类型和参数