informix11.7新功能—碎片整理程序
碎片整理程序的作用是什么？
碎片整理程序将分区中的多个小区段合并成较长的连续区段，从而减少分区中总的区段数量。如果有大小适当的连续区段可用，那么在碎片整理完成后，只要在碎片整理程序运行时不向分区添加区段，分区最终会成为单个区段，分区可以是数据或者索引分区。碎片整理操作是在线操作。在进行碎片整理操作时，碎片整理程序不会执行独占锁，这样分区对于其他操作来说也是可用的。
Informix 11.70 还提供压缩、重新打包、和收缩功能。11.70 碎片整理程序与压缩、重新打包、和收缩有何不同？
压缩减少所存储数据的大小，从而在分区中生成未使用的空间。
重新打包将分区末端的行移动到分区上部的空白页空间中。
收缩将空的区段释放回数据库空间。
因此，压缩、重新打包、和收缩可能会像碎片整理程序一样，能够减少分区总的区段数量。然而，压缩、重新打包、和收缩在较低级别运行；碎片整理程序在区段级别运行。
碎片整理程序如何工作？
当在一个分区上调用碎片整理程序时，它首先进行检查，来确保正运行在有效的分区类型之上，并且不存在压缩之类的冲突操作与碎片整理程序并行运行。（如果存在与碎片整理程序冲突的操作，将返回错误代码。）然后碎片整理程序会检查是否有必要进行碎片整理。如果分区没有或仅有一个区段，那么就不会执行碎片整理；碎片整理程序会返回不含错误代码的成功操作。
当碎片整理操作开始时，表中会生成由 onstat -g defragment 命令所访问的条目。然后分区被 “冻结”（换句话说，仅对当前数量的区段进行碎片整理）。在碎片整理程序运行时增加的区段将不会被清除。注意，在每个数据库空间上只允许同时进行一个碎片整理操作。
接着，碎片整理程序会进入一个循环，它首先会尝试在涵盖两个或多个区段的分区中定位连续的空闲空间，然后会将这一空间分配给分区，并将数据从旧区段移动到新区段中。理想情况下，存在一个足够大的连续存储块来涵盖分区中的全部区段。在运行碎片整理程序之前向数据库空间增加区块有助于确保获得这一结果。如果最大的空闲区段无法涵盖两个或更多分区区段，碎片整理程序会设置错误代码并返回。
分区末端的空闲空间要作为碎片整理程序所涵盖的空间来考虑。如果这样不可取，那么可以在运行碎片整理程序之前在分区上运行收缩。
一旦碎片整理程序找到了能够涵盖两个或多个区段的空闲区段， 它会将页从旧区段移动到新区段。在移动时，碎片整理程序会采用缓存池来保持与其他使用的同步。如果缓存池的使用存在问题，那么建议在非高峰时间运行碎片整理程序。移动完每个页后，就可以对分区进行更新之类的操作了。“锁定” 时间越短越好，这样用户就不会感觉到碎片整理程序的运行。在移动每个页面时，会记录一个简短的日志。当初始分区区段为空时，事务就被提交了，此时移动已完成。碎片整理事务很短；不可能出现一个长事务。检查点没有被碎片整理程序阻塞。
分区可能包含空页。这通常发生在分区末端，不会复制这些页。
对于每次碎片整理，在碎片整理启动时，都会相应地在在线日志中出现一个消息。
仅在最后的事务被中止时，碎片整理程序才会发生故障。多数情况下，大部分任务已提交，不需要重做。在碎片整理操作正处于故障当中时，碎片整理程序不会自动再次启动。在快速恢复过程中，所有已提交事务都会重做，部分完成的事务将被放弃，并且数据库空间会恢复到一致状态。可在数据库空间上运行 oncheck -ce 命令，并且不会显示出区块中的 “漏洞”。
可在碎片整理完成后，利用 oncheck -pt 来检查分区区段的数量。
某些特定的分区操作会与 11.70 碎片整理程序冲突。这些冲突操作包括：压缩、重新打包、收缩、更改、在线索引构建、截断、以及删除。碎片整理程序不能在已分区分区、备份服务器、或者临时表上运行。
碎片整理程序应用示例
可利用 dbadmin 数据库中的 execute function 语法，或者通过 OAT 接口来调用碎片整理程序。指定一个表名导致该表中的所有片段被整理。可以指定分区号（partnum），那样的话，仅对该 partnum 进行碎片整理。在 11.70 UC2 及更新的版本中，可直接指定索引名。在 11.70 UC1 中，可以对索引进行碎片整理，但必须指定其 partnum。
可通过 dbaccess，或者通过 ESQL C 或 Java 程序来访问 execute function 语法。
我们以 Informix 所附带的销售演示数据库表作为示例表，可通过运行 sqldist bin 目录中的 dbaccessdemo_ud 脚本来创建此演示数据库。（有关其他信息，见 IBM Informix DB Access Users Guide 中关于如何进行设置的相关信息。）很不幸，dbaccessdemo_ud 所创建的表很短，而且有时在特定环境下可能仅包含一个区段。可运行以下命令来查看该表中的区段：
oncheck -pt sales_demo:sales
可以看到，该表中有三个区段。如果仅有一个区段，那么碎片整理程序就无法真正对其进行碎片整理，但是，此种情况下，碎片整理程序会返回成功。例如，在 oncheck -pt 的输出中，可以看到类似于清单 1 中展示的内容：
清单 1. 区段清单
Extents
Logical Page Physical Page Size Physical Pages
0 1:186118 8 8
8 1:186132 8 8
16 1:186168 16 16
这指出了销售表包含三个区段。第一个长度为 8 的区段从页 186118 开始。我们可利用 dbadmin 命令来对该分区进行碎片整理。在 dbaccess 中，选择 sysadmin 数据库，在 dbaccess 中，运行命令：
清单 2. 对分区进行碎片整理
execute function task ('defragment', 'sales_demo:sales');
或者，如果需要对表的索引或者片段进行碎片整理，则为：
execute function task ('defragment partnum', '1049104');
可在 oncheck -pt 输出中找到分区。
碎片整理完成后，可利用 oncheck -pt 来验证分区中的区段数量。
在本例中，您将看到一个区段。
Extents
Logical Page Physical Page Size Physical Pages
0 1:186184 32 32
如何监测碎片整理操作
可利用 onstat 的 onstat -g defragment 选项来监测碎片整理操作。必须在已启动碎片整理程序的分区上运行该命令，来查看正在进行的碎片整理操作。由于碎片整理操作可能运行得很快，特别对于小表更是如此，所以只能在很短的时间内看到碎片整理信息。
该命令的输出如下：
清单 3. onstat -g defragment
onstat -g defragment 的输出
Defrag info
id table name id dbsnum partnum status substatus errnum
62 test:informix.tab1 55 3 3145730 SEARCHING_FOR_EXTENT 0 0
62 test:informix.tab1 55 3 3145730 MERGING_EXTENTS 0 0
不同类型的状态是：
SEARCHING_FOR_EXTENT, MERGING_EXTENTS, DEFRAG_COMPLETED, DEFRAG_FAILED
在 DEFRAG_FAILED- 的情况下，它给出的是 errnum。在所有其他情况下 errnum 是 0。
限制概述
要注意以下限制：
在一个分区上，仅允许同时进行一个碎片整理操作。
在一个数据库空间中，仅允许同时进行一个碎片整理操作。
如果在相同分区中已经存在以下操作，则碎片整理操作中止：
截断
删除
压缩、重新打包、收缩
解压缩
在线索引构建
更改
碎片整理程序将分区中的多个小区段合并成较长的连续区段，从而减少分区中总的区段数量。如果有大小适当的连续区段可用，那么在碎片整理完成后，只要在碎片整理程序运行时不向分区添加区段，分区最终会成为单个区段，分区可以是数据或者索引分区。碎片整理操作是在线操作。在进行碎片整理操作时，碎片整理程序不会执行独占锁，这样分区对于其他操作来说也是可用的。
Informix 11.70 还提供压缩、重新打包、和收缩功能。11.70 碎片整理程序与压缩、重新打包、和收缩有何不同？
压缩减少所存储数据的大小，从而在分区中生成未使用的空间。
重新打包将分区末端的行移动到分区上部的空白页空间中。
收缩将空的区段释放回数据库空间。
因此，压缩、重新打包、和收缩可能会像碎片整理程序一样，能够减少分区总的区段数量。然而，压缩、重新打包、和收缩在较低级别运行；碎片整理程序在区段级别运行。
碎片整理程序如何工作？
当在一个分区上调用碎片整理程序时，它首先进行检查，来确保正运行在有效的分区类型之上，并且不存在压缩之类的冲突操作与碎片整理程序并行运行。（如果存在与碎片整理程序冲突的操作，将返回错误代码。）然后碎片整理程序会检查是否有必要进行碎片整理。如果分区没有或仅有一个区段，那么就不会执行碎片整理；碎片整理程序会返回不含错误代码的成功操作。
当碎片整理操作开始时，表中会生成由 onstat -g defragment 命令所访问的条目。然后分区被 “冻结”（换句话说，仅对当前数量的区段进行碎片整理）。在碎片整理程序运行时增加的区段将不会被清除。注意，在每个数据库空间上只允许同时进行一个碎片整理操作。
接着，碎片整理程序会进入一个循环，它首先会尝试在涵盖两个或多个区段的分区中定位连续的空闲空间，然后会将这一空间分配给分区，并将数据从旧区段移动到新区段中。理想情况下，存在一个足够大的连续存储块来涵盖分区中的全部区段。在运行碎片整理程序之前向数据库空间增加区块有助于确保获得这一结果。如果最大的空闲区段无法涵盖两个或更多分区区段，碎片整理程序会设置错误代码并返回。
分区末端的空闲空间要作为碎片整理程序所涵盖的空间来考虑。如果这样不可取，那么可以在运行碎片整理程序之前在分区上运行收缩。
一旦碎片整理程序找到了能够涵盖两个或多个区段的空闲区段， 它会将页从旧区段移动到新区段。在移动时，碎片整理程序会采用缓存池来保持与其他使用的同步。如果缓存池的使用存在问题，那么建议在非高峰时间运行碎片整理程序。移动完每个页后，就可以对分区进行更新之类的操作了。“锁定” 时间越短越好，这样用户就不会感觉到碎片整理程序的运行。在移动每个页面时，会记录一个简短的日志。当初始分区区段为空时，事务就被提交了，此时移动已完成。碎片整理事务很短；不可能出现一个长事务。检查点没有被碎片整理程序阻塞。
分区可能包含空页。这通常发生在分区末端，不会复制这些页。
对于每次碎片整理，在碎片整理启动时，都会相应地在在线日志中出现一个消息。
仅在最后的事务被中止时，碎片整理程序才会发生故障。多数情况下，大部分任务已提交，不需要重做。在碎片整理操作正处于故障当中时，碎片整理程序不会自动再次启动。在快速恢复过程中，所有已提交事务都会重做，部分完成的事务将被放弃，并且数据库空间会恢复到一致状态。可在数据库空间上运行 oncheck -ce 命令，并且不会显示出区块中的 “漏洞”。
可在碎片整理完成后，利用 oncheck -pt 来检查分区区段的数量。
某些特定的分区操作会与 11.70 碎片整理程序冲突。这些冲突操作包括：压缩、重新打包、收缩、更改、在线索引构建、截断、以及删除。碎片整理程序不能在已分区分区、备份服务器、或者临时表上运行。
碎片整理程序应用示例
可利用 dbadmin 数据库中的 execute function 语法，或者通过 OAT 接口来调用碎片整理程序。指定一个表名导致该表中的所有片段被整理。可以指定分区号（partnum），那样的话，仅对该 partnum 进行碎片整理。在 11.70 UC2 及更新的版本中，可直接指定索引名。在 11.70 UC1 中，可以对索引进行碎片整理，但必须指定其 partnum。
可通过 dbaccess，或者通过 ESQL C 或 Java 程序来访问 execute function 语法。
我们以 Informix 所附带的销售演示数据库表作为示例表，可通过运行 sqldist bin 目录中的 dbaccessdemo_ud 脚本来创建此演示数据库。（有关其他信息，见 IBM Informix DB Access Users Guide 中关于如何进行设置的相关信息。）很不幸，dbaccessdemo_ud 所创建的表很短，而且有时在特定环境下可能仅包含一个区段。可运行以下命令来查看该表中的区段：
oncheck -pt sales_demo:sales
可以看到，该表中有三个区段。如果仅有一个区段，那么碎片整理程序就无法真正对其进行碎片整理，但是，此种情况下，碎片整理程序会返回成功。例如，在 oncheck -pt 的输出中，可以看到类似于清单 1 中展示的内容：
清单 1. 区段清单
Extents
Logical Page Physical Page Size Physical Pages
0 1:186118 8 8
8 1:186132 8 8
16 1:186168 16 16
这指出了销售表包含三个区段。第一个长度为 8 的区段从页 186118 开始。我们可利用 dbadmin 命令来对该分区进行碎片整理。在 dbaccess 中，选择 sysadmin 数据库，在 dbaccess 中，运行命令：
清单 2. 对分区进行碎片整理
execute function task ('defragment', 'sales_demo:sales');
或者，如果需要对表的索引或者片段进行碎片整理，则为：
execute function task ('defragment partnum', '1049104');
可在 oncheck -pt 输出中找到分区。
碎片整理完成后，可利用 oncheck -pt 来验证分区中的区段数量。
在本例中，您将看到一个区段。
Extents
Logical Page Physical Page Size Physical Pages
0 1:186184 32 32
如何监测碎片整理操作
可利用 onstat 的 onstat -g defragment 选项来监测碎片整理操作。必须在已启动碎片整理程序的分区上运行该命令，来查看正在进行的碎片整理操作。由于碎片整理操作可能运行得很快，特别对于小表更是如此，所以只能在很短的时间内看到碎片整理信息。
该命令的输出如下：
清单 3. onstat -g defragment
onstat -g defragment 的输出
Defrag info
id table name id dbsnum partnum status substatus errnum
62 test:informix.tab1 55 3 3145730 SEARCHING_FOR_EXTENT 0 0
62 test:informix.tab1 55 3 3145730 MERGING_EXTENTS 0 0
不同类型的状态是：
SEARCHING_FOR_EXTENT, MERGING_EXTENTS, DEFRAG_COMPLETED, DEFRAG_FAILED
在 DEFRAG_FAILED- 的情况下，它给出的是 errnum。在所有其他情况下 errnum 是 0。
限制概述
要注意以下限制：
在一个分区上，仅允许同时进行一个碎片整理操作。
在一个数据库空间中，仅允许同时进行一个碎片整理操作。
如果在相同分区中已经存在以下操作，则碎片整理操作中止：
截断
删除
压缩、重新打包、收缩
解压缩
在线索引构建
更改