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

[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.

[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.

++

[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

[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