Professional Documents
Culture Documents
30 Jul 2009
IBM® DB2® 9.7 introduces enhancements that allow you to make changes to the
database objects while keeping these objects fully accessible to the database users
during the modification. These enhancements allow database administrators to make
vital changes to the database schema on the fly without any disruption to users. This
article includes examples that demonstrate how to use the ALTER TABLE command
to rename columns and change column data types. Other examples demonstrate
how to use the ADMIN_MOVE_TABLE routine to move and modify tables while
keeping them accessible.
Overview
This article provides a guide to using the new enhancements to DB2 9.7 that enable
you to make online changes to the database schema. Online change means that the
objects being changed remain available for read and write access even during the
change process.
• CREATE with errors support has been added for the views and inline
SQL functions.
• ALTER COLUMN SET DATA TYPE support has been extended.
• Tables can be changed and moved online using the
ADMIN_MOVE_TABLE routine.
To use the examples in the article, you must have DB2 9.7 for Linux, UNIX, and
Windows. Refer to the Resources section for a link you can use to download a free
trial version of DB2 9.7 for Linux, UNIX, and Windows.
Once you have created the SAMPLE database, follow these steps to create the
required table and data used in the examples:
1. Use the following command to create a table based on the system catalog
that simulates customer information:
Listing 1. Create CUSTOMER_INFO table
3. In this final step, you create a view and function on top of the
CUSTOMER_INFO table.
Note the order in which you create the objects. You create the
EXISTING_CUSTOMERS view before you create the FULL_NAME
function that the view depends on. This is significant because by default,
this would cause the CREATE OR REPLACE VIEW statement to fail with
an SQL0440N error.
However, beginning with version 9.7 you can configure DB2 to allow
creation of objects with certain types of errors such as missing dependent
objects. This capability can be useful for database object creation, design,
and modification because it permits you to have a random order of
CREATE commands. It also allows you to verify the syntax of new views
and procedures without creating the objects they depend on.
In order to enable this feature, use the following command to change the
AUTO_REVAL dynamic database configuration parameter to have a
value of DEFERRED_FORCE.
is automatically revalidated.
Use the following commands to create the new view and function. Note
that the commands take advantage of the new CREATE OR REPLACE
syntax that is applicable to functions, procedures, views, modules,
aliases, triggers, variables, and nicknames. As the name implies, this
syntax creates the object, or if it exists already, replaces it. In other words,
for existing objects it combines both DROP and CREATE in one
command plus it preserves the existing privileges granted on the object.
• First, you can rename columns online, while workload is running against
the table, without any disruption to your users.
• Second, DB2 9.7 has extended its support for changing column data
types on existing tables.
The following example demonstrates how to rename a column using the ALTER
TABLE command while keeping the table fully accessible:
The ALTER COLUMN SET DATA TYPE option on the ALTER TABLE statement has
been extended to support all compatible types. For example, you can now change a
column defined with a data type of INTEGER to have a data type of VARCHAR, or
you can change a data type of TIMESTAMP to DATE. Refer to the "Casting between
data types" article of the DB2 Information Center for a complete list of compatible
data types (see the Resources section for a link).
During the ALTER TABLE operation with the ALTER COLUMN SET DATA TYPE
option, DB2 performs a complete validation to ensure the data in the column is
compatible with new data type and there is no truncation, overflow, or any other type
of error. The column default values are also verified to ensure that they conform to
the new data type. If the column type and the data content are compatible, the data
type is successfully altered. Otherwise, the ALTER command returns an error.
The following example demonstrates how to change the data type of a column
named customer_age from VARCHAR(2) to SMALLINT:
ALTER TABLE customer_info ALTER COLUMN customer_age SET DATA TYPE SMALLINT;
In most cases, ALTER SET DATA TYPE requires table reorganization (reorg)
because it changes the physical row format. You can use the
ADMIN_REVALIDATE_DB_OBJECTS routine to automatically determine if the table
requires reorg or not:
If you need to have write access to the database available while column data type is
changed, you can use of ADMIN_MOVE_TABLE routine described in the next
section.
In addition to changing the tablespace location of a table, you can also use the
ADMIN_MOVE_TABLE routine to alter multi-dimensional clustering, partitioning
In the following example, an SQL statement captures foreign key information and
generates DROP statements:
The next example demonstrates how to move the CUSTOMER_INFO table to a new
tablespace:
INIT_START 2009-06-11-13.24.43.250000
REPLAY_END 2009-06-11-13.24.45.250000
REPLAY_START 2009-06-11-13.24.44.641000
REPLAY_TOTAL_ROWS 0
REPLAY_TOTAL_TIME 0
STATUS COMPLETE
SWAP_END 2009-06-11-13.24.45.391000
SWAP_RETRIES 0
SWAP_START 2009-06-11-13.24.45.329000
VERSION 09.07.0000
21 record(s) selected.
The next example is a bit more complex. This example moves the same
CUSTOMER_INFO table, but it uses the LOAD option instead of the INSERT FROM
CURSOR option, which is the default.
Several factors contribute to making the LOAD option faster than INSERT FROM
CURSOR option:
• LOAD does not log the changes on the target per record.
• LOAD is highly parallelized for CPU and I/O processing.
• LOAD performs large block writes to the target table. This provides
additional I/O efficiencies.
Note that this operation is not recoverable, so if you need to recover your database
to the point in time between the table move completion time and following backup,
the table may get lost. In order to avoid data loss, you can use the KEEP option. The
KEEP option forces the ADMIN_MOVE_TABLE routine to keep the original Also,
when using LOAD as the copy option, you must use the FORCE option. The FORCE
option requirement serves as a reminder that LOAD is a non-recoverable operation
and that if you want recoverability, you must create a backup.
CALL SYSPROC.ADMIN_MOVE_TABLE
('DB2INST1', 'CUSTOMER_INFO',
'NEW_TS', 'NEW_TS', 'NEW_TS',
'', '', '', '',
'KEEP, COPY_USE_LOAD, FORCE', 'MOVE')
Result set 1
--------------
KEY VALUE
-------------------------------- ----------------------------
AUTHID DB2INST1
CLEANUP_END 2009-06-11-13.36.43.360000
CLEANUP_START 2009-06-11-13.36.43.297000
COPY_END 2009-06-11-13.36.42.704000
COPY_OPTS OVER_INDEX,LOAD,WITH_INDEXES
COPY_START 2009-06-11-13.36.40.563000
COPY_TOTAL_ROWS 6745
INDEX_CREATION_TOTAL_TIME 0
INDEXNAME CUSTOMER_ID_PK
INDEXSCHEMA DB2INST1
INIT_END 2009-06-11-13.36.40.266000
INIT_START 2009-06-11-13.36.39.172000
ORIGINAL CUSTOMER_INFOAC61b#o
REPLAY_END 2009-06-11-13.36.43.125000
REPLAY_START 2009-06-11-13.36.42.704000
REPLAY_TOTAL_ROWS 0
REPLAY_TOTAL_TIME 0
STATUS COMPLETE
SWAP_END 2009-06-11-13.36.43.250000
SWAP_RETRIES 0
SWAP_START 2009-06-11-13.36.43.125000
VERSION 09.07.0000
22 record(s) selected.
The example in Listing 3 moves the table much faster and saves the original table
with the name CUSTOMER_INFOAC61b#o.
The next example demonstrates how to alter the tablespace not only for table data,
but also for indexes and LOBs. It also demonstrates how to change properties of the
table. The CUSTOMER_INFO table keeps the indexes and LOBs in the
USERSPACE1 tablespace, while table data is moved to the NEW_TS tablespace.
The example converts the table to use Multi Dimensional Clustering (MDC) using the
CUSTOMER_TYPE column as the clustering key and changes the data type of
CUSTOMER_AGE column back to VARCHAR(2).
CALL SYSPROC.ADMIN_MOVE_TABLE(
'DB2INST1', 'CUSTOMER_INFO',
'NEW_TS', 'USERSPACE1', 'USERSPACE1',
'CUSTOMER_TYPE', '', '',
'customer_id INTEGER NOT NULL,
first_name VARCHAR(128) NOT NULL,
last_name VARCHAR(128),
address_street VARCHAR(128),
address_city VARCHAR(128),
address_state VARCHAR(25),
address_country VARCHAR(30),
customer_age VARCHAR(2),
customer_type VARCHAR(10)',
'', 'MOVE');
Result set 1
--------------
KEY VALUE
-------------------------------- --------------------------------
AUTHID MAKSYMP
CLEANUP_END 2009-06-11-14.30.04.438000
CLEANUP_START 2009-06-11-14.30.04.422000
COPY_END 2009-06-11-14.30.03.750000
COPY_OPTS OVER_INDEX,ARRAY_INSERT
COPY_START 2009-06-11-14.30.03.219000
COPY_TOTAL_ROWS 6745
INDEX_CREATION_TOTAL_TIME 1
INDEXNAME CUSTOMER_ID_PK
INDEXSCHEMA DB2INST1
INIT_END 2009-06-11-14.30.03.125000
INIT_START 2009-06-11-14.30.02.250000
PAR_COLDEF customer_id INTEGER NOT NULL,
Conclusion
This article described:
Resources
Learn
• On the DB2 for Linux, UNIX, and Windows area on developerWorks, get the
resources you need to advance your skills on DB2 9.7.
• "The SAMPLE database" article of the DB2 for Linux, UNIX, and Windows
Information Center provides instructions for how to create the SAMPLE
database used in the examples this article.
• The "Casting between data types" article of the DB2 for Linux, UNIX, and
Windows Information Center provides a complete list of compatible data types
supported by the ALTER COLUMN SET DATA TYPE option on the ALTER
TABLE statement.
• Find additional information describing how to use DB2 in the DB2 for Linux,
UNIX, and Windows Information Center.
• Browse the technology bookstore for books on these and other technical topics.
Get products and technologies
• Download a free trial version of DB2 9.7 for Linux, UNIX, and Windows.
Discuss
• Participate in the discussion forum for this content.