Informix Guide to SQL: Syntax SQL Statements

Use the ALTER FRAGMENT statement to alter the distribution strategy or storage location of an existing table or index.

The clauses of the ALTER FRAGMENT statement let you perform the following tasks.

The ALTER FRAGMENT statement applies only to table or index fragments that are located at the current site (or cluster, for Enterprise Decision Server). No remote information is accessed or updated.

Warning: This statement can cause indexes to be dropped and rebuilt. Before undertaking alter operations, check corresponding sections in your "Performance Guide" to review effects and strategies

General Privileges

You must have the Alter or the DBA privilege to change the fragmentation strategy of a table. You must have the Index or the DBA privilege to alter the fragmentation strategy of an index.

You cannot use the ALTER FRAGMENT statement on a temporary table, an external table, or a view.

If your table or index is not already fragmented, the only clauses available to you are INIT and ATTACH.

You cannot use ALTER FRAGMENT on a typed table that is part of a table hierarchy.

You cannot use the ALTER FRAGMENT statement on a generalized-key (GK) index. Also, you cannot use the ALTER FRAGMENT statement on any table that has a dependent GK index defined on it. In addition, you cannot use this statement on a table that has range fragmentation.

If the surviving_table has hash fragmentation, the only clauses available are ATTACH and INIT.

If your database uses logging, the ALTER FRAGMENT statement is executed within a single transaction. When the fragmentation strategy uses large numbers of records, you might run out of log space or disk space. (The database server requires extra disk space for the operation; it later frees the disk space).

When you run out of log space or disk space, try one of the following procedures to make more space available:

• Turn off logging and turn it back on again at the end of the operation. This procedure indirectly requires a backup of the root dbspace.
• Split the operations into multiple ALTER FRAGMENT statements, moving a smaller portion of records at each time.

For information about log-space requirements and disk-space requirements, see your Administrator's Guide. That guide also contains detailed instructions about how to turn off logging. For information about backups, refer to your Backup and Restore Guide.

You can place as many rows into a fragment as the available space in the dbspace allows.

1. Run the UPDATE STATISTICS statement on the table. This step fills the sysfragments system catalog table with the current table information.
2. Query the sysfragments system catalog table to examine the npused and nrows fields. The npused field gives you the number of data pages used in the fragment, and the nrows field gives you the number of rows in the fragment.

Use the attach clause to combine tables that contain identical table structures into a fragmentation strategy.

Important: Use the create table statement or the init clause of the ALTER fragment statement to create fragmented tables.

The ATTACH clause allows you to perform the following tasks:

• Create a single fragmented table by combining two or more identically-structured, nonfragmented tables

(See Combining Nonfragmented Tables to Create a Fragmented Table.)

• Attach one or more tables to a fragmented table

(See Attaching a Table to a Fragmented Table.)

You must be the DBA or the owner of the tables that are involved to use the ATTACH clause.

Any tables that you attach must have been created previously in separate dbspaces. You cannot attach the same table more than once.

All consumed tables listed in the ATTACH clause must be identical in structure to the surviving table; that is, all column definitions must match. The number, names, data types, and relative position of the columns must be identical.

You cannot attach a fragmented table to another fragmented table.

Additional Restrictions on the ATTACH Clause Specific to EDS

In addition to the general restrictions, every consumed table must be of the same usage type as the surviving table. For information about how to specify the usage type of a table, refer to Usage-Type Options.

You cannot use the ATTACH clause in certain situations. The attach operation fails:

• if the consumed tables contain data that belongs in some existing fragment of the surviving table.
• if existing data in the surviving table would belong in a new fragment.

In other words, you cannot use the ATTACH clause for data movement among fragments. To perform this task, see the INIT Clause.

The BEFORE and AFTER options allow you to place a new fragment either before or after an existing dbspace. You cannot use the BEFORE and AFTER options when the distribution scheme is round-robin.

When you attach a new fragment without an explicit BEFORE or AFTER option, the database server places the added fragment at the end of the fragmentation list, unless a remainder fragment exists. If a remainder fragment exists, the new fragment is placed just before the remainder fragment. You cannot attach a new fragment after the remainder fragment.

When you create or append to a hybrid-fragmented table, the positioning specification (BEFORE, AFTER, or REMAINDER) applies to an entire dbslice. You can use any dbspace in a dbslice to identify the dbslice for the BEFORE or AFTER position.

When you transform tables with identical table structures into fragments in a single table, you allow the database server to manage the fragmentation instead of allowing the application to manage the fragmentation. The distribution scheme can be round-robin or expression-based.

To make a single, fragmented table from two or more identically-structured, nonfragmented tables, the ATTACH clause must contain the surviving table in the attach list. The attach list is the list of tables in the ATTACH clause.

To include a rowid column in the newly-created single, fragmented table, attach all tables first and then add the rowid with the ALTER TABLE statement.

To attach a nonfragmented table to an already fragmented table, the nonfragmented table must have been created in a separate dbspace and must have the same table structure as the fragmented table. In the following example, a round-robin distribution scheme fragments the table cur_acct, and the table old_acct is a nonfragmented table that resides in a separate dbspace. The example shows how to attach old_acct to cur_acct:

ALTER FRAGMENT ON TABLE cur_acct ATTACH old_acct

When you attach one or more tables to a fragmented table, a consumed table must be nonfragmented.

When you attach one or more tables to a fragmented table, a consumed table can be nonfragmented or have hash fragmentation.

If you specify a consumed_table that has hash fragmentation, the hash column specification must match that of the surviving_table and any other consumed_table involved in the attach operation.

When you alter a hybrid-fragmented table with either an ATTACH or DETACH clause, you need specify only one dbspace to identify the entire set of dbspaces that are associated with a given expression in the base fragmentation strategy of the table.

The set of dbspaces associated with an expression in the base fragmentation strategy of the table might have been defined as one or more dbslices or a dbspaces. For more information, see Fragmenting by HYBRID.

If you know the name of the dbslice, but not any of the dbspaces that it comprises, you can name the first dbspace in the dbslice by adding .1 to the name of the dbslice. For example, if the dbslice were named dbsl1, you could specify dbsl1.1.

After the attach executes, all consumed tables no longer exist. Any constraints (CHECK or NOT NULL) that were on the consumed tables also no longer exist.

You must reference the records that were in the consumed tables through the surviving table.

In a logging database, when the attach executes, the database server extends any attached index on the surviving table according to the new fragmentation strategy of the surviving table. All rows in the consumed table are subject to these automatically adjusted indexes. For information on whether the database server completely rebuilds the index on the surviving table or reuses an index that was on the consumed table, see your Performance Guide.

In a nonlogging database, when the attach executes, the database server does not extend indexes on the surviving table according to the new fragmentation strategy of the surviving table. To extend the fragmentation strategy of an attached index according to the new fragmentations strategy of the surviving table, you must drop the index and recreate it on the surviving table.

A detached index on the surviving table retains its same fragmentation strategy. That is, a detached index does not automatically adjust to accommodate the new fragmentation of the surviving table.

For more information on what happens to indexes, see the discussion about altering table fragments in your Performance Guide.

Each BYTE and TEXT column in every table that is named in the ATTACH clause must have the same storage type, either blobspace or tblspace. If the BYTE or TEXT column is stored in a blobspace, the same column in all tables must be in the same blobspace. If the BYTE or TEXT column is stored in a tblspace, the same column must be stored in a tblspace in all tables.

In Enterprise Decision Server, BYTE and TEXT columns are stored in separate fragments that are created for that purpose. If a table includes a BYTE or TEXT column, the database server creates a separate, additional fragment in the same dbspace as each regular table fragment. BYTE or TEXT columns are stored in the separate fragment that is associated with the regular table fragment where a given row resides.

When an attach occurs, BYTE and TEXT fragments of the consumed table become part of the surviving table and continue to be associated with the same rows and data fragments as they were before the attach.

When you attach tables, any triggers that are defined on the consumed table no longer exist, and all rows in the consumed table are subject to the triggers that are defined in the surviving table. That is, triggers on the surviving table survive the ATTACH, but triggers on the consumed table are dropped.

No triggers are activated with the ATTACH clause, but subsequent data-manipulation operations on the new rows can activate triggers.

Views on the surviving table survive the ATTACH, but views on the consumed table are dropped.

You can attach a nonfragmented table to a table with any type of supported distribution scheme. In general, the resulting table has the same fragmentation strategy as the prior fragmentation strategy of the surviving_table. However, when you attach two or more nonfragmented tables, the distribution scheme can either be based on expression or round-robin.

The following table shows the distribution schemes that can result from different distribution schemes of the tables mentioned in the ATTACH clause.

The following table shows the distribution schemes that can result from different distribution schemes of the tables mentioned in the ATTACH clause.

When you attach a nonfragmented table to a table that has hash fragmentation, the resulting table has hybrid fragmentation.

You can attach a table with a hash distribution scheme to a table that currently has no fragmentation, hash fragmentation, or hybrid fragmentation. In any of these situations, the resulting table has a hybrid distribution scheme.

The following examples illustrate the use of the ATTACH clause to create fragmented tables with different distribution schemes.

The following example combines nonfragmented tables pen_types and pen_makers into a single, fragmented table, pen_types. Table pen_types resides in dbspace dbsp1, and table pen_makers resides in dbspace dbsp2. Table structures are identical in each table.

ALTER FRAGMENT ON TABLE pen_types 

	ATTACH pen_types, pen_makers

After you execute the ATTACH clause, the database server fragments the table pen_types round-robin into two dbspaces: the dbspace that contained pen_types and the dbspace that contained pen_makers. Table pen_makers is consumed, and no longer exists; all rows that were in table pen_makers are now in table pen_types.

Consider the following example that combines tables cur_acct and new_acct and uses an expression-based distribution scheme. Table cur_acct was originally created as a fragmented table and has fragments in dbspaces dbsp1 and dbsp2. The first statement of the example shows that table cur_acct was created with an expression-based distribution scheme. The second statement of the example creates table new_acct in dbsp3 without a fragmentation strategy. The third statement combines the tables cur_acct and new_acct. Table structures (columns) are identical in each table.

CREATE TABLE cur_acct (a int) FRAGMENT BY EXPRESSION

	a < 5 in dbsp1,

	a >= 5 and a < 10 in dbsp2;



CREATE TABLE new_acct (a int) IN dbsp3;



ALTER FRAGMENT ON TABLE cur_acct ATTACH new_acct AS a>=10;

When you examine the sysfragments system catalog table after you alter the fragment, you see that table cur_acct is fragmented by expression into three dbspaces. For additional information about the sysfragments system catalog table, see the Informix Guide to SQL: Reference.

In addition to simple range rules, you can use the ATTACH clause to fragment by expression with hash or arbitrary rules. For a discussion of all types of expressions in an expression-based distribution scheme, see FRAGMENT BY Clause for Tables.

Warning: When you specify a date value in a fragment expression, make sure to specify 4 digits instead of 2 digits for the year. When you specify a 4-digit year, the DBCENTURY environment variable has no effect on the distribution scheme. When you specify a 2-digit year, the DBCENTURY environment variable can affect the distribution scheme and can produce unpredictable results. For more information on the DBCENTURY environment variable, see the "Informix Guide to SQL: Reference." Hybrid Fragmentation Distribution Scheme

Consider a case where monthly sales data is added to the sales_info table defined below. Due to the large amount of data, the table is distributed evenly across multiple coservers with a system-defined hash function. To manage monthly additions of data to the table, it is also fragmented by a date expression. The combined hybrid fragmentation is declared in the following CREATE TABLE statement:

CREATE TABLE sales_info (order_num int, sale_date date, ...)

FRAGMENT BY HYBRID (order_num) EXPRESSION

sale_date >= '01/01/1996' AND sale_date < '02/01/1996'

IN sales_slice_9601,

sale_date >= '02/01/1996' AND sale_date < '03/01/1996'

IN sales_slice_9602,

.

.

.

sale_date >= '12/01/1996' AND sale_date < '01/01/1997'

IN sales_slice_9612

The data for a new month is originally loaded from an external source. The data is distributed evenly across the name coservers on which the sales_info table is defined, using a system-defined hash function on the same column:

CREATE TABLE jan_97 (order_num int, sale_date date, ...)

	FRAGMENT BY HASH (order_num) IN sales_slice_9701
INSERT INTO jan_97 SELECT (...) FROM ...

Once the data is loaded, you can attach the new table to sales_info. You can issue the following ALTER FRAGMENT statement to attach the new table:

ALTER FRAGMENT ON TABLE sales_info ATTACH jan_97 

	AS sale_date >= '01/01/1997' AND sale_date < '02/01/1997'

Use the DETACH clause to detach a table fragment from a distribution scheme and place the contents into a new nonfragmented table.

In Enterprise Decision Server, the new table can also be a table with hash fragmentation.

For an explanation of distribution schemes, see FRAGMENT BY Clause for Tables.

The new table that results from the execution of the DETACH clause does not inherit any indexes or constraints from the original table. Only the data remains.

The new table that results from the execution of the DETACH clause does not inherit any privileges from the original table. Instead this table has the default privileges for any new table. For further information on default table-level privileges, see the GRANT statement on Table-Level Privileges.

The DETACH clause cannot be applied to a table if that table is the parent of a referential constraint or if a rowid column is defined on the table.

In Enterprise Decision Server, you cannot use the DETACH clause if the table has a dependent GK index defined on it.

The following example shows the table cur_acct fragmented into two dbspaces, dbsp1 and dbsp2:

ALTER FRAGMENT ON TABLE cur_acct DETACH dbsp2 accounts

This example detaches dbsp2 from the distribution scheme for cur_acct and places the rows in a new table, accounts. Table accounts now has the same structure (column names, number of columns, data types, and so on) as table cur_acct, but the table accounts does not contain any indexes or constraints from the table cur_acct. Both tables are now nonfragmented.

The following example shows a table that contains three fragments:

ALTER FRAGMENT ON TABLE bus_acct DETACH dbsp3 cli_acct

This statement detaches dbsp3 from the distribution scheme for bus_acct and places the rows in a new table, cli_acct. Table cli_acct now has the same structure (column names, number of columns, data types, and so on) as bus_acct, but the table cli_acct does not contain any indexes or constraints from the table bus_acct. Table cli_acct is a nonfragmented table, and table bus_acct remains a fragmented table.

The new table will be a hash-fragmented table if the surviving_table had hybrid fragmentation and the detached dbslice has more than one fragment. In a hybrid-fragmented table, you specify the dbslice to be detached by naming any dbspace in that slice.

Consider the sales_info table discussed in the Hybrid Fragmentation Distribution Scheme. Once the January 1997 data is available in the sales_info table, you might archive year-old sales_info data.

ALTER FRAGMENT ON TABLE sales_info 

	DETACH sales_slice_9601.1 jan_96

In this example, data from January 1996 is detached from the sales_info table and placed in a new table called jan_96.

The INIT clause allows you to:

• move a nonfragmented table from one dbspace to another dbspace.
• convert a fragmented table to a nonfragmented table.
• fragment an existing table that is not fragmented without redefining the table.
• convert an existing fragmentation strategy to another fragmentation strategy
• fragment an existing index that is not fragmented without redefining the index
• convert a fragmented index to a nonfragmented index.

Warning: When you execute the ALTER FRAGMENT statement with this clause, it results in data movement if the table contains any data. If data moves, the potential exits for significant logging, for the transaction being aborted as a long transaction, and for a relatively long exclusive lock being held on the affected tables. Use this statement when it does not interfere with day-to-day operations. .

Element	Purpose	Restrictions	Syntax
dbslice	Dbslice that contains the fragmented information	The dbslice must exist at the time you execute the statement.	Identifier, p. 4-205
dbspace	Dbspace that contains the fragmented information	The dbspace must exist at the time you execute the statement.	Identifier, p. 4-205

You cannot use the INIT clause to change the fragmentation strategy of a table that has a GK index.

For more information about the storage spaces in which you can store a table, see Using the IN Clause.

When you use the INIT clause to modify a table, the tabid value in system catalog tables changes for the affected table. The constrid of all unique and referential constraints on the table also change.

Nonfragmented tables contain a pseudocolumn called the rowid column. Fragmented tables do not contain this column unless it is explicitly created.

Use the WITH ROWIDS option to add a new column called the rowid column. The database server assigns a unique number to each row that remains stable for the existence of the row. The database server creates an index that it uses to find the physical location of the row. Each row contains an additional 4 bytes to store the rowid column after you add the WITH ROWIDS option.

Important: Informix recommends that you use primary keys, rather than the rowid column, as an access method.

Converting a Fragmented Table to a Nonfragmented Table

You might decide that you no longer want a table to be fragmented. You can use the INIT clause to convert a fragmented table to a nonfragmented table. The following example shows the original fragmentation definition as well as how to use the ALTER FRAGMENT statement to convert the table:

CREATE TABLE checks (col1 int, col2 int)

	FRAGMENT BY ROUND ROBIN IN dbsp1, dbsp2, dbsp3;



ALTER FRAGMENT ON TABLE checks INIT IN dbsp1;

You must use the IN dbspace clause to place the table in a dbspace explicitly.

When you use the INIT clause to change a fragmented table to a nonfragmented table (that is, to rid the table of any fragmentation strategy), all attached indexes become nonfragmented indexes. In addition, constraints that do not use existing user indexes (detached indexes) become nonfragmented indexes. All newly nonfragmented indexes exist in the same dbspace as the new nonfragmented table.

When you use the INIT clause to change a fragmented table to a nonfragmented table, the fragmentation strategy of detached indexes (and constraints that use detached indexes) is not affected.

Use the FRAGMENT BY portion of the INIT clause to fragment an existing non-fragmented table or convert an existing fragmentation strategy to another fragmentation strategy.

For more information on the available fragmentation strategies, see the FRAGMENT BY Clause.

You can redefine a fragmentation strategy on a table if you decide that your initial strategy does not fulfill your needs. When you alter a fragmentation strategy, the database server discards the existing fragmentation strategy and moves records to fragments as defined in the new fragmentation strategy.

The following example shows the statement that originally defined the fragmentation strategy on the table account and then shows an ALTER FRAGMENT statement that redefines the fragmentation strategy:

CREATE TABLE account (col1 int, col2 int) 

	FRAGMENT BY ROUND ROBIN IN dbsp1, dbsp2;



ALTER FRAGMENT ON TABLE account

	INIT FRAGMENT BY EXPRESSION 

	col1 < 0 in dbsp1,

	col2 >= 0in dbsp2;

If an existing dbspace is full when you redefine a fragmentation strategy, you must not use it in the new fragmentation strategy.

You can use the INIT clause to define a fragmentation strategy on a nonfragmented table. It does not matter whether the table was created with a storage option.

When you use the INIT clause to fragment an existing nonfragmented table, all indexes on the table become fragmented in the same way as the table.

When you use the INIT clause to fragment an existing nonfragmented table, indexes retain their existing fragmentation strategy.

The following example shows the original table definition as well as how to use the ALTER FRAGMENT statement to fragment the table:

CREATE TABLE balances (col1 int, col2 int) IN dbsp1;



ALTER FRAGMENT ON TABLE balances INIT 

	FRAGMENT BY EXPRESSION

	col1 <= 500 IN dbsp1,

	col1 > 500 and col1 <=1000 IN dbsp2,

	REMAINDER IN dbsp3;

The INIT FRAGMENT BY clause for indexes allows you to fragment an existing index that is not fragmented without redefining the index. You can convert an existing fragmentation strategy to another fragmentation strategy. Any existing fragmentation strategy is discarded and records are moved to fragments as defined in the new fragmentation strategy. You can also convert a fragmented index to a nonfragmented index.

Use the FRAGMENT BY clause for indexes to define the expression-based distribution scheme.

You can fragment unique indexes only if the table uses an expression-based distribution scheme. The columns that are referenced in the fragment expression must be indexed columns. If your ALTER FRAGMENT INIT statement fails to meet either of these restrictions, the INIT fails, and work is rolled back.

You might have an attached unique index on a table fragmented by Column A. If you use INIT to change the table fragmentation to Column B, the INIT fails because the unique index is defined on Column A. To resolve this issue, you can use the INIT clause on the index to detach it from the table fragmentation strategy and fragment it separately.

System indexes (such as those used in referential constraints and unique constraints) use user indexes if the indexes exist. If no user indexes can be used, system indexes remain nonfragmented and are moved to the dbspace where the database was created. To fragment a system index, create the fragmented index on the constraint columns, and then use the ALTER TABLE statement to add the constraint.

You can detach an index from a table-fragmentation strategy with the INIT clause, which causes an attached index to become a detached index. This breaks any dependency of the index on the table fragmentation strategy.

Use the ADD clause to add another fragment to an existing fragmentation list.

You can add more dbspaces to a round-robin distribution scheme. The following example shows the original round-robin definition:

CREATE TABLE book (col1 int, col2 title)
FRAGMENT BY ROUND ROBIN in dbsp1, dbsp4;

To add another dbspace, use the ADD clause, as shown in the following example:

ALTER FRAGMENT ON TABLE book ADD dbsp3;

Adding a fragment expression to the fragmentation list in an expression-based distribution scheme can shuffle records from some existing fragments into the new fragment. When you add a new fragment into the middle of the fragmentation list, all the data existing in fragments after the new one must be re-evaluated. The following example shows the original expression definition:

.

.

.

	FRAGMENT BY EXPRESSION

	c1 < 100 IN dbsp1,

	c1 >= 100 and c1 < 200 IN dbsp2,

	REMAINDER IN dbsp3;

If you want to add another fragment to the fragmentation list and have this fragment hold rows between 200 and 300, use the following ALTER FRAGMENT statement:

ALTER FRAGMENT ON TABLE news ADD

	c1 >= 200 and c1 < 300 IN dbsp4;

Any rows that were formerly in the remainder fragment and that fit the criteria c1 >= 200 and c1 < 300 are moved to the new dbspace.

The BEFORE and AFTER options allow you to place a new fragment either before or after an existing dbspace. You cannot use the BEFORE and AFTER options when the distribution scheme is round-robin.

When you attach a new fragment without an explicit BEFORE or AFTER option, the database server places the added fragment at the end of the fragmentation list, unless a remainder fragment exists. If a remainder fragment exists, the new fragment is placed just before the remainder fragment. You cannot attach a new fragment after the remainder fragment.

You cannot add a remainder fragment when one already exists. When you add a new fragment to the fragmentation list, and a remainder fragment exists, the records in the remainder fragment are retrieved and re-evaluated. Some of these records may move to the new fragment. The remainder fragment always remains the last item in the fragment list.

Use the DROP clause to drop an existing fragment from a fragmentation list.

You cannot drop one of the fragments when the table contains only two fragments. You cannot drop a fragment in a table that is fragmented with an expression-based distribution scheme if the fragment contains data that cannot be moved to another fragment. If the distribution scheme contains a REMAINDER option, or if the expressions were constructed in an overlapping manner, you can drop a fragment that contains data.

When you want to make a fragmented table nonfragmented, use either the INIT or DETACH clause.

When you drop a fragment from a dbspace, the underlying dbspace is not affected. Only the fragment data within that dbspace is affected. When you drop a fragment all the records located in the fragment move to another fragment. The destination fragment might not have enough space for the additional records. When this happens, follow one of the procedures that are listed in Making More Space to increase your space, and retry the procedure.

The following examples show how to drop a fragment from a fragmentation list. The first line shows how to drop an index fragment, and the second line shows how to drop a table fragment.

ALTER FRAGMENT ON INDEX cust_indx DROP dbsp2;



ALTER FRAGMENT ON TABLE customer DROP dbsp1;

Use the MODIFY clause to change an existing fragment expression on an existing dbspace. You can also use the MODIFY clause to move a fragment expression from one dbspace to a different dbspace.

When you use the MODIFY clause, the underlying dbspaces are not affected. Only the fragment data within the dbspaces is affected.

You cannot change a REMAINDER fragment into a nonremainder fragment if records within the REMAINDER fragment do not pass the new expression.

When you use the MODIFY clause to change an expression without changing the dbspace storage for the expression, you must use the same name for the mod_dbspace and the new_dbspace.

The following example shows how to use the MODIFY clause to change an existing expression:

ALTER FRAGMENT ON TABLE cust_acct 

	MODIFY dbsp1 to acct_num < 65 IN dbsp1

When you use the MODIFY clause to move an expression from one dbspace to another, mod_dbspace is the name of the dbspace where the expression was previously located, and new_dbspace is the new location for the expression.

The following example shows how to use the MODIFY clause to move an expression from one dbspace to another:

ALTER FRAGMENT ON TABLE cust_acct

	MODIFY dbsp1 to acct_num < 35 in dbsp2

In this example, the distribution scheme for the cust_acct table is modified so that all row items in the column acct_num that are less than 35 are now contained in the dbspace dbsp2. These items were formerly contained in the dbspace dbsp1.

When you use the MODIFY clause to change the expression and move it to a new dbspace, change both the expression and the dbspace name.

If your indexes are attached indexes, and you modify the table, the index fragmentation strategy is also modified.

Related statements: CREATE TABLE, CREATE INDEX, and ALTER TABLE

For a discussion of fragmentation strategy, refer to the Informix Guide to Database Design and Implementation.

For information on how to maximize performance when you make fragment modifications, see your Performance Guide.