Developpez.com
Accueil
Vous avez sans doute, comme moi, utilisé l’outil de performance livré depuis la version 2005 de SQL Server et qui se nomme DTA (Database Tuning Advisor). Chez mon client actuel qui possède une base de données volumineuse en nombre d’objets (environ 15 000 entre les tables, les vues, les index et les statistiques) nous avons rencontré un problème quant à l’utilisation de cet outil en mode console.
Dans le cadre de la gestion des incidents et de la gestion de la capacité d’un service informatique, il peut être intéressant de définir des alertes de fonctionnement de SQL Server et de son environnement pour anticiper d’éventuels problèmes de fonctionnement. En effet, rien n’est plus désagréable pour une équipe de production par exemple d’être mis au courant par un utilisateur qu’un de ses serveurs est en panne ou que le système d’information ne fonctionne pas. La qualité de service de cette équipe s’en retrouverait affectée.
Récemment un internaute s’est étonné de voir que lorsqu’il réalisait une opération de réduction de fichier à l’aide de la commande DBCC SHRINFILE après une sauvegarde du journal des transactions, celui-ci ne se réduisait pas à la 1ère tentative. Une seconde opération de journal était nécessaire avant de pouvoir réduire le fichier à la taille désirée. Quelle en est la cause ? Nous allons pouvoir y répondre en utilisation la commande DBCC LOGINFO.
Une des problématiques que rencontre mon client lors de releases de son application principale est de s’assurer qu’aucun utilisateur ne soit connecté pendant la fenêtre de mise à jour de ces bases de données ceci afin de garantir qu’aucune perturbation ne soit créée pendant l’application de ces mises à jour. L’utilisation des points de terminaison ou ENDPOINT de SQL Server peut s’avérer bien utile dans ce cas.
Ce billet est purement informatif. Je vous propose de vous expliquer brièvement la la façon dont le moteur SQL alloue les pages de données lors d’une insertion d’enregistrements dans une table. Comme vous le savez sans doute une base de données est une collection de pages de 8 Ko réparties sur un ou plusieurs fichiers physiques. Une page peut donc contenir plusieurs lignes d’une table selon le cas . Les commandes DBCC EXTENTINFO et sp_spacused nous aideront à comprendre ce mécanisme d’allocation.
Il y a quelques temps mon client m’a demandé de réfléchir à un template générique d’installation pour SQL Server 2005 pour une équipe non DBA en charge du déploiement sur un certain nombre de serveurs. Dès lors, 2 solutions s’offraient à nous : Créer une documentation d’installation détaillée avec copie d’écran ou installer SQL Server 2005 par script automatique. Cette 2ème solution permettrait de réduire considérablement la documentation à fournir et minimiserait le temps d’installation pour l’équipe de déploiement.
Il y a quelques jours, j’ai eu à faire face à un problème d’occupation CPU élevé sur un des serveurs SQL du client chez lequel je me trouve. Après quelques investigations, je me suis posé la question suivante : Est ce que le serveur utilise le parallélisme et comment savoir quels lots de requêtes a recours à un traitement en parallèle ?
Aujourd’hui j’ai eu une discussion avec un de mes collaborateurs de travail au sujet du mécanisme AWE et des architectures 64 bits SQL Server. Celui-ci me disait que AWE n’était pas nécessaire dans ce cas alors que ce mécanisme peut tout à fait être implémenté sur des architectures 64 bits. Voyons pourquoi.
Pour mon 1er billet, je vais vous faire part d’une discussion intéressante que j’ai eu avec un de mes responsables de travail concernant la parallélisation des requêtes sur SQL Server. En effet les premiers temps où je suis arrivé dans l’entreprise, on m’a présenté l’infrastructure informatique et un des serveurs sur lequel j’allais exercer mes fonctions de DBA.
Ce serveur a des caractéristiques plutôt intéressantes. (2 Processeurs Intel Xeon 2 quadricoeur 2,33GHz avec 8 Go de RAM et un peu plus de 1 Téra Octets d’espace disque pour héberger les données avec une version SQL Server 2005 Entreprise Edition). Ce serveur héberge 16 bases de données qui fonctionnent toutes en environnement OLTP et où l’activité transactionnelle est plutôt soutenue.
Cependant mon responsable a été surpris quand je lui ai annoncé qu’il était bien souvent inutile de laisser la parallélisation activée dans ce genre d’environnement et qu’à l’inverse on risquait de perdre en performance. Il a fallu bien évidemment le lui prouver.
© 2000-2020 - www.developpez.com
Partenaire : Hébergement Web
