备份与恢复的概述
本章节介绍备份与恢复的概念和有关计划备份与恢复操作的信息。
备份与恢复的概念
GBase 8s 提供用于备份与恢复数据库服务器数据的实用程序onbar 和 ontape。这两个实用程序将备份与恢复存储空间和逻辑日志。但是,它们支持不同的功能部件,因此请务必了解其差异。这些主题说明了 GBase 8s 数据库服务器备份与恢复的基本概念,并比较 onbar 和 ontape 实用程序。
onbar 使用存储管理器对存储空间(数据库空间)和逻辑文件进行备份与恢复,但 ontape 不使用存储管理器。
备份系统
恢复系统包含备份与恢复系统,它允许您备份数据库服务器的数据,并在当前数据毁坏或无法访问的情况下随即恢复备份的数据。
数据毁坏或丢失的原因可能从程序错误到磁盘故障,或直到损坏整个设备的灾难性事故等。恢复系统使您可以恢复在类似的灾难性事故中丢失的数据。
备份系统
备份是数据库服务器维护的一个或多个数据库空间(也称为存储空间)和逻辑日志的副本。您还可以备份 Blob 空间和智能大对象空间。
备份副本通常会写入辅助存储介质,例如磁盘、磁带或光盘。以脱机方式存储介质,并且如有可能,请保存一个非现场的副本。
数据库备份不会替换常规的操作系统备份,后者备份除了 GBase 8s 数据库文件之外的其他文件。
下图说明了数据库备份的基本概念。
图: 数据库服务器数据的备份
不必始终备份所有的存储空间。如果某些表每天都更改而其他一些则很少更改,那么每次备份数据库服务器时都备份包含未更改表的存储空间,这将导致效率低下。因此必须仔细地规划备份调度以避免备份或恢复数据时较长的延迟。
备份级别
为了提供灵活性,onbar 和 ontape 实用程序支持三个备份级别。
0 级
0 级备份将备份指定存储空间内所有包含数据的已使用的页。
0 级备份可能耗时比较长,因为 onbar 会写入所有磁盘页面以备份介质。1 级和 2 级备份花费的时间有可能几乎 与 0 级备份相同,这是因为数据库服务器必须扫描所有的数据以确定自上次备份以来更改的内容。从 0 级、1 级 和 2 级备份恢复数据的时间比从 0 级备份和一长串逻辑日志备份恢复数据花费的时间要少。
1 级
1 级备份只备份自上次指定的存储空间进行 0 级备份后更改的数据。
所有已更改的表和索引页(包含带有已删除数据的那些页面)都将进行备份。复制到备份的数据反映 1 级备份开始时更改过的数据的状态。
1 级备份占用的空间和花费的时间比 0 级备份要少,因为前者只将上次 0 级备份后更改的数据复制到存储管理器中。
2 级
2 级备份只备份自上次指定的存储空间进行 1 级备份后更改的数据。
2 级备份包含自上次 1 级备份后在存储空间中更改过的每个表和索引页的副本。
2 级备份占用的空间和花费的时间比 1 级备份要少,因为前者只将上次 1 级备份后更改的数据复制到存储管理器中。
如果磁盘和其他介质损坏并需要更换,您需要对所有存储空间和相关逻辑日志至少进行 0 级备份,才能在更换硬件上完全恢复数据。
逻辑日志备份
逻辑日志备份是所有填满的逻辑日志文件在磁盘或磁带上的副本。逻辑日志文件存储发生在备份间的数据库服务器活动记录。
要释放填满的逻辑日志文件,首先要备份它们。数据库服务器将重用这些已释放的逻辑日志文件用于记录新事务。有关逻辑日志的完整描述,请参阅《GBase 8s 管理员指南》。
即使没有指定为数据库或表记录日志,您仍然需要备份逻辑日志,因为它们包含了管理信息,例如检查点记录和块的添加和删除。如果备份了这些逻辑日志文件,即使不为任何数据库使用日志记录仍然可以进行热恢复。
手动和连续逻辑日志备份
您可以手动备份逻辑日志,也可以启用连续逻辑日志备份。
手动逻辑日志备份将备份所有已满的逻辑日志文件,并在当前逻辑日志文件处停止。必须仔细监视逻辑日志,并根据需要启动逻辑日志备份。
要了解逻辑日志文件是否已准备好进行备份,请检查 onstat -l 的标志字段。当逻辑日志文件标记为已备份后,它可以被重新使用。当标志字段显示以下值中的任意一个时,逻辑日志文件已准备好进行备份:
U------
U-----L
值 U 表示逻辑日志文件已被使用。值 L 表示最近的检查点发生时指示的逻辑日志文件是当前文件。值 C 指示当前日志。如果B 出现在第三列,那么逻辑日志文件已备份并可以重新使用。
U-B---L
标志值 U---C-L 或 U---C-- 表示当前逻辑日志。虽然允许您备份当前逻辑日志,但这样做将强制执行日志切换,从而浪费逻辑日志空间。等到逻辑日志文件填满后才备份它。
如果开启连续逻辑日志备份,数据库服务器将自动备份每个要填满的逻辑日志。如果关闭连续逻辑日志备份,那么继续填充逻辑日志文件。如果所有逻辑日志都已填满,数据库服务器会挂起,直到备份了这些日志为止。您可以通过在 onconfig 文件中设置 ALARMPROGRAM 配置参数或者通过运行 onbar 或 ontape 命令来启动连续逻辑日志备份。
日志回收
当数据库服务器处于脱机状态时,您可以执行特别的逻辑日志备份,称为日志回收。在日志回收中,数据库服务器直接从磁盘访问日志文件。日志回收将备份所有还未备份并且还未毁坏或损坏的逻辑日志。
日志回收使您可以将所有数据恢复到最近一个可用的并且没有被毁坏的逻辑日志文件以及最近一次完整的事务中。
保存逻辑日志备份
您应该频繁执行逻辑日志备份,然后从至少最近两个 0 级备份保存逻辑日志备份,这样就可以使用它们来完成恢复。
经常进行逻辑日志备份,原因如下:
- 释放已满的逻辑日志文件
- 当包含逻辑日志的磁盘出现故障时将数据丢失降低到最小限度
- 确保恢复包含一致的以及最近的事务
您应该从最近两个 0 级备份保存逻辑日志备份,因为如果某个 0 级备份不可访问或无法使用,您可以从较旧备份中恢复数据。如果所有逻辑日志备份都是不可访问或无法使用的,那么无法从这些逻辑日志文件或任意后继逻辑日志文件中前滚这些事务。
您会丢失未备份或未回收的逻辑日志文件中的事务。
为举例说明,如下图所示,假定您在星期一晚上 10 点执行 0 级备份,并接着在星期二午夜备份逻辑日志。在星期三上午 11 点发生灾难性事故,数据库遭到毁坏。除非您设置了连续逻辑日志备份,否则您将不能恢复星期二午夜和星期三上午 11 点之间发生的事务。
如果包含带有逻辑日志的存储空间的磁盘受损,那么星期二午夜后的事务将丢失。要从最近的逻辑日志备份中恢复这些事务,请尝试在修理或更换坏磁盘前回收这些逻辑日志并随后执行冷恢复。
图: 存储空间和逻辑日志备份
恢复系统
恢复就是从已备份的存储空间和逻辑日志文件中重新创建数据库服务器的数据。
由于以下任一条件造成数据库服务器数据不可访问时,恢复将重新创建这些数据:
- 需要更换包含数据库服务器数据的出故障的磁盘。
- 程序的逻辑错误毁坏了数据库。
- 需要将数据库服务器数据移到新的计算机上。
- 用户意外地毁坏或破坏了数据。
要将数据恢复到发生故障时的状态,必须至少具有在发生故障之前每个存储空间的一个 0 级备份以及包含存储空间备份后所有事务的逻辑日志文件。
物理和逻辑恢复
onbar 和 ontape 分两个阶段恢复数据库服务器的数据。 第一个阶段是物理恢复,它从所有或选定存储空间的备份中恢复数据。第二个阶段是逻辑恢复,它从逻辑日志备份中恢复事务。
物理恢复
在物理恢复期间,onbar 或 ontape 从最近的 0 级、1 级和 2 级备份恢复数据。当遇到磁盘故障时,可以只将驻留在出故障的磁盘上带有块的那些存储空间恢复到新磁盘上。下图对物理恢复进行了说明。
图: 物理恢复
逻辑恢复
如下图所示,数据库服务器重放逻辑日志来重新应用上次备份后发生的所有数据库事务。逻辑恢复仅应用于已物理恢复的存储空间上。
图: 逻辑恢复
数据库服务器将自动分辨要恢复哪些逻辑日志。
有关更多信息,请参阅使用 onbar 恢复数据和使用 ontape 恢复。
热恢复、冷恢复和混合恢复
恢复数据时,您必须确定是在数据库服务器处于停顿、联机还是脱机方式时进行该操作。恢复的类型取决于服务器处于其中哪一种操作方式。
恢复的种类如下:
- 如果在数据库服务器处于联机或静默状态时恢复非关键数据库空间,那么该过程称为热恢复。
- 当 GBase 8s 处于脱机状态时,您只能执行冷恢复。
- 混合恢复是对某些存储空间进行冷恢复后接着对其余的存储空间进行热恢复。
热恢复
如下图所示,热恢复将恢复非关键的存储空间。热恢复由一个或多个物理恢复、一个逻辑日志备份以及一个逻辑恢复组成。
图: 热恢复
不能同时执行多个热恢复。
冷恢复
如下图所示,冷恢复会回收逻辑日志,并恢复关键数据库空间(根数据库空间以及包含物理日志和逻辑日志文件的数据库空间)、其他存储空间以及逻辑日志。
图: 冷恢复
通过在恢复期间为任何块提供新路径名和偏移量,可以在与执行备份的计算机不同的计算机上执行冷恢复。
恢复整个系统备份时,不需要恢复逻辑日志。整个系统备份包含在执行备份时整个实例的快照,它在所有数据库空间之间具有逻辑一致性。
当恢复标准备份时,您必须执行逻辑恢复来恢复逻辑日志。
冷恢复首先对所有关键存储空间进行物理恢复,接着恢复非关键存储空间,最后恢复逻辑日志。根数据库空间的保留页恢复后,数据库服务器进入恢复方式。当逻辑恢复完成后,数据库服务器进入停顿方式。使用 onmode 命令使数据库服务器变成联机状态。
如果镜像关键数据库空间,那么您不太可能在磁盘故障后执行冷恢复,因为数据库服务器可以使用镜像的存储空间。如果镜像逻辑日志空间,当一个或多个磁盘出现故障时更可能回收逻辑日志数据。
恢复复制前,Enterprise Replication 服务器需要进行冷恢复。
混合恢复
混合恢复可使关键数据更快可用,但是,完整恢复需要更长的时间,因为逻辑日志将进行多次恢复和重放,初始冷恢复时一次,每个后续热恢复时各一次。
存储在冷恢复中的初始存储空间集合必须包含服务器中的所有关键存储空间。如果在初始冷恢复期间并未达到恢复所有存储空间的程度,那么可以避免恢复它们所必需的时间,从而与执行整个服务器的冷恢复相比,您可以使服务器更快地处于联机状态。然后您可以在一个或多个热恢复中恢复剩余的存储空间。
在冷恢复期间没有恢复的存储空间即使可能没有被故障损坏,也只有在热恢复中对它们进行恢复以后才可用。
连续日志恢复
连续日志恢复可保持辅助系统可用,以在恢复日志的主系统发生故障时替换主系统。
标准日志恢复将恢复所有可用日志文件备份并应用日志记录。在最后一个可用日志恢复和应用之后,日志恢复结束。仍处于打开状态的事务将回滚到事务清除阶段,然后服务器将处于停顿模式。服务器停顿后,将不能恢复更多的逻辑日志。
通过连续日志恢复(而不是事务清除),在恢复最后一个可用日志后,服务器将处于日志恢复暂挂状态。恢复客户机(ontape 或 onbar)退出并将控制权返回给您。对处于此状态的服务器,您可以在其他逻辑日志可用之后,启动另一个逻辑恢复。一旦将每个日志恢复作为连续日志恢复启动,您可以不断地继续该循环。
连续日志恢复的作用之一就是在主系统故障的情况下保持辅助系统可用。可以在辅助系统上恢复曾经在主系统上备份的逻辑日志(当逻辑日志可用时)。如果主系统发生故障,那么可以在辅助系统上恢复剩下的可用逻辑日志,并使辅助系统联机作为新的主系统。
连续的日志恢复所需的网络带宽远比高可用性数据复制 (HAC) 和企业数据复制 (ER) 所需的带宽少。连续的日志恢复比 HAC和 ER 更便捷,因为您可以在任意时间启动连续的日志恢复。因此,在不可预料的情况下(如网络间断时),连续的日志恢复比 HAC 或 ER 更稳健。
有关更多信息,请参阅通过使用 onbar 来配置连续日志恢复和使用 ontape 配置连续日志恢复。
onbar 和 ontape 实用程序的比较
本主题包含的信息可帮助您比较 onbar 和 ontape 实用程序,以便您可以决定何时使用每个实用程序。
onbar
通过使用存储管理器跟踪备份和存储介质,从而备份并恢复存储空间(数据库空间)和逻辑文件。当需要执行以下操作时,请使用该实用程序:
- 选择具体存储空间
- 备份到具体时间点
- 执行单独的物理和逻辑恢复
- 并行备份与恢复多个不同的存储空间
- 并发使用多个磁带机进行备份与恢复
- 执行导入的恢复
- 执行外部备份与恢复
ontape
记录、备份与恢复数据,能够更改数据库的日志记录状态。不使用存储管理器。当需要执行以下操作时,请使用该实用程序:
- 在不使用存储管理器的情况下备份与恢复数据
- 备份但不选择存储空间
- 更改数据库的日志记录方式
ontape 和 onbar 生成的备份不兼容。不能使用 ontape 创建一个备份再使用 onbar 来将其恢复,反之亦然。
下表比较 onbar 与 ontape。
表 1. onbar 和 ontape 之间的差异
实用程序能够…… | onbar | ontape |
---|---|---|
使用存储管理器来跟踪备份和存储介质吗? | 是 | 否 |
备份所有的数据库服务器数据吗? | 是 | 是 |
备份选定的存储空间吗? | 是 | 否 |
备份逻辑日志文件吗? | 是 | 是 |
执行连续逻辑日志备份吗? | 是 | 是 |
执行连续逻辑日志恢复? | 是 | 是 |
在数据库服务器处于联机状态时进行备份吗? | 是 | 是 |
在数据库服务器处于停顿方式时进行备份吗? | 是 | 是 |
恢复所有的数据库服务器数据吗? | 是 | 是 |
恢复选定的存储空间吗? | 是 | 是 |
串行地备份并恢复存储空间吗? | 是 | 是 |
是否在数据库服务器脱机时执行冷恢复? | 是 | 是 |
初始化高可用性数据复制吗? | 是 | 是 |
将数据恢复到特定的时间点吗? | 是 | 否 |
执行单独的物理和逻辑恢复吗? | 是 | 是 |
并行地备份并恢复不同的存储空间吗? | 是 | 否 |
并发使用多个磁带机进行备份与恢复吗? | 是 | 否 |
重新启动恢复吗? | 是 | 否 |
是否在冷恢复期间重命名块路径名或设备? | 是 | 是 |
执行导入的恢复吗? | 是 | 是 |
执行外部备份与恢复吗? | 是 | 是 |
监视性能吗? | 是 | 否 |
更改数据库的日志记录方式吗? | 否 | 是 |
是否使用外部程序变换数据? | 是 | 是 |
是否从云存储进行备份或恢复? | 否 | 是 |
其他差异:
-
紧急引导文件和 sysutils 数据库
ontape 实用程序不使用 sysutils 数据库或紧急引导文件。
-
同时会话
用于 GBase 8s 主存储管理器 的 onbar 支持同时发生的会话。
带有 Storage Manager 的 onbar 最多支持每个 Storage Manager 实例同时有 4 个会话。ontape 实用程序支持两个同时发生的会话,一个用于物理备份或恢复,而另一个用于日志备份。
-
设备支持和存储管理
ontape 实用程序支持其他主机上的远程备份设备。
用于 GBase 8s 主存储管理器 的 onbar 支持将备份生成导出至指定的目录和设备。
onbar 支持各种硬件平台上不同集合的磁带机。
也可以将 onbar 用于第三方存储管理器,以获取设备支持和存储管理。
-
更改数据库的日志记录方式
您不能更改 onbar 的日志记录方式;但您可以在使用 onbar 时使用 ondblog实用程序来完成此任务。
您还可以使用 SQL 管理 API 备选项 ALTER LOGMODE 来更改日志记录方式。
有关每个实用程序的详细信息,请参阅使用 onbar 备份和使用 ontape 备份。
计划备份与恢复
这些主题描述了如何计划备份与恢复,例如,通过计划恢复策略与备份系统来进行。
计划恢复策略
使用 onbar 或 ontape 之前,请规划您的恢复目标。
数据丢失的类型
计划恢复策略时的第一步是确定可接受的数据丢失量(如有)。
可能发生以下类型的数据丢失:
- 以下内容的删除:
- 行、列、表或数据库
- 块、存储空间或逻辑日志
- 数据毁坏或产生了不正确的数据
- 硬件故障(例如包含块文件的磁盘故障或备份磁带磨损)
- 数据库服务器故障
- 自然灾害
确定失败严重性
确定恢复目标后再创建恢复计划。计划应该包含多级故障的恢复目标。
下表显示了针对各种数据丢失量的故障的恢复计划。
表 1. 恢复计划样本
故障严重性 | 数据丢失 | 建议的恢复计划 |
---|---|---|
小 | 非关键数据丢失。 | 可以一直等到非高峰时间才恢复该数据。请使用热恢复。 |
中 | 丢失的数据对于您的业务很关键,但不驻留在关键数据库空间中。 | 尽快对该数据执行热恢复。 |
大 | 关键数据库空间丢失。 | 立即使用混合恢复来恢复关键数据,并在非高峰时间使用热恢复来恢复非关键数据。 |
灾难 | 所有数据都丢失。 | 尽快执行冷恢复或混合恢复。 |
数据使用情况确定备份调度
制定恢复计划后,请根据您使用数据的方式创建备份计划。
您使用数据的方式将确定您计划备份调度的方式,如下所示:
-
数据使用
用户如何使用数据?
- 关键数据库空间(根数据库空间以及包含物理日志和至少一个逻辑日志文件的数据库空间)
- 关键业务应用程序数据
- 由于法律或记录保存原因的长期数据存储
- 组之间的数据共享
- 测试数据
-
事务时间
可以丢失多长的事务时间?即,要手动重新输入丢失的事务可能花费多长时间?例如:您可以承担重新输入过去三个小时里发生的所有事务吗?
-
数量和分布
丢失多少数据是您可以承担的?例如:您丢失了客户概要文件的四分之一,或者丢失了中西部地区的销售数据而西海岸的数据仍然是完好无损的。
询问以下问题将有助于确定您希望备份数据的频率和时间:
- 您的业务是否存在可以恢复系统的停机时间?
- 如果您的系统是 24x7 全天候运行的(没有停机时间),是否存在可以进行恢复的非高峰时间?
- 如果恢复必须在高峰期内发生,该时间有多关键?
- 数据库服务器处于联机状态时可以恢复哪种数据(热恢复)?哪种数据必须在脱机状态下进行恢复(冷恢复)?
- 有多少存储设备可用于备份与恢复数据?
调度备份
您的恢复策略应该包含备份调度。 定制备份计划以满足您系统的需要。数据更改越频繁、更改越重要,您就需要越频繁地备份该数据。
您的备份计划还应该指定备份级别。
下表显示中小型系统的备份计划样本。
表 1. 样本备份计划
备份级别 | 备份调度 |
---|---|
完整备份(0 级) | 星期六下午 6 点 |
增量备份(1 级) | 星期二和星期四下午 6 点 |
增量备份(2 级) | 每天下午 6 点 |
对经常更新的存储空间进行 0 级备份 | 每小时 |
更改物理模式(例如将块添加到存储空间)后,请执行 0 级备份。(请参阅准备备份数据。)
基于标号的访问控制的安全需求
对于基于标签的访问控制 (LBAC),运行 onbar 或 ontape 的人员无需获得安全策略或其他特权的豁免,即可备份或恢复数据。
使用 onbar 或 ontape 恢复数据之后,LBAC 保护仍是完整的。
计划备份系统
要为数据计划足够的备份保护,请分析数据库服务器配置和活动以及安装时可用的备份介质类型。
还要考虑存储介质、磁盘、计算机和控制器以及网络大小的开支。
执行 0 级备份前的操作
在执行以下任何操作之后,您必须至少为根数据库空间和已修改的存储空间执行 0 级备份:
- 添加或删除镜像。
- 移动、删除逻辑日志文件或调整逻辑日志文件的大小。
- 更改物理日志的大小或位置。
- 更改存储管理器的配置。
- 添加、移动或删除数据库空间。
- 对任意类型的存储空间添加、移动或删除块。
- 添加、移动或删除 Blob 空间或智能大对象空间。
例如,如果添加新数据库空间 dbs1,那么您会在消息日志中看到一条警告,要求您对根数据库空间和新数据库空间执行 0 级备份。如果试图对根数据库空间或新数据库空间执行增量备份作为代替,onbar 将自动对新数据库空间执行 0 级备份。
尽管在添加日志文件后不再需要立即备份,但是因为数据结构发生了变化,所以下一个备份应该是 0 级备份。
如果创建的存储空间与已删除的存储空间同名,那么会执行两次 0 级备份:
- 在删除存储空间后并在创建同名的存储空间前备份根数据库空间。
- 创建存储空间后,备份根数据库空间和新存储空间。
执行 0 级备份后的操作
在执行以下任何操作之前,您必须为已修改的存储空间执行 0 级备份:
- 将非日志记录数据库转换为日志记录数据库。
- 在将 RAW 表变更为 STANDARD 类型之前。此备份确保转换到日志记录表类型之前未记录的数据是可恢复的。
评估硬件和内存资源
当您计划备份系统时,请评估您的硬件和内存资源。
评估以下数据库服务器和硬件配置元素以确定要使用哪些存储管理器和存储设备:
- I/O 虚拟处理器数
- 可用内存量以及处理器活动的分布
另请考虑备份与恢复所需的临时磁盘空间。数据库服务器使用临时磁盘空间来存储备份期间被覆盖以及内存中发生查询处理而溢出的之前数据映像。
准备备份数据时,请确保正确设置 DBSPACETEMP 环境变量或参数,以便指定的数据库空间具有足够空间,能满足您的需求。如果指定的数据库空间中空间不足,备份将失败,并且将使用根数据库空间,或者在填满根数据库空间之后,备份将失败。
评估备份与恢复时间
多种因素(包括数据库服务器配置和数据库大小)会影响系统备份与恢复数据所需的时间量。
备份或恢复花费的时间取决于以下因素:
-
磁盘或磁带设备的速度
存储设备的速度越快,备份或恢复的时间就越快。
-
当磁盘或系统故障要求您重新构建数据库时,要恢复的增量备份的数目
增量备份比完全备份使用的存储空间少,并且还能缩短恢复时间。
-
数据库中存储空间的大小和数目
备份:许多小存储空间的备份时间比总大小相同的一些大存储空间稍微长一些。
恢复:通常恢复的时间与恢复最大存储空间和逻辑日志的时间相同。
-
存储空间是否镜像
如果存储空间被镜像,将减少必须恢复被损坏的或被破坏的数据的可能性。可以在数据库服务器联机的情况下在非高峰时间恢复镜像。
-
在备份与恢复期间用户中断的时间长度
如果在数据库服务器处于联机状态时执行备份和热恢复,用户可以继续他们的工作但可能会注意到响应变慢。如果在数据库服务器处于停顿方式下执行备份和热恢复,那么用户必须退出数据库服务器。如果在数据库服务器处于脱机状态时执行冷恢复,那么数据库服务器对于用户不可用,因此恢复进行得越快越好。外部备份与恢复将除去系统停机时间。
-
备份调度
并不是每个备份或恢复会话中都必须包含所有的存储空间。通过调度备份,相对于很少或从不更改的那些存储空间,您可以更加频繁地对快速更改的存储空间进行备份。确保对每个存储空间至少进行一次 0 级备份。
-
数据库空间中表的布局以及磁盘中数据库空间的布局
设计您的数据库服务器模式时,以能够快速恢复重要信息的目的来组织数据。例如,将关键的和常用的数据隔离在最快的磁盘的一小组存储空间中。还可以将大表分段使其分布在数据库空间中,用来平衡 I/O 并最大化多个磁盘上的吞吐量。有关更多信息,请参阅《GBase 8s 性能指南》。
-
数据库服务器和系统负载
数据库服务器或系统上的负载越大,备份或恢复的时间就越长。
-
备份与恢复配置参数的值
例如:onbar 用来与数据库服务器交换数据所用的数据缓冲区的数目和大小可能影响性能。使用 BAR_NB_XPORT_COUNT 和 BAR_XFER_BUF_SIZE 配置参数可控制数据缓冲区的数目和大小。
评估日志记录和事务活动
当您计划备份系统时,另请考虑日志记录和事务活动。
以下数据库服务器使用需求将影响您针对存储管理器和存储设备的决策:
-
期望的事务活动的数量和比率
-
逻辑日志的数目和大小
如果需要从事务活动少的数据库服务器恢复数据,请定义许多小逻辑日志。由于逻辑日志备份不频繁,因此不太可能丢失数据。
-
逻辑日志文件填充的速度有多快
在日志文件填满之前进行备份,这样数据库服务器就不会挂起。
-
数据库和表的日志记录方式
当使用许多非日志记录数据库或表时,逻辑日志备份可能变得不太频繁。
压缩行数据
压缩行数据可使备份与恢复数据更高效。
先压缩行数据然后再备份,可以提高备份与恢复的速度并且减少所需的备份介质。备份与恢复期间,较小的数据大小比未压缩数据具有以下优势:
- 备份更快。
- 恢复更快。
- 逻辑日志更小。
- 备份映像更小。
如果使用外部压缩实用程序来压缩已压缩行数据的备份映像,那么可能不会减少备份映像大小,因为已压缩数据通常无法进一步压缩。在某些情况下,已压缩行数据的备份映像大小可能大于外部实用程序压缩的备份映像大小。
使用外部程序变换数据
您可以在备份之前将外部程序用作过滤器插件来将数据变换为其他格式,然后在恢复之后将数据变换回原始格式。
要压缩或变换数据,请使用 BACKUP_FILTER 和 RESTORE_FILTER 配置参数调用外部程序。
如果在备份行数据之前将其压缩,那么使用外部实用程序压缩备份映像可能不会生成更小的备份映像。
任何人都可以拥有该过滤器,但是非特权用户不能具有写访问权。对过滤器的许可权与对 GBase 8s 服务器或 GBase 8s 实用程序所调用的其他任何可执行文件的许可权相同。