|
Problem IC81508
|
Status: Closed |
ALTER TABLE ON A TABLE OF WHICH AN INVALID VIEW HAS REFERENCES TO CAN ABEND DB2 WITH SIGNAL 11 |
| product: |
DB2 FOR LUW / DB2FORLUW / 970 - DB2 |
| Problem description: |
If a view is created but marked as invalid at the creation time
(for example, the CREATE VIEW statement returns a warning
message SQL20480W),
an ALTER TABLE statement on the table of which the view has
references
to can abend DB2 with signal 11.
This APAR does NOT apply to if the view was created successfully
but
later marked invalid.
A possible call stack in the db2diag.log is:
5 sqlnq_qtb::generate_unambiguous_name
6 sqlnq_qun::generate_unambiguous_name
..
18 sqlnq_handle_named_ref_in_src
19 sqlnq_sem
20 sqlnp_smactn
21 sqlnp_parser
22 sqlnp_main
23 sqlnq_handle_sql_stmt
24 sqlnn_regen_trigger
25 sqlrlDropDepTriggers
26 sqlrlalt
27 sqlnq_alter_table_end
28 sqlnq_alter_table_stmt
29 sqlnp_smactn
==================================== |
| Problem Summary: |
****************************************************************
* USERS AFFECTED: *
* ALL *
****************************************************************
* PROBLEM DESCRIPTION: *
* Alter of base table reference in an invalid view could *
* cause signal 11 crash during re-validation of the view *
* *
* For example you have a view that references base table 'T1' *
* *
* Running an alter similar to the following may crash the *
* instance *
* ALTER TABLE T1 ALTER COLUMN TESTCOL1 SET DATA TYPE *
* VARCHAR(16) *
* *
* Will see a stack similar to the following *
* *
* *
* 0 ossDumpStackTraceEx *
* *
* 1 OSSTrapFile::dumpEx *
* *
* 2 sqlo_trce *
* *
* 3 sqloEDUCodeTrapHandler *
* *
* 4 __invoke_dynamic_linker__ *
* *
* 5 sqlnq_qtb::generate_unambiguous_name *
* *
* 6 sqlnq_qun::generate_unambiguous_name *
* *
* 7 sqlnq_resolve_alias *
* *
* 8 sqlnq_qtb::get_col_num *
* *
* 9 sqlnq_pid::containsNullEQNull *
* *
* 10 sqlnq_expxppchild::relins *
* *
* 11 sqlnq_prd *
* *
* 12 sqlnq_create_hxp *
* *
* 13 sqlnq_create_hxp *
* *
* 14 sqlnq_create_hxp *
* *
* 15 sqlnq_create_hxp *
* *
* 16 sqlnq_create_hxp *
* *
* 17 sqlnq_create_hxp *
* *
* 18 sqlnq_handle_named_ref_in_src *
* *
* 19 sqlnq_sem *
* *
* 20 sqlnp_smactn *
* *
* 21 sqlnp_parser *
* *
* 22 sqlnp_main *
* *
* 23 sqlnq_handle_sql_stmt *
* *
* 24 sqlnn_regen_trigger *
* *
* 25 sqlrlDropDepTriggers *
* *
* 26 sqlrlalt *
* *
* 27 sqlnq_alter_table_end *
* *
* 28 sqlnq_alter_table_stmt *
* *
* 29 sqlnp_smactn *
* *
* Problem is in the code at the time we re-validate the view *
* in that the code leaves garbage memory behind. The crash *
* fails thousand steps later when the code steps into the *
* garbage memory. *
****************************************************************
* RECOMMENDATION: *
* Upgrade to DB2 V9.7 Fix Pack 6 *
**************************************************************** |
| Local Fix: |
Recreating the view with a valid syntax before running the ALTER
TABLE statement. |
| available fix packs: |
DB2 Version 9.7 Fix Pack 6 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 7 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 8 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9 for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 9a for Linux, UNIX, and Windows
DB2 Version 9.7 Fix Pack 10 for Linux, UNIX, and Windows
|
| Solution |
First fixed in DB2 Version 9.7 Fix Pack 6 |
| Workaround |
not known / see Local fix |
| BUG-Tracking |
forerunner : APAR is sysrouted TO one or more of the following: IC83040
follow-up : |
| Timestamps |
Date - problem reported :
Date - problem closed :
Date - last modified :
| 17.02.2012
27.06.2012
27.06.2012 |
| Problem solved at the following versions (IBM BugInfos) |
9.7.FP6
|
| Problem solved according to the fixlist(s) of the following version(s) |
| 9.7.0.6
|
 |
