L'outil d'analyse des meilleures pratiques pour Microsoft SQL Server 2000 est un outil de gestion de base de données développé par l'équipe de développement de Microsoft SQL Server qui vous permet de détecter si la base de données conçue suit les directives des meilleures pratiques pour le fonctionnement et la gestion de SQL Server. Ces directives sont reconnues pour contribuer à améliorer les performances et l’efficacité des bases de données et à faciliter la maintenance des applications.
2. Commencez à utiliser SQL BPA Best Practices Analyzer
Une fois l'installation terminée, il y aura un document Word du guide de l'utilisateur de SQL Server Best Practices Analyzer. Comment l'utiliser est clairement expliqué. Les étapes de base sont les suivantes :
(1) Journal. dans SQL BPA
(2) Ajouter une analyse / Instance SQL Server détectée
Vous devez saisir ici le nom convivial de l'instance qui est utilisé pour l'associer au groupe de meilleures pratiques créé ultérieurement (il suffit de le conserver identique au nom de l'instance SQL Server). ). La valeur par défaut de Database List est *, ce qui signifie qu'elle contient toutes les bases de données de l'instance SQL Server actuelle. Cependant, BPA ignorera la détection des bases de données telles que « master », « tempdb », « msdb », « pubs » et « northwind ».
(3) Pour gérer les groupes de bonnes pratiques,
vous devez d'abord créer un groupe de bonnes pratiques, qui combine en fait certaines règles et l'associe à l'instance SQL Server saisie précédemment.
(4) Analysez l'instance SQL Server
et déplacez le groupe de meilleures pratiques précédemment créé vers la liste Groupes de meilleures pratiques à exécuter, afin qu'il puisse être exécuté conformément aux règles précédemment définies et générer un rapport pour fournir des suggestions et des lignes directrices d'amélioration.
3. Je pense que les règles incluses dans SQL BPA v1.0
sont le point clé, car ce n'est qu'en comprenant ces directives de bonnes pratiques pour le fonctionnement et la gestion de SQL Server que nous pouvons essayer de suivre ces règles lors de la conception de bases de données et de l'écriture de scripts T-SQL. améliorer les performances et l'efficacité de SQL Server et des applications.
En fait, toutes les règles sont ici (version anglaise) file:///C:/Program%20Files/Microsoft%20SQL%20Server%20Best%20Practices%20Analyzer/html/RuleInformation.html#_Rule:_Explicit_Index_Creation Veuillez noter que je . use SQL BPA est installé dans le chemin par défaut. Si vous modifiez le chemin d'installation, il ne sera pas ici.
Voici quelques règles qui m'intéressent :
(1)
Règles de conception de base de données : tables sans clés primaires ni contraintes uniques.
Vérifiez la base de données pour vous assurer que toutes les tables ont une clé primaire définie ou qu'une colonne a une contrainte unique définie.
Règle : User Object Naming (dénomination des objets utilisateur)
détecte les objets utilisateur nommés avec le préfixe sp_, xp_ ou fn_ pour éviter les conflits de noms avec les objets intégrés de SQL Server. Si SQL Server détecte que la procédure stockée porte le préfixe sp_, il interrogera d'abord la procédure stockée dans la base de données master, ce qui affecte les performances.
Par conséquent, les directives suivantes doivent être suivies :
N'utilisez pas le préfixe sp_ pour nommer des procédures stockées définies par l'utilisateur ;
n'utilisez pas le
préfixe xp_ pour nommer des procédures stockées étendues définies par l'utilisateur ;
.
En fait, vous pouvez le nommer en utilisant des préfixes tels que usp_, uxp_ ou ufn_, et u signifie défini par l'utilisateur.
(2)
Règle
T-SQL
: la liste de colonnes du curseur FOR UPDATEdétecte la clause FOR UPDATE dans les procédures stockées, les fonctions, les vues et les déclencheurs. Lorsqu'un curseur définit une clause FOR UPDATE, il est recommandé de fournir des colonnes de colonnes explicites. FOR UPDATE est utilisé pour définir des colonnes actualisables dans le curseur. Si OF column_name est fourni, seules les colonnes répertoriées peuvent être modifiées. Si aucune liste de colonnes n'est spécifiée, toutes les colonnes peuvent être mises à jour sauf si l'option de concurrence READ_ONLY est spécifiée. SQL Server peut optimiser les opérations en fonction des colonnes spécifiées.
Règle : L'utilisation du curseur
vérifie si la possibilité de mise à jour du curseur est correctement définie dans les procédures stockées, les fonctions, les vues et les déclencheurs. Un échec sera signalé dans les situations suivantes :
lorsqu'un curseur ne définit pas la clause FOR UPDATE, mais est mis à jour via le curseur ;
lorsqu'un curseur définit la clause FOR UPDATE, mais n'est pas mis à jour via le curseur ;
Cependant, nous essayons généralement d'éviter d'utiliser le curseur côté serveur, car il consomme des ressources mémoire du serveur et affecte les performances de SQL Server. Des requêtes imbriquées ou des instructions WHILE peuvent être utilisées à la place du curseur. Même si vous utilisez le curseur, vous devez faire attention à définir certaines options du curseur, telles que FAST_FORWARD.
Règle : Création explicite d'index
Il est recommandé d'utiliser CLUSTERED ou NONCLUSTERED pour créer explicitement l'index.
Règle : INSERT Column List
nécessite que lors de l'utilisation de INSERT, la liste de colonnes soit fournie explicitement pour améliorer la maintenabilité du code.
Règle : La configuration des déclencheurs imbriqués
détecte les déclencheurs qui ne sont pas déclenchés en raison de problèmes de configuration avec les déclencheurs imbriqués. Celui-ci est relativement rare, je l'ai donc posté directement.
Lorsque l'option de configuration 'déclencheurs imbriqués' est définie sur 0, tout déclencheur AFTER défini sur les tables/vues mises à jour à l'intérieur d'un déclencheur INSTEAD OF n'est pas déclenché. Cette règle :
1) Vérifie la valeur de l'option de configuration et se termine si elle n'est pas 0.
2) Analyse tous les déclencheurs INSTEAD OF et génère une liste de tables/vues cibles de DML à partir d'un déclencheur.
3) Vérifie si l'une des cibles DML identifiées a des déclencheurs AFTER définis.
4) Signale la non-conformité de ces déclencheurs
.cas.
Règle : l'option NOCOUNT dans Triggers
détecte les déclencheurs et garantit que SET NOCOUNT ON est écrit devant les déclencheurs.
SQL Server enverra un message « terminé » après l'exécution de chaque instruction. Ces informations peuvent entraîner des conséquences inattendues pour l'application qui déclenche le déclencheur. Par conséquent, c'est une bonne habitude de conception d'ajouter SET NOCOUNT ON devant le déclencheur.
Bien entendu, il est recommandé d'ajouter SET NOCOUNT ON devant les procédures et fonctions stockées. De cette manière, le nombre de lignes affectées par l'exécution d'une série de commandes SQL ne sera pas retransmis au client, réduisant ainsi le trafic réseau et améliorant les performances.
Règle : NULL Comparisons
détecte les comparaisons d'égalité ou d'inégalité impliquant des constantes NULL dans les procédures stockées, les fonctions, les vues et les déclencheurs. Il est recommandé de définir ANSI_NULLS sur ON et d'utiliser le mot clé IS pour comparer les constantes NULL.
Règle : Résultats dans les déclencheurs
vérifie les déclencheurs pour s'assurer qu'aucune donnée n'est renvoyée à l'appelant. Par conséquent, il n'est pas recommandé d'utiliser les instructions suivantes dans les déclencheurs :
Instruction PRINT
SELECT (sans affectation ni clause INTO)
FETCH (sans affectation)
Règle : La portée des transactions
détecte la plage de transactions dans les procédures stockées et les déclencheurs. Il est recommandé que le début et la fin de la transaction se trouvent dans la même structure T-SQL.
De manière générale, essayez de réduire autant que possible la portée de la transaction pour éviter de consommer beaucoup de ressources et d'affecter les performances de SQL Server.
Règle : SELECT *
détecte l'utilisation de SELECT * dans les procédures stockées, les fonctions, les vues et les déclencheurs. Bien que SELECT * soit plus pratique, cela réduira la maintenabilité du programme. Les modifications apportées à la table ou à la vue peuvent entraîner des erreurs ou des modifications des performances.
Par conséquent, il est recommandé de spécifier explicitement la liste de champs après l'instruction SELECT.
Règle : SET Options
détecte l'utilisation des instructions SET suivantes dans les procédures stockées et les déclencheurs.
Il est recommandé de définir les options suivantes sur ON :
ANSI_NULLS
ANSI_PADDING
ANSI_WARNINGS
ARITHABORT
CONCAT_NULL_YIELDS_NULL
QUOTED_IDENTIFIER
recommande que les options suivantes soient définies sur OFF :
NUMERIC_ROUNDABOUT
Règle : Temp Table Usage
détecte l'utilisation de tables temporaires dans les procédures stockées et les déclencheurs. Lors de la création d'une table temporaire, CREATE INDEX doit être créé et une fois l'utilisation terminée, la table temporaire doit être libérée.
Étant donné que les tables temporaires généreront un grand nombre d'opérations d'E/S disque, il est recommandé d'utiliser des variables TABLE pour remplacer l'utilisation de tables temporaires.
Cependant, en raison des limites de l'exécution simultanée et de la maintenance des informations statistiques, les tables temporaires sont toujours recommandées lorsqu'une grande quantité de données est insérée dans des tables temporaires.
Règle : TOP sans ORDER BY
détecte le manque d'instructions ORDER BY TOP dans les procédures stockées, les fonctions, les vues et les déclencheurs. Lors de l'utilisation de l'instruction TOP, il est recommandé de spécifier les conditions de tri. Dans le cas contraire, les résultats produits dépendront du plan d'exécution SQL et entraîneront un comportement inattendu.
Règle : L'utilisation de tables/vues qualifiées par schéma
détecte si le propriétaire est spécifié lorsque les tables et les vues sont référencées dans des procédures stockées, des fonctions, des vues et des déclencheurs. Bien que lorsque vous référencez un objet spécifique dans SQL Server, vous n'avez pas besoin de spécifier le serveur, la base de données et le propriétaire (schéma), ce qui signifie que vous n'avez pas besoin de vous soucier de nom_serveur.nom_base de données.nom_propriétaire.***, mais SQL Server recommande que il peut être utilisé dans une procédure stockée, une fonction. Lors du référencement d'une table ou d'une vue dans une vue ou un déclencheur, il est préférable de spécifier le propriétaire de la table ou de la vue.
Lorsque SQL Server interroge un objet table/vue sans propriétaire spécifié, il interroge d'abord le propriétaire par défaut, puis dbo. Cela entraînera des coûts d'exploitation supplémentaires pour le produit SQL Server. En spécifiant le propriétaire, vous pouvez améliorer les performances de SQL Server. (Première fois que j'entends cette déclaration)
4. URL de téléchargement des documents de référence et
des outils de ressources associés :
de téléchargement vidéo :