Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

MS SQL Server Discussion :

Déterminer la validité d'une BDD


Sujet :

MS SQL Server

  1. #1
    Membre éclairé
    Déterminer la validité d'une BDD
    Bonjour,

    Je travail sur une application qui est déployée sur plusieurs sites de production et en différentes versions. Il arrive parfois que des erreurs de déploiement ou mise à jour provoquent des incidents de production quand la BDD ne correspond pas à la version de l'application qui l'utilise.

    J'ai déjà un brouillon de code qui calcul un hashcode à partir des tables, colonnes des tables, contraintes, code des fonctions et code des procstoc, sans tenir compte des données dans les tables (seule la structure compte): ca permet d'identifier à coup sure au démarrage si la BDD est de la bonne version. Mais cette je trouve cette solution est assez lourde.
    La solution ultra simple d'ajouter un numéro de version de la BDD dans une des tables a été envisagée, mais elle peut être facilement modifiée par un administrateur pour contourner cette sécurité et forcer le démarrage de l'appli.

    Y-a-t'il un moyen plus simple de déterminer si la BDD à laquelle l'appli se connecte est de la bonne version? A savoir structure des tables, colonnes et contrainte qui les lient + code des fonctions et des procstoc de la bonne version.
    Je n'ai rien trouvé sur les forum à ce sujet.

    Merci.

  2. #2
    Membre éprouvé
    Le plus professionnel est de déployer les schémas de BD par intégration continue, avec un gestionnaire de code source type git.

  3. #3
    Membre éclairé
    @MaximeCh: Je suis d'accord, mais là ça ne se fait pas pour différentes raison que je ne peux pas développer ici. Il arrive qu'un dump soit installé avec une version de l'appli plus récente sur une nouvelle VM lorque que les anciennes VM de prod sont décommissionnées. Mon but est d'avoir un diagnostique de la compatibilité de la BDD dès le démarrage sans attendre qu'il y ait des incidents de prod.

  4. #4
    Membre éprouvé
    Je ne vois rien à part le hash en base avec procédure stockée...

  5. #5
    Modérateur

    Citation Envoyé par bertry Voir le message
    mais elle peut être facilement modifiée par un administrateur pour contourner cette sécurité et forcer le démarrage de l'appli.
    Alors il faudrait retirer les privilèges (voire virer ! ) l'admin qui (ab)use de ses privilèges pour... faire n'importe quoi.

  6. #6
    Membre éclairé
    Citation Envoyé par aieeeuuuuu Voir le message
    Alors il faudrait retirer les privilèges (voire virer ! ) l'admin qui (ab)use de ses privilèges pour... faire n'importe quoi.
    C'est la différence que je constate entre la théorie qu'on nous enseigne en formation ou à l'école et la pratique sur le terrain. Parfois par manque de moyens et/ou la pression hierarchique on fini par bricoler pour que ça tourne quand même. Les admins ne sont (peut-être ^^) pas à virer, il font de leur mieux avec les moyens et le temps qu'on leur donne...

    Ici, il s'agit de trouver une solution pour éviter des bugs en prod.

  7. #7
    Membre éprouvé
    On est dans la politique ou dans la technique ?
    tu te bats contre quelqu'un? contre qui? ils ont quels droits que tu n'as pas? tu as quel droit qu'ils n'ont pas? vous partagez quels droits?

    Parce que niveau technique il y a un panel de mesures possibles, les hash ça me paraît de loin le plus simple, sinon un log de toutes les modifs sur le schéma, une caméra sur le poste de l'admin...

  8. #8
    Modérateur

    Je ne blame personne, mais ce qui est sûr c'est que le problème ne pourra pas être règle d'une façon technique.
    Par exemple, votre calcul de HASH sur les objets en base empêchera l'appli de démarrer du jour au lendemain, même si elle est dans la bonne version, le jour où un de ces admin créera un objet supplémentaire (une fonction de test, une table pour sauvegarde telle ou telle données,...)

    Par ailleurs, vous en dites peu sur le contexte, on peut donc difficilement proposer des alternatives.
    Qui sont ces admins qui modifient à la main le contenu des tables ? quel est leur rôle et quels sont leurs privilèges ? (il y a sans doute moyen de réduire leur privilèges sans les empêcher de faire leur travail)

    Aussi, effectuez vous souvent des restaurations en production ? pour quelles raisons ?

  9. #9
    Rédacteur

    Ce calcul de hash est une idiotie car suivant l'accès aux données que va prendre l'optimiseur, il se peut que l'on obtiennent pas les mêmes résultats...

    A +
    Cette signature n'a pas pu être affichée car elle comporte des erreurs.

  10. #10
    Membre éclairé
    @Tous:
    Je suis d'accord avec vous tous, une petite solution technique ne suffira jamais à compenser de mauvaises pratiques qui ont fini pas s'installer. Pour ce qui est du contexte, comme il s'agit du domaine professionnel, je ne suis pas autorisé à donner de détails.

    Citation Envoyé par SQLpro Voir le message
    Ce calcul de hash est une idiotie car suivant l'accès aux données que va prendre l'optimiseur, il se peut que l'on obtiennent pas les mêmes résultats...
    A +
    @SQLpro: Merci pour cette précision.


    Pensant, sans trouver, qu'il y avait déjà des solutions clé en main dans SQL server à mon problème, j'avais créé ce post. Je vais donc le cloturer en vous remerciant de vos réponses.

  11. #11
    Modérateur

    Citation Envoyé par SQLpro Voir le message
    Ce calcul de hash est une idiotie car suivant l'accès aux données que va prendre l'optimiseur, il se peut que l'on obtiennent pas les mêmes résultats...

    A +
    ça dépend de la façon de calculer le hash

    Par exemple, ceci renverra toujours la même valeur :

    Code :Sélectionner tout -Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
     
    SELECT CHECKSUM_AGG(CHECKSUM(name))
    FROM 
    (
    	SELECT name
    	FROM sys.objects
    	UNION ALL
    	SELECT name
    	FROM sys.columns
    ) AS T