DB2 LUW 9.5 – Changing Collating Sequence Without Recreating Database

Here is the information on the CREATE INDEX statement for DB2. You may also want to check these links on designing indexes and space requirements for indexes as they also deal with your question on what factors into index page space.

Based on the last link it would seem to me that the page size for the index would be your column lengths + the index overhead. This may take you beyond the page size for your table. (Maybe that is what is happening here.) You could also try to place your table in a bigger tablespace. It may place the index in a bigger page size as well.

EDIT: I have tested this locally as well to see. Using Control Center I was able to get a more detailed picture of the error message. Per DB2: "Explanation:

The index could not be created or altered because the sum of the key column internal lengths would exceed the index key length limit. Also, an index cannot be created using a LONG VARCHAR, LONG VARGRAPHIC, or LOB column. If the index is defined on a typed table, there is additional index overhead that reduces the maximum length by 4 bytes. The index may be altered by an ALTER TABLE or ALTER NICKNAME statement that alters the data type of one or more columns.

An index extension could not be created because the sum of the columns returned by the GENERATE KEY function would exceed the index key length limit.

The index key length limit is based on the page size of the tablespace used by the index:

Max Key Length  Page size
--------------  ---------
1K              4K
2K              8K
4K              16K
8K              32K

The statement cannot be processed. The specified index or index extension was not created or the table or nickname could not be altered.

User response:

To modify the index definition or alter column, eliminate one or more key columns and reduce the key length to the permitted maximum. For an index extension definition, specify a different GENERATE KEY function, or redefine the function to reduce the length of the returned row."

As mentioned in my comment below your key size would be at least 32 + (4000 * 2 (for UTF-16)) + 2 (for varchar length identifier) + index overhead, so you are already at 8034+ bytes. This means just over 7K. I'm guessing you are not defining a tablespace, so it will default to USERSPACE1, which is an 8K tablespace), so you have a 2K max key length as shown by the table above, plus your error message). In order to make this key, you have to do one of two things

1. Alter your table definition so it isn't so big (probably reduce your varchar size) so you can fit within a 1K max key definition. I'm guessing you don't want to do this so then you end doing the next one:

2. Since your key space requires 8K key length, you need a 32K page size. You can leave the table in a default 4K tablespace, but the index MUST be in a 32K tablespace. If you are using automatic storage you could easily create a tablespace with the following:

create bufferpool BP32K immediate size 250 automatic pagesize 32K;
create large tablespace TS32K pagesize 32K managed by automatic
storage bufferpool BP32K; 
create table line (
  field_key   integer not null,
  value       varchar(4000),
  ... ) index in TS32K; 
create index key_value_idx on line (field_key, value);

This will place the index in the 32K tablespace and you should be fine.

There are several aspects that you might want to consider.

Firstly, you can assign proper authorities to the target instance owner during the restore automatically by using the DB2_RESTORE_GRANT_ADMIN_AUTHORITIES registry variable. If it's set to ON prior to the restore, the user performing the restore will get those authorities.

Secondly, most of the binding/compiling problems come from the fact that only the object owner, that is, the authorisation ID that created the object in the first place, is given permissions to perform certain operations on it. If you run DDL scripts in production as the instance owner, then this would be the owner ID of all objects after the restore, no matter the DB2_RESTORE_GRANT_ADMIN_AUTHORITIES setting. You could, of course, use the TRANSFER OWNERSHIP statement to change that, but in real life, with tens of thousands of objects in the database, this may not be practical.

To avoid the "secondly" part, in many organisations folks use a special "builder" authorisation ID, separate from the instance owner, to run DDL scripts. This ID will not be given any unnecessary privileges, can be tightly controlled, and, when existing in all environments, should be able to perform all necessary tasks without adding security exposure.