Discussion :

[Nadinette]

Salut,
Ma société vient de se voir confier une grosse TMA.
La base de données fait 400Go répliquée sur deux sites.
On est donc pas en code first. Du coup, je suis trop jeune pour connaitre les anciens usages pour revenir en arrière quand on passe des scripts d'alter table etc pour déployer une évolution.
SQL Server peut-il automatiquement rollbacker le passage d'un script ou on doit pondre le script pour revenir en arrière ?
L'option restaure backup est exclue car ça prend 6 heures on peut faire jusqu'à un déploiement par jour.
J'avoue que je suis bloquée. Je ne sais pas du tout quoi proposer.
Pourriez-vous m'aider ?
Merci

[al1_24]

Pour faire simple et rapide :

• Rollback possible sur les instructions DML (celles qui modifient les données : ajout, modification, suppression de lignes)
• Pas de rollback possible sur les instructions DDL (celles qui modifient les structures : création/modification/suppression de tables, index, vues...)

[Nadinette]

Du coup comment font les grosses boites ?
Lorsqu'on a un cluster, c'est possible genre de casser la liaison, de lancer l'appli sur un seul serveur en gardant l'autre dans l'ancienne version et si ça marche de reconstruire la liaison pour resynchroniser avec la nouvelle structure ou le contraire si ça ne fonctionne pas ?
Merci
Désolé si ces questions sont bêtes mais je ne suis pas du tout dba

[Invité]

Pour faire simple et rapide :

• Rollback possible sur les instructions DML (celles qui modifient les données : ajout, modification, suppression de lignes)
• Pas de rollback possible sur les instructions DDL (celles qui modifient les structures : création/modification/suppression de tables, index, vues...)

J'ai l'impression que Nadinette parle de Rollback au sens général de retour en arrière, pas un vrai rollback au sens transaction SQL
Peux-tu nous confirmer ça ?

Pour gérer le modèle de données, j'ai déjà employé des outils comme RedGate SQL Compare qui permet de générer des scripts de retour en arrière vers une version particulière mais ça demande de faire du versionnage proprement. Visual Studio peut aussi faire ça.
Dans un autre société, pour chaque modification effectuée, on avait le script et un script de retour en arrière.
Évidemment, il y a des limitations dans ces modifications : si tu supprimes une colonne, tu peux la recréer mais le contenu ne sera plus là.

Cela-dit si c'est un besoin régulier de retour en arrière en Production, il faudrait sérieusement revoir les pratiques de tests et validations dans les autres environnements en premier.
C'est une procédure qui devrait être employée de façon très exceptionnelle.

[mikedavem]

Pour faire simple et rapide :

• Rollback possible sur les instructions DML (celles qui modifient les données : ajout, modification, suppression de lignes)
• Pas de rollback possible sur les instructions DDL (celles qui modifient les structures : création/modification/suppression de tables, index, vues...)

L'annulation d'une opération DDL est possible sur SQL Server (par ex CREATE TABLE , ADD COLUMN etc ...)

Dans un autre société, pour chaque modification effectuée, on avait le script et un script de retour en arrière.
Cela-dit si c'est un besoin régulier de retour en arrière en Production, il faudrait sérieusement revoir les pratiques de tests et validations dans les autres environnements en premier.
C'est une procédure qui devrait être employée de façon très exceptionnelle.

Il faut en effet prévoir les scripts de retour (UNDO) dans le meilleur des mondes. Mais je rejoins Nadinette sur le fait que tout cela doit être validé et testé en amont avant de passer en prod.
Les environnements INT / ACC etc .. sont faits pour cela.

Évidemment, il y a des limitations dans ces modifications : si tu supprimes une colonne, tu peux la recréer mais le contenu ne sera plus là.

En principe d'une version N à N+1 on ne supprime jamais une colonne qui est censée ne plus être utilisée et on attend le passage à une version >= N+2. En cas de souci, il possible de revenir en arrière assez facilement. C'est ce que nous pratiquons en tout cas chez nous dans le cadre de notre politique de CI/CD.

++

[hmira]

• Pas de rollback possible sur les instructions DDL (celles qui modifient les structures : création/modification/suppression de tables, index, vues...)

C’est faux !
Sous SQL Server, les commandes DDL, à quelques très rares exceptions près, peuvent être enrôlées dans une transaction.

A+

PS : J’avais pas vu la réponse, ci-dessus, beaucoup plus complète, de mikedavem

[Invité]

En principe d'une version N à N+1 on ne supprime jamais une colonne qui est censée ne plus être utilisée et on attend le passage à une version >= N+2. En cas de souci, il possible de revenir en arrière assez facilement. C'est ce que nous pratiquons en tout cas chez nous dans le cadre de notre politique de CI/CD.

C'est intelligent ça !
Perso, dans les pratiques que j'ai vu, on supprime tout de suite... ou jamais !

Si c'est une colonne potentiellement sensible à supprimer, j'ai tendance à copier les données dans une table temporaire que je supprimerai quelques mois plus tard.

[mikedavem]

C'est intelligent ça !
Perso, dans les pratiques que j'ai vu, on supprime tout de suite... ou jamais !

Si c'est une colonne potentiellement sensible à supprimer, j'ai tendance à copier les données dans une table temporaire que je supprimerai quelques mois plus tard.

Ca joue aussi tant qu'on peut revenir en arrière

[Nadinette]

Salut,

On est en présence d'une application ancienne développée avec des vielles techniques et une base de données maintenue par un développeur qui était le moins mauvais de la boite en SQL et en aucun cas un DBA.
Il y a souvent des problèmes lors des livraisons mixtes (Code + Data).

Pour rollbacker le code ça prend 5 minutes.
pour remonter un backup ca prend 6 heures !

Je veux trouver une solution qui réduirait drastiquement le temps de remontée du backup OU trouver une autre astuce.

Merci

[escartefigue]

Si la mise à disposition des données est bien conçue, les applications ne lisent pas les tables directement, elles utilisent les vues.
Quand une colonne devient obsolète, le plus simple est donc de faire une nouvelle version de vue dans laquelle cette colonne n'est plus référencée et laisser la table en l'état. Les applications migrent sur cette version de vue (sauf si certaines spécifiques consultent les archives)
Le ratio bénéfice/risque de la suppression réelle de la colonne de la table est trop faible pour justifier ce genre de chantier.

[Invité]

On est en présence d'une application ancienne développée avec des vielles techniques et une base de données maintenue par un développeur qui était le moins mauvais de la boite en SQL et en aucun cas un DBA.
Il y a souvent des problèmes lors des livraisons mixtes (Code + Data).

De ce que tu écris, le problème est peut-être là : besoin d'une personne ayant des connaissances avancées en base de données pour gérer l'évolution du modèle de données. Difficile de contourner le problème en faisant des mises en prod essai / erreur.

Quand je fais des mises en production (et c'est vraisemblablement le cas des autres participants de ce fil), c'est excessivement rare qu'il y ait besoin d'un rollback.
Et s'il y a problème de bd, je suis capable de patcher rapidement dans la majorité des cas.

Si j'avais besoin de faire un rollback régulièrement à cause d'un problème bd, mon boss m'aurait remercié rapidement.

[Nadinette]

Dans ce cas faire preuve de talent c'est de régler le problème sans chercher un coupable sinon on vire toute la boite.

[mikedavem]

Encore une fois la solution passe par la mise en place d'un environnement de livraison correcte pour éviter ce genre de problèmes en production ou les scénarios de déploiement peuvent être rejoués pour garantir qu'il n'y a aura à priori aucun souci le jour de la production (le risque zéro n'existe pas).
Néanmoins tu peux utiliser les snapshots de bases de données SQL Server (disponible pour toutes les éditions SQL Server 2016 SP1+) pour rapidement revenir en arrière en cas de problème. J'ai déjà eu recours à ce genre de mécanisme dans le passé et cela fonctionne plutôt bien. Attention cependant à la place nécessaire (si beaucoup de pages sont touchées) et à la performance si important dans ton cas).

Bien que pratique cette méthode a aussi l'inconvénient qu'il faille s'assurer que tu sois le seul à mettre à jour les données au moment de ta MEP car tu vas aussi annuler les changements dans le même intervalle.

++

[SQLpro]

Une autre possibilité est de faire un snapshot SQL Server de la base avant modif, afin de revenir en arrière par une restauration, en principe plus rapide qu'un rollback.

Attention, pendant ce temps là, pas d'accès aux données par des utilisateurs sinon, il se verrons rétrogradées leurs données aussi !

A +

[Waldar]

Du coup comment font les grosses boites ?

Chez un grand site marchand du web, géré sur SQL-Serveur, les livrables contenaient obligatoirement le ou les scripts de livraison ainsi que le ou les scripts de rollbacks.
Ces scripts sont enchaînés sur tous les environnements hors prod : MEP puis Rollback dans la foulée, vérification que la plateforme est bien à l'état initial, puis MEP et vérification que la plateforme est bien à l'état attendu.
Une fois ces étapes validées, le script de MEP pouvait être passé en production, le script de rollback étant jugé suffisamment fiable.
Je me demande même si le MEP => Rollback n'était pas joué deux fois (en hors prod), mais je ne me souviens plus exactement.