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號是按序列遞增的，並且不會因為系統故障導致id號丟失。必須加上no cache,order兩個選項。
DB2學習總結
表是由確定的列數和可變的行數組成的邏輯結構。列是一組資料型別相同的值。行是組成表中耽擱記錄的連續的值。在表中不必對行進行排序。要對結果集進行排序，必須在從表中選擇資料的sql語句中顯示指定排序。在每個列和行的相交處是乙個稱為值的特定資料項。基表存放使用者資料，且它使用create table語句建立...
db2使用總結
tableid 413 24 檢視資料庫管理配置環境資訊 get db cfg for nm1226 show detail 25 更改locklist update db cfg for dbname using locklist 100000 26 更改maxlocks update db cf...
DB2常用函式總結
一 字元轉換函式 1 ascii 返回字元表示式最左端字元的ascii 碼值。在ascii 函式中，純數字的字串可不用 括起來，但含其它字元的字串必須用 括起來使用，否則會出錯。2 char 將ascii 碼轉換為字元。如果沒有輸入0 255 之間的ascii 碼值，char 返回null 3 lo...