Discussion :

[GBAGO]

Bonjour à tous,

J'aimerais savoir si la commande

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 truncate table nom_table

fonctionne sous informix ou bien y aurait-il une équivalence?
J'ai une table qui contient plusieurs données et quand je tente de la vider avec

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 delete table nom_table

, le système se plante.

Merci de votre collaboration.

[blackstreet]

Bonjour,

Oui, La commande Tuncate fonctionne sous informix. mais à partir de la version 10 de Informix :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

TRUNCATE TABLE person

[begooden-it]

Le système te plante très vraisemblablement parce que tu as provoqué une "long transaction". C'est un cas très courant dans IDS, qui n'est pas un plantage en soi, mais un simple dépasser de capacité. J'explique brièvement:
tu as une base de données journalisée, donc ton moteur conserve les informations qui permettront de remettre tes données dans l'état initial si l'application décide de rollbacker la transaction.
Ces informations sont conservées dans le "logical log" ( pas le physical log qui ne fait que conserver l'image-avant des pages de données), qui est un ensemble de "fichiers" contenu en général dans le rootdbspace, ou bien un dbspace spécifique. Cet ensemble a une taille limitée, et fonctionne en remplissage cyclique: le 1er logical log est plein, on passe au 2ème, et ainsi de suite jusqu'au dernier. Lorsque le dernier est plein, on repasse en théorie au premier, mais à condition que:
* celui-ci ait été libéré, c'est à dire qu'il ait été backupé par ontape -c/a ou onbar,
* et qu'il ne contienne plus aucune information concernant une transaction en cours d'exécution.

Si l'une de ces deux conditions n'est pas respectées, ton logical log est plein et ton système est bloqué, ce qui peut dans certains cas se terminer en situation critique où l'issue est le restore de ton instance. En cas d'"oubli" du backup des logical logs, il suffit de les backuper et si tu récupères de l'espace, tu es hors de danger.

Afin d'éviter une situation de blocage total où le logical log serait plein et ne pourrait plus exécuter le rollback de ta transaction, interviennent à ce stade deux paramètres ONCONFIG, qui sont LTXHWM et LTXEHWM: limite de marée-haute des long transactions. LTXHWM, un pourcentage, déterminera le seuil de remplissage du logical log à partir duquel la transaction fautive est rollbackée. ( erreur -458 ), et dont le rollback a besoin d'écrire dans le logical log. LTXEHWM déterminera, en cas d'existence de plusieurs longues transactions, quelle transaction aura l'exclusivité du rollback, en mettant toutes les autres en pause.

C'est donc une situation potentiellement très embarrassante qui peut mener au restore de l'instance.

Les solutions:

Au delà du travail du DBA de bien configurer la taille du logical log ( en fonction de ce que fait l'application en général ), et de LTXHWM et LTXEHWM, les techniques suivantes sont d'une grande aide:
* l'avènement ( enfin ) de la commande TRUNCATE, disponible à partir de 10.0 xC4
* le workaround stupide mais très efficace si applicable: DROP TABLE et CREATE TABLE avec le même schéma si possible et ton DBA t'autorise à le faire;-)
* l'utilisation de table de type RAW TABLE ( qui peut être établi temporairement et rebasculé à STANDARD), qui désactive la journalisation seulement sur cette table; Disponible à partir de 10.00.xC3. Très intéressant quand tu as une possible long transaction mais que tu ne peux pas dropper la table.

Voila j'espère que celà apportera de l'eau à ton moulin et au moulin de ceux qui ressentiront les mêmes sympômes.

Eric