none
Crash de base de données - comment connaitre la cause ? RRS feed

 > 

  • Question

  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour,

     

    Nous utilisons une application métier qui tourne sur SQL Server 2008. 

    Un incident "grave" est intervenu il y a 3 semaines, et a entraîné la corruption de la base. L'éditeur du logiciel a du restaurer un backup de la veille pour retrouver un état stable. Cet éditeur nous stipule que le problème viendrait de chez nous, car un administrateur aurait importé un fichier ou fait une mise à jour logicielle... Ce dont je doute fort.. Quoiqu'il en soit, je suis en train de consulter les diverses logs en notre possession.

    A l'heure supposée du crash, je trouve ceci :

    28/04/2011 15:04:07 Setting database option RECOVERY to BULK_LOGGED for database xxxxxx

    Est-ce un traitement automatique de la BDD, ou cela nécessite-t'il une intervention humaine ?

    S'ensuite ensuite des traitements sur des tables et index (8277-U & 22601-IX)

    Je consulte le fichier log_xx.trc, mais je ne trouve pas d'infos très détaillées. 

    Par exemple , j'ai une trace sur l'objet DB (16964 - DB), Object Altered, à l'heure précise du "RECOVERY to BULK_LOGGED" mais je ne sais pas en quoi consiste ce traitement, ni qui l'a initié.

    Pouvez-vous aiguiller mes recherches ? Je ne sais plus trop o regarder.

    Merci

     

    mardi 24 mai 2011 10:28
    |

Réponses

  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Ok votre histoire se complique donc vous allez avoir beaucoup de difficultés pour retrouver votre  "coupable" sans avoir mis d'outils de surveillance en place.

    ++

    MCDBA | MCITP SQL Server 2005 / SQL Server 2008 | LPI Linux 1
    • Proposé comme réponse Papy Normand jeudi 26 mai 2011 10:26
    • Marqué comme réponse Yann BODIC jeudi 26 mai 2011 11:30
    jeudi 26 mai 2011 10:08
    |
    Modérateur

Toutes les réponses

  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour,

    BULK_LOGGED est une des options possible pour le mode de récupération utilisant les journeaux de transaction.Elle permet surtout de diminuer la place nécessaire pour les journaux de transaction ( donc de théoriquement gagner du temps lors des sauvegardes ).

    Ce changement de mode de récupération peut se faire en traitement automatique ( dans un job lancé par SQL Agent ) ou avec une intervention humaine ( par un script T-SQL ou PowerShell ).

    Le problème est que ce problème a eu lieu il y a 3 semaines et je ne sais pas si vous avez encore tous les journaux correspondant à cette époque ( SQL Server,SQL Agent ).Par contre, la corruption de la base peut avoir plusieurs causes dont un problème du disque sur lequel se trouve la base de donn"es. Je connais suffisamment les éditeurs de logiciel pour savoir qu'ils sont prêts à tout pour rejeter la faute sur le client pour s'éviter dêtre considéres comme potentiellement responsables.

    Pourrie-vous poster le message exact indiquant qu'il y a eu corruption de la base ? Regardez si à l'heure où est apparu ce message de corruption, il s'est produit d'autres incidents ( ou une sauvegarde ou une restauration de base de données ).Une vérification du disque pourrait être utile ( il pourrait être judicieux de programmer un changement de disque plutôt que d'attendre son crash ). Regardez aussi si vous n'avez pas de problème de place disque.

    N'hésitez pas à poster à nouveau pour de l'aide ou explications complémentaires.

    Bonne journée

    Mark Post as helpful if it provides any help.Otherwise,leave it as it is.
    mardi 24 mai 2011 20:04
    |
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonsoir,

    L'information que vous avez donnée n'indique rien. En fait, le BULK_LOGGED est un modèle de récupération et dans votre cas il s'agit d'un switching probablement d'un modèle de récupération complet a celui BULK_LOGGED. Je m'explique, l'intérêt de ce switching est généralement conseiller dans le cas d'un traitement de masse sur la base de données, d'ou pour des raisons d'améliorations de performance ce changement permet d'accélerer les traitements. toutefois des bonnes pratiques sont conseillées pour utiliser cet technique. De plus, je tiens à vous informer que cette opérations peut etre automatisé par programmation (une applicaton) ou par intervention d'un administrateur.

    Merci

    Best Regards Don't forget to mark it as answer if it helps
    mardi 24 mai 2011 20:07
    |
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour,

    Amélioration des performances cela dépend et gagner du temps sur les sauvegardes c'est encore moins sûr. Le but de ce mode est surtout est d'éviter le grossissement et la saturation du journal des transactions.

    Cf http://blog.developpez.com/mikedavem/p8923/sql-server-2005/histoire-de-sauvegarde-le-mode-de-recupe/

    Si vous avez encore la trace (par défaut) en principe vous devez avoir une information sur celui qui a initié l'action sur l'altération de vos objets (avec les colonnes NTUserName, NTDomainName, HostName, ObjectID, DatabaseName ...)

    ++

    MCDBA | MCITP SQL Server 2005 / SQL Server 2008 | LPI Linux 1
    mercredi 25 mai 2011 08:31
    |
    Modérateur
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour,

     

    Merci pour vos réponses.

    La corruption de la base n'est pas démontrable en tant que telle. Il est possible que ça soit une corruption "logicielle". L'éditeur a restauré une sauvegarde de la BDD 1/2 après le crash. Dans les logs à ma disposition, je peux vous fournir ceci

    http://imageshack.us/photo/my-images/861/20110525105712.png

     

    Dans le fichier ERRORLOG j'ai ceci

     

    2011-04-28 00:00:38.36 spid23s     This instance of SQL Server has been using a process ID of 2040 since 26/04/2011 11:55:08 (local) 26/04/2011 09:55:08 (UTC). This is an informational message only; no user action is required.

    2011-04-28 15:04:07.15 spid63      Setting database option RECOVERY to BULK_LOGGED for database xxxxx.

    2011-04-28 15:35:23.91 Serveur     SQL Server is terminating because of a system shutdown. This is an informational message only. No user action is required.

    Bref rien de bien concluant.
    Dans les logs trace, vous avez un aperçu des tables qui sont updatées. Elles le sont dans un ordre alphabétique, ce qui me fait penser à un traitement de maintenance ou autre, et qu'ensuite, des travaux d'indexation se mettent en place. Durant ce traitement, un utilisateur distant se connecte à la base pour travailler et à partir de ce moment là tout part en vrille (au niveau utilisation). peut-être est-ce à cause d'une utilisation lors d'une opération de maintenance ?
    Je suis un peu perdu, et je crains qu'on ne sache jamais...
    Merci

    mercredi 25 mai 2011 09:08
    |
  • Question
    Connectez-vous pour voter
    1
    Connectez-vous pour voter

    La corruption de la base n'est pas démontrable en tant que telle. Il est possible que ça soit une corruption "logicielle". L'éditeur a restauré une sauvegarde de la BDD 1/2 après le crash. Dans les logs à ma disposition, je peux vous fournir ceci

    _Oui très probablement. Une corruption physique n'aurait pas donné la même chose.

    Je ne vois pas le nom des colonnes de la trace chez vous mais avez vous les colonnes qui concernent l'hôte, le domaine et l'application qui a exécuté un update de vos tables ? Il faudrait regarder dans ce sens. Vous ne pourrez pas faire grand chose de plus dans votre cas à moins d'avoir activé des audits sur votre serveur.

    ++

     

    MCDBA | MCITP SQL Server 2005 / SQL Server 2008 | LPI Linux 1
    mercredi 25 mai 2011 14:51
    |
    Modérateur
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    L'hôte est le nom du serveur qui héberge la base, les notions de NTdomain et NTuser sont vides. L'application name est vide aussi. Pas simple :/

    Je précise juste l'arhcitecture : un serveur SQL sur un Serveur 2008, les utilisateurs se connectant via Applidis Systancia à une application publiée.

     

    merci pour votre aide

     

    jeudi 26 mai 2011 07:14
    |
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Ok votre histoire se complique donc vous allez avoir beaucoup de difficultés pour retrouver votre  "coupable" sans avoir mis d'outils de surveillance en place.

    ++

    MCDBA | MCITP SQL Server 2005 / SQL Server 2008 | LPI Linux 1
    • Proposé comme réponse Papy Normand jeudi 26 mai 2011 10:26
    • Marqué comme réponse Yann BODIC jeudi 26 mai 2011 11:30
    jeudi 26 mai 2011 10:08
    |
    Modérateur
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Mystère et boule de gomme.

     

    Merci encore

    jeudi 26 mai 2011 11:30
    |
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour,

     

    J'arrive aprés la bataille avec mes gros sabots mais je me pose queqlues question par rapport à votre problème.

     

    Il est question de crash et de corruption de base...

    Une corruption de base d'un point de vue SQL Server est simple à mettre en évidence (mais pas d'en connaitre la cause :-( ) il suffit de passer un DBCC CHECKDB sur la base "corrompue". Si SQL detecte des erreur: il y a corruption. Sinon c'est que la base est saine d'un point de vue SQL Server.

    S'il s'agit d'une corruption SQL Server les cause sont souvent matériel, ou lié a un anti-virus, ou autre maillon du sous-système disque.

    Si la corruption n'est pas SQL (aucune erreur remonté par le DBCC CHECKDB) ... c'est qu'il s'agit d'une corruption applicative. Elle est donc due a l'application :-).

     

    La sécurité et l'intégrité des données est la première préoccupation de SQL Server.

     

    Si on parle de crash... il suffit de regarder les ERRORLOG (ou l'event log applicatif) Vous y trouverez forcément des informations sur le crash (s'il s'agit d'un pb SQL Server).

     

     

     

     

    lundi 6 juin 2011 15:03
    |
  • Question
    Connectez-vous pour voter
    0
    Connectez-vous pour voter

    Bonjour,

    Pas de problème pour les sabots :)

    J'ai rencontré l'éditeur du logiciel depuis. La corruption est logicielle. Enfin, si on peut parler de corruption.

    Il y a une option dans le logiciel qui permet de (la bonne idée) purger les tables en vue d'un import de données...

    Ceci explique cela.. snif...

     

    Merci en tout cas

    lundi 6 juin 2011 15:29
    |