In diesem Artikel gehen wir auf Fehler von DBAs ein, deren Folgen durchaus spürbar waren und mit denen ich mich auseinandersetzen musste.
Der Zweck des Artikels besteht darin, Benutzer daran zu hindern, diese Fehler zu wiederholen. Manchmal ist eine schlechte Erfahrung sogar noch wertvoller als eine positive.
- Prozenterhöhung von Datenbankdateien
Da das Dateiwachstum der Datenbank eine ziemlich ressourcenintensive Operation ist, scheint es eine gute Idee zu sein, dieses Wachstum in prozentualen Verhältnissen festzulegen. Ich stimme zu, dass viele Richtlinien empfehlen, ein festes Inkrement in MB und nicht in Prozent festzulegen. Sie erklären jedoch nicht die Gründe. Aus der Praxis heraus wird es nicht empfohlen, das Inkrement einer Datenbankdatei auf über 1 GB einzustellen, da MS SQL Server 1 GB 2 Mal anstelle von 2 GB auf einmal zuweist.
Auch wenn Sie weniger als 32 MB zuweisen , früher oder später wird die Datenbank einfach langsamer. Daher ist es besser, eine feste Schrittweite für Datenbankdateien von 32 bis 1024 MB festzulegen. Warum ist es jedoch nicht möglich, das Inkrement von Datenbankdateien in Prozent anzugeben? Es stellt sich heraus, dass das DBMS, sobald die Datei kleiner als 1 MB ist, diesen Wert auf 0 MB rundet und diese Datei nicht mehr vergrößert. Infolgedessen ist das System heruntergefahren. Um herauszufinden, um wie viel wir die Datei vergrößern müssen, führen Sie einfach eine tägliche Analyse durch, um zu überprüfen, wie viel jede Datei in MB gewinnt, und stellen Sie die entsprechende Zahl im Bereich von 32 bis 1024 MB ein. Wir können Statistiken über das Wachstum von Datenbankdateien auf folgende Weise sammeln. - Es gibt viele Fremdschlüssel für eine Tabelle
Haben Sie jemals versucht, den Plan zu überprüfen, wenn Sie mindestens eine Zeile aus einer Tabelle löschen, auf die von fast Hunderten anderer Tabellen verwiesen wird? Sie werden überrascht sein, wie viele verschachtelte Schleifen es gibt. Alle von ihnen sind Fremdschlüsselprüfungen. Aus diesem Grund ist es bei großen Tabellen (mehr als eine Million Datensätze) besser, Fremdschlüssel für eine Tabelle zu deaktivieren, in der Daten gelöscht werden. Dann müssen Sie alle erforderlichen und zugehörigen Daten löschen. Aktivieren Sie danach Fremdschlüssel. Eine ähnliche Situation tritt bei kaskadierenden Aktualisierungen und Löschungen auf. Bei vielen externen Links (Hunderte) kann das Löschen auch nur einer Zeile zu einer langen und sehr umfangreichen Sperrung führen. - Viele unnötige Indizes
Sehr oft sieht man in Richtlinien, dass beim Erstellen von Fremdschlüsseln Indizes erstellt werden müssen, insbesondere wenn diese Schlüssel für Joins verwendet werden. Sie müssen überprüfen, ob Indizes verwendet werden, andernfalls verlangsamen diese unnötigen Indizes nur alle Datenänderungsvorgänge. Um dies zu überprüfen, verwenden Sie die folgende Abfrage: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
- Ineffiziente Nutzung von Ressourcen
Es wird häufig empfohlen, das Transaktionsprotokoll und die Datenbankdatei auf verschiedenen Speichergeräten zu speichern. Wenn Sie RAID 10 mit 4 und mehr SSD-Festplatten verwenden, macht es keinen Sinn, Dateien voneinander zu isolieren. Für eine höhere Geschwindigkeit kann die tempdb-Datenbank bei Bedarf auf einer Festplatte gespeichert werden, die vom RAM getrennt ist. Außerdem führt eine zu große Menge an RAM, die dem DBMS zur Verfügung gestellt wird, dazu, dass letzteres den gesamten Speicher mit irrelevanten Abfrageplänen füllt. - Schlechte Backups
Es ist immer notwendig, die erstellten Backups nicht nur zu überprüfen, sondern auch auf einen Prüfstand zu verschieben und wiederherzustellen. All dies muss mit weiteren Benachrichtigungen an Administratoren über problematische und erfolgreiche Wiederherstellungen automatisiert werden. - Schlechte Fehlertoleranz
Bevor Sie einen Cluster aus zwei oder mehr Servern erstellen, müssen Sie sicherstellen, dass das Datenspeichersystem auch ausfalltolerant ist. Fällt letzteres aus, wird die gesamte Fehlertoleranz auf null reduziert. - Kompliziert Diagnose ohne einfache Überprüfung
Wenn es zu einem Systemausfall kommt, müssen Sie zuerst die MS SQL Server-Protokolle überprüfen und dann tiefer graben. Sie sollten zunächst einfache Überprüfungen durchführen und dann zu einer komplexen Diagnose übergehen. - Verlorene Tische
Tabellen können mit unnötigen Daten erweitert werden, die in einer separaten Datenbank archiviert oder gelöscht werden müssen. Außerdem dürfen die Tische nicht mehr verwendet werden.
Das sind die Situationen, auf die ich gestoßen bin. Daher möchte ich empfehlen, die oben genannten Fehler nicht zu wiederholen.
Möchten Sie Ihre Erfahrungen oder solche Fehler bei der Verwaltung von Datenbanken teilen, lassen Sie es mich gerne wissen – ich bespreche sie gerne.
