I den här artikeln kommer vi att granska DBAs misstag, vars konsekvenser var ganska märkbara och som jag var tvungen att ta itu med.
Syftet med artikeln är att förhindra användare från att upprepa dessa misstag. Ibland är en dålig upplevelse till och med mer värdefull än en positiv.
- Procentuell ökning av databasfiler
Eftersom filtillväxten i databasen är en ganska resurskrävande operation, kan det tyckas att det kan vara en bra idé att sätta denna tillväxt i procent. Jag håller med om att många riktlinjer rekommenderar att man ställer in ett fast inkrement i MB, snarare än i procent. De förklarar dock inte orsakerna. Baserat på praxis rekommenderas det inte att ställa in ökningen av en databasfil över 1 GB, eftersom MS SQL Server kommer att allokera 1 GB 2 gånger istället för 2 GB på en gång.
Också, om du allokerar mindre än 32 MB , förr eller senare kommer databasen helt enkelt att sakta ner. Så det är bättre att ställa in en fast ökning på databasfiler från 32 till 1024 MB. Men varför är det omöjligt att ange ökningen av databasfiler i procent? Det visar sig att så fort filen är mindre än 1 MB, rundar DBMS av detta värde till 0 MB och slutar öka denna fil. Som ett resultat är systemet nere. För att ta reda på hur mycket vi behöver för att öka filen, utför helt enkelt en daglig analys för att kontrollera hur mycket varje fil ökar i MB och ställ in lämpligt antal i intervallet från 32 till 1024 MB. Vi kan samla in statistik om tillväxten av databasfiler på följande sätt. - Det finns många främmande nycklar för ett bord
Har du någonsin försökt kontrollera planen när du tar bort minst en rad från en tabell som refereras av nästan hundratals andra tabeller? Du kommer att bli förvånad över att veta hur många kapslade slingor det finns. Alla är checkar av främmande nyckel. Det är därför om tabeller är stora (över en miljon poster), är det bättre att inaktivera främmande nycklar för en tabell där data kommer att raderas. Sedan måste du radera all nödvändig och relaterade data. Efter det, aktivera främmande nycklar. En liknande situation uppstår med överlappande uppdateringar och raderingar. Om det finns många externa länkar (hundratals) kan radering av ens en rad leda till en lång och mycket omfattande blockering. - Många onödiga index
Mycket ofta kan du se i riktlinjerna att när du skapar främmande nycklar är det nödvändigt att bygga index, speciellt när du använder dessa nycklar för sammanfogningar. Du måste kontrollera att index används, annars kommer dessa onödiga index bara att sakta ner alla datamodifieringsoperationer. För att kontrollera detta, använd följande fråga: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
- Ineffektiv användning av resurser
Det rekommenderas ofta att lagra transaktionsloggen och databasfilen på olika lagringsenheter. Om du använder RAID 10 med 4 eller fler SSD-diskar, är det ingen mening med att isolera filer från varandra. För en högre hastighet, om nödvändigt, kan tempdb-databasen lagras på en disk som är delad från RAM. Dessutom kommer för stora mängder RAM-minne som tillhandahålls till DBMS att göra att DBMS fyller hela minnet med irrelevanta frågeplaner. - Dåliga säkerhetskopior
Det är alltid nödvändigt att inte bara kontrollera de skapade säkerhetskopiorna utan också att flytta dem på ett testställ och återställa dem. Allt detta måste automatiseras med ytterligare meddelande till administratörer om både problematiska och framgångsrika återställningar. - Dålig feltolerans
Innan du gör ett kluster med två eller flera servrar måste du se till att datalagringssystemet också är feltolerant. Om det senare misslyckas kommer hela feltoleransen att reduceras till noll. - Komplicerat diagnostik utan enkla kontroller
Om det finns ett systemavbrott måste du först kontrollera MS SQL Server-loggarna och sedan gräva djupare. Du bör först utföra enkla kontroller och sedan gå vidare till en komplex diagnostik. - Förlorade bord
Tabeller kan utökas med onödiga data som behöver arkiveras i en separat databas eller raderas. Dessutom får tabellerna inte längre användas.
Det är de här situationerna jag har stött på. Därför skulle jag vilja rekommendera att du inte upprepar ovanstående misstag.
Vill du dela med dig av dina erfarenheter eller sådana misstag när du administrerar databaser får du gärna meddela mig – jag diskuterar gärna dem.