infomix 11.5的一些特性
转自IBM网站上的一个系列文章，虽时间比较久了。但仍比较有意义。
http://www.ibm.com/developerworks/cn/data/library/techarticles/dm-0907zhanggy2/
http://www.ibm.com/developerworks/cn/data/library/techarticles/dm-0908zhanggy/
http://www.ibm.com/developerworks/cn/data/library/techarticles/dm-0908zhanggy2/
Informix 数据库目前最新的版本是 11.5，从 Informix 9、Informix 10 到 Informix 11.5，在数据库性能、数据库管理及应用开发等方面都有了很大的提高，而且推出了很多非常有用的新特性。通过对这些特性的使用，可以大大提高数据库性能、增强数据库可管理性及应用开发的灵活性。我们这里，给大家介绍其中的一些特性，希望对大家能有所帮助。
数据库管理方面的一些实用特性
使用可配置的页面大小
我们知道，在 Informix 中，数据存储的最基本的单位是页，在 Informix 10 版本之前，数据页面的大小是固定的，不能被改变，通常，在 sun、HP 等平台上，数据页的大小为 2K，AIX 及 windows 平台，数据页的大小为 4K 。从 Informix 10 版本开始，我们可以配置 Informix 数据库页面的大小，数据库页面的大小可以是 2K-16K 。通过提供可配置的页面大小功能，可以给我们带来很多好处：
- 空间使用的效率会更高
从 Informix 10 开始，一个页面可以达到 16K 的连续空间，可以更有效的使用数据空间。比如说，我们表中一行的数据大小为 1200 字节，那么，当使用 2K 大小页面时，只能存放 1 行数据，3 行数据需要 6K 大小空间；如果采用 4K 大小页面，那么 3 行数据可以放在一个 4K 页面上，空间会节省 %33 。那么，当对 30 行数据而言，如果采用 2K 大小页面时，需要占用 60k 大小空间，如果采用 4K 大小页面时，只需要占用 40k 大小空间，如果采用 6k 大小页面时，则仅需要占用 36k 大小空间 , 可以节省 40% 的空间。 - 支持更大的索引键值， 最大可以达到 3K 。
这样，我们可以在一个索引页面上放置更多的索引键，支持更大的键值，而不需要增加索引树的层次。采用可配置页面大小功能，可以显著提高具有大量重复索引键值情况下的处理性能。 - 存取效率的提高
通过采用可配置页面大小功能，可以降低数据页和索引页的 IO 操作次数，提高存取效率。通过配置页面大小，很长的记录行可以只存放在单个页面上，降低了读取每条记录的页面数目；在以前的版本中，超长的记录需要 remainders pages，采用大的页面足够用来存放整条记录，略去了访问 remainders pages 的时间；大的索引页面可以存放更多的索引项，从而降低了索引的层数，减少了在索引树上遍历的开销；在决策支持应用的环境中，使用大的页面可以降低全表扫描的页面的数目，提高运行效率。
我们可以在数据库空间（dbspace）级别以及缓冲池（buffer pool）级别来定义数据页面的大小，其范围可以是 2K-16K，而且定义的数据页面大小必须是系统缺省页面大小的倍数。可配置的页面大小功能需要系统开启大块（large chunk）功能。
在创建 dbspace 时，这个特性允许指定标准或临时 dbspace 的页大小。如果要使用比默认页大小所允许的键长更长的键，可能需要指定非默认的页大小。 根 dbspace 使用默认的页大小。如果希望指定页大小，指定的值必须是默认页大小的整数倍，而且不能超过 16 KB 。
使用 onspaces 命令创建 dbspace 的基本语法如下：
onspaces – c – d dbs – k pgsize – p path -o offset -s size ；
其中，pgsize 用来指定 dbspace 的页面大小 (in K)：
- 页面大小的范围从 2K 到 16K 。
- 页面大小必须是缺省页面大小 (2k or 4K) 的倍数。
- Dbspace 创建之后，页面大小不能修改。
- 如果相对应的页面大小的缓冲池不存在，online 将通过配置参数 BUFFERS_DEF 自动创建一个。
- rootdbs 必须使用系统默认的页面大小。
- 动态创建的日志文件必须在使用系统默认的页面大小的数据库空间上分配。
在创建缓冲池时，我们可以使用新的 BUFFERPOOL 配置参数或者 onparams 工具为 dbspace 中所有非默认页大小对应的页定义缓冲池。在使用 BUFFERPOOL 配置参数或者 onparams 工具定义缓冲池时，需要指定缓冲池的信息，包括大小、缓冲池中的 LRUS 个数、缓冲池中的缓冲区个数、lru_min_dirty 和 lru_max_dirty 的值。 BUFFERS、LRUS、LRU_MAX_DIRTY 和 LRU_MIN_DIRTY 配置参数都不再使用。在 Version 10.0 中，以前在 BUFFERS、LRUS、LRU_MAX_DIRTY 和 LRU_MIN_DIRTY 配置参数中指定的那些信息，现在要使用 BUFFERPOOL 配置参数或者 onparams 工具指定。使用 BUFFERPOOL 配置参数或 onparams 工具输入的信息代替了以前用过时的参数指定的信息。
通过 onparams 指定缓冲池的基本语法如下：
onparams – b – g pgsize – n buffs – r lrus – x max – m min ；
其中：
- pgsize – 缓冲池的页面大小，必须是缺省页面大小 (2k or 4K) 的倍数；
- buffs – 缓冲池中的页面数目；
- lrus – 缓冲池中的 LRU 队列的数目；
- max – 缓冲池中最大脏页的百分比；
- min - 缓冲池中最小脏页的百分比；
使用 onparams 创建缓冲池举例：
onparams – b – g 8 – n 3000 – r 4 – x .9 – m .5 ；
通过上述命令，我们，
- 创建一个 8k 页面大小的缓冲池，该缓冲池具有 3000 个页面，由 4 个 LRU 队列组成。
- 最大脏页百分比为 0.9% , 最小脏页百分比为 0.5% 。
- 每个不同页面大小的缓冲池只能有一个。
- 缓冲池创建之后，需要重启 online 才能生效。
- 在创建 dbspace 时，不需要通过 onparams 来创建缓冲池 . online 将通过配置参数 BUFFERS_DEF 自动创建一个。
当采用可配置的页面大小后，Informix 数据库中的 onstat 和 oncheck 命令的输出也发生了相应的变化：
onstat – d – b – B – P – R – X 的输出都发生了变化
- onstat -d 命令的输出增加了数据页大小项：
Dbspaces address number flags fchunk nchunks pgsize flags owner name ad357e8 1 0x60001 1 1 2048 N B informix rootdbs b62a5b0 2 0x60001 2 1 4096 N B informix dbsp1 2 active, 2047 maximum Chunks address chunk/dbs offset page Rd page Wr pathname ad35948 1 1 0 493 5803 /local0/engines/ol_tuxedo/ifmxdata/rootdbs b62a710 2 2 0 4 20 /local0/engines/ol_tuxedo/ifmxdata/dbsp1 2 active, 32766 maximum NOTE: The values in the "page Rd" and "page Wr" columns for DBspace chunks are displayed in terms of system base page size. Expanded chunk capacity mode: always
- onstat -b 命令的输出变化：
IBM Informix Dynamic Server Version 11.10.UC1 -- On-Line -- Up 00:01:39 -- 1075308 Kbytes Buffer pool page size: 2048 44454970 0 84 1:30563 4472f000 18 801 80 ffffffffffffffff 0 4445d418 0 84 1:30562 447b1800 18 801 80 ffffffffffffffff 45d654e0 44468b60 0 84 1:30567 4485e000 18 801 80 ffffffffffffffff 0 44476ec0 0 84 1:30565 44934000 18 801 80 ffffffffffffffff 0 444875b8 0 84 1:30564 44a2b800 18 801 80 ffffffffffffffff 0 4449dc50 0 84 1:30566 44b7d000 18 801 80 ffffffffffffffff 0 444d0700 0 c23 1:34245 44e78000 18 801 10 0 0 444d1800 0 c23 1:34253 44e88000 18 801 10 0 0 444d2900 0 c23 1:34261 44e98000 18 801 10 0 0 444d3a00 0 c23 1:34269 44ea8000 18 801 10 0 0 444d4b00 0 c23 1:34277 44eb8000 18 801 10 0 0 444d5c00 0 c23 1:34285 44ec8000 18 801 10 0 0 444d6c78 0 84 1:30568 44ed7800 18 801 80 ffffffffffffffff 0 444d6d00 0 c23 1:34293 44ed8000 18 801 10 0 0 444d7e00 0 c23 1:34301 44ee8000 18 801 10 0 0 444d8f00 0 c23 1:34309 44ef8000 18 801 10 0 0 444da000 0 c23 1:34317 44f08000 18 801 10 0 0 444db100 0 c23 1:34325 44f18000 18 801 10 0 0 444dc200 0 c23 1:34333 44f28000 18 801 10 0 0 444dca80 0 c23 1:36184 44f30000 18 801 10 0 0 444dd300 0 c23 1:34341 44f38000 18 801 10 0 0 444ddb80 0 c23 1:34346 44f40000 18 801 10 0 0 444ed288 0 84 1:30569 45028800 18 801 80 ffffffffffffffff 0 4472 modified, 5000 total, 8192 hash buckets, 2048 buffer size Buffer pool page size: 8192 0 modified, 1000 total, 1024 hash buckets, 8192 buffer size
- 新增加 onstat -g buf 显示定义的缓冲池的信息
onstat -g buf 命令的输出显示：
IBM Informix Dynamic Server Version 11.10.F -- On-Line -- Up 00:00:25 -- 1075788 Kbytes Profile Buffer pool page size: 2048 dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached 2065 2067 274619 99.25 4418 36043 81649 94.59 bufwrits_sinceckpt bufwaits ovbuff flushes 14850 0 0 6 Fg Writes LRU Writes Avg. LRU Time Chunk Writes 0 0 nan 2909 Buffer pool page size: 8192 dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached 0 0 0 0.00 0 0 0 0.00 bufwrits_sinceckpt bufwaits ovbuff flushes 0 0 0 0 Fg Writes LRU Writes Avg. LRU Time Chunk Writes 0 0 nan 0
- onchecks 命令将显示相应的页面大小
以下示例显示了 oncheck -pt 命令的输出示例：
TBLspace Report for testdb:tab1 Physical Address 2:10 Creation date 10/07/2004 17:01:16 TBLspace Flags 801 Page Locking TBLspace use 4 bit bit-maps Maximum row size 14 Number of special columns 0 Number of keys 0 Number of extents 1 Current serial value 1 Pagesize (k) 4 First extent size 4 Next extent size 4 Number of pages allocated 340 Number of pages used 337 Number of data pages 336 Number of rows 75806 Partition partnum 2097154 Partition lockid 2097154 Extents Logical Page Physical Page Size Physical Pages 0 2:106 340 680
RTO 策略
我们知道，当 Informix 数据库执行崩溃恢复时，以前我们没有任何方法可以预测崩溃恢复将在什么时间完成，Informix 11 提出了 RTO 技术，当采用 RTO 技术后，我们可以指定测崩溃恢操作完成的时间，这样，使得崩溃恢复时间可以被我们把握。
关于非阻塞检查点技术的特点及技术实现，请参考文章“ Informix 11 非阻塞检查点及 RTO 策略应用实践”。
SQL 管理 API （SQL Administration API）
我们知道，Informix 数据库有很多实用程序来进行数据库管理工作，比如，我们会使用 onspace 命令来创建新的数据空间，使用 oncheck 命令来对磁盘上的数据及索引进行检查。但是，这些实用程序只能在命令行执行，不能在 SQL 语句中进行调用，这样，我们很难在应用程序中来执行数据库管理操作，也很难进行远程数据库管理操作。为了解决上述问题，Informix 11 版本中增加了 admin( ) 或 task( ) 函数，DBA 现在可以通过调用新的内置的 admin( ) 或 task( ) 函数通过发出 SQL 语句就可以完成数据库管理任务了。由于是通过 SQL 语句来调用 admin( ) 或 task( ) 函数，我们还可以实现远程数据库管理任务，这两个函数具有模拟相应实用程序的命令行参数的参数。例如，下面的 SQL 语句相当于 oncheck -ce 命令，它指示数据库服务器检查区段：
EXECUTE FUNCTION admin('check extents');
有些选项还可以完成没有相应实用程序的任务。
现在，我们可以使用 EXECUTE FUNCTION 语句来调用内置 admin( ) 或 task( ) 函数，以完成与执行 Informix 的各种管理实用程序等同的管理任务。主要包括管理空间，管理配置，运行例程作业和系统验证（oncheck 功能）等方面的管理操作。
两个内置管理函数（task() 和 admin()）仅在 sysadmin 数据库中可用。仅 DBSA 可运行 task() 和 admin() 函数。但是缺省情况下，只有用户 informix 可连接到 sysadmin 数据库。
例如，如果 sysadmin 数据库是当前的数据库，那么以下语句执行用于缓慢关闭数据库服务器的任务：
EXECUTE FUNCTION task ('onmode','k') ；
如果 sysadmin 数据库不是当前的数据库，但您是有权连接到 sysadmin 数据库的用户，您可以执行以下命令：
Execute function sysadmin:task ('onmode','k');
task() 和 admin() 函数提供相同的功能；它们的不同仅在于返回码。 task() 函数返回描述命令结果的字符串。 admin() 函数返回整数，该数值和 command_history 表相关联。
下边显示了 task() 和 admin() 函数运行输出结果：
EXECUTE FUNCTION task('create dbspace', 'dbspace2', '/CHUNKS/dbspace2');
(expression) created dbspace number 2 named dbspace2
EXECUTE FUNCTION admin('create dbspace', 'dbspace2', '/CHUNKS/dbspace2');
(expression) 107
每次尝试调用 ADMIN 或 TASK 函数都会产生两个结果：
- 执行一个 command 任务，通常是模拟管理实用程序
- 将新行插入到 sysadmin 数据库的 command_history 表中。
command_history 表
command_history 表包含管理 API 已运行的所有命令的列表。该表还会显示命令的结果。该表位于 sysadmin 数据库中，是一个 RAW（无日志记录）表。
command_history 表显示管理任务是通过 admin() 还是 task() 函数执行的，并显示执行命令的用户的相关信息、命令的执行时间、命令，以及数据库服务器完成命令运行时返回的消息。
下表显示 command_history 表信息的示例：
| 列 | 数据类型 | 描述 |
|---|---|---|
| cmd_number | serial | 每行的唯一标识 |
| cmd_exec_time | datetime year-to-second | 命令的启动时间 |
| cmd_user | varchar | 执行命令的用户 |
| cmd_hostname | varchar | 执行命令的主机的名称 |
| cmd_executed | varchar | 所执行的命令 |
| cmd_ret_status | integer | 返回码 |
| cmd_ret_msg | lvarchar | 返回消息 |
下表显示了示例命令和 command_history 表中的关联结果。
| 所执行的命令 | 返回消息示例 |
|---|---|
| set sql tracing on | 对 1000 个 2024 字节的缓冲区打开 SQL 跟踪。 |
| create dbspace | 已添加空间“ space12 ”。 |
| 检查点 | 检查点已完成。 |
| add log | 已向数据库空间 logdbs 添加了 3 个逻辑日志。 |
ADMIN 或 TASK 指定的 command 任务发生在由于在 command_history 表中插入新行而引起的单独事务中。如果命令成功执行，但是到 command_history 中的插入操作失败，那么命令将生效，而 online.log 错误条目将指示问题。
这两个函数不同之处主要在于它们的名称以及它们的返回值，返回值指示当调用函数时将发生什么：
- TASK 返回了在其插入 command_history 表的新行中 cmd_ret_msg 列的值。此 LVARCHAR 值指示命令的结果（或失败）。
- ADMIN 基于 ADMIN 插入 command_history 表的新行中 cmd_number 列的串行值返回了一个整数值。
- 如果该值大于 0，那么命令成功，且新行已插入到 command_history 表中。
- 如果该值等于 0，那么命令成功，但是 Dynamic Server 无法将新行插入到 command_history 中。
- 如果该值小于 0，那么命令失败，但是新行已插入到 command_history 表中。
command 规范和任何其他的参数都可以为 ADMIN 或 TASK 函数定义管理任务。例如，等价于 oncheck -ce 命令的此 SQL 语句可指导数据库服务器检查扩展数据块：
EXECUTE FUNCTION admin('check extents');
如果调用此函数时 command_history 表有 200 行，且命令已成功，那么 informix 会执行该命令并返回整数 201 。如果命令失败，那么此示例会返回值 -201 。
要显示命令历史记录，请运行以下 SQL 语句：
SELECT * from command_history ；
比如，当我们创建了一个 dbspace2 数据空间后，系统执行成功，返回码为 108，我们可以在 command_history 表中查看相关信息：
EXECUTE FUNCTION admin('create dbspace','dbspace2',
'$INFORMIXDIR/SPACE/dbspace2', '20MB');
(expression) 108
SELECT * FROM command_history WHERE cmd_number IN (108)
cmd_number 108
cmd_exec_time 2005-11-17 16:26:15
cmd_user informix
cmd_hostname olympia.beaverton.ibm.com
cmd_executed create dbspace
cmd_ret_status 0
cmd_ret_msg created dbspace number 2 named dbspace2
在一个固定的时间周期之后，将会自动除去 command_history 表中的任务。您可以通过更改 ph_threshold 表中的 COMMAND HISTORY RETENTION 行来修改该时间周期。 COMMAND HISTORY RETENTION 参数设置数据行在 command_history 表中保留的时间长度。
您可以使用诸如 delete 或 truncate table 之类的 SQL 命令从表中手动除去数据。
您必须对 sysadmin 数据库执行 task() 和 admin() 函数。
task() 和 admin() 函数支持的主要管理命令列表如下，具体语法大家可参考 Informix 信息中心中相关命令语法内容。
- ADD BUFFERPOOL
- ADD CHUNK
- ADD LOG
- ADD MEMORY
- ADD MIRROR
- ALTER CHUNK OFFLINE
- ALTER CHUNK ONLINE
- ALTER LOGMODE
- ALTER PLOG
- ARCHIVE FAKE
- CHECK DATA
- CHECK EXTENTS
- CHECK PARTITION
- CHECKPOINT
- CLEAN SBSPACE
- CREATE BLOBSPACE
- CREATE CHUNK
- CREATE DBSPACE
- CREATE SBSPACE
- CREATE TEMPDBSPACE
- CREATE BLOBSPACE
- DROP BLOBSPACE
- DROP CHUNK
- DROP DBSPACE
- DROP LOG
- DROP SBSPACE
- DROP TEMPDBSPACE
- ONMODE
- PRINT ERROR
- PRINT PARTITION
- QUIESCENT
- RENAME SPACE
- SET CHUNK OFFLINE
- SET CHUNK ONLINE
- SET DATASKIP ON
- SET DATASKIP OFF
- SET SBSPACE ACCESSTIME ON
- SET SBSPACE ACCESSTIME OFF
- SET SBSPACE AVG_LO_SIZE
- SET SBSPACE LOGGING ON
- SET SBSPACE LOGGING OFF
- SET SQL TRACING
- SET SQL TRACING OFF
- SET SQL TRACING ON
- SET SQL TRACING RESIZE
- SET SQL USER TRACING
- SET SQL USER TRACING CLEAR
- SET SQL USER TRACING OFF
- SHUTDOWN
- START MIRRORING space
- STOP MIRRORING
行数据压缩及存储优化技术
我们知道，从 Informix 11.5 xC4 开始，Informix 数据库提供了行压缩技术，它采用一种静态的基于字典的压缩算法，将表（table）或表分区（table fragments）中的数据行中重复的数据模式映射到一个占用空间较少的符号，从而减少表格或表分区数据的总大小。这些重复的数据模式不仅可以是一列中的数据，也可以是一列中的部分数据，甚至可以是跨数据列的数据。通过采用行压缩技术，Informix 11.5 可以节省高达 80% 的存储空间。同时，由于数据是采用压缩方式存储，I/O 读取效率会有 20% 左右的提高，内存使用效率会更高，数据库备份及恢复的时间也得到相应的减少。
关于非阻塞检查点技术的特点及技术实现，请参考文章“ Informix 11.5 行数据压缩及存储优化技术应用实践”。
使用 ontape 备份数据到指定目录中
从 Informix 11 版本开始，ontape 命令可以将数据及日志备份到目录中，ontape 命令将在该目录下自动为备份数据及日志建立新的文件。你可以通过设置 TAPEDEV 及 LTAPEDEV 参数指向一个目录来实现。使用 ontape 命令将数据及日志备份到目录中 , 可以为我们带来如下好处：
- 多个实例可以同时备份到相同的目录下
- 可以通过操作系统工具对数据进行压缩等操作
- 当日志文件填满后，可以配置系统自动备份该日志文件
使用时，你必须对该目录拥有写权限，并保证有足够的空间保存备份数据。
在使用 ontape 命令可以将数据及日志备份到目录时，我们要选择 -y 选项关闭 ontape 的交互提示信息。
下边例子用来执行 0 级备份：
ontape -s -L 0 -y
备份到目录中的数据文件名的格式为：hostname_servernum_Ln ；而日志文件的文件名为 hostname_servernum_Lognnnnnnnnnn 。
当我们为 TAPEDEV 和 LTAPEDEV 指定目录时，可以使用 IFX_ONTAPE_FILE_PREFIX 环境变量来指定备份文件名的前缀（替换hostname_servernum 格式）。
如果将 IFX_ONTAPE_FILE_PREFIX 的值设置为 My_Backup，那么备份文件名具有以下名称：
- My_Backup_L0
- My_Backup_L1
- My_Backup_L2
- My_Backup_Log0000000001
- My_Backup_Log0000000002
我们可以使用下述命令设置 IFX_ONTAPE_FILE_PREFIX 环境变量：
>>-setenv--IFX_ONTAPE_FILE_PREFIX--string---------------------->
另外，我们还可以在目录中创建连续逻辑日志文件备份。如果空间可用，逻辑日志将自动备份。 设置过程如下：
- 将 LTAPEDEV 参数设置为现有目录。
- 在 UNIX 上将 ALARMPROGRAM 参数设置为 log_full.sh 的完整路径，在 Windows 上将 ALARMPROGRAM 设置为 log_full.bat 的完整路径。
- 将 ALARMPROGRAM 参数中的备份程序从 onbar -b -l 更改为 ontape -a -y 。
- 重新启动数据库服务器。
SQL 下钻查询特性
在 SQL 语句性能监控时，我们经常要了解 SQL 语句执行了多长时间； SQL 语句运行时占用了多少系统资源，如 CPU 占用情况、内存占用情况、磁盘 I/O 读写情况； SQL 语句等待系统资源如磁盘 I/O 及锁的时间及次数等。通过 SQL 语句对系统的资源使用及等待情况，我们可以了解到 SQL 语句运行的瓶颈，并及时调整系统资源配置，或者调整用户的应用程序。我们虽然可以使用 set explain 命令帮助我们了解一些 SQL 语句性能问题，但是当我们启用 SET EXPLAIN 功能时，SQL 语句性能可能已经出现了问题，为了能够让 DBA 更及时、更详细地了解 SQL 语句的资源使用情况并做出相应的调整，在 Informix 11 版本中，提供了 SQL 下钻查询特性来满足上述功能。
关于 SQL 下钻查询特性的技术特点、使用范围及技术实现，请参考发表在 developerWorks 中国网站 Information Management 专区中文章“Informix 11.5 SQL 语句性能监控方法及实现 ”中的相关内容。
数据库性能方面的一些实用特性
非阻塞检查点
在 Informix 数据库使用过程中，当发生检查点操作时，会阻塞数据库应用程序的运行，直到检查点操作完成为止。这样，会显著降低数据库的性能。这时，我们往往需要调整数据库参数来减少检查点操作对系统性能的影响，但这种调整往往比较复杂，很难达到最优效果。为了解决上述问题，Informix 11 提出了非阻塞检查点技术，采用该技术后，检查点操作不再阻塞数据库应用程序的运行，系统效率得到显著的提高，也不再需要进行复杂的数据库调整操作。
关于非阻塞检查点技术的特点及技术实现，请参考文章“ Informix 11 非阻塞检查点及 RTO 策略应用实践”。
已落实读取隔离的并行性增强（LAST COMMITTED）
在 Informix 中，当用户在对一行或多行数据进行修改，另外用户要对相同数据进行读操作时，会出现锁等待（Lock Wait）现象，该用户要等到锁释放才可以继续操作。这会影响应用程序的效率。特别是在 OLTP 系统中，还容易产生死锁（Deadlocks）现象，影响系统的运行效率。为了提高应用程序效率，我们往往要调整 lock timeout 参数，将其设置为 30-60 秒，当锁等待超时后，中断该会话。另外，有些用户可能会将隔离级别设置为脏读，但对于有大量 update 操作的应用，这种隔离级别会读取幻象数据（phantom data），数据准确性不能得到保证。
如下面例子，采用 committed read 隔离级别，会产生锁等待现象。
begin work; create table tab(col1 int, col2 int) lock mode row; insert into tab values(10,11); insert into tab values(20,21); commit work; session 1: -------------- begin work; update tab set col2=99 where col1=10; session 2: -------------- begin work; set isolation to committed read ; select * from tab where col1=10; 244：Could not do a physical-order read to fetch next row. 107: ISAM error: record is locked.
如下面例子，采用 committed read 隔离级别，会产生死锁现象。
begin work; create table tab(col1 int, col2 int) lock mode row; insert into tab values(10,11); insert into tab values(20,21); commit work; session 1: -------------- begin work; set lock mode to wait; update tab set col2=99 where col1=10; select * from tab where col1=20; session 2: -------------- begin work; set lock mode to wait; update tab set col2=99 where col1=20; select * from tab where col1=10;
为了解决上述问题，提高应用系统并发执行效率，Informix 11 提供已落实读取隔离的并行性增强功能，通过为 SET ISOLATION TO COMMITTED READ 语句引入了新的 LAST COMMITTED 关键字选项，可减少尝试读取表时发生锁定冲突的风险。采用该语句，当用户读取正在被其他用户修改的数据时不在处于锁等待状态，而是可以读取修改前最近落实版本的数据值。 这样，由于不会产生锁等待，应用程序效率会显著提高，而且，由于是读取修改前最近落实版本的数据值，也不会产生读取幻象数据（phantom data）的问题，同时，也会大大减少产生死锁的现象。
如下面例子，当采用 committed read last committed 隔离级别后，用户将读取修改前最近落实版本的数据值，不会产生锁等待现象。
begin work; create table tab(col1 int, col2 int) lock mode row; insert into tab values(10,11); insert into tab values(20,21); commit work; session 1: -------------- begin work; update tab set col2=99 where col1=10; session 2: -------------- begin work; set isolation to committed read last committed; select * from tab where col1=10; C1 C2 10 11
我们可以通过以下几种方法来提高使用“已落实读”、“脏读”、“读已落实”或“读未落实”隔离级别的会话中的并行性能：
- 使用 Set Isolation to Committed Read Last Committed 语句
- 通过设置新的 USELASTCOMMITTED 配置参数扩展到脏读（Dirty Read）、未落实读取（Read Uncommitted）和已落实读取（Read Committed）隔离级别。
USELASTCOMMITTED 选项可具有以下四个值中的任意一个：
- 如果值为“ COMMITTED READ ”，那么当数据库服务器尝试读取处于“已落实读”或“读已落实”隔离级别的行而遇到互斥锁时，它将读取最近落实的数据版本。
- 如果值为“ DIRTY READ ”，那么当数据库服务器尝试读取处于“脏读”或“读已落实”隔离级别的行而遇到互斥锁时，它将读取最近落实的数据版本。
- 如果值为“ ALL ”，那么当数据库服务器尝试读取处于“已落实读”、“脏读”、“读已落实”或“读未落实”隔离级别的行而遇到互斥锁时，它将读取最近落实的数据版本。
- 如果值为“ NONE ”，那么此值将禁用可访问已锁定行中上次落实的数据版本的 USELASTCOMMITTED 功能。在此设置下，如果会话在尝试读取处于“已落实读”、“脏读”、“读已落实”或“读未落实”隔离级别的行时遇到互斥锁，那么在落实或回滚持有互斥锁的并发事务之前，事务不能读取该行。
- SET ENVIRONMENT USELASTCOMMITTED 语句
SET ENVIRONMENT 语句可以在运行时指定影响相同例程中随后提交的查询的选项。 SET ENVIRONMENT USELASTCOMMITTED 可指定遇到由其他会话持有的互斥锁的查询和其他操作在更改数据值时是否应使用最近落实的数据版本，而不是等待锁被释放。
此语句在执行当前会话期间可覆盖 USELASTCOMMITTED 配置参数设置。您可以使用 SET ISOLATION 语句来覆盖 USELASTCOMMITTED 会话环境设置。
例如，以下语句指定“已落实读”隔离方式，并将系统缺省 USELASTCOMMITTED 配置参数设置替换为读取最近落实的数据版本（数据位于并发阅读器持有互斥锁的行中）的设置。
SET ISOLATION COMMITTED READ; SET ENVIRONMENT USELASTCOMMITTED 'ALL';
任何 SPL 例程都可使用这些语句在会话期间指定“已落实读上次已落实”事务隔离级别。这些语句启用读取数据的 SQL 操作，从而在执行读取行的操作期间遇到互斥锁时使用上次落实的版本。当另一个会话尝试修改同一行时，这样可避免死锁情况或其他锁定错误。
例如，PUBLIC.sysdbopen 或 user.sysdbopen 过程中的以下语句在连接时指定“已落实读”隔离方式，并将显式或缺省 USELASTCOMMITTED 配置参数设置替换为读取表（其中并发阅读器持有互斥锁）中最近落实的数据版本的设置：
create procedure PUBLIC.sysdbopen() SET ISOLATION COMMITTED READ; SET ENVIRONMENT USELASTCOMMITTED 'ALL'; end procedure;
除 sysdbopen( ) 之外，任何 SPL 例程都可使用这些语句在会话期间指定“已落实读上次已落实”事务隔离级别。这些语句启用读取数据的 SQL 操作以在执行读取表的操作期间遇到互斥锁时使用上次落实的版本。当另一个会话尝试修改同一个行或表时，这样可避免死锁情况或其他锁定错误。
当启用 LAST COMMITTED 选项后， onstat 命令的输出也进行了相应的变化：
- -k 选项增加了新的内容
- -x 选项增加了“ LC ”作为隔离级别
- “ -g sql ” 选项增加了“ LC ”作为隔离级别
该功能支持 B 树索引和函数型索引，但不支持 R 树索引。它只支持“行”级别锁定，它不支持以下这些表：正在被 DataBlade 模块访问的表、列中具有集合数据类型的表、使用虚拟表界面创建的表、具有页面级别锁定的表、具有专用表级别锁定的表或无事务记录的数据库中的表。 它也不支持 HDR Secondary 。
在跨服务器的分布式查询中，如果发出查询的会话的隔离级别具有有效的 LAST COMMITTED 隔离级别，但一个或多个参与操作的数据库不支持该 LAST COMMITTED 功能，那么整个事务符合发出该事务的会话的“已落实读”或“脏读”隔离级别，而不启用 LAST COMMITTED 选项。
在 UNIX 上用 direct I/O 提高 cooked 文件的性能
在 Informix 11 中，随着 direct I/O 特性的引入，可以提高用于常规数据库空间块的 cooked 文件的 I/O 性能。使用文件系统的 I/O 通常慢于使用原始设备的 I/O 。这是因为通过文件系统进行读写有附加的开销。这增加了另一层的工作。此外，可能存在一个缓冲系统。这种缓冲会降低性能，而 IDS 不能控制操作系统的这个子系统。 Direct I/O 可以绕过文件系统层，包括任何缓冲，因此读和写的效率更高。可以使用 DIRECT_IO 配置参数启用 direct I/O 。 cooked 文件的性能可以接近用于数据库空间块的原始设备的性能。
DIRECT_IO 不能用于临时数据库空间，只能用于常规的数据库空间块。文件系统和操作系统必须支持给定页大小的 direct I/O 。对于原始设备，不支持 direct I/O 。对于原始设备上的块，更可取的 I/O 方法是 KAIO(kernel asynchronous I/O) 。
DIRECT_IO ONCONFIG 参数：
| DIRECT_IO 设置 | 描述 |
|---|---|
| 0 | Direct I/O 被关闭 |
| 1 | Direct I/O 被打开 |
注意： 有些操作系统启用 direct I/O，并且实现使用 KAIO (kernel asynchronous i/o) 。如果启用了 direct I/O，数据库服务器会尝试使用 KAIO 以完成这项工作。如果启用了 KAIO，可以减少 AIO 虚拟处理器的数量。这里假设 KAIO 已被启用（KAIOOFF 在环境中没有被设置）。
Windows 不支持 DIRECT_IO ONCONFIG 参数，因为在 Windows 平台上 direct I/O 是默认被启用的。
使用非日志记录原始表（RAW TABLE）
在 Informix 数据库中，如果采用日志模式的数据库，那么当对表进行大批量数据装载时，会消耗大量的日志，如果没有合适大小的日志空间，可能造成日志用满而挂起的问题。从 Informix 9.2 开始，您可在日志记录数据库中使用非日志记录原始表（raw table）来加快最初的装入和数据验证。数据仓库及其他应用程序可能具有非常大的表，需要很长的装入时间。装入非日志记录表比装入日志记录表要快。
RAW 表是非日志记录永久表并且类似于非日志记录数据库中的表。 RAW 表使用轻附加，这会将行快速添加到每个表分段的末尾。支持但不记录 RAW 表中的更新、插入和删除。 RAW 表不支持引用约束、唯一约束和回滚。如果从上次物理备份后还未更新 RAW 表，那么可以从该次备份中恢复该表。快速恢复将回滚 STANDARD 表（但非 RAW 表）上未完成的事务。无论是存储在日志记录数据库还是非日志记录数据库中，RAW 表的属性都相同。
要创建用于装入的非日志记录表，您可使用 CREATE RAW TABLE 语句或 ALTER TABLE 语句将表类型从 STANDARD 更改为 RAW 。 RAW 类型的表不允许引用约束，这样最初的装入就比 STANDARD 类型的表要快。原始表的装入完成后，您可通过将表类型更改为 STANDARD 来将其更改为日志记录表（在日志记录数据库中）。然后可使用 ALTER TABLE 语句将引用约束添加到表中并使用 CREATE INDEX 语句来添加索引。
下面例子显示了 raw table 创建的方法：
create raw table xyz
( col1 INT, col2 CHAR(10)
)
in dbspace {fragment by whatever};
or
alter table xyz type raw ;
下面例子显示了 raw table 恢复为 standard table 的方法
alter table xyz type standard ;
要装入原始表，您可使用任何数据装入实用程序，例如快速方式的 dbimport 或 HPL 。装入数据后，请执行 0 级（level-0）备份。修改原始表中的任何数据或在事务中使用它之前，请将表类型更改为 STANDARD 。
如果在原始表的装入期间发生错误或故障，结果数据将是故障时留在磁盘上的任何数据。
dbexport 和 dbschema 实用程序支持 CREATE RAW TABLE 和 ALTER TABLE...TYPE（RAW）语句。
注意：请勿在事务中使用 RAW 表。在已装入数据后，请首先使用 ALTER TABLE 语句将表更改为 STANDARD 类型并执行 0 级备份，然后再在事务中使用该表。
数据库应用开发方面的一些实用特性
会话配置例程（Session Configuration Routines）
在 Informix 11 版本中，新增加了 sysdbopen( ) 和 sysdbclose( ) 内置 SPL 过程，使数据库管理员能在用户连接到数据库或从数据库断开连接时，自动执行相关的 SQL 和 SPL 语句。通过使用这两个 SPL 过程，我们可以在连接或访问时更改数据库服务器会话的属性，而不更改会话所运行的应用程序。这样，对于那些不能通过修改应用程序的源代码来设置环境选项（或环境变量）或包含与会话相关的 SQL 语句（例如，由于 SQL 语句包含从供应商处获得的代码）的情况，该操作非常有用。同样，对于自动化应用程序终止之后需要执行的操作，主要是清除操作，这两个程序也很有用。
如果 DBA 将用户的登录标识指定为名称是 sysdbopen( ) 的过程的所有者，当指定用户连接到数据库或从数据库断开连接时，Informix Dynamic Server 会执行该过程。如果 DBA 将 PUBLIC 指定为所有者，当不是任何这些内置会话配置过程所有者的用户连接到数据库时，会自动执行该例程。同样，当已连接到数据库的用户执行引用其他数据库中对象的分布式操作（如跨数据库或跨服务器查询）时，不会调用 sysdbopen( ) 例程。
同样，如果没有为该用户在数据库中注册 user.sysdbclose( )，当该用户关闭与数据库的连接时，将会自动调用另一内置过程 user.sysdbclose( ) 或 public.sysdbclose( ) 。
如果要更改会话的属性，可为各种数据库设计定制 sysdbopen( ) 和 sysdbclose( ) 过程以支持特定用户或 PUBLIC 组的应用程序。 sysdbopen( ) 和 sysdbclose( ) 过程可包含数据库服务器在数据库打开或关闭时为用户或 PUBLIC 组执行的一系列 SET、SET ENVIRONMENT、SQL 或 SPL 语句。
例如，对于 user1，可定义包含 SET PDQPRIORITY、SET ISOLATION LEVEL、SET LOCK MODE、SET ROLE 或 SET EXPLAIN ON 语句的过程，无论何时 user1 使用 DATABASE 或 CONNECT TO 语句打开数据库时，这些过程都将执行。
sysdbopen( ) 过程中由 SET ENVIRONMENT 语句指定的会话环境变量 PDQPRIORITY 和 OPTCOMPIND 的任何设置都将在整个会话期间保持。对于常规过程非持久的 SET PDQPRIORITY 和 SET ENVIRONMENT OPTCOMPIND 语句，在 sysdbopen( ) 过程包含它们时将保持。
当作为过程所有者的用户从数据库断开连接时，将运行 user.sysdbclose( ) 过程（或者此时将运行 PUBLIC.sysdbclose( )，前提是此过程存在且当前用户不具有任何 sysdbclose( ) 过程）。
使用 sysdbopen( ) 和 sysdbclose( ) 内置 SPL 过程的先决条件：只有 DBA 或用户 informix 能够在 SQL 的 ALTER PROCEDURE、ALTER ROUTINE、CREATE PROCEDURE、CREATE PROCEDURE FROM、CREATE ROUTINE FROM、DROP PROCEDURE 或 DROP ROUTINE 语句中创建或更改 sysdbopen( ) 或 sysdbclose( ) 。
设置 sysdbopen() 和 sysdbclose() 过程以配置会话属性的基本操作步骤：
- 将 IFX_NODBPROC 环境变量设置为任何值（包括 0）以使数据库服务器绕过和防止 sysdbopen( ) 或 sysdbclose( ) 过程的执行。
- 编写 CREATE PROCEDURE 或 CREATE PROCEDURE FROM 语句以定义特定用户或 PUBLIC 组的过程。
- 测试过程（例如，通过使用 EXECUTE PROCEDURE 语句中的 sysdbclose( )）。
- 取消设置 IFX_NODBPROC 环境变量以使数据库服务器能够运行 sysdbopen( ) 或 sysdbclose( ) 过程。
下面的程序为特定用户 usr1 设置角色，并将隔离级别设为 committed read 。
create procedure usr1.sysdbopen() set role oltp; set isolation to committed read; end procedure;
这样，当用户 usr1 通过 DATABASE 或 CONNECT 语句连接到数据库时，将设置 oltp 角色，并将隔离级别设为 committed read 。
下面的程序设置 PUBLIC 组的角色和 PDQ 优先级。
create procedure public.sysdbopen() set role others; set pdqpriority 1; end procedure;
这样，当用户通过 DATABASE 或 CONNECT 语句连接到数据库时，如果没有为该用户创建自己的 sysdbopen( ) 过程，他将执行 public.sysdbopen() 过程，设置 oltp 角色，并将 PDQ 优先级设为 1 。
下面的程序为 PUBLIC 组创建 sysdbclose() 过程。
CREATE PROCEDURE public.sysdbclose() INSERT INTO logit VALUES(USER, “ O “ ,CURRENT::DATETIME YEAR TO SECOND); END PROCEDURE;
这样，当用户断开数据库连接时，如果没有为该用户创建自己的 sysdbclose() 过程，他将执行 public.sysdbclose() 过程，将用户信息、操作状态及相应的时间戳的信息保存到 logit 表中。
Disabling logging for temporary tables
在 Informix 数据库中，我们经常会创建一些临时表来处理应用中的临时信息。系统可以采用如下两种方式创建临时表：
- 使用 SELECT INTO TEMP 语句隐含地创建临时表
- 使用 CREATE TEMP TABLE 语句显示地创建临时表
如果数据库采用非日志模式，DBSPACETEMP 环境变量或配置参数设置后，临时表会自动创建在由 DBSPACETEMP 环境变量或配置参数指定的数据空间上；如果数据库采用日志模式，那么创建的临时表缺省情况下是记日志的，不会被创建在由 DBSPACETEMP 环境变量或配置参数指定的数据空间上，那么由 SELECT ... INTO TEMP 语句创建的临时表将被创建在根数据空间（Root dbspace）上，由 CREATE TEMP TABLE 语句创建的临时表将被创建在数据库所在的数据空间上。如果希望临时表创建在由 DBSPACETEMP 环境变量或配置参数指定的数据空间上，我们需要使用 SELECT INTO TEMP with no log 语句或 CREATE TEMP TABLE with no log 语句来创建临时表。
下边例子显示了在日志模式数据库中创建临时表的方法：
$ export DBSPACETEMP=dbs1,dbs2 SELECT number FROM account INTO TEMP tp1 Use with a logged database: Temp table tp1 is created in the rootdbs: SELECT number FROM account INTO TEMP tp2 WITH NO LOG Temp table tp2 is fragmented across dbs1,dbs2:
临时表按照如下优先顺序创建在相应的数据空间上：
- 由 DBSPACETEMP 环境变量指定的数据空间
- 由 DBSPACETEMP 配置参数指定的数据空间
如果设置了 DBSPACETEMP 环境变量，那么临时表会创建在由 DBSPACETEMP 环境变量指定的数据空间上，如果没有设置 DBSPACETEMP 环境变量，那么临时表会创建在由 DBSPACETEMPP 配置参数指定的数据空间上。
出于性能考虑，一般我们建议在多个物理磁盘上创建多个临时表空间，这样，当创建临时表时，它会分片到所有临时表空间上，提高并发处理效率。
在采用日志模式的数据库中，对临时表的所有 DML 操作都要记日志，而且不加 with no log 选项，临时表不会创建在由 DBSPACETEMP 环境变量或配置参数指定的临时数据空间上，往往数据会写到根数据空间（Root dbspace）上，影响系统性能，而且用户在创建临时表时，往往总是忘记 with no log 选项。为了解决上述问题，Informix 11 版本开始提供了关闭对临时表记日志的方法，这样，建临时表时，即使没加 with no log 选项，临时表也会创建在由 DBSPACETEMP 环境变量或配置参数指定的临时数据空间上。
我们可以采用下述两种方法来关闭对临时表记日志：
- 修改 onconfig 配置参数
TEMPTAB_NOLOG 1
- 通过 onmode 命令动态改变
onmode -Wf "TEMPTAB_NOLOG =1" onmode -Wm "TEMPTAB_NOLOG =1"
其中，-Wm 选项改变参数值后立即生效； -Wf 选项改变参数值后立即生效，同时将新的参数值写到 onconfig 配置文件中。
使用 TEMPTAB_NOLOG 参数来禁用临时表上的日志记录。该参数可以改进应用程序的性能，尤其是在有 HDR 辅助服务器、RS 辅助服务器或 SD 辅助服务器的数据复制环境中，因为其防止 Informix 通过网络传输临时表。
数据库高可用集群方面的一些实用特性
用户的关键业务系统，特别是 OLTP 系统，都要求提供 24X7 不间断的应用服务，这就要求数据库系统能够提供强大的高可用能力。这种能力不仅仅体现在主机及备机的接管方面，同时要能够提供远程容灾能力，以及本地的负载均衡能力。针对上述对数据库的要求，Informix 从版本 6 开始， 就提供了 HDR 技术，它是通过数据库的事务日志的方式实现了主、备机互相接管的功能，当主机工作时，备机提供只读功能，因此，备机可以提供查询、报表等功能，实现负载分担的功能，当主机发生故障，备机会自动接管，实现主机及备机的接管功能。从 Informix 7.2.2 版本开始，Informix 数据库提供了 ER(Enterprise Replication) 数据库复制技术，它也是通过读取数据库日志的方式实现数据同步功能，当源数据库数据发生变化后，Informix 数据库通过读取数据库日志，将变化的数据及时同步到目标数据库，采用 ER 的方式，和 HDR 不同，HDR 数据库的接管是基于数据库服务器的，也就是它的作用范围是基于整个实例的，而 ER 的作用范围是作用于一个表，你可以灵活定义需要复制哪些数据列及数据行，而且可以灵活定义数据复制的方式，是采用主从方式、汇总方式还是双向复制方式。从 Informix 11 开始，Informix 数据库提供了 SDS(Shared Disk Secondary)、RSS(Remote Standalone Secondary)、CLR(Continuous Log Restore) 等高可用集群技术，提供了更加强大的高可用能力。从 Informix 11.5 开始，HDR、SDS、RSS 备机都支持读写能力，提供了更强大的负载均衡能力。同时，从 Informix 11.5 开始，Informix 还提供了 Connection Manager 功能部件，它可以提供 SLA(Service Level Agreement) 功能，更好地实现负载均衡的能力，同时提供了 FOC(Fail Over Connection) 功能，实现透明故障接管能力，而且，所有这些对客户端应用来说是透明的。
结论
本文主要给大家介绍了 Informix 11.5 数据库中一些对数据库性能、数据库管理及应用开发等方面非常有用的特性，特别是新特性的介绍。此外，还有很多很有用的特性，比如说，基于标签的安全机制 LBAC、调度管理任务 、新的 SQL 函数 、XML 发布函数 、索引自连接查询计划 、多用户管理模式 、基于 PHP 的 OpenAdmin tool for IDS 、改善的统计信息收集和查询解释文件 、Enterprise Replication 的性能增强等，关于更多的相关特性的介绍，大家可以参考 Informix 信息中心的相关内容。
第二部分
我们知道，检查点是数据库服务器的一个非常重要的操作，用于将缓冲池内的事务和数据全部或部分清仓到磁盘，为数据库服务器生成一致性点，这样，当数据库服务器发生故障时，可以在已建立的点上重新启动。
检查点的目的在于定期将逻辑日志中的重新启动点向前移动。如果检查点不存在而且发生故障，那么数据库服务器应需要处理自系统重新启动以来逻辑日志中记录的所有事务。
完全检查点及模糊检查点
在版本 Informix 11 之前，Informix 有两种类型的检查点，一种是完全或同步检查点（Full or sync checkpoints），另一种是模糊检查点（Fuzzy checkpoints）。完全或同步检查点会将缓冲池内所有被修改的数据清仓到磁盘上，建立一个数据库服务器的一致点。通常，在发生完全或同步检查点操作时，数据库服务器中的事物被阻塞，直到检查点操作完成。当检查点持续时间很长，会对系统性能造成较大的影响。为了减少检查点对系统性能的影响，从 Informix 9.2 版本开始，Informix 引入了模糊检查点的概念，采用模糊检查点方式，同完全或同步检查点操作一样，将缓冲池内变化的数据清仓到磁盘上，但是，对数据库内置数据类型的 insert,update 及 delete 操作所改变的数据，不会被清仓到磁盘上，这样，每次模糊检查点操作持续的时间会大大减少，从而减少了对系统性能的影响。
当发生下述情况，系统会产生模糊检查点操作：
- 超过检查点间隔设定值，通常这个值在 onconfig 配置文件的 CKPTINTVL 参数中设置。
- 物理日志达到总大小的 75%
- 执行诸如增加数据库空间、增加块（chunk）之类的管理事件
- 执行 onmode -c fuzzy 命令
而当发生下述情况，系统会产生完全或同步检查点操作：
- 当使用 ontape 或 ON-Bar 命令进行备份或恢复操作时
- 当数据库服务器完成快速恢复（fast recovery）或完全恢复（ull recovery）
- 每个逻辑日志空间一个检查点：Informix Dynamic Server 不能覆盖包含当前检查点的逻辑日志，所以它必须在转移到那个逻辑日志之前触发检查点
- 执行 onmode -c 命令
- 执行正常的数据库服务器关闭操作
当发生完全检查点操作或模糊检查点操作时，数据库服务器会执行以下一系列操作：
- 阻塞事务
- 将物理日志缓冲区中的数据清仓到磁盘
- 将缓冲区中被修改的数据清仓到磁盘。如果是模糊检查点操作，informix 页清除线程会将非 inserts, deletes, updates 操作产生的变化数据清仓到磁盘，而由 inserts, deletes, updates 操作产生的变化数据不会被清仓到磁盘上；如果是完全检查点操，informix 页清除线程会将所有变化的数据清仓到磁盘。
- 将检查点完成记录写到逻辑日志缓冲区中，同时，将检查点信息更新到系统的保留页中 (system reserve page) 。
- 将逻辑日志缓冲区中的数据清仓到磁盘上
- 逻辑上清空物理日志
在 Informix 11 版本之前，不论是完全检查点操作还是模糊检查点操作都会阻塞事务，影响系统性能。因此，用户需要采用各种方法来尽量减少完全检查点操作及模糊检查点操作持续时间。通常，用户会将 LRU 参数调整的非常小，通过持续不断地清仓缓冲池中数据来减少检查点操作的时间。但是，当将 LRU 参数调整的非常小时，会降低写操作的缓冲，耗费大量的 CPU 资源，同时增加了对缓冲池的争用现象，同样也会影响系统 OLTP 的性能。系统优化工作成为一项非常困难的工作。另外，当有大量事务被阻塞时，模糊检查点操作时间是不可预料的，同时，采用模糊检查点操作方式，数据库服务器的故障恢复的时间也变得不可预知。
在 Informix 11 版本之前，检查点操作也会使用户在系统响应时间及系统可恢复性方面产生困惑：如果检查点的间隔短，系统恢复性能好，但会有更多的事务被阻塞；如果检查点的间隔长，更少的事务被阻塞，但系统恢复时间会更长。
非阻塞检查点
针对检查点上述的问题，从 Informix 11 版本开始，Informix 已将其检查点算法替换为事实上的非阻塞检查点算法。现在，Informix Dynamic Server 允许应用程序在发生检查点处理期间继续处理事务。 Informix Dynamic Server 监视工作负载及过去的检查点性能，并更加频繁地触发检查点以避免关键资源（如物理或逻辑日志）耗尽，确保事务在检查点处理期间不会受到阻塞。对于那些对响应时间很敏感的应用程序，原先使用主动 LRU 清仓减少检查点静止时间的方法可能被更改。由于事务处理在检查点处理期间不会受到阻塞，因此 LRU 清仓的主动性可能有所下降。让 LRU 清仓的主动性下降可以增强事务性能。
图 1. 显示了非阻塞检查点工作示意图
当系统触发非阻塞检查点操作时，首先短暂阻塞事务的处理，记录系统恢复信息，清仓逻辑日志缓冲区中的内容，记录检查点信息；之后，系统中的事务操作不再被阻塞，恢复继续运行，系统将内存中所有被修改的数据清仓到磁盘上，最后，将检查点的信息记载到系统保留页中，这样就完成了一个非阻塞检查点操作。我们可以看到，非阻塞检查点操作允许应用程序在发生检查点处理期间继续处理事务，事务不再被阻塞。
从 Informix 11 版本开始，Informix Dynamic Server V9 中引入的模糊检查点（fuzzy checkpoint）已经被摒弃。
检查点可在以下某个情境中出现：
当指定事件发生时。例如，每当将数据库空间添加到服务器或执行数据库备份时，检查点将出现。
通常，这些类型的事件会触发阻塞事务处理的检查点。因此，这些检查点称为阻塞检查点。
当资源限制发生时。例如，逻辑日志空间的每个范围需要检查点来保证日志具有开始快速恢复的检查点。数据库服务器将在物理日志达到总大小的 75% 时触发检查点，以避免物理日志溢出。
资源限制触发的检查点通常不会阻塞事务。因此，这些检查点称为非阻塞检查点。
但是，如果在检查点处理期间数据库服务器将要耗尽资源，那么在检查点处理的中段将出现事务阻塞，以保证耗尽资源之前检查点能够完成。如果事务被阻塞，那么服务器将更频繁的尝试触发检查点，以避免检查点处理期间的事务阻塞。
为了避免检查点阻塞事务处理，我们需要：
- 打开自动检查点特性。更频繁的检查点将发生。这可以防止由于缺少资源而发生阻塞。
- 增加物理日志或逻辑日志的大小。服务器将在在线日志中放置一条消息，建议增加哪种资源，以及它的大小应该是多少。
- LRU 刷新调整的更积极，覆盖 AUTO_LRU_TUNING 参数。
自动检查点 AUTO_CKPTS
自动检查点引起数据库服务器触发更频繁的检查点，以避免事务阻塞。自动检查点尝试监视系统活动和资源使用情况（物理和逻辑日志使用情况以及缓冲池脏的程度）以能够及时地触发检查点，这样检查点的处理就可在物理日志或逻辑日志耗尽之前完成。
数据库服务器为逻辑日志空间的每个范围生成至少一个自动检查点。这保证了可开始快速恢复的检查点的存在。
我们可以使用 AUTO_CKPTS 配置参数可在数据库服务器启动时启用或禁用自动检查点。默认情况下，在配置文件中它是自动启用的。
在 onconfig 文件中，我们可以设置下述参数：
AUTO_CKPTS 1
我们也可通过使用 onmode -wm 或 onmode -wf 来动态地启用或禁用自动检查点。
- turns off. onmode – wm AUTO_CKPTS=0 onmode – wf AUTO_CKPTS=0 - turns on. onmode – wm AUTO_CKPTS=1 onmode – wf AUTO_CKPTS=1
如果关闭了 AUTO_CKPTS，则 Informix Dynamic Server 只根据以下 4 个事件触发检查点：
- 诸如归档、onmode -c、增加数据库空间、启动和关闭服务器之类的管理事件
- 物理日志满了 75% 。确保物理日志较大，以避免在达到 CKPTINTVL 之前发生检查点处理
- 每个逻辑日志空间一个检查点：Informix Dynamic Server 不能覆盖包含当前检查点的逻辑日志，所以它必须在转移到那个逻辑日志之前触发检查点
- ONCONFIG 参数 CKPTINTVL
我们可以使用 onstat – g ckp 来监控系统检查点信息 , 以及建议资源分配信息。
onstat -g ckp 命令输出：
IBM Informix Dynamic Server Version 11.50.F -- On-Line -- Up 00:01:20 -- 299368 Kbytes Auto Checkpoints=On RTO_SERVER_RESTART=60 seconds Estimated recovery time 7 seconds Critical Sections Clock Total Flush Block # Ckpt Wait Long #Dirty Interval Time Trigger LSN Time Time Time Waits Time Time Time Buffers 1 18:41:36 Startup 1:f8 0.0 0.0 0.0 0 0.0 0.0 0.0 4 2 18:41:49 Admin 1:11c12cc 0.3 0.2 0.0 1 0.0 0.0 0.0 2884 3 18:42:21 Llog 8:188 2.3 2.0 2.0 1 0.0 2.0 2.0 14438 4 18:42:44*User 10:19c018 0.0 0.0 0.0 1 0.0 0.0 0.0 39 5 18:46:21 RTO 13:188 54.8 54.2 0.0 30 0.6 0.4 0.6 68232 Physical Log Logical Log Dskflu Total Avg Total Avg /Sec Pages /Sec Pages /Sec 4 3 0 1 0 2884 1966 163 4549 379 7388 318 10 65442 2181 39 536 21 20412 816 1259 210757 1033 150118 735 Max Plog Max Llog Max Dskflush Avg Dskflush Avg Dirty Blocked pages/sec pages/sec Time pages/sec pages/sec Time 8796 6581 54 43975 2314 0
onstat -g ckp 命令输出说明：
| AUTO_CKPTS | On/Off | Displays if automatic checkpoints feature is on or off |
|---|---|---|
| RTO_SERVER_RESTART | Seconds | Displays the RTO policy. 0=RTO policy is off. |
| Estimated recovery time | Seconds | This is the estimated time it would take the IDS server to perform fast recovery. |
| Interval | Number | Checkpoint interval id |
| Clock Time | Wall clock time | This is the wall clock time that the checkpoint occurred |
| Trigger | Text | There are several events that can trigger a checkpoint. The most common are RTO, Plog or Llog (running out of logical log resources). |
| LSN | Log position | Log position of checkpoint |
| Total Time | Seconds | Total checkpoint duration from request time to checkpoint completion |
| Flush Time | Seconds | Time to flush bufferpools |
| Block Time | Seconds | Transaction blocking time |
| # Waits | Number | Number of transactions that blocked waiting for checkpoint |
| Ckpt Time | Seconds | amount of time it takes for all transactions to recognize a checkpoint has been requested |
| Wait Time | Seconds | Average time thread waited for checkpoint |
| Long Time | Seconds | Longest amount of time a transaction waited for checkpoint |
| # Dirty Buffers | Number | Number of buffers flushed to disk during checkpoint processing |
| Dskflu/Sec | Number | Number of buffers flushed to disk per sec during checkpoint processing |
| Plog Total Pages | Number | Total number of pages physically logged during the checkpoint interval |
| Plog Avg/Sec | Number | Average rate of physical log activity during the checkpoint interval |
| Llog Total Pages | Number | Total number of pages logically logged during the checkpoint interval |
| Llog Avg/Sec | Number | Average rate of logical log activity during the checkpoint interval |
为了保存关于最近检查点性能的信息，Informix 11 在 SYSMATER 数据库中增加了下面两个表：
表 1. 用于检查点的新的 Sysmaster 表
| 表 | 描述 |
|---|---|
| syscheckpoint | 存放关于最近 20 个检查点的历史 |
| sysckptinfo | 跟踪检查点活动 |
LRU 的自动调优 AUTO_LRU_TUNING
在 Informix 11 之前，数据库管理员常见的做法是将 LRU 刷新调得更积极，以便不断地排出 LRU，经常将 LRU_MIN_DIRTY 设置为 1，LRU_MAX_DIRTY 设置为 2，这样，检查点将更快地完成，因为要做的工作更少了，同时这也减少了其他线程等待检查点完成所需的时间。
但是，在 Informix 11 中，由于在检查点期间事务处理不会被阻塞，因此不必将 LRU 刷新调得如此积极。通常，可以将 LRU_MIN_DIRTY 设置为 70，LRU_MAX_DIRTY 设置为 80 。将 LRU 刷新调得缓一些，可以提高写操作的缓冲，减少 CPU 资源的占用，并减少对缓冲池的争用现象，提高事务性能。在 Informix 11 上，通过放缓 LRU 刷新可以明显提高性能。
但是，当系统出现下述情况，会自动将 LRU 刷新调整的更积极一些：
- 当系统中一个页错误替代了一个热页面，LRU 刷新积极度自动增加 1% 。
- 当系统发生了页置换前台写操作，则数据库服务器将 LRU 设置增加 10%，并且在随后的每个检查点继续增加 LRU 刷新，直到页置换前台写操作停止
自动 LRU 调整只是使 LRU 刷新变得更积极，而不能减少 LRU 刷新。自动 LRU 调整不是永久的，不会记录在 ONCONFIG 文件中。 LRU 刷新会被重新设置为数据库服务器启动时使用的 ONCONFIG 文件中包含的值。
自动 LRU 调优对所有缓冲池都有影响，并且会调整 BUFFERPOOL 配置参数中的 LRU_MIN_DIRTY 和 LRU_MAX_DIRTY 值。
AUTO_LRU_TUNING 配置参数指定当服务器启动时是否启用自动 LRU 调优。默认情况下，在配置文件中 AUTO_LRU_TUNING 已被启用。
在 onconfig 文件中，我们可以设置下述参数：
AUTO_LRU_TUNING 1
我们也可以使用 onmode -wm 或 onmode -wf 动态地启用或禁用 LRU 调优。
- turns off. onmode – wm AUTO_LRU_TUNING= 0 onmode – wf AUTO_LRU_TUNING= 0 - turns on. onmode – wm AUTO_LRU_TUNING= 1 onmode – wf AUTO_LRU_TUNING= 1
自动 AIO VP 调优 AUTO_AIOVPS
从 Informix 11 版本开始，我们可以使用 AUTO_AIOVPS 配置参数使数据库服务器可以在服务器检测到 AIO VP 没有跟上 I/O 工作负载时自动调整 AIO VP 和刷新线程的数量。
默认情况下，AUTO_AIOVPS 在配置文件中已启用。
在 onconfig 文件中，我们可以设置下述参数：
AUTO_AIOVPS 1
我们也可以使用 onmode -wm 或 onmode -wf 动态地启用或禁用 AIO VP 和刷新线程的自动增加。
- turns off. onmode – wm AUTO_AIOVPS=0 onmode – wf AUTO_AIOVPS=0 - turns on. onmode – wm AUTO_AIOVPS=1 onmode – wf AUTO_AIOVPS=1
Recovery Time Objective (RTO) 策略
我们知道，当 Informix 数据库执行崩溃恢复时，我们没有任何方法可以预测崩溃恢复将在什么时间完成，需要多少物理日志及逻辑日志。同时，也没有什么配置参数来优化崩溃恢复的性能：CKPTINTVL 不能根据工作负载的变化进行相应的调整，模糊检查点使崩溃恢复时间更加不可预测。
Informix Dynamic Server V11 引入了配置参数 RTO_SERVER_RESTART 。该参数指定数据库服务器将尝试完成恢复并回到联机或静态模式的秒数。如果出现了崩溃，需要使服务器回到联机模式，那么这个参数就很方便。通过配置参数 RTO_SERVER_RESTART，使得崩溃恢复时间可以被我们把握。
在逻辑重放的过程中，必须处理每个日志记录。在此处理中，必须从磁盘读取页面。这种 I/O 会大大降低日志重放的性能。如果不知道快速恢复的逻辑部分需要多少 I/O，就难于判断恢复需要多长时间。
为了实现这个目标，并在规定的秒数内变得可用， Informix Dynamic Server 必须管理快速恢复期间发生的 I/O 量。当配置 RTO_SERVER_RESTART 时，Informix Dynamic Server 利用物理日志以保存它认为在逻辑恢复中要用到的附加前像（before-image）。
在快速恢复的物理部分，缓冲池将自动装入从最近检查点前滚逻辑日志所需的数据页。这里不必从磁盘读页面，因为它已经在内存中，可以直接使用。
启用 RTO_SERVER_RESTART 之后，数据库服务器 :
- 通过更频繁地触发检查点确保自动检查点没有用完关键资源（例如逻辑空间）而阻塞
- 忽略配置参数 CKPTINTVL
- 自动调整 AIO 虚拟处理器和清理线程的数量
- 自动调优 LRU 刷新，以接纳增加的检查点
Informix 通过 RAS_PLOG_SPEED 和 RAS_LLOG_SPEED 两个 ONCONFIG 参数来计算什么时侯触发检查点。 RAS_PLOG_SPEED 和 RAS_LLOG_SPEED 这两个 ONCONFIG 参数用于存放在快速恢复期间物理日志和逻辑日志恢复的速度。
RAS_PLOG_SPEED 最初是在物理日志初始化时设置的。
RAS_LLOG_SPEED 被初始化为 RAS_PLOG_SPEED 的 1/8 。
每当发生快速恢复时，这两个值将被更新，以反映实际的恢复速度。它们的单位是页 / 秒。
IBM 将这两个参数包括在 ONCONFIG 文件中，使得那些将 Informix Dynamic Server 嵌入到应用程序中的客户可以提供预先计算的值，从而不需要进行调优就能达到最佳性能。除非在 IBM 技术支持的指导下，否则 DBA 不应修改这些值。
但是，启用 RTO_SERVER_RESTART 也有一些不好的地方：
- 存储用于逻辑恢复的页面会增加物理日志活动 -- 这可能影响事务的性能
- 增加检查点的频率 -- 可以通过增加物理日志的大小以缓和这一点
默认情况下，RTO_SERVER_RESTART 被禁用。该配置参数的取值范围如下表所示：
表 2. RTO_SERVER_RESTART 配置参数的值
| RTO_SERVER_RESTART 设置 | 取值范围 |
|---|---|
| Off | 0 |
| On | 60-1800 |
可以通过手动地修改配置文件或者使用 onmode -wf RTO_SERVER_RESTART 以更改 RTO_SERVER_RESTART 配置参数。
RTO_SERVER_RESTART 的新值在数据库服务器停止并重新启动之后生效。
onmode -wf RTO_SERVER_RESTART=60
当启用 RTO_SERVER_RESTART，系统中的物理日志、逻辑日志及缓冲池都要足够大来保存 RTO_SERVER_RESTART 时间周期内所有的修改。
如果物理日志或逻辑日志空间太小，检查点就会因为日志空间不够而被触发；如果缓冲池太小，快速恢复将执行清仓到磁盘的操作，产生 I/O，降低快速恢复效率，将不能满足 RTO 的策略。
通常，对于缓冲池空间小于 4 千兆字节的系统，物理日志的大小可定在所有缓冲池总大小的 110% 。对于较大的缓冲池，以 4 千兆字节的物理日志空间开始，然后监视检查点活动。如果检查点出现太频繁，而且可能将影响性能，那么增加物理日志大小。
结论
Informix 11 数据库中的非阻塞检查点技术是一个非常重要的技术，使用它，可以显著提高数据库性能，从 Informix 11 开始，非阻塞检查点是数据库默认的检查点操作。同样，当我们采用 Informix 11 中的 RTO 技术后，数据库的崩溃恢复操作时间也可以由我们自己把握，显著提高了数据库服务质量水平 SLA（Service Level Agreement）。有关非阻塞检查点及 RTO 策略更详细的信息，大家可以参考 Informix 信息中心的相关内容。
第三部分
我们知道，从 Informix 11.5 xC4 开始，Informix 数据库提供了行压缩技术，它采用一种静态的基于字典的压缩算法，将表（table）或表分区（table fragments）中的数据行中重复的数据模式映射到一个占用空间较少的符号，从而减少表格或表分区数据的总大小。这些重复的数据模式不仅可以是一列中的数据，也可以是一列中的部分数据，甚至可以是跨数据列的数据。通过采用行压缩技术，Informix 11.5 可以节省高达 80% 的存储空间。同时，由于数据是采用压缩方式存储，I/O 读取效率会有 20% 左右的提高，内存使用效率会更高，数据库备份及恢复的时间也得到相应的减少。
图 1. 采用行压缩技术的示意图
上图中，我们发现，smpo 在数据行中重复出现，在压缩时，我们将其用（01）表示； Dallas TX 75063 同样在数据行中重复出现，在压缩时，我们将其用（02）表示，这样，会节省大量数据空间。
Informix 数据库不仅可以对行数据进行压缩，还可以整合表压缩后的空闲空间，并将该空闲空间归还给数据空间重复使用。通过采用行数据压缩技术，可以为我们带来如下好处：
- 大大节省硬盘存储空间
- 对于表分区（table fragments）压缩，减少了磁盘的使用
- 节省了逻辑日志的使用，从而节省更多的空间，并可以防止高吞吐量的联机事务处理出现瓶颈
- 数据页读取更少，因为一个数据页上可以容纳更多的行
- 需要规模较小的缓冲池，因为同样大小的缓冲池可以容纳更多的数据
- I/O 活动会更少：在一个数据页上会容纳更多的数据，对 insert, update, 及 delete 操作的日志记录会更小
- 在分区表环境，可以将不经常访问的历史数据分区进行压缩，而对经常访问的数据分区不进行压缩
- 可以释放表中不再需要的空闲空间
- 更快速的数据库备份及恢复
行压缩技术比较适合于 I/O 操作密集型的表，特别是缓冲池命中率较低的情况。在 OLTP 环境下，对 I/O 操作密集型的表进行行压缩，会显著提高处理性能。如果应用程序缓冲池命中率较高，而且高性能比磁盘空间的使用更重要，这时，采用行压缩技术就不太合适，因为压缩会降低处理性能。
采用行压缩技术，由于一个数据页上可以容纳更多的行，因此，数据库优化器会采用和未进行行压缩处理不同的执行计划。
如果你在使用数据库复制技术 ER，在一个复制服务器上对数据进行压缩，不会影响在其他复制服务器上的数据。
如果你在使用 High-Availability Data Replication (HDR), 在源对数据进行压缩，在目标同样会对数据进行压缩。你不能在 HDR secondary, RS secondary, or SD secondary server 上对数据进行压缩，因为 HDR 目标服务器上的数据必须和源上的一样。
哪些数据可以被压缩
我们通常会对表或表分区中具有重复模式的数据进行压缩。行压缩对数据类型没有任何限制，一般来讲，文本数据会比数值类型更容易被压缩，因为文本类型数据中会更容易包含重复模式。但我们不能仅仅根据数据类型来预测数据压缩比。
比如说：
- 对于存储在 char 或 varchar 字段中的文本数据，采用不同的语言或字符集，数据压缩比往往都不同
- 对于数值类型数据，如果存在大量的 0，往往压缩效果会好，但对于包含大量不同数值的数据，压缩效果不会太好
- 数据中包含大量空格的数据压缩效果会好
- 数据已经采用不同的压缩算法压缩之后，压缩效果不会太好
哪些数据不能够被压缩
我们不能对下边数据进行压缩：
- 在 sysmaster, sysutils, sysuser, syscdr, syscdcv1 数据库中的表或表分区
- Catalogs
- 临时表
- 虚拟表接口表（Virtual-table interface tables）
- A tblspace tblspace
- Internal partition tables
- 数据压缩字典表（Dictionary tables）
- Indexes
- 保存在数据行外边的 LOB 数据
使用行数据压缩及存储优化技术的基本步骤
当执行行数据压缩及存储优化任务时，用户必须能够连接到 sysadmin 数据库，并且必须是数据库服务器管理员（DBSA ）。通常，只有 informix 用户可以执行上述操作。
使用行数据压缩及存储优化技术主要包含以下步骤：
- 评估使用行压缩技术的压缩比
- 激活实例级数据压缩功能
- 创建数据压缩字典
- 压缩表或表分区中的行数据
- 整合表或表分区数据（Repack the table or fragment rows）
- 回收空闲空间（Reclaim free space）
评估使用行压缩技术的压缩比
在对表或表分区进行压缩前，我们可以使用 estimate_compression 命令评估一下，使用压缩功能会节省多少空间。评估的结果是根据数据抽样得出的，实际的压缩比可能与评估的结果不太一样。
下面例子显示了使用 estimate_compression 命令进行压缩评估的方法：
execute function sysadmin:task(‘table estimate_compression’,’orders1);
(expression) est curr change partnum table
----- ----- ------ ---------- -----------------------------------
87.5% 0.0% +87.5 0x0010017a stores:informix.orders1
Succeeded: table estimate_compression stores:informix.orders1
上边例子显示出，我们可以对 orders1 表进行 87.5% 的压缩（est 列），当前的压缩比是 0.0%（curr 列），change 列显示压缩比可以改变的压缩比是多少。
我们还可以使用 estimate_compression 命令的其他选项来进行压缩评估：
execute function sysadmin:admin(‘table estimate_compression’,’orders1); execute function sysadmin:task(‘fragment estimate_compression’,‘0x500003’); execute function sysadmin:admin(‘fragment estimate_compression’,‘0x500003’);
激活实例级数据压缩功能
在压缩数据之前，我们要先激活数据压缩功能。对于数据库服务器，我们只需激活一次。如果我们仅仅是要对数据压缩进行评估，我们不需要激活数据压缩功能。同样，如果我们使用 repack 或 shrink 命令释放空闲空间，我们也不需要激活数据压缩功能。
激活数据压缩功能，我们可以使用如下命令：
execute function sysadmin:task(‘enable compression’); execute function sysadmin:admin(‘enable compression’);
当实例激活数据压缩功能后，如果需要迁移到以前不支持压缩功能的版本，我们需要将数据进行解压缩或删除被压缩的表。
创建数据压缩字典
在 Informix 11.5 中，我们会为每一个被压缩的表或表分区建立一个数据压缩字典。在数据压缩字典中，保存重复的数据模式及相应的一个占用空间较少的符号。数据压缩字典会根据表或表分区中的数据随机抽样来创建，但数据必须至少 2000 行，不足 2000 行数据的表或表分区将不会创建数据压缩字典。数据压缩字典可以最多保存 3840 个数据模式，每一个数据模式的长度可以是 2 字节到 15 字节。在行压缩过程中，每一个数据模式会由一个 12 位（12-bit）的符号数字来代替。
Informix 会尝试选择最佳的数据模式进行压缩。数据压缩字典被保存在隐藏的字典表中。我们可以通过查询 sysmaster 数据库中的 syscompdicts_full 表或 syscompdicts 视图来获得数据压缩字典的相关信息。
通常，数据压缩字典会大约占用 100KB 的空间，因此，比较小的表不太适合进行压缩。另外，如果表或表分区中的数据行小于 4 个字节，Informix 也不会对其进行压缩。
当我们创建好数据压缩字典后，任何新插入或被修改的行都会被压缩。已经存在的行不会被压缩。
下面例子显示了使用 create_dictionary 命令创建数据压缩字典的方法：
execute function sysadmin:task(‘table create_dictionary’,’orders1’); execute function sysadmin:admin(‘table create_dictionary’,’orders1’); execute function sysadmin:task(‘fragment create_dictionary’, ‘0x500003’); execute function sysadmin:admin(‘fragment create_dictionary’, ‘0x500003’);
压缩表或表分区中的行数据
当执行 compress 命令对表或表分区数据进行压缩时，Informix 根据数据压缩字典对表或表分区中的所有数据进行压缩。如果数据压缩字典没有存在，压缩操作会帮我们创建一个数据压缩字典。当有新的数据插入或修改时，Informix 会自动按照数据压缩字典进行相应的压缩。
如果表中的数据发生了显著的变化，我们考虑数据压缩字典是按照旧数据来构建的，我们可以对数据进行解压缩，再重新进行压缩操作。
下面例子显示了使用 ccompress 命令压缩数据的方法：
execute function sysadmin:task(‘table compress’,’orders1’); execute function sysadmin:admin(‘table compress’,’orders1’); execute function sysadmin:task(‘fragment compress’, ‘0x500003’); execute function sysadmin:admin(‘fragment compress’, ‘0x500003’);
整合表或表分区数据（Repack the table or fragment rows）
repack 命令相当于磁盘的碎片整理工具，将表或表分区中的数据都迁移到最前边，将空闲空间整合到一块。由于 repack 操作在移动数据的同时，允许用户访问相应的表或表分区，因此，当采用低于 Repeatable Read 隔离级别的查询会产生幻想读的问题。为了解决这个问题，我们可以使用 Repeatable Read 隔离级别或者使用repack_offline命令。
下面例子显示了使用 repack 命令整合数据的方法：
execute function sysadmin:task(‘table repack’,’orders1’); execute function sysadmin:admin(‘table repack’,’orders1’); execute function sysadmin:task(‘fragment compress’, ‘0x500003’); execute function sysadmin:admin(‘fragment compress’, ‘0x500003’); execute function sysadmin:task(‘table repack_offline’,’orders1’); execute function sysadmin:admin(‘table repack_offline’,’orders1’); execute function sysadmin:task(‘fragment repack_offline’, ‘0x500003’); execute function sysadmin:admin(‘fragment repack_offline’, ‘0x500003’);
回收空闲空间（Reclaim free space）
shrink 命令用于将空闲空间归还给数据空间重复使用，这样可以减少表或表分区的空间占用。
下面例子显示了使用 shrink 命令回收空闲空间的方法：
execute function sysadmin:task(‘table shrink’,’orders1’); execute function sysadmin:admin(‘table shrink’,’orders1’); execute function sysadmin:task(‘fragment shrink’, ‘0x500003’); execute function sysadmin:admin(‘fragment shrink ’, ‘0x500003’);
我们可以在一个命令中执行上述命令选项的任意组合，但数据库服务器按照下边的顺序进行执行：
create_dictionary compress repack shrink
下面例子显示在一个命令中执行命令选项组合的方法：
execute function sysadmin:task(‘table compress repack shrink’,’orders1’); execute function sysadmin:task(‘table compress repack’,’orders1’); execute function sysadmin:task(‘table compress shrink’,’orders1’); execute function sysadmin:task(‘table repack shrink’,’orders1’);
数据解压缩
我们可以使用 uncompress 命令对表或表分区中的数据进行解压缩、阻止对新插入或修改的数据进行压缩及禁用数据压缩字典。同样，由于 uncompress 操作在移动数据的同时，允许用户访问相应的表或表分区，因此，当采用低于 Repeatable Read 隔离级别的查询会产生幻想读的问题。为了解决这个问题，我们可以使用 Repeatable Read 隔离级别或者使用 uncompress_offline 命令。
下面例子显示了使用 uncompress 命令解压缩数据的方法：
execute function sysadmin:task(‘table uncompress ’,’orders1’); execute function sysadmin:task(‘table uncompress_offline’,’orders1’); execute function sysadmin:task(‘fragment uncompress’, ‘0x500003’);
删除非活动的数据压缩字典
我们可以使用 purge_dictionary 命令删除非活动的数据压缩字典。在删除非活动的数据压缩字典之前，我们需要解压缩表或表分区中的压缩数据。当我们执行解压缩操作时，数据压缩字典会变成非活动状态，此时，我们可以删除它。
下面例子显示了使用 purge_dictionary 命令删除非活动的数据压缩字典的方法：
execute function sysadmin:task(‘table purge_dictionary’,’orders1’); execute function sysadmin:task(‘fragment purge_dictionary’, ‘0x500003’);
行数据压缩及存储优化的监控方法
我们可以使用数据库服务器实用程序、sysmaster 数据库表及 sysmaster 数据库视图来显示数据压缩统计信息及压缩字典相关的各种信息。
System-Monitoring Interface (SMI)
我们可以通过查询 sysmaster 数据库视图 syscompdicts 来显示 Informix 系统中活动及非活动数据压缩字典的元数据定义信息。
下面例子显示了 syscompdicts 中数据压缩字典信息：
> select * from sysmaster:syscompdicts; dict_partnum 1048954 dict_code_version 1 dict_dbsnum 1 dict_create_times+ 1242486139 dict_create_logun+ 5 dict_create_logpos 1941580 dict_drop_timesta+ 1242486268 dict_drop_loguniq+ 6 dict_drop_logpos 4378760 dict_partnum 1048954 dict_code_version 1 dict_dbsnum 1 dict_create_times+ 1242741114 dict_create_logun+ 10 dict_create_logpos 1634380 dict_drop_timesta+ 0 dict_drop_loguniq+ 0 dict_drop_logpos 0 2 row(s) retrieved.
我们也可以通过查询 sysmaster 数据库表 syscompdicts_full 来显示 Informix 系统中活动及非活动数据压缩字典的元数据定义信息及压缩字典的二进制对象信息。
只有 informix 用户可以访问该表。
下面例子显示了 syscompdicts_full 中数据压缩字典信息：
> select * from sysmaster:syscompdicts_full; dict_partnum 1048954 dict_code_version 1 dict_dbsnum 1 dict_create_times+ 1242486139 dict_create_logun+ 5 dict_create_logpos 1941580 dict_drop_timesta+ 1242486268 dict_drop_loguniq+ 6 dict_drop_logpos 4378760 dict_dictionary <BYTE value> dict_partnum 1048954 dict_code_version 1 dict_dbsnum 1 dict_create_times+ 1242741114 dict_create_logun+ 10 dict_create_logpos 1634380 dict_drop_timesta+ 0 dict_drop_loguniq+ 0 dict_drop_logpos 0 dict_dictionary <BYTE value> 2 row(s) retrieved.
onstat utility
我们可以使用 onstat – g ppd 命令来显示当前正在打开的活动压缩字典信息。它不能显示非活动的压缩字典信息。
下面例子显示了 onstat – g ppd 命令输出信息：
$ onstat -g ppd IBM Informix Dynamic Server Version 11.50.FC4 -- On-Line -- Up 1 days 19:42:23 -- 157696 Kbytes Partition Compression Dictionary Info partnum Version DbsNum CrTS CrLogID CrLogPos DrTS DrLogID DrLogPos 0x10017a 1 1 1242741114 10 1634380 0 0 0
onstat – g ppd 命令输出描述：
partnum使用数据压缩字典的表分区号
Version正在创建数据压缩字典的程序代码的版本号
DbsNum数据压缩字典所在的数据表空间号
CrTS数据压缩字典创建的时间戳
CrLogID当数据压缩字典创建时，所分配的日志号
CrLogPos当数据压缩字典创建时，所分配的逻辑日志的位置
DrTS数据压缩字典删除的时间戳
DrLogID当数据压缩字典删除时，所分配的日志号
DrLogPos当数据压缩字典删除时，所分配的逻辑日志的位置
我们还可以使用 onstat – g dsk 命令来跟踪当前正在执行的压缩操作的活动状态。
下面例子显示了 onstat – g dsk 命令输出信息：
$ onstat –g dsk IBM Informix Dynamic Server Version 11.50.FC4 -- On-Line -- Up 3 days 01:18:15 -- 174080 Kbytes Partnum OP Processed Cur Page Duration Table 0x02900002 4 2793215 246952 158s stock 0x02800005 4 1355213 248383 68s order_line
onstat – g dsk 命令输出描述：
- partnum
表或表分区的分区号
- OP
下边标志标识执行压缩的不同操作：
- 1 = create_dictionary
- 2 = compress
- 4 = repack
- 8 = repack_offline
- 16 = shrink
- 32 = uncompress
- 64 = uncompress_offline
- 128 = estimate_compression
- 256 = purge_dictionary
- Processed
相关操作处理的数据行数
- Curr Page
当前操作正在处理的数据行的页号
- Duration
操作持续的时间，以秒为单位
- Table
表名称
oncheck utility
我们可以使用 oncheck -pT 命令来显示表或表分区中压缩的行数及压缩的百分比。
下面例子显示了 oncheck -pT 命令输出信息：
$ oncheck –pT stores:orders1
TBLspace Report for stores:informix.orders1
Physical Address 1:32201
Creation date 04/09/2009 10:56:44
TBLspace Flags 8000801 Page Locking
TBLspace use 4 bit bit-maps
TBLspace is compressed
Maximum row size 80
Number of special columns 0
Number of keys 0
Number of extents 2
Current serial value 1024
Current SERIAL8 value 1
Current BIGSERIAL value 1
Current REFID value 1
Pagesize (k) 4
First extent size 8
Next extent size 8
Number of pages allocated 81
Number of pages used 81
Number of data pages 80
Number of rows 20217
Partition partnum 1048954
Partition lockid 1048954
Extents
Logical Page Physical Page Size Physical Pages
0 1:32766 8 8
8 1:32794 73 73
Compression Dictionary Identifiers
rowid loguniq logpos
1303 10 18f04c
TBLspace Usage Report for stores:informix.orders1
Type Pages Empty Semi-Full Full Very-Full
---------------- ---------- ---------- ---------- ---------- ----------
Free 0
Bit-Map 1
Index 0
Data (Home) 80
----------
Total Pages 81
Unused Space Summary
Unused data slots 0
Unused bytes per data page 36
Total unused bytes in data pages 2880
Home Data Page Version Summary
Version Count
0 (current) 80
Compressed Data Summary
Number of rows 20217
Number of compressed rows 20217
Percentage of compressed rows 100.00
结论
本文主要给大家介绍了 Informix 11.5 数据库行压缩技术的原理、优势，行压缩技术的具体使用及相应的监控方法。通过使用行压缩技术，不仅可以节省数据存储空间，还可以提高数据库处理性能，加快数据库备份及恢复的操作时间。有关行压缩技术更详细的信息，大家可以参考 Informix 信息中心的相关内容。
参考资料
学习
- 通过 Information Management 专区 Informix 专题，了解 Informix 产品和技术相关的更多内容。
- 参考 Informix 11.5 信息中心， 获得更多 Informix 11.5 全面的产品知识。
- 通过访问 Informix 11.5 高可用集群技术及应用实现，了解 Informix 的高可用集群技术及应用实现。
- 通过访问 连接管理器在 Informix 11.5 高可用集群中的使用，了解 Informix 的连接管理器技术及在高可用集群中的使用。
