Consider fragmenting your tables if you have at least one of the following goals:
To improve the performance of individual queries, use fragmentation with parallel database query (PDQ) to scan in parallel fragments that are spread across multiple disks.
Fragmentation can reduce contention for data that is located in large tables that are used by multiple queries and OLTP applications. Fragmentation reduces contention because each fragment resides on a separate I/O device, and the database server directs queries to the appropriate fragment.
If a fragment becomes unavailable, the database server can still access the remaining fragments.
When the database server uses parallel inserts and external tables to load a table that is fragmented across multiple coservers, it allocates threads to light append the data into the fragments in parallel. For more information on this load method, refer to the chapter on loading with external tables in the IBM Informix: Administrator's Reference.
You can also use the alter fragment table with the attach clause to add data quickly to a very large table.
Fragmentation gives you a finer backup-and-restore granularity. This granularity can reduce the time that is required for backup-and-restore operations. In addition, you can improve the performance of backup-and-restore operations if you use ON-Bar to perform these operations in parallel.
Each of the preceding goals has its own implications for the fragmentation strategy that you ultimately implement. Fragmentation Strategies discusses these issues. Your primary fragmentation goal determines, or at least influences, how you implement your fragmentation strategy.
In deciding whether to use fragmentation to meet any of the preceding goals, keep in mind that fragmentation requires some additional administration and monitoring activity. For more information about fragmentation, refer to your IBM Informix: Performance Guide.
Home | [ Top of Page | Previous Page | Next Page | Contents | Index ]