Pense-bête : Ingres

Published: 08-01-2015

Updated: 30-01-2016

By: Maxime de Roucy

tags: database ingres

Mes notes concernant Ingres.

Liste des versions

Installation

Installation sur un nspawn CentOS (seul yum est installé) :

root@laptop # useradd ingres
root@laptop # yum install tar
root@laptop # pwd
/opt
root@laptop # ls
ingres-10.1.0-125-gpl-linux-ingbuild-x86_64.tgz
root@laptop # tar xvzf ingres-10.1.0-125-gpl-linux-ingbuild-x86_64.tgz
root@laptop # cd ingres-10.1.0-125-gpl-linux-ingbuild-x86_64/
root@laptop # ./ingres_express_install.sh

L’installation peut être assez longue et sembler bloquée. Attendre 15 minutes minimum.

On peut utiliser le script install.sh à la place de ingres_express_install.sh pour faire une installation personnalisé.

Accès au utilitaire Ingres :

root@laptop # su - ingres
max@laptop % cd /opt/Ingres/IngresII/ingres/
max@laptop % source .ingIIsh

Terminal

J’ai choisi « gnome-sun » comme terminal. Pourquoi ? Parce que j’ai essayé plein de truc jusqu’a ce que ça marche… Pour accéder au menu : Esc+Shift+1(pas celui du pavé numérique), soit Esc+1. Pour pouvoir affiché toutes les options (>), il faut être dans le menu. En bref Esc+Shift+1 (soit Esc+1) puis AltGr+> (soit >).

Ça fonctionne avec tous les layout.

Btrfs

Attention, j’ai eu des problème avec btrfs. Après l’installation de Ingres j’ai fait un snapshot de mon nspawn et essayé de faire un ingstart dans celui-ci : Aucun DBMS configuré. cbf ne me listé plus aucun DBMS… bref là merde.

Dynamic query cache

Sources :

Permet de mettre en caches certaines requête pour les traiter plus rapidement. Encore très limité. Nécessite que la requête soit préparée et utilise un curseur.

ii.hostname.dbms.*.cache_dynamic

Il est aussi possible de mettre en cache le « query plan » d’une requête via l’instruction REPEATED mais cette fonctionnalité n’est pas relative au « dynamic query cache ».

Je copie ici un text extrait du blogs.planetingres.org aujourd’hui disparu et que j’ai retrouvé via Internet Archive :

Cached Dynamic Query

It has been a very busy few months and the appliance team moves apace and is continuously subjected to requests for new applications and Ingres releases. With the latest release of Ingres one of the new features is cached dynamic query plans; that will benefit any application that uses prepared dynamic queries. Ingres has long had the ability to cache query plans for stored procedures and from queries in embedded SQL programs using the REPEATED keyword. The latter has meant that queries are identified and tagged in the application. For applications that are written using a driver for example, ODBC, JDBC, .NET and PHP it hasn’t been possible, until now, to use store a query plan for reuse. This feature benefits queries that take a long time to optimize and compile (for a particular value of long) and obviously the more times the same query is executed the better the benefit of caching as the optimization and compilation time is amortized over the number of executions.

As this is the first implementation it is disabled by default and the scope is severely limited. For now it is implemented only for selects and for queries that require greedy enumeration.

To give an example; the application that I am using generates queries for its underlying database and I have no control over it. These queries although complex return a very low volume of results. Looking at the query plans there are between 50 and 80 candidate tables and indices. Without greedy enumeration these queries don’t even compile, not only that but these queries are executed hundreds of times. With greedy enumeration the query must complete compilation, before that there is only a partial plan so setting join op time out won’t help.

So here is how you can control caching:

CBF - ii.hostname.dbms.*.cache_dynamic: ON or OFF

SQL :

Until cached dynamic query plans I had to suffer in silence. I’d be interested if anyone else finds the feature a benefit, if you do let me know.

Compression

Il est possible de compresser les données et les indexes via l’instruction COMPRESSION.

Clustering

Pas de clustering actif-actif.

Limites

Sources :

La taille des base de donnée n’est pas limité en revanche la taille des tables est limité à 8×1024^2^ de pages (sachant que les page peuvent faire 2K, 4K, 8K, 16K, 32K ou 64K).

Procédures

ANSI/ISO SQL-92

Ingres est compatible avec le SQL-92 (voir la section « ANSI Compliance » du « SQL Reference Guide »).

Parallele query

Ingres supporte la parallélisation d’une requête (unique).

Materialized View

Ingres ne supporte pas les vues matérialisée.

IMADB

Source : SysAdmin.pdf section « Chapter 10: Understanding Ingres Management Architecture »

La imadb permet de monitorer l’état de la base de donnée et d’intéragir avec elle.

Modify … to truncated

Sources :

MODIFY … TO TRUNCATED; permet de supprimer rapidement toutes les entrées d’une table et de libérer directement l’espace disque pour le système. Il transforme la structure de la table en « heap ».

Pour supprimer toutes les entrées d’une table il est plus pertinant d’utiliser MODIFY … TO TRUNCATED et de revenir à la bonne structure de table que de supprimer totalement la table et de la recréer.

Backup

Source :

Les sauvegardes se font via ckpdb. Ou unloaddb (ou copydb) pour faire des « backup » de type « sqldump ».

Les checkpoints (ckp) sont des snapshot de la base de donnée (ou de certaines tables).

Le « journaling » permet de faire du backup dynamic de la base, il est utilisé en combinaison avec les checkpoints. Ils permettent de garder une trace de tous les changement appliqués aux tables journalisée après le dernier checkpoint.

Les dumps servent à conserver les transactions en cours durant les checkpoints online.

On peut voir l’état des checkpoint, des journaux et des dump via la commande infodb (voir CommandRef.pdf section « infodb Command—Display Database Information »).

Recovery

DatabaseAdmin.pdf section « Recovery », principalement « Rollforward ».

DBMS

Pour démarrer n DBMS, dans le fichier config.dat indiquer …ingstart.*.dbms: n

taille des pages

Source : Wiki actian : Ingres How to choose your page size for your tables

max@laptop % grep 'p.k_status' config.dat

si la taille des page est à 2k, on ne peut pas faire de row locking… on passe directement au page locking. Si une entré fait plus de 2k elle est répartie sur plusieurs pages et donc on va locker plusieurs pages d’un coup si on veut accéder à cette entré.

Server classes

Source : Connectivity.pdf section « Server Classes ».

D’après ce que j’ai compris on peut connécté Ingres à plusieurs autres DBMS d’un autre type et se servir de Ingres comme plate-forme principal de connection. Via le paramètre « server class » on peut spécifier quel type de DBMS on veut contacter. Par défaut on contact « ingres », mais on peut aussi contacter « oracle », « db2 » et j’en passe.

Mais les « server classes » ont une autre utilisation. On peut spécifier un « serveur class » particulier (dont le nom n’est pas déjà utilisé) pour un/des DBMS.

% grep server_class config.dat
….dbms.*.server_class:     INGRES

Ensuite on peut se connecter spécifiquement à ces DBMS en indiquant le « server class » correspondant.

structure de table

Sources :

Les tables ingres sont stockées dans des fichiers et ces fichiers sont organisés en « pages ». Il existe trois type de pages :

index
utilisées dans les structures ISAM et BTREE, elles contiennent des informations qui permette un accès plus rapide (directe) à une autre page.
leaf
utilisées dans la structures BTREE, elles contiennent TODO
data
utilisées dans toutes les structures, elles contiennent les données proprement dite.

Un simple CREATE TABLE … ne permet pas de sélectionner une autre structure de table que heap. En revanche, cela est possible avec CREATE TABLE … AS SELECT … WITH STRUCTURE. On peut changer la structure à postériory avec un MODIFY.

Lorsqu’on créé une table si le paramètre cbf table_auto_structure est à ON, que la table est créée avec une key et que la commande ne spécifie pas WITH STRUCTURE alors la structure de la table sera automatiquement BTREE.

Heap

La structure la plus simple. C’est une liste chainée de pages. Si une donnée est supprimée, l’espace qu’elle occupait n’est jamais réutilisé. Ce n’est pas vrai pour les donnée de la dernière page.

Cette structure est adaptée pour les tables très petites et accèdée en read-only.

Hash

TODO

ISAM

TODO

BTREE

TODO

Isolation Levels

Source : DatabaseAdmin.pdf « Isolation Levels »

Le niveau d’isolation permet de définir quand et sur quoi doivent être placé les lock en lecture et écriture.

Les valeurs possible sont :

Les problème qui peuvent survenir sur le niveau d’isolation est à « Read Uncommitted » sont décrit ci-dessous. Ici T1 et T2 sont des transactions.

Dirty Read
T1 modifie un ligne mais ne commit pas. T2 lie cette ligne. T1 fait un rollback. T1 à lue une valeur qui n’a jamais été commité, qui n’est pas sensé avoir existé.
Non-repeatable Read
T1 lie une ligne. T2 modifie cette ligne et commit. Si T1 essaye de relire la ligne, il obtiendra une valeur différente.
Phantom Rows
T1 fait un requête qui lui retourne un nombre N de ligne satisfaisant une condition C. T2 ajoute une ligne qui satisfait la condition C. Si T1 relance la même requête il n’obtiendra pas le même nombre de ligne (N+1).

Le tableau de possibilité est le suivant :

Isolation Level Dirty Read Non-Repeatable Read Phantom Rows
Read Uncommitted Yes Yes Yes
Read Committed No Yes Yes
Repeatable Read No No Yes
Serializable No No No

READLOCK

Source : DatabaseAdmin.pdf « READLOCK »

À moin que le niveau de lock soit à « MVCC » ou « TABLE », par défaut les lock en lecture sont en mode « shared ». Il est possible de modifier ce comportement et d’utiliser le mode « nolock » et « exclusive ».

shared
Un accès en lecture (shared lock) sur une page permet à d’autre utilisateur d’y accéder en lecture (shared lock). En revanche il y empèche les accès en écriture (exclusive lock).
nolock
Un accès en lecture ne requière aucun lock. Quelque soit le niveau d’isolation configuré, si on spécifie « READLOCK=NOLOCK » cela revient à faire du « Read Uncommitted ».
exclusive
Un accès en lecture requière un lock exclusif. Il ne peut donc pas y avoir plusieurs lecture en parallèle.

MVCC

Sources :

MVCC (Multi-Version Concurrency Control) est un niveau de lock (même si c’est pas vraiment du « locking ») apparue dans Ingres 10 qui permet de ne pas utilisé de lock 😕

En fait chaque transaction travail sur sont propre snapshot des tables.

logging/debugging

SC930

La trace SC930 permet de logger toutes les requêtes traitée par Ingres.

Attention, c’est un log très verbeux et qui peut rapidement saturer l’espace disque.

DBMS LOG

Il existe une variable « II_DBMS_LOG » qui permet de logger des informations détaillées concernant les DBMS dans des fichiers séparés. Lorsqu’on spécifie cette variable on peut utiliser les chaînes « %p » et « %d » qui seront respectivement remplacés par le PID du DBMS et sa date de démarrage. Cette possibilité à l’avantage de ne pas consommer de ressource si ce n’est un peu d’espace disque.

max@laptop % ingsetenv II_DBMS_LOG "/path/iidbms_%p.log"

En revanche ça nécéssite de redémarrer Ingres.

Il existe aussi la commande SQL SET TRACE OUTPUT … (voir SQLRef.pdf section « [No]Trace Output ») qui permet d’activer la trace sur le DBMS courant sans avoir à redémarrer Ingres.

troubleshooting

Je conseille la lecture de cette article : Troubleshooting Ingres (lien cassé : http://www.ca.com/us/support/ca-support-online/product-content/knowledgebase-articles/faq337115.aspx)

logdump

Le détaille des options de cette commande est disponible dans ses sources.

Permet d’afficher le transaction log file. Les transactions les plus récentes sont affichée à la fin.

LA=(1437676161,8876,1364),PREV_LA=(1437676161,8876,1284),LEN=80,SEQ=4
    LSN=(55B13281,000092A0), COMP_LSN=(00000000,00000000), DBID=0x55B13426, XID=0x000055B1564A0825
    ET           Length:    56  Flags
        TIME: Fri Jul 24 03:13:18 2015 STATE: COMMIT

LA=(1437676161,8877,284),PREV_LA=(0,0,0),LEN=268,SEQ=1
    LSN=(55B13281,000092A1), COMP_LSN=(00000000,00000000), DBID=0x00000001, XID=0x000055B1564A084B
    OPENDB       Length:   244  Flags:
        NAME(iidbdb,$ingres) ID:1 ROOT: /opt/Ingres/IngresII/ingres/data/default/iidbdb)

SQL

max@laptop % sql iidbdb

tables

List des tables :

* select table_name from iitables where table_type='T' \g

Ou plus simplement :

* help \g

Récupérer quelques info sur une table :

* help matable \g

Récupérer plus d’info :

* help table matable \g

bases

List des bases.

* select name from iidatabase \g

info

List les colone d’une table.

* help ma_table\g