Discussion :

[Logan Mauzaize]

Bonjour à tous,


Je viens poster dans cette section car je n'ai pas vraiment trouvé d'autres qui correspondent à ma problématique mais si c'est le cas, n'hésitez pas à me le signaler !


Alors je commence par ma problématique générale :
J'ai une base de données qui contient un assez grand nombre d'information. Son schéma évolue assez violemment de manière régulière, ce qui rend les mises à jour longues, complexes et critiques.
A chaque mise à jour, il y a des erreurs durant la procédure car il y a des préconditions non remplies, des fichiers de configuration mal renseigné, etc. Le support niveau 3 (développeurs) sont alors les seuls aptes à trouver le problème (acceptable) et à "cuisiner" une reprise de la mise à jour (trop contraignant pour mon client).

Le fonctionnement actuel :
La base de données est une Oracle 10g R2 sous Linux. L'installation et la mise à jour de la base de données s'effectue via des scripts KSH qui exécute des scripts SQL via le client en ligne de commande (SQL*Plus). Un seul script SQL principal est exécuté qui ensuite rappel d'autres scripts. Par défaut, l'option permettant d'ignorer les erreurs est activée, de sorte qu'en cas d'erreur, l'erreur est inscrite sur les sorties standard et le déroulement du script se poursuit.
En général en cas d'erreur, la personne au commande corrige rapidement le problème et relance entièrement le script. Le soucis étant qu'une erreur ignorée peut avoir compromis définitivement la BDD (données perdues), ou avoir mis la base de données dans un état complètement instable et nécessite de nombreuses opérations manuelles pour terminer la mise à jour.


Solution générale
D'un point de vue générale, nous avons opté pour le principe suivant : "découper" les scripts SQL en étapes. Les étapes sont jouées les unes après les autres s'il n'y a pas d'erreur "détectée". A la fin de chaque étape, on "trace" la bonne exécution du script afin de ne pas le rejouer en cas de reprise.

Il me reste donc à trouver comment découper les étapes (exécution conditionnelle), détecter les erreurs et tracer la bonne exécution.

Solution détaillée
Nous avons imaginé la solution suivante :

• Création d'une table de "synoptique" qui contiendrait la liste des étapes et leur état.
• Création d'un référentiel d'update. Celui contiendrait un script par étape et éventuellement des sous-répertoires.
• Création d'un script qui construirait le "synoptique" (insertion dans la table correspondante) en se basant sur les scripts contenus à la racine du référentiel, en triant par ordre alphabétique.
• Création d'un script qui générait un script SQL principal selon les états des étapes du "synoptique". Après l'exécution de chaque étape, le script principal met à jour la table de "synoptique". Toute erreur arrête le script.
• Chaque script d'étape se découpe deux parties : actions et contrôles. Les erreurs des actions sont ignorées et les contrôles consistent pour la plupart à vérifier dans le dictionnaire l'état des objets (tables, vues, etc.). L'échec d'un contrôle génère une erreur qui est renvoyée au script appelant.

Questions
Je pense que cette problématique n'est pas nouvelle et je voudrais votre avis sur les choix que nous avons effectués ?
Avez-vous optés pour d'autres solutions ? Que ce soit dans le principe générale ou dans son implémentation ?

[CinePhil]

Je viens de passer ce matin un paquet de patches SQL sur la BDD de notre ERP spécial enseignement supérieur : Cocktail.

La politique qui a été adoptée est constituée de :
- une table "db_version" dans chaque schéma de la BDD ;
- une vérification par chaque patch que la version précédente est bien présente dans la table db_version, avant exécution des instructions principales du patch ;
- un ajout de la version de patch qui vient d'être passée dans la table db_version.

Et nous avons bien sûr la consigne de passer les patches dans l'ordre de leur publication. La vérification en début de patch pallie les éventuels oublis en bloquant l'exécution du patch.

De plus, les patches, notamment DML, commencent par une instruction d'annulation en cas d'erreur et se terminent par un commit si tout s'est bien passé.

Un tableau récapitulatif des versions publiées est disponible sur le site de Cocktail et j'ai personnellement un tableau qui reprend la liste des publications et ce qui a été patché chez nous.

[Logan Mauzaize]

Ok merci pour ce retour, dans le principe générale l'idée est la même.

Je prends note tout de même que les vérifications s'effectuent dans l'étape suivante ... Je vais peut-être opté pour un double-check en externalisant la vérification.

Surtout que derrière l'idée des étapes, c'est la bascule en plusieurs temps car j'ai des limites d'interruption de service. Donc on distingue ce qui peut se faire OnLine et OffLine. Et on fait ça en deux-trois interruptions de 30 minutes. L'enjeu d'avoir un maximum de choses en automatiques vient de là : minimiser le temps d'interruption en minimisant les interventions manuelles.

Concernant les DMLs c'est pas possible sauf cas particulier. J'ai généralement des volumes très importants de données à manipuler (plusieurs Go) et j'exploserai l'espace temporaire. Donc je travaille par "lot" ou "tranche" et je commit à chaque fois.

[Luckyluke34]

Bonjour,

Vu que c'est du pur base de données, je pense que tu aurais plus de réponses sur Décisions SGBD voire Langage SQL.

Sinon il existe des outils de mise à jour différentielle de schéma de base de données qui marchent bien, comme Apex.

[Logan Mauzaize]

Justement, il n'y a pas que des scripts SQL, il y a aussi du Shell. D'ailleurs les ordres SQL en eux mêmes ne me posent pas de problème.
Je dois rester sur ce couple car tout doit être aussi automatique que possible. Ce sont des indiens qui exécutent les commandes alors il vaut mieux qu'il y en ait le moins possible. Et, de plus, je n'ai pas la main sur ces serveurs.

Merci pour les conseils, je vais mettre un message Décisions SGBD avec un lien vers ici.