Dans cet article, nous allons passer en revue les erreurs des DBA dont les conséquences étaient assez perceptibles et auxquelles j'ai dû faire face.
Le but de l'article est d'empêcher les utilisateurs de répéter ces erreurs. Parfois, une mauvaise expérience est encore plus précieuse qu'une bonne.
- Pourcentage d'incrémentation des fichiers de base de données
Étant donné que la croissance des fichiers de la base de données est une opération assez gourmande en ressources, il peut sembler que définir cette croissance en pourcentage peut être une bonne idée. Je suis d'accord que de nombreuses directives recommandent de définir un incrément fixe en Mo, plutôt qu'un pourcentage. Cependant, ils n'en expliquent pas les raisons. En pratique, il n'est pas recommandé de définir l'incrément d'un fichier de base de données au-dessus de 1 Go, car MS SQL Server allouera 1 Go 2 fois au lieu de 2 Go à la fois.
De plus, si vous allouez moins de 32 Mo , tôt ou tard la base de données ralentira tout simplement. Il est donc préférable de définir un incrément fixe sur les fichiers de base de données de 32 à 1024 Mo. Cependant, pourquoi est-il impossible de spécifier l'incrément des fichiers de base de données en pourcentage ? Il s'avère que dès que le fichier est inférieur à 1 Mo, le SGBD arrondit cette valeur à 0 Mo et arrête d'augmenter ce fichier. En conséquence, le système est en panne. Pour savoir combien nous devons augmenter le fichier, effectuez simplement une analyse quotidienne afin de vérifier combien chaque fichier gagne en Mo et définissez le nombre approprié dans la plage de 32 à 1024 Mo. Nous pouvons collecter des statistiques sur la croissance des fichiers de base de données de la manière suivante. - Il existe de nombreuses clés étrangères pour une table
Avez-vous déjà essayé de vérifier le plan lors de la suppression d'au moins une ligne d'une table référencée par des centaines d'autres tables ? Vous serez surpris de savoir combien de boucles imbriquées il y a. Tous sont des contrôles de clé étrangère. C'est pourquoi si les tables sont volumineuses (plus d'un million d'enregistrements), il est préférable de désactiver les clés étrangères pour une table dans laquelle les données seront supprimées. Ensuite, vous devrez supprimer toutes les données nécessaires et connexes. Après cela, activez les clés étrangères. Une situation similaire se produit avec des mises à jour et des suppressions en cascade. S'il y a beaucoup de liens externes (des centaines), la suppression d'une seule ligne peut entraîner un blocage long et très étendu. - Beaucoup d'index inutiles
Très souvent, vous pouvez voir dans les directives que lors de la création de clés étrangères, il est nécessaire de construire des index, en particulier lors de l'utilisation de ces clés pour les jointures. Vous devez vérifier que des index sont utilisés, sinon ces index inutiles ne feront que ralentir les opérations de modification des données. Pour vérifier cela, utilisez la requête suivante :select DB_NAME(t.database_id) as [DBName] , SCHEMA_NAME(obj.schema_id) as [SchemaName] , OBJECT_NAME(t.object_id) as [ObjectName] , obj.Type as [ObjectType] , obj.Type_Desc as [ObjectTypeDesc] , ind.name as [IndexName] , ind.Type as IndexType , ind.Type_Desc as IndexTypeDesc , ind.Is_Unique as IndexIsUnique , ind.is_primary_key as IndexIsPK , ind.is_unique_constraint as IndexIsUniqueConstraint , t.[Database_ID] , t.[Object_ID] , t.[Index_ID] , t.Last_User_Seek , t.Last_User_Scan , t.Last_User_Lookup , t.Last_System_Seek , t.Last_System_Scan , t.Last_System_Lookup from sys.dm_db_index_usage_stats as t inner join sys.objects as obj on t.[object_id]=obj.[object_id] inner join sys.indexes as ind on t.[object_id]=ind.[object_id] and t.index_id=ind.index_id where (last_user_seek is null or last_user_seek <dateadd(year,-1,getdate())) and (last_user_scan is null or last_user_scan <dateadd(year,-1,getdate())) and (last_user_lookup is null or last_user_lookup <dateadd(year,-1,getdate())) and (last_system_seek is null or last_system_seek <dateadd(year,-1,getdate())) and (last_system_scan is null or last_system_scan <dateadd(year,-1,getdate())) and (last_system_lookup is null or last_system_lookup <dateadd(year,-1,getdate())) and t.database_id>4 and t.[object_id]>0 -- system databases are excluded
- Utilisation inefficace des ressources
Il est souvent recommandé de stocker le journal des transactions et le fichier de base de données sur des périphériques de stockage différents. Si vous utilisez RAID 10 avec 4 disques SSD et plus, il n'y a aucun sens à isoler les fichiers les uns des autres. Pour une vitesse plus élevée, si nécessaire, la base de données tempdb peut être stockée sur un disque séparé de la RAM. De plus, une trop grande quantité de RAM fournie au SGBD obligera ce dernier à remplir toute la mémoire avec des plans de requête non pertinents. - Mauvaises sauvegardes
Il faut toujours non seulement vérifier les sauvegardes créées mais aussi les déplacer sur un banc d'essai et les restaurer. Tout cela doit être automatisé avec une notification supplémentaire aux administrateurs des récupérations problématiques et réussies. - Mauvaise tolérance aux pannes
Avant de créer un cluster de deux serveurs ou plus, vous devez vous assurer que le système de stockage de données est également tolérant aux pannes. Si ce dernier échoue, la totalité de la tolérance d'échec sera réduite à zéro. - Compliqué diagnostic sans simples vérifications
S'il y a un temps d'arrêt du système, vous devez d'abord vérifier les journaux MS SQL Server, puis creuser plus profondément. Vous devez d'abord effectuer des vérifications simples, puis procéder à un diagnostic complexe. - Tables perdues
Les tables peuvent être étendues avec des données inutiles qui doivent être archivées dans une base de données séparée ou supprimées. De plus, les tables ne peuvent plus être utilisées.
Ce sont les situations que j'ai rencontrées. Par conséquent, je voudrais recommander de ne pas répéter les erreurs ci-dessus.
Souhaitez-vous partager votre expérience ou de telles erreurs lors de l'administration de bases de données, n'hésitez pas à me le faire savoir - je serai heureux d'en discuter.
