Db2

確定索引的頁面大小

  • March 4, 2019

我正在將一組數據庫從程式碼集 ISO8859-1 遷移到 UTF-8,STRING_UNITS=CODEUNITS32。我懷疑相當多的索引將不再適合目前的表空間頁面大小(SQL0614N)。是否有可用於確定每個索引的最小頁面大小的公式?

我找到了 Serge Reilau 的以下文章:

https://www.ibm.com/developerworks/community/blogs/SQLTips4DB2LUW/entry/getrowsize?lang=en

我想我可以修改以確定索引的大小,但我不完全確定相同的公式是否適用於索引。

任何指針?

不確定這是否真的正確,但我會用它作為估計,直到我找出更好的東西:

CREATE OR REPLACE FUNCTION GetInxSize(indschema VARCHAR(128), indname VARCHAR(128))
RETURNS INTEGER
SPECIFIC GETINXSIZE
READS SQL DATA
DETERMINISTIC
NO EXTERNAL ACTION
   RETURN
       SELECT SUM(
                   CASE c.TYPENAME
                      WHEN 'SMALLINT'        THEN length
                      WHEN 'INTEGER'         THEN length
                      WHEN 'BIGINT'          THEN length
                      WHEN 'REAL'            THEN length
                      WHEN 'DOUBLE'          THEN length
                      WHEN 'DECFLOAT'        THEN length
                      WHEN 'DECIMAL'         THEN TRUNC(length / 2) + 1
                      WHEN 'CHARACTER'       THEN 4*length
                      WHEN 'VARCHAR'         THEN 4*length + 4
                      WHEN 'GRAPHIC'         THEN length * 2
                      WHEN 'VARGRAPHIC'      THEN length * 2 + 4
                      WHEN 'XML'             THEN 4*c.inline_length + 3
                      WHEN 'DATE'            THEN length
                      WHEN 'TIME'            THEN length
                      WHEN 'TIMESTAMP'       THEN length
                      ELSE raise_error('78000', 'Unknown type')
                   END +
                      CASE WHEN NULLS = 'Y' THEN 1 ELSE 0 END
                )
       FROM SYSCAT.INDEXES i
       JOIN SYSCAT.INDEXCOLUSE ic
           ON i.indschema = ic.indschema
           AND i.indname = ic.indname
       JOIN SYSCAT.COLUMNS c
           ON i.tabschema = c.tabschema
           AND i.tabname = c.tabname
           AND ic.colname = c.colname
       WHERE i.indschema = GetInxSize.indschema
         AND i.indname = GetInxSize.indname
@

有問題的 DB:s 不使用壓縮,而且我也跳過了不能成為索引一部分的類型。

SELECT rtrim(indschema) || '.' || rtrim(indname)
FROM SYSCAT.INDEXES i 
JOIN SYSCAT.TABLES t 
   ON i.tabschema = t.tabschema 
   AND i.tabname = t.tabname 
JOIN SYSCAT.TABLESPACES ts 
   ON coalesce(t.index_tbspace, t.tbspace) 
WHERE t.tabschema not like 'SYS%' 
 AND getinxsize(indschema, indname) > ts.pagesize / 4;

一切:

SELECT distinct rtrim(t.tabschema) || '.' || rtrim(t.tabname)
FROM SYSCAT.INDEXES i 
JOIN SYSCAT.TABLES t 
   ON i.tabschema = t.tabschema 
   AND i.tabname = t.tabname 
JOIN SYSCAT.TABLESPACES ts 
   ON coalesce(t.index_tbspace, t.tbspace) = ts.tbspace 
WHERE t.tabschema not like 'SYS%' 
 AND getinxsize(indschema, indname) > ts.pagesize / 4;

編輯:索引中 XML 列的範例

如下表:

CREATE TABLE TESTING_APA.ATOM_FEED  
( FEED_XML XML 
, FEED_XML_IS_NULL SMALLINT NOT NULL 
     GENERATED ALWAYS AS (CASE WHEN FEED_XML IS NULL THEN 1 ELSE 0 END) 
) IN USERSPACE1
ORGANIZE BY ROW;

生成兩個索引(雖然不知道為什麼),其中列的類型名稱是 XML:

select tabschema, tabname, indname, colnames 
from syscat.indexes 
where indname in ('SQL190304085605540','SQL190304085605550')

TESTING_APA  ATOM_FEED  SQL190304085605540  +FEED_XML                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       
TESTING_APA  ATOM_FEED  SQL190304085605550  +FEED_XML                    

此外,顯式 xml 索引還會在目錄中生成列類型為 XML 的索引。

由於源數據庫不是 UTF-8,因此不能有任何 JSON 列。對於 UTF-8 數據庫,調查 JSON 索引是否起作用可能是值得的。然而,函式 GetInxSize 是專門為處理非 utf -> utf 而設計的,因此必須針對 utf-8 數據庫進行更改。

引用自:https://dba.stackexchange.com/questions/231028