当DB2数据库第一次被创建的时候，有3个日志文件，被称做主要日志文件，作为创建过程的一部分被分配了。在Linux和Unix平台上，这些日志文件共有1,000个大小为4KB的页面;在Windows平台上，这些日志文件共有250个大小为4KB的页面。然而，被使用的主要日志文件的数量，连同每一个能够容纳的数据量，都被数据库配置文件中的logprimary 和logfilsiz 参数所控制。所有被创建的主要日志文件的使用方式都由为数据库选择的日志策略所决定。有两个可使用的不同的策略，一个是循环日志，一个是档案归建日志。但是一种被称为无限活动日志的混合方式也许工作得最好。

　　循环日志要求存储在日志缓冲区的记录以循环的顺序被写入主要日志文件。一旦主要日志文件被写满，并且仍被标记为“不可用”，DB2数据库管理器就会分配次要日志文件，并且将记录写入其中。被允许的次要日志文件的总数由数据库配置文件的logsecond参数控制。

　　在档案归建日志中，与循环日志类似，存放在日志缓冲区的日志记录被写入预先分配的主要日志文件中。然而，与循环日志不同的是，这些日志文件永远不会被重用。每次当主要日志文件被写满的时候，另一个主要日志文件就会被分配，这样所要使用的主要日志文件的数量(由数据库配置参数logprimary指定)就总是可得的。只要磁盘还有空间，这个过程就会持续下去。

　　无限活动日志。你也许考虑通过简单地配置数据库，让其使用大量所需的主要和/或次要日志文件来避免日志空间被全部用光。然而，被允许的日志文件(主要的和次要的组合在一起)的最大数量是256个，并且如果你的日志文件的尺寸相对较小，那么当事务的工作量变大或者是事务运行了过长的时间，你仍然有可能很快地用光全部日志空间。而且，由于每次被迫分配日志文件的时候都会影响性能，你就会想要尽可能地避免分配大量的次要日志文件。理想情况是，你希望分配足够的主要日志文件来应付大多数情况，并且使用刚好可以应付事务的工作量最高峰时的数量的次要日志文件。如果你非常关注日志空间的消耗殆尽，并且你想要避免分配大量的次要日志文件，那么你可以配置数据库，使其执行一种被称为无限活动日志或者无限日志的策略。无限活动日志允许一个跨越所有主要日志和一个或多个档案归建日志的活动事务，并且有效地允许事务使用无限数量的日志文件。为了能够使用无限活动日志，你只需简单地设置数据库配置参数userexit 和logsecond 分别为yes 和 –1。注意到下面这一点是很重要的，即当数据库配置参数userexit设置为yes时，每当日志文件被关闭的时候，一个用户提供的userexit 程序就会被调用，并且这个程序会将不需要的日志文件移动至另一个可以永久存储的位置(因此，服务器上日志存储空间被消耗殆尽的危险就会被消除)。

　　当服务器配置参数logsecond被设置为-1时，配置参数logprimary和logfilsiz仍然用于指定DB2在活动日志路径上保留多少个主要日志文件，以及每个文件应该有多大。如果DB2需要从一个日志文件中读取日志，但是这个文件不在活动日志路径上，DB2就会调用userexit 程序从存档文件中检索日志文件，并且将其拷贝至活动日志区域，这样其他针对相同文件的读取就会加快速度。DB2管理着这些所需日志文件的检索、拷贝和移除。

　　注意：虽然无限活动日志可被用于支持那些大的作业环境，它们需要的日志空间超出了正常情况下分配的主要日志空间，但是它仍然有它的权衡点。特别是，回滚操作(无论是在savepoint级，还是在事务级)的执行，会由于需要在档案存储地点检索日志文件而变得非常缓慢。同样地，崩溃恢复也会由于同样的原因而变得很慢。

DB2 Web 服务提供者的安全性 实现对 DB2 UDB 的低层访问控制

评论 (0) All