Bonjour, je m’appelle Curt. Je suis ingénieur principal senior et je travaille au sein de l’équipe GSE.
Cette vidéo est consacrée à la présentation du journal d’erreurs SQL Server. Son emplacement, les informations qu’il contient et pourquoi il peut nous aider à résoudre les problèmes de Microsoft SQL Server.
Le moyen le plus rapide d’accéder au journal est donc de passer par Microsoft SQL Server Management Studio.
Si nous effectuons une recherche verticale sur le conteneur « Management », puis sur « SQL Server logs », nous voyons les journaux d’erreurs que SQL Server a collectés pour cette installation de SQL.
Il existe six journaux d’archivage qui sont conservés par SQL d’événements passés qui se sont produits sur ce serveur. Le journal actuel est celui qui collecte toutes les informations depuis le dernier redémarrage de SQL Server, et le journal des erreurs est régénéré chaque fois que SQL Server est redémarré.
Examinons le journal actuel pour vous donner une idée de ce que nous pouvons nous attendre à voir ici. Le premier élément que nous voyons est le type d’installation pour SQL Server. Dans ce cas, il s’agit de SQL Server 2019.
Il nous donne également des informations sur la version du produit. Dans ce cas, nous travaillons avec une installation RTM de base de SQL Server. Nous obtenons également des informations sur le système d’exploitation.
Dans ce cas, il s’agit d’une installation de Windows 10 sur une station de travail. En vous déplaçant dans le journal et ce que vous verrez dans Studio Management est que les premiers événements sont enregistrés en bas du journal tel qu’il apparaît, et les derniers événements se trouvent vers le haut du journal.
En parcourant le journal, nous voyons des choses comme le mode d’authentification qui est mixte, nous voyons l’emplacement réel du journal d’erreurs - c’est l’emplacement par défaut pour les fichiers du programme du journal d’erreurs/Microsoft SQL Server et le dossier d’installation pour l’instance de SQL elle-même.
On retrouve également les informations relatives au compte de service qui a été utilisé pour démarrer SQL Server. Une autre entrée qui peut être importante sont les paramètres de démarrage, l’emplacement par défaut que SQL a actuellement pour les fichiers de base de données, ainsi que l’emplacement du journal d’erreurs et les fichiers journaux que nous voyons pour SQL Server.
Nous obtenons également des informations sur les cœurs du système, le nombre de processeurs disponibles que SQL peut utiliser et la quantité de mémoire disponible que SQL voit au niveau physique lorsque le système démarre.
Une autre information qui suit est que la base de données système est en cours de connexion. Si nous avons des bases de données de production utilisateur, nous voyons également ces informations, mais la chose la plus notable à propos du journal d’erreurs SQL Server et son plus grand avantage est en fait le retour d’informations sur les erreurs qui sont vues par SQL Server.
Il ne peut pas s’agir uniquement du moment du démarrage, mais aussi de la durée de vie du service en cours d’exécution. Nous avons donc ici une erreur sans conséquence, mais qui fait référence à Polybase, la configuration Polybase sur le système.
En fait, Polybase n’a pas été installé avec cela, il n’y a pas d’informations de configuration Polybase, donc ce n’est pas un problème pour cette installation, mais c’est un exemple de message que nous voyons comme une erreur.
Maintenant, pour entrer un peu plus dans les détails sur les endroits où le journal d’erreurs peut être extrêmement utile, par exemple lorsque SQL Server ne démarre pas.
Ce journal est le précédent journal que j’avais dans notre journal actuel, et SQL Server n’a pas démarré dans cette tentative de démarrage.
Il s’agit d’une erreur fabriquée, et la façon dont j’ai fabriqué cette erreur est que j’ai déplacé l’emplacement de la base de données modèle, qui est une base de données système.
Il s’agit d’une base de données qui sert de modèle pour toutes les bases de données créées par SQL Server. Lorsque SQL Server démarre, il doit démarrer et utiliser une base de données tempdb, et la base de données model est le modèle pour la base de données tempdb.
Ainsi, sans un modèle, la base de données tempdb n’a pas pu démarrer, ou n’a pas pu se mettre en ligne et le service SQL Server n’a pas pu démarrer.
Ceci est un exemple de ce que nous pourrions voir dans le journal d’erreurs. Nous verrions l’erreur, nous verrions plus d’informations sur la raison pour laquelle l’erreur a été générée - dans ce cas, il n’a pas pu trouver un fichier de base de données, le fichier de base de données modèle - et plus tard, il nous dira qu’il n’a pas pu trouver le fichier journal de la base de données modèle, ce qui signifie que la base de données tempdb n’a pas pu être créée.
La mauvaise nouvelle, c’est que le journal d’erreurs peut vous renvoyer pour vous donner des informations sur la façon de résoudre votre problème.
Maintenant, nous devons garder à l’esprit que lorsque nous voyons une entrée pour une erreur comme celle-ci, elle sera également incluse dans les journaux d’application.
Le même événement est enregistré dans le journal de l’application système. Le premier message d’erreur indique que le fichier de base de données est introuvable, et le second indique que le fichier journal est introuvable.
Encore une fois, il s’agit d’un exemple fabriqué d’une panne. Bien sûr, cela peut être très important pour vous si vous dépannez un problème réel.
Par exemple, si un fichier de base de données majeur est corrompu, comme la base de données modèle, le service for SQL ne démarre pas et c’est dans cette zone que vous obtiendrez des informations pour en savoir plus à ce sujet et pour résoudre les problèmes.
Assez parlé du contenu du journal d’erreurs. Nous pouvons également accéder aux journaux d’erreurs dans l’explorateur de fichiers. Encore une fois, nous devons connaître l’emplacement du fichier du journal d’erreurs, nous l’avons vu dans le journal d’erreurs lui-même.
Nous savons qu’il s’agit de l’emplacement par défaut du journal des erreurs et du répertoire des journaux de l’installation de SQL Server.
Voyez toujours les mêmes informations - nous avons le choix de l’éditeur de texte avec lequel vous souhaitez les afficher. Encore une fois, la vue est différente.
Ici, les événements les plus anciens se trouvent en haut du journal lorsque vous examinez le journal brut lui-même, et les plus récents sont en bas.
Il existe un autre moyen de trouver l’emplacement du journal des erreurs, qui consiste à accéder à l’installation du programme à partir du menu Démarrer pour cette instance de SQL Server.
Ici, nous accédons à « SQL Server Configuration Manager ». Configuration Manager affiche tous les services pour cette installation de SQL.
Si nous allons dans « SQL Server Service », cliquez dessus avec le bouton droit de la souris, puis accédez à « Properties », « Startup Parameters », le paramètre « -e » est l’endroit où se trouve le journal des erreurs.
Et parfois, il est très important de comprendre cela, car vous n’avez peut-être pas d’installation de Studio Management à regarder.
Si ce n’est pas le cas, vous devez commencer à réfléchir à tous les emplacements de disque disponibles pour cette installation particulière de SQL.
Souvent, vous pouvez simplement aller droit au but, accéder à Configuration Manager, trouver ces paramètres de démarrage et, ce faisant, vous pouvez savoir exactement où se trouve ce journal d’erreurs.
Voilà qui conclut notre analyse du journal des erreurs SQL Server. J’espère que cette vidéo vous a aidé à comprendre où trouver le journal et comment il peut vous aider à résoudre les problèmes de Microsoft SQL Server.
Merci de votre attention et au revoir.
