ROWID問題1：SELECT 表後，發現ID號並未按我們預想的那樣遞增，而是出現斷裂，甚至序號混亂
解決方案：該問題應該出現在集羣環境中，加上NO CACHE,ORDER兩個選項
ROWID問題2：清除表中數據後，再插入數據我們會發現ID號不是從1開始，而是從刪除前的ID號加1開始分配。
解決方案：
重置ID起始號，命令 ALTER TABLE TEST1 ALTER COLUMN ID RESTART WITH 1
以下詳細解釋下問題1的原因
產生序列號混亂不按我們設想的產生的CREATE TABLE語句一般如下：
CREATE TABLE TEST1(
ID INT
GENERATED ALWAYS AS IDENTITY(START WITH 1,INCREMENT BY 1),
NAME CHAR(10) NOT NULL WITH DEFAULT,
PRIMARY KEY (ID)
)
首先明確下，這段語句，DB2默認有兩個選項：CACHE [20]
CACHE [20] 預先分配20個id，並保存在cache中。 NO ORDER 是爲了，讓DB2 members能夠把預分配ID號存入CACHE。
這兩個選項主要目的是在集羣環境中，更高效的插入數據。然而事物都有兩面性，效率是提高了，卻無法保證插入數據後，id號是嚴格按序列遞增的。
原因如下：爲解釋方便，假設集羣中有兩個member，分別是M1 和M2。應用從哪個member往表中插入數據是隨機的。
假設首先從M1往表中插入數據，則M1分配了ID號（1至20）；假設，插入了10條數據。
接着應用又往表中插入數據，假設從M2往表中插入數據；則M2自動預分配ID號（21至40）；假設，插入了10條數據。
此時，我們SELECT表，會發現數據佔用的ID號是1至10,21至30。此時，就出現了ID號不是按序列遞增的問題。
接着，應用又往表中插入數據，假設這次是從M2往表中插入5條數據。則這5條數據ID號，就是31至35。
然後，應用又往表中插入數據，假設這次是從M1往表中插入35條數據。則這35條數據ID號，就是11至20,41至60,61至65。插入的過程中，DB2爲M1預分配了2次ID號。
此時，我們SELECT表，會發現數據ID號從上到下依次是1至10,21至35,11至20,41至65。
以上假設，均在集羣環境中驗證通過。
總結ID號分配及使用規律如下：
- ID號在DB2 member對錶插入數據前纔對表進行預分配，默認一次預分配20個。如果不夠使用，會再次分配20個，直到在應用在該member上數據插入完畢
- 分配後的ID號歸某個member所有，其他member無法使用該ID號。
- 預分配的ID號存在CACHE中，系統出現故障後，會丟失ID號，而丟失的ID號也無法再次使用。
因此，爲了保證插入數據後，ID號是按序列遞增的，並且不會因爲系統故障導致ID號丟失。必須加上NO CACHE,ORDER兩個選項。