Informix News


invispix 10x10

Deutliche Reduzierung der Satzanzahl einer Tabelle mit Text und BYTE im Tablespace

(Beitrag von CURSOR Mitarbeiter Andreas Seifert)

Normalerweise sind die Limitierungen für Tabellen in einer Informix-Instanz ausreichend hoch, so das man keine Probleme beim Betrieb der Instanz bekommt. Nutzt man die alten Simple Large Objects TEXT und BYTE in Informix ist das aber anders. Diese BLOBs können noch nicht in einem Smart-Blobspace liegen, wie die neuen Smart Large Objects sondern müssen in einen Blobspace (alter Typ).

Im Gegensatz zu Smart-Blobspaces können Blobspaces aber nicht mit Logging angelegt werden. Das hat große Nachteile, wenn man eine Hochverfügbarkeitslösung wie HDR, RSS oder SDS nutzen möchte.  Da alle diese Lösungen über den Austausch von logical Log-Informationen funktionieren, werden Objekte die nicht über das log. Log laufen nicht repliziert.

Die einzige Lösung, die Simple Large Objects mit log. Log zu betreiben ist, auf einen Blobspace zu verzichten und die BLOBs in den Tablespace zu speichern.

Jetzt kommen aber die die Tabellen-Limits von Informix zum Tragen. Eine Row darf 32kByte lang werden. Das ist in diesem Fall kein problematisches Limit, weil für ein Simple Large Object in die Row-Size nur ein Descriptor von 56Byte eingeht. Ein weiteres Limit, die maximale Anzahl Pages pro Fragment, ist hier wesentlich tragischer. Dieses Limit liegt nämlich bei 16.777.215 Daten-Pages. Die Frage ist, zählen die Pages, die ein Simple Large Object belegt dazu?

Die Dokumentation von Informix schweigt hierzu. Um zu ermitteln, ob die Blob-Pages zu den Daten-Pages zählen, haben wir ein 100GB großen Chunk angelegt. Plattform war Windows mit 4k Pagesize. In einer Schleife wurden in die Tabelle mit 2 Feldern vom Typ TEXT Sätze mit durchschnittlich 300kByte an Daten eingefügt. Die Frage war - bei wieviel Sätzen ist Schluß?

create table "informix".testtable 
  (
    f01 char(64) not null ,
    f02 char(4),
    f03 char(30),
    f04 char(2),
    f05 char(1),
    f06 char(5),
    f07 char(5),
    f08 char(1),
    f09 text ,
    f10 text ,
    f11 char(8),
    f12 date,
    f13 date
  );
Schema der Testtabelle

Wenn die Blob-Pages zu den Daten-Pages zählen, so sollten wir an das Page-Limit stoßen. Die Anzahl Sätze die man erreichen kann berechnet sich wie folgt:

300kByte Daten pro Satz / 4kByte Pagesize = 75 Pages pro Satz

Limit für Pages pro Fragment 16.777.215 / 75 Pages pro Satz = 223.696,2 Sätze

In diesem Fall ist zu erwarten, das bei ca. 223.696 Sätzen ein Fehler auftritt. So kam es auch. Das load-Script meldete nach einer Weile auch folgenden Fehler bei 222493 Sätzen:

D:	mp	est>dbaccess testdb load

Database selected.


  605: Cannot write blob.   136: ISAM error: no more extents
  847: Error in load file row 1.
Error in line 2
Near character position 52

Database closed.
Fehlermeldung des dbaccess beim load der Daten

Das klingt erst einmal irreführend, denn nach Prüfung der Tabelle hatte diese nur 7 Extents. Die Fehlermeldung ISAM 136 hat aber mehrere Bedeutungen. Im ausführlichen Fehlertext steht, man soll ein onstat -t ausführen und die Ausgabe betrachten:

IBM Informix Dynamic Server Version 12.10.FC3 -- On-Line -- Up 1 days 00:37:15 -- 74880 Kbytes

Tblspaces
 n address          flgs ucnt tblnum   physaddr         npages nused  npdata nrows  nextns
.
.
.
. 1010 8135d030         0    1    500001   5:4              50     6      0      4      1
1015 81369030         2    1    600001   6:4              50     4      0      0      1
1016 811e3030         0    1    700001   7:4              100    70     0      68     2
1017 811e3ae0         0    1    700002   7:5              8      6      3      71     1
1018 8119c030         0    1    700003   7:6              16     12     6      557    1
1019 81213030         0    1    700004   7:7              64     43     38     114    1
1028 81452030         0    1    70000d   7:16             8      3      0      0      1
1032 81857030         0    1    700011   7:20             128    70     53     513    5
1046 8185b030         0    1    70001f   7:34             8      3      0      0      1
1067 81933060         0    1    700034   7:511            8      3      0      0      1
1074 81902980         0    1    70003b   7:518            8      2      0      0      1
1082 81830680         2    1    700043   7:526            16777215 16777215 13906  222493 7
1083 81927030         40000002 1    700044   7:527            384    280    0      0      8
1084 8121aa70         40000002 1    700045   7:528            384    278    0      0      8
 76 active, 1084 total
Ausgabe des onstat -t

Folgender Satz aus dem Fehlertext:

"If nused is close to 0xFFFFFF (16,777,215), the maximum number of pages has been reached for the table. Reallocate the table in a dbspace with a larger page size as described above."

zeigt, das hier das Page-Limit für das Tabellenfragment erreicht wurde.

Schöner zusammengefasst zeigt ein oncheck -pT testdb:testtable den Zustand:

TBLspace Report for testdb:informix.testtable

    Physical Address               7:526
    Creation date                  06/26/2014 09:59:08
    TBLspace Flags                 c01        Page Locking
                                              TBLspace contains TBLspace BLOBs
                                              TBLspace use 4 bit bit-maps
    Maximum row size               240       
    Number of special columns      2         
    Number of keys                 0         
    Number of extents              7         
    Current serial value           1         
    Current SERIAL8 value          1         
    Current BIGSERIAL value        1         
    Current REFID value            1         
    Pagesize (k)                   4         
    First extent size              8         
    Next extent size               2097152   
    Number of pages allocated      16777215  
    Number of pages used           16777215  
    Number of data pages           13906     
    Number of rows                 222493    
    Partition partnum              7340099   
    Partition lockid               7340099   

    Extents                       
         Logical Page     Physical Page        Size Physical Pages
                    0            7:1271       65536      65536
                65536           7:66815      262144     262144
               327680          7:328975      589824     589824
               917504          7:918831      917504     917504
              1835008         7:1836399     2359296    2359296
              4194304         7:4195823     4194304    4194304
              8388608         7:8390383     8388607    8388607


TBLspace Usage Report for testdb:informix.testtable

    Type                  Pages      Empty  Semi-Full       Full  Very-Full
    ---------------- ---------- ---------- ---------- ---------- ----------
    Free                     59
    Bit-Map                2065
    Index                     0
    Data (Home)           13906
    TBLspace BLOBs     16761185          0        184     352182   16408819
                     ----------
    Total Pages        16777215

    Unused Space Summary

        Unused data slots                                 3
        Unused bytes per data page                      164
        Total unused bytes in data pages            2280584
        Unused bytes in TBLspace Blob pages       456503339

    Home Data Page Version Summary

                 Version                                 Count

                       0 (current)                      13906
Ausgabe des oncheck -pT testdb:testtable

Hier sieht man auch, das die Tabellendaten nur 13.906 Pages verbrauchen und der gesamte Rest die Blobpages sind.

Etwas versteckt findet man die passenste Fehlermeldung in der Datei $DBTEMP/$INFORMIXSERVER.alarm. Dort steht:

2014-06-26 12:22:19  WARNING: partition 'testdb:informix.testtable': no more pages

Zeile aus der Date $DBTEMP/$INFORMIXSERVER.alarm

Diese Meldung besagt genau das, was passiert ist. Man hat das Limit der Pages einer Partition erreicht. Leider fehlt diese Meldung in den Log-Dateien, in die man in erster Linie schaut um Probleme zu erkennen. Hat man die automatische Alarmierung im Alarmprogramm aktiviert, bekommt man sie aber als Mail.

Stößt man an diese Grenze, gibt es verschiedene Lösungen:

1. Man verlegt die Tabelle in einen DBSpace mit größerer Pagesize

Wenn man sich die Berechnung ansieht gewinnt man hier bei Verdopplung der Pagesize nur knapp das Doppelte der Sätze. Die maximale Pagesize berägt 16k, was in unserem Beispiel nur ca. 890.000 Sätze bedeutet.

2. Man nutzt die Fragmentierung

Hiermit läßt sich dieses Problem leicht lösen. Ich kann 2047 DBSpaces haben, Fragmentieren geht auch innerhalb eines DBSpaces schon, so das man hier nicht mehr an das Limit stößt.

Der Nachteil dieser Lösung: Fragmentierung ist nur in der Enterprise / Advanced Enterprise - Edition erlaubt. Alle anderen Editionen dürfen die Fragmentierung nicht nutzen.

3. Man nutzt Smart Large Objects

Diese Lösung bietet sich an, Smart Large Objects kann ich in Smart-Blobspaces legen, bei denen ich wählen kann, ob der Space mit oder ohne log. Log läuft. Allerdings ist das Handling der Smart Large Objects in der Anwendungsentwicklung abweichend von dem der Simple Large Objects. Es kann sich hierbei ein hoher Aufwand bei der Umstellung der Applikation ergeben oder man nutzt nur eine gekaufte Anwendung und ist gar nicht in der Lage eine solche Umstellung zu machen.

Leider kann man sich hier nicht mit einer View behelfen, die die Smart Large Objects entsprechend casted, weil die IBM zwar einen Cast von TEXT nach CLOB und BYTE nach BLOB eingebaut hat, aber nicht für den umgekehrten Weg.

Diese Lösung wäre nur mit einer selbstgeschriebenen UDR möglich, die eine Umsetzung von TEXT in CLOB oder BYTE in BLOB in beide Richtungen ermöglicht.


Dipl. Wirtschaftsinformatiker Andreas Seifert
(Geschäftsbereich IBM Distribution)
 
CURSOR Software AG  
Friedrich-List-Straße 31  
D-35398 Gießen  
Diese E-Mail-Adresse ist vor Spambots geschützt! Zur Anzeige muss JavaScript eingeschaltet sein!

 
invispix 10x10

News Kategorien / zurück zur Übersicht ...

News ÜbersichtNews Übersicht

News Übersicht

Informix NewsInformix News

Informix News

IBM Db2 NewsIBM Db2 News

IBM Db2 News

Scout NewsblogScout Newsblog

Scout Newsblog

NewsletterNewsletter

Newsletter

News ArchivNews Archiv

News Archiv

invispix 10x10
OEM/ESA LizenzenOEM/ESA Lizenzen

IBM OEM Lizenzen

Informix für EinkäuferInformix für Einkäufer

Informix für Einkäufer

IBM Db2 für EinkäuferIBM Db2 für Einkäufer

IBM Db2 für Einkäufer

Cognos für EinkäuferCognos für Einkäufer

Cognos für Einkäufer

Diese Seite verwendet Cookies. Mit dem Besuch unserer Seite, erklären Sie sich mit dem Einsatz von Cookies einverstanden.
Weitere Informationen Ok