Question & Answer
Question
Why does an online reorg fail with SQL2219N reason code 13?
Cause
An attempt to perform an online reorg of a table may fail with SQL2219N reason code 13. One possible reason for this is if there was an alter table that added a row change timestamp column. For example:
CREATE TABLE ABC ( f1 integer , f2 char(30) ) ORGANIZE BY ROW
DB20000I The SQL command completed successfully.
insert into ABC ( f1 , f2 ) values ( 1 , 'value1' )
DB20000I The SQL command completed successfully.
alter table ABC add column f3 TIMESTAMP NOT NULL IMPLICITLY HIDDEN GENERATED BY DEFAULT FOR EACH ROW ON UPDATE AS ROW CHANGE TIMESTAMP
DB20000I The SQL command completed successfully.
select f1,f2,f3 From ABC
F1 F2 F3
----------- ------------------------------ --------------------------
1 value1 0001-01-01-00.00.00.000000
1 record(s) selected.
reorg table ABC inplace allow write access start
SQL2219N The inplace table reorganization failed on one or more members.
Table name: "MYSCHEMA.ABC". Reason code: "13".
reorg table ABC
DB20000I The REORG command completed successfully.
select f1,f2,f3 From ABC
F1 F2 F3
----------- ------------------------------ --------------------------
1 value1 2016-11-23-20.27.29.692152
1 record(s) selected.
Answer
The reason why the online reorg fails above is because during the reorganisation there could be an attempt to move a row without having the value in ROW CHANGE TIMESTAMP materialised. Ie the value in this column is yet to be determined after the column has been added and prior to any rows with this column being allowed to be moved via a reorg for example.
At present, the current functionality only allows for the movement of this row via a Load Replace or an OFFLINE reorg and not during an ONLINE reorg.
Was this topic helpful?
Document Information
Modified date:
16 June 2018
UID
swg21994681