Gestion des erreurs et intégrité des données lors du changement du schéma de table

Question

Nous avons quelques clients avec de grands ensembles de données et pendant notre procédure de mise à niveau, nous devons modifier le schéma des différentes tables (ajouter des colonnes, renommer les autres, changer occasionnellement les types de données, rare).

Auparavant, nous allions via une table temporaire avec le nouveau schéma, puis en supprimant l'original et en renommant la table temporaire, mais j'espère pouvoir l'accélérer considérablement en utilisant ALTER table ... à la place.

Ma question est de savoir quels problèmes d'intégrité des données et de gestion des erreurs dois-je prendre en compte? Dois-je inclure toutes les modifications apportées à une table dans une transaction (et si oui, comment?) Ou est-ce que le SGBD garantira l'atomicité et l'intégrité au cours d'une opération ALTER?

Nous recommandons déjà fortement aux clients de sauvegarder leurs données avant de commencer la mise à niveau, ce qui devrait toujours être une option de repli.

Nous devons cibler SQL Server 2005 et Oracle, mais je peux évidemment ajouter du code conditionnel s'ils nécessitent des approches différentes.

Answer 1

Commentaires pour Oracle uniquement:

• modifications de table sont DDL, de sorte que le concept d'une transaction ne s'applique pas - chaque instruction DDL verrouille la table pendant toute la durée de l'opération et soit réussit ou échoue. Ajouter des colonnes (nullable!) Ou renommer des colonnes existantes est un processus relativement léger et ne devrait présenter aucun problème si le verrou de table peut être acquis.Si vous ajoutez ou modifiez des contraintes (NOT NULL ou d'autres contraintes de vérification plus complexes), Oracle vérifie les données existantes pour valider les contraintes, sauf si vous ajoutez la clause ENABLE NOVALIDATE à la contrainte DDL. La validation des données existantes peut être un processus long pour les grandes tables. Si vous souhaitez que la mise à niveau soit exécutée sous la forme d'un script SQL * Plus, sauvegardez-vous beaucoup de maux de tête en utilisant la directive "every sqlerror exit sql.sqlcode" pour interrompre le script lors du premier échec. l'examen des mises à niveau partiellement mises en œuvre plus facile. Si la mise à niveau doit être effectuée sur un système en direct où vous ne pouvez pas contrôler les transactions ou vous permettre de les manquer, utilisez le package Oracle DBMS_REDEFINITION, qui crée automatiquement une configuration temporaire des tables temporaires et des déclencheurs pour capturer en vol transactions tout en redéfinissant la table dans le "contexte". Attention - beaucoup de travail et une courbe d'apprentissage abrupte pour cette option.

Answer 2

Si vous utilisez SQL Server, alors les instructions ddl sont transactionnelles, alors retournez dans une transaction (je ne pense pas que cela s'applique à Oracle).

Nous divisons les mises à niveau en correctifs individuels associés à une fonctionnalité particulière. Les correctifs appliqués vont dans une table database_patch_history, et il est facile de voir quels correctifs ont été appliqués et comment les restaurer. Comme vous le dites, il est important de faire une sauvegarde avant de commencer.

Answer 3

Si vous changez radicalement les types de données de colonnes, par exemple, changez un VARCHAR en INT, le SGBD va paniquer et vous perdrez probablement ces données. Heureusement, de nos jours, les SGBD sont assez intelligents pour effectuer certaines conversions de type de données sans perdre les données, mais vous ne voulez pas risquer de les endommager lors des modifications.

Vous ne devriez pas perdre de données en renommant des colonnes et certainement pas en ajoutant de nouvelles colonnes, c'est quand vous déplacez les données sur ce que vous devez être concerné. Tout d'abord, sauvegardez la totalité de la table, à la fois le schéma et les données, afin de pouvoir, à la seconde, revenir au schéma précédent. Deuxièmement, regardez les changements que vous essayez de faire, voyez à quel point ils sont drastiques - essayez de comprendre exactement ce qui doit changer. Si vous effectuez des conversions de type de données, placez-les d'abord dans une table intermediatery avec 3 colonnes, la clé étrangère (id ou autre pour que vous puissiez localiser la ligne), les anciennes données et la nouvelle colonne. Poussez ensuite directement les anciennes données dans la nouvelle colonne ou convertissez-les au niveau de l'application. Quand tout est dans les bons types et que tout a réussi, lancez les instructions ALTER et remplissez à nouveau la base de données! C'est assez simple à faire, il suffit d'un processus de pensée logique.

Answer 4

J'ai dû faire des changements de ce genre dans le passé et j'ai toujours été très paranoïaque à propos de la perte de données. Pour aider à atténuer ce risque, j'ai toujours fait des tonnes de tests sur des bases de données "sandbox" qui reflétaient les bases de données cibles dans le schéma et les données aussi étroitement que possible. Testez le processus autant que possible avant de le déployer, comme vous le feriez pour tout autre domaine de l'application.