当前位置:首页 » 软件开发
开发技术指南» 文章正文
    引言: Jianing Fan 软件工程师,Motorola 2004 年 3 月 本文将详细讨论如何配置和管理逻辑日志。
 

 

    摘要:ravi veduladb2 dba, wipro technologies 2003 年 10 月 本文展示了将 db2 udb 历史文件放入一个表中,再以这个表为基础执行管理任务的一种方法。 简介 db2® universal database™ (udb) 历史文件包含了恢复事件和管理事件的记录,它与 os/390® 系统下 db2 中的 sysibm.sy......
 ·gui 工具简介(第 2 部分)    »显示摘要«
    摘要:raul f. chongdb2 universal database consulting services, ibm 多伦多实验室 2003 年 7 月 raul chong 继续对与 db2 udb express 一起提供的 gui 工具进行介绍。在第 2 部分,他讲到了如何利用这些 gui 工具自动化数据库任务和进行基本的性能调优,他还讲到了与这些 gui 工具本身相关的故障诊断与排除......


逻辑日志的使用情况
jianing fan

软件工程师,motorola 【程序编程相关:构建 ASP.NET Web 站点

【推荐阅读:处理 DB2 UDB 表中的数据

2004 年 3 月 本文将详细讨论如何配置与管理逻辑日志.本文还将通过一个实际生活中的例子演示如何估计与预测逻辑日志的使用情况.

简介 【扩展信息:Add-In Technical Pre

逻辑日志(logical log)是数据库管理的一个重要方面.如果没有得到适当的管理,逻辑日志将给数据库管理员带来许多头痛的事.最常见的一些问题是:

长事务(long transaction).如果一个事务达到独占长事务高水准线(exclusive long transaction high water mark,eltm)时还没有提交或回滚,我们就说该事务是长的.独占长事务高水准线是一个配置参数,该参数规定单个事务能横跨逻辑日志多大的百分比.只要一个事务达到了在一个 informix dynamic server 配置文件中设置的 eltm,服务器将中止该事务,并开始回滚该事务.在回滚期间,服务器将挂起进一步的数据库操作,前端用户将在他们的应用程序中遭遇中止. 灾难恢复(disaster recovery).如果我们丢失了任何逻辑日志,那么在遇到灾难时,我们能选择的恢复策略就要受到限制.我们只能执行代码恢复(cold restore).热恢复(warm restore)是不可能的,因为 informix dynamic sever 需要检查所有逻辑日志来重新应用自上一次备份之后的数据库事务.结果就是数据丢失. 慢性能(slow performance).如果没有将逻辑日志放在适当的位置,例如,如果我们将逻辑日志放在 root dbspace 中,或者磁盘上其他的热点(hot spot)中,那么系统与服务器的整体性能就会遭殃. informix dynamic server 中止.如果没有正规地备份逻辑日志,并且在系统中使用了所有的逻辑日志,那么 informix dynamic server 将中止,并挂起其他数据库连接与操作.

本文将详细讨论如何配置与管理逻辑日志.本文还将通过一个实际生活中的例子演示如何估计与预测逻辑日志的使用情况.

什么是逻辑日志?

逻辑日志实际上是一组文件,这些文件保存了自上次 0 级备份以来数据库事务与数据库服务器变更的历史记录.逻辑日志文件不是普通的操作系统文件.它们是由 informix dynamic server 在第一次初始化期间自动创建的,由 informix dynamic server onparams实用程序管理.逻辑日志文件是循环的.换句话说,在它们被填满之后,又可以一次接一次地重复使用.但是,对于重用有一定的条件:

必须备份逻辑日志文件.默认情况下,当日志文件被填满时,informix dynamic server 服务器将自动备份逻辑日志文件.这是由配置文件中的 alarmprogram 参数规定的.应该总是将该参数设置为一个名为 log_full.sh 的脚本,该脚本会进行逻辑日志文件的备份.log_full.sh 是随 informix dynamic server 软件包一起提供的一个服务器系统脚本. 逻辑日志中的所有记录都必须与关闭的事务相关联.这里提到的关闭的事务,是指要么提交要么回滚了的事务.如果一个事务悬而未决,而在逻辑日志中又有与之关联的一条记录,那么该逻辑日志就不能重用. 逻辑日志决不能包含最后检查点记录. onstat -l输出可以告诉我们那个逻辑日志包含了最后检查点记录:如果在输出中标志字段的最后一位是“l”,那么表明逻辑日志包含了最后检查点记录,因而不能重用. 逻辑日志决不能包含任何没有刷新到磁盘的事务.这是为了确保所有事务不会丢失.当一个事务完成时,它呆在逻辑日志中,等待检查点的到来,以便刷新到磁盘.如果我们在检查点之前重用逻辑日志,那么将丢失所有那些事务.

在配置逻辑日志时,我们需要注意以下问题:

大小.逻辑日志文件的适当大小介于 200 kb(最小)与 2,097,152 kb(最大)之间.这是一个很宽的范围,也没有什么难于遵循的规则.基本上,更小的逻辑日志文件有更小的恢复粒度.如果包含逻辑日志文件的磁盘崩溃,那些上次没有备份的逻辑日志文件就有丢失的风险. 数量.至少应该总是有三个逻辑日志文件,最多可有 32,767 个.这同样是个很宽的范围.请根据生产环境来作出决定.逻辑日志文件的数量决不能超过配置文件中 logmax 参数的值.不过,在 informix dynamic server 9.40x 该限制已被撤销. 位置.逻辑日志文件的位置相当重要.当 informix dynamic server 进行第一次初始化时,它自动地创建逻辑日志文件,并将这些文件一起放在 root dbspace 中.逻辑日志将导致大量向 root dbspace 的磁盘写操作,而那里存储了所有重要的系统统计信息,这样就可能导致磁盘 i/o 争用.为了最小化 root dbspace 的磁盘争用,以提高整个系统的性能,应该将逻辑日志移出 root dbspace,而将它们分布在其他磁盘设备中. 备份.在添加新逻辑日志之后,要做一次备份,可以是实备份(使用实备份设备),也可以是“假”备份(使用 /dev/null).否则,informix dynamic server 就不能使用那些新添加的逻辑日志.这一限制在 informix dynamic server 9.4x 中已被撤销,在那里,informix dynamic server 可以在将逻辑日志添加到系统之后马上使用它们. 在任何时候都要维护最少情况下的三个逻辑日志.否则 informix dynamic server 将不能启动.

此外,下面有一些性能方面的考虑:

逻辑日志备份.当逻辑日志被填满时,必须备份它们.备份逻辑日志时将占用系统资源,例如 cpu 与内存,并且妨碍那些涉及与逻辑日志存放在相同磁盘上的数据的事务. 检查点.检查点阻塞用户或数据库事务处理.如果频繁地备份与释放逻辑日志,那么检查点将经常出现,结果就是数据库事务可能会经常被阻塞,从而占有更长的时间才得以完成. 数据库事务日志记录的类型.使用无缓冲日志记录的数据库会比那些使用缓冲日志记录的数据库更快地填充逻辑日志.

要了解关于如何有效地配置逻辑日志的细节,请参考 ibm informix dynamic server administrators guide, version 9.4(在本文中引作 administrators guide)的第 13 章.


...   下一页
 · db2 基础: 表空间和缓冲池    »显示摘要«
    摘要:david kline,db2® vendor enablement, partnerworld® for developers, ibm®开发人员技术支持(developer technical support,dts)中心 — 达拉斯 gabor wieser, db2® vendor enablement, partnerworld® f......
» 本期热门文章:

©2000-2007 All Rights Reserved. 最佳浏览:1024X768 MSIE