1.1 概述
INFORMIX的建立及维护与管理都是一个较为繁琐的过程，特别是系统的性能优化更加要求优化熟悉 INFORMIX 整个系统的结构配置。 INFORMIX 在实际的运行中，会因环境的不断变化而产生如性能降低，甚至出现故障。这就需要用户不断地对 INFORMIX 进行性能优化及系统维护。
INFORMIX给用户提供了 onstat ， oncheck 等监控和检查工具。
本章将对维护操作所涉及的内容作一简要介绍及部分说明，具体内容请参看相关资料。
1.2 安装和初始配置
1.2.1 安装
安装的主要步骤如下：
(1) 以 root 身份登录，创建 UNIX 环境，这包括创建 informix 用户，设置环境变量 INFORMIXDIR ， PATH ，等，进入到＄ INFORMIXDIR 目录。
(2) 装入 INFORMIX 软件， copy 其文件至 INFORMIX 安装目录中。
(3) 安装 IINFORMIX ，运行其安装 shell 程序（如 . /InstallonLine ），修改 产品文件的owner ， group 和 mode 。
用户在初始化系统前应仔细阅读$INFORMIXDIR/release 目录中的 release note 。在该文件中包括了许多与操作系统、内核参数以及系统更新相关的重要信息。
主要的环境变量设置如下 ：
INFORMIXDIR 设置为INFORMIX 产品所在目录
PATH 包括$INFORMIXDIR/bin
ONCONFIG 设置onconfig 文件名
INFORMIXSERVER 设置为onconfig 参数中的 DBSERVERNAME 值
PSORT_NPROCS 设置为物理CPU VPs 数
所有informix 用户和系统用户推荐使用 korn shell 。所有环境变量在 .profile 中设置。
在为系统准备磁盘空间时，必须首先正确设置如下权限：
chmod 660 device_name
chown informix device_name
chgrp informix device_name
1.2.2 初始配置
OnLine 初始配置包括配置的规则与磁盘空间初始化。这些配置任务较为繁琐，接下来对几个重要的参数设置进行简要说明，在实际操作中，用户可以参考相关资料来进行配置。
机器在出厂时已预置了核心配置参数，但如果用户自己需要，则需要进一步调整这些参数。关于核心配置参数请检查release notes 。
1. Root 初始化
动态服务器的初始化包括两部分：磁盘初始化，创建root dbspace 。 root dbspace 中有 12 页专门用于存放系统信息，称为系统保留页。剩余空间中包含被称为 chunk free list 的页， 50 页 tblspace tblspace ， 4 页 database tablespace 。在 root dbspace 中还存储 sysmaster 和 sysutils 数据库。
在系统初始化时，物理日志和逻辑日志都自动建立在root dbspace 中。逻辑日志的最优大小很难确定，因为与各系统的事务活动状况紧密相关。刚开始时可以将其大小设定为 3 至 5MB ，如果不够以后可以随时追加。
在初始化时应创建一个较小的物理日志。因为在DBMS 系统中，尤其在 OLTP 环境下，数据库操作非常频繁，日志中必须记录大量的信息，所以用户最好能将多个日志分布在不同的设备上。有一种非常简单的方法：即在系统初始化完毕后，将物理日志移至其它设备，并扩大其空间。一般来说物理日志大一些为好（ 300MB-500MB ），这样可以避免频繁地初始化检查点（物理日志 75% 满时进行）。
请一定要牢记，root dbspace 的位置和初始 chunk 大小是无法改变的，除非重新初始化，但这将清除现有系统中的所有信息。
root dbspace的镜像功能可以在初始化时打开也可以稍后打开。
2. 系统配置
动态服务器必须具有唯一的SERVERNUM 。该参数用做系统共享内存段的码（ key ）。客户连接时根据参数 DBSERVERNAME 确认服务器，所以该参数也必须唯一，同时它也必须与通讯配置文件中的条目相匹配。 DBSERVERNAME 或 DBSERVERALIASES 都必须与一种通讯接口（共享内存， tli ， sockets ）相应。在通讯配置文件中必须包括所有的服务器名。
如果系统内存严重不足，UNIX 会将某些进程整个交换出实存。 通过设置 RESIDENT 参数，可以保证共享内存的驻留段始终在共享内存中而不会被交换到磁盘上，否则系统的性能将会受到极大地影响。
许多UNIX 操作系统会降低长时间运行进程的优先级。组成服务器的 oninit 进程因而会受到影响，导致系统性能下降。参数 NOAGE 将禁止这种情况的发生。该参数与系统平台有关。如果在系统中出现上述现象，但系统又不支持 NOAGE 参数，可以利用 renice 命令提高优先级。 ps 命令的 PRI 列表示进程的优先级。在某些系统上，利用 top 命令也可以显示进程优先级。
3. CPU VPs配置
正确配置CPU VP 的数量对于系统的性能有很大的影响。系统需要有足够多的 CPU VP 以加速线程的执行从而保证系统中其它进程能占用足够的 CPU 时间。
具体的配置方法如下：
利用onstag -g rea 命令监控线程就绪队列。检查 CPU VP 类线程的数目是否总是大于 CPU VP 的数量。若是，则表明总有一些就绪的 CPU 线程在等待 CPU VP ，应该增加 CPU VP 数量 。
命令onstat -g glo 可以显示 CPU VP 的信息。
从系统的角度来说应随时监控分析cpu 的使用情况，以了解系统是否还有潜力可挖。有很多系统提供了这一类工具，例如 sar 。只要有 CPU 空闲时间或 I/O 等待时间，就说明可以增加 CPU VP 数量以完成更多的任务（在相同时间内）。但如果系统 CPU 资源已充分利用，增加 CPU VP 也不会提高系统性能。
在最后的配置完成后，用户应修改UNIX 的启动与关机命令。
在UNIX 系统的启动中，应包含 INFORMIX 的环境变量的设置，及加入 OnLine 的应用程序，如 oninit 用于启动数据库。
在UNIX 系统的关闭中，也应将有关 OnLine 应用程序加入关机命令，以卸下 INFORMIX 。
1.2.3 系统初始化
系统的初始化包括两个过程，磁盘空间初始化和共享内存初始化。初始化命令为oninit 。 Oninit 应带什么参数，及在启动过程中碰到的问题可以参看相关资料。
1.3 系统性能的优化
接下来，讲述与系统性能关系比较紧密的几点。
1.3.1 磁盘空间布局
提高系统性能，最明显的方法就是优良的磁盘空间布局策略。
在配置和初始化OnLine 磁盘空间之后，再来修改不合适或不理想的磁盘空间布局，不是一个简单的问题。原则上，在每次建立 blobspace 或 dbspace 时，用户就应该综合考虑各种因素，进行较好的规划。但实际上，即使是最初的最优设置也会因环境的变化而降低。这就必然需要在通常的维护中不断改进。
1.3.2 优化Blobspace Blobpage 大小
评估blobspace 存储策略时，可用下面两个准则衡量其有效性：
l Blobpage 充满度
l 每个blob 要求的 page 数
blobpage 充满度是指每一个 blobpage 存储的数据总量。
1.3.3 消除人为的资源瓶颈
这就要求管理人员应使用户尽可能遵守下面四条原则：
l 在一个合理的时间间隔内，不要让一个事务一值被打开而不提交或回滚
l 一般不要使用作业控制机制来中止一个进程，除非用户确实想中止自己的作业
l 不要在经常备访问的表中进行大规模的更新
l 在为一个应用规定特定的隔离级别之前，应先考虑它可能带来的存取问题
1.3.4 共享内存缓冲区
一般来说读缓存命中率应>95% ，写缓存命中率应 >85% 。利用 onstat -p 命令可以获得关于读写缓存命中率的信息。提高缓存命中率的方法很简单：增加 BUFFERS 。如果 LRU_MAX_DIRTY 和 LRU_MIN_DIRTY 设置得过小，将会降低读写缓存命中率，因为缓冲区刷新过于频繁。但如果一次检查点过程很长，在此期间即使 LRU 的上下限都很低也不一定影响性能。
1.3.5 日志缓冲区的大小
物理和逻辑日志缓冲区的最佳大小依赖于用户所处的环境。一般来说，日志缓冲区应足够大，以便使写磁盘日志的物理I/O 次数减至最少。然而从另一方面来说，缓冲区也不应太大，否则为了达到其他目的，用户还得分配能发挥更高效率的共享内存空间。
另外，当用户使用有缓冲的日志登录时，还得考虑内存中的数据量。日志缓冲区越大，操作系统失败后日志数据就丢失得越多。故用户应该权衡增加缓冲区大小所带来的好处与操作系统失败可能导致的数据丢失的恶果。
1.3.6 检查点的频率
检查点的频率及其持续时间能影响OnLine 的性能。在检查点期间， OnLine 禁止所有数据库服务器进程进入临界区，因此用户进程可能会被中断，所以，频繁出现检查点可能会降低 OnLine 的性能。
而使OnLine 具有较少频率的检查点隐含了下列两点代价：
l 操作系统失败后可能会需要较长的快速恢复时间。
l 较大的物理日志会需要较多的磁盘空间。
1.4 日常维护操作
日常维护操作包括OnLine 的模式转换，逻辑日志管理， archive 管理， OnLine 活动的监控及 OnLine 配置的修改。
1.4.1 模式转换
数据库共有六种工作模式，在这几种模式的转换中所用到的命令是oninit 和 onmode 。
日常操作中经常用到的是启动数据库至在线模式和关闭数据库至离线模式，
分别对应的命令是 oninit 与 onmode 。
1.4.2 逻辑日志管理
该管理工作包括如下内容：
l 检查逻辑日志文件配置
l 改变逻辑日志磁带设备的路径名，块尺寸，磁带尺寸
l 改变逻辑日志文件的最大数目
l 改变逻辑日志文件的大小
l 逻辑日志文件状态
l 逻辑日志文件标识号
l 增加及删除一个逻辑日志文件
l 转移一个逻辑日志文件
l 改变数据库的日志登录状态
l 逻辑日志文件的备份
对于这部分的具体内容，可以参看相关资料
1.4.3 Archive 管理
Archive是指 OnLine 数据在某一个特定时间的副本，它存储于一卷或多卷磁带上。 OnLine 支持三级增量 archive ：
0级 archive ，即基线 archive 。
1级 archive ，保存自上一个 0 级 archive 以来的所有变化。
2级 archive ，保存自上一个 0 级 archive 或上一个 1 级 archive 以来的所有变化。
该管理工作包括以下内容：
l 估算 archive 建立时间
l 计划 archive 调度
l 检查 archive 配置
l 改变 archive 磁带设备的路径名，块长度，磁带容量
l 创建任意类型的 archive
l 在 archive 期间日志文件填满时的处理
l archive 工作被过早中止时的处理
该部分的具体内容可参看相关资料。
1.4.4 监控 OnLine 活动
系统提供了onstat 和 oncheck 命令给用户来检查和监控 OnLine 的活动具体命令使用方法可参看相关资料说明。
这部分内容包括：
l 监控archive 历史
l 监控Blobspace 中的 blobs
l 监控Dbspace 中的 blobs
l 监控缓冲区
l 监控缓冲池活动
l 监控检查点
l 监控chunk
l 监控配置信息
l 监控数据库
l 监控Dbspaces
l 监控磁盘页
l 监控extent
l 监控索引关键字值和索引页
l 监控日志登录活动
l 监控消息日志
l 监控OnLine 活动的概要表
l 监控共享内存和latch
l 监控Tblspace
l 监控用户和事务
1.4.5 修改配置
这部分的内容主要包括：
l Blobspace 配置的修改，如创建和删除一个 blobspace 。
l 缓冲区配置的修改，如改变缓冲池中缓冲区的数目，改变日志缓冲区的大小。
l chunk 配置的修改，如增加一个 chunk ，改变最大的 chunk 数目。
l Dbspace 配置的修改，如创建和删除一个 dbspace 。
l 强制驻留配置的修改，如在本次对话期间强制或取消驻留共享内存，强制或取消驻留共享内存。
l 镜像配置的修改，如改变一个镜像 chunk 的状态，运行镜像，启动或中止在 dbspace 或 blobspace 中的镜像。
l 物理日志配置的修改，改变物理日志的位置或大小。
l 其他共享内存参数的配置的修改，如改变检查点的间隔，改变控制台信息的目的地等。
1.5 数据的一致性，恢复和迁移
1.5.1 数据的一致性
为最有效地进行一致性检查及确保archive 的完整性，应当对所有数据及 OnLine 控制信息的一致性进行周期性确认。由于检查所耗费的时间及可能造成的资源竞争问题，应该在 INFORMIX 活动最少的时候安排检查。
INFORMIX提供了 oncheck 给用户用于检查数据的一致性，具体内容可以参看相关资料。
1.5.2 镜像
对一个chunk 作镜像时， OnLine 会保持一个 shunk 数据的两个备份。对主 chunk 的每一次写入都会对镜像 chunk 自动同样地随着进行。主 chunk 出现了故障，镜像功能可以使用户对镜像 chunk 执行读写，直到恢复了主 chunk ，所有这些都不致于中断用户对数据的访问。
1.5.3 OnLine 日志登录
逻辑日志文件是OnLine 所有数据恢复机制的中心。
即便没有创建有事务日志的数据库，在处理期间逻辑日志文件也会接受三种类型的记录：
l 对所有数据库的 SQL 定义语句
l 对 OnLine 配置信息的改变
l 检查点事件
逻辑日志文件在OnLine 的数据恢复和一致性机制中有下面几个功能：
(1) 如果对一个数据库应用了事务而某个事务又必须回滚，OnLine 使用逻辑 日志文件的记录将由于该事务引起的该数据库变化逆向消除。
(2) 如果需要进行数据重装，OnLine 使用逻辑日志文件中的记录将上次 archive 以来执行的所有工作前滚。
(3) 如果OnLine 已经以不可控制的方式卸下， OnLine 使用逻辑日志文件中的记录进行快速恢复，是系统回复至一致性状态而不丢失数据的 OnLine 方式。
1.5.4 快速恢复
快速恢复是在运行方式从脱机方式变为静止时， OnLine 自动执行的容错功能。快速恢复的目标是在系统发生故障时，将 OnLine 恢复到物理上，逻辑上一致的状态，并尽可能减少已做工作的损失。
快速恢复要达到两个目标：
l 物理日志文件用于将OnLine 恢复至已知的物理一致性的最近点，即最近的检查点。
l 逻辑日志文件用于将OnLine 恢复至逻辑上一致 ―― 将在该检查点后提交的事务前滚，并将仍未完成的事务回滚。
快速恢复用于处理类似下面的情况：OnLine 正用于处理多于 40 用户的任务，一些事务正在进行，不知不觉中，操作系统发生了故障。
1.5.5 数据重装
OnLine环境中有三种情形要求数据库管理员进行一次数据重装：
l 要替换一个或多个磁盘
l 磁盘出现了介质故障
l OnLine 数据经历了一次严重的崩溃
一次数据重装的效果相当于最近一次archive 再加上已 backup 至逻辑日志磁带上的所有数据库的变化。
不能对表及数据库有选择地进行重装。重装是对整套archive 及逻辑日志 backup 带进行的， OnLine 对这些带中涉及所有 OnLine 数据库的全部内容进行重装。
需严格按照操作规程进行。
小 结
INFORMIX的建立及维护与管理都是一个较为繁琐的过程，特别是系统的性能优化更加要求优化熟悉 INFORMIX 整个系统的结构配置。 INFOMRIX 在实际的运行中，会因环境的不断变化而产生如性能降低，甚至出现故障。这就需要用户不断地对 INFOMRIX 进行性能优化，及系统维护。
日常维护操作包括OnLine 的模式转换，逻辑日志管理， Achive 管理， OnLine 活动的监控及 OnLine 配置的修改。
习 题
6-1 什么是 Achive? INFORMIX-OnLine 支持几级增量 Achive?
6-2 快速恢复要达到哪两个目标 ?
2940
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
