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: alwaysonstat -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 0onchecks 命令将显示相应的页面大小 以下示例显示了 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 680RTO 策略
我们知道，当 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 BUFFERPOOLADD CHUNKADD LOGADD MEMORYADD MIRRORALTER CHUNK OFFLINEALTER CHUNK ONLINEALTER LOGMODEALTER PLOGARCHIVE FAKECHECK DATACHECK EXTENTSCHECK PARTITIONCHECKPOINTCLEAN SBSPACECREATE BLOBSPACECREATE CHUNKCREATE DBSPACECREATE SBSPACECREATE TEMPDBSPACECREATE BLOBSPACEDROP BLOBSPACEDROP CHUNKDROP DBSPACEDROP LOGDROP SBSPACEDROP TEMPDBSPACEONMODEPRINT ERRORPRINT PARTITIONQUIESCENTRENAME SPACESET CHUNK OFFLINESET CHUNK ONLINESET DATASKIP ONSET DATASKIP OFFSET SBSPACE ACCESSTIME ONSET SBSPACE ACCESSTIME OFFSET SBSPACE AVG_LO_SIZESET SBSPACE LOGGING ONSET SBSPACE LOGGING OFFSET SQL TRACINGSET SQL TRACING OFFSET SQL TRACING ONSET SQL TRACING RESIZESET SQL USER TRACINGSET SQL USER TRACING CLEARSET SQL USER TRACING OFFSHUTDOWNSTART MIRRORING spaceSTOP 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_L0My_Backup_L1My_Backup_L2My_Backup_Log0000000001My_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) 功能，实现透明故障接管能力，而且，所有这些对客户端应用来说是透明的。
