DB2 UDB v8支持的备份与恢复功能<br />内容简介<br />设计周密的数据库备份与恢复策略，是建立稳定、可靠、安全的数据库应用环境的前提。本文简要介绍了IBM最新的关系数据库管理系统DB2 UDB v8所支持的各种数据库备份与恢复模式，实现相应模式所必须具备的条件，以及在制订数据库备份与恢复策略时应该考虑的一些问题。<br /><br />正文<br />在以IT架构为基础的现代生产环境中，数据是企业最宝贵的资源。数据的丢失往往意味着难以计量和弥补的损失。从这一角度出发，对数据进行备份与恢复，是数据库管理系统最重要的功能之一。是否具有灵活、健全的数据备份与恢复机制也是当前衡量一个关系数据库系统是否稳定，是否安全的重要指标。<br />为了更好的保护客户的关键数据，IBM DB2 UDB V8提供了健全的备份、恢复功能，以方便用户制订并实施满足自己业务需求的数据保护策略。<br />DB2支持的备份功能<br />数据库的备份与表空间的备份<br />根据备份的数据对象粒度来划分，DB2支持完整数据库的备份和对表空间的备份。<br />对完整数据库进行周期性的备份，是一个合理的数据备份策略中不可缺少的部分。进行完整数据库备份的频率越高，备份中的数据也就越接近当前。当问题出现，需要进行恢复时，所花费的时间和工作量也就相对越少。但是，进行完整的数据库备份需要占用大量的存储空间；备份所花费的时间也最长。所以，如何衡量二者的得与失，从而选择合理的备份周期，是系统管理员需要认真考虑的问题。无论如何，保留至少一份完整数据库备份是确保事故发生时，数据不会丢失的必要条件。<br />表空间的备份，相对完整数据库备份而言，所需要的空间较少。应用表空间备份最多的场合，是针对大数据对象进行备份。一般说来，如果用户的表中有Long Field或大对象（LOB）列的时候，为了方便集中管理，都会把这些数据统一存放在单独的表空间里。这些数据访问和修改的频率比较低。因此，并不一定需要和数据库中的其它数据同步进行备份。所以为了专门备份这些数据，用户可能会考虑采用表空间的备份。<br /><br />离线备份与在线备份<br />离线备份是指在数据备份过程时，只有备份程序可以连接到数据库上，其它任何程序在备份过程中都无法与数据库之间建立连接。而在线备份则不然，在备份过程中，其它应用程序依然可以连接到数据库上，可以执行查询、修改等操作。如果用户的数据库系统对数据库不可用的时间有严格的要求，可以使用在线备份。不过在线备份要求数据库被设置成为“可前滚恢复（Roll Forward Recover Enabled）”的状态，即要求对日志进行归档（设置数据库参数logretain或者userexit Enabled）。而且，在线备份相对而言比离线备份的速度慢。<br />表空间备份也可以在线进行。在备份过程中，表空间依然可以被应用程序所访问，备份过程中的修改被记录在日志中。<br /><br />增量备份<br />相对于其它的备份方式而言，增量备份可以大大减少存储备份文件所需要的空间。但是，缺点在于备份文件管理复杂度较高。<br />DB2支持的增量备份方式有两种，Incremental备份和Delta备份。<br />Incremental备份操作的起点是最近一次完整数据库备份操作成功的时刻，那一时刻之后发生的所有数据库修改，都将被Incremental备份所记录。如果多次进行Incremental备份，则会产生重复的备份记录。<br />        Delta备份操作的起点是最近一次数据库备份操作成功的时间，无论该次备份是完整数据库备份，Incremental备份或者是Delta备份。所有从那时刻之后发生的所有数据库修改，都将被Delta备份所记录。Delta备份不会产生重复的备份记录，但是管理备份历史和备份文件的难度更大。<br />        DB2也支持表空间和数据库混合的增量备份，但毫无疑问，这更增加了维护备份文件的复杂度，从而使数据恢复过程的难度也增大。<br />        执行增量备份要求设置数据库配置参数“trackmod”的值为“YES”。<br /><br />        备份的目标设备<br />        DB2在进行备份操作的时候，支持把数据备份到多种目标设备上，包括磁带设备，定义的磁盘路径，TSM服务器或者其它别的服务器上。<br />DB2支持的恢复功能<br />        DB2所支持的恢复模式包括中断恢复（Crash Recovery），版本恢复（Version Recovery）、前滚恢复(Roll Forward Recovery)和增量恢复。<br />        中断恢复的主要目的是帮助数据库在交易遇到意外的中断后，可以恢复到一致的，可用的状态。当意外的中断发生时，数据库的事务也许正处于一个不完整的状态，导致数据的一致性遭到破坏。当重新启动数据库的时候（Restart Database），数据库管理系统会自动提交已经执行完毕的事务，自动回滚没有进行完的事务，从而恢复数据的一致性，使数据库恢复到可以使用的状态。<br />        中断恢复在数据库没有遭到损坏的情况下，可以实现数据库的一致性。在数据库遭遇损坏，部分数据发生丢失的情况下，中断恢复就无能为力了。这时候，用户可以使用版本恢复功能或前滚恢复功能来修复受损的数据库。<br />        版本恢复就是使用先前完整的数据库备份文件来对数据库进行恢复操作。它可以把数据库恢复到备份完成的时刻。但自那以后所发生的数据库修改将会丢失。在多分区的数据库环境下，版本恢复操作必须在所有的分区上进行。当然它也要求每个分区上恢复操作所使用的数据是在同一时刻备份的。<br />        显然版本恢复需要用户定期的备份数据，备份的周期越频繁，产生的数据损失就越少。<br />        如果用户希望得到更强大的数据库恢复功能，可以考虑使用前滚恢复。前滚恢复可以把数据恢复到事故出现前的某一指定时刻或者恢复到事故发生的时刻。但它的要求也更苛刻，用户必须同时具有完整的数据库备份和归档的日志文件。<br />前滚恢复又可以分为两种情况，一种是数据库级别的前滚恢复，另一种是表空间级别的前滚恢复。对数据库级别的前滚恢复，用户首先使用完整的数据库备份进行一次版本恢复，然后把数据库日志记载的各种数据库修改再次应用到数据库上，从而把数据恢复到用户指定的时刻。如果用户是在多分区的环境下，进行恢复操作，必须保证所有的分区都被恢复到了同一水平。表空间级别的前滚恢复与数据库级别的前滚恢复雷同，但恢复所影响的范围只集中在某一个表空间上。<br />增量恢复的恢复过程相对比较繁琐。一般说来，进行增量恢复需要执行以下几个步骤：<br />1．确定恢复操作的最终状态，也就是说要把数据库恢复到哪一个备份时刻（假设为时刻T）；<br />2．利用最近一次的完整数据库备份进行版本恢复；<br />3．按照备份的次序恢复在T时刻前的各个数据库备份；<br />4．反复进行步骤3，直到恢复到T时刻的数据备份。<br />从恢复的过程可以看出，增量恢复要求用户对备份的文件有很好的管理，否则恢复操作就难以进行下去。<br />虽然用户可以在线进行数据库的备份，但数据库的恢复却必须离线进行。应用程序在数据库恢复过程中，不允许访问DB2数据库。唯一的例外是进行表空间的恢复时，被恢复的表空间处于不可用的状态，但其它表空间依然可以接受用户的访问请求。