I denne artikel skal vi gennemgå DBAs fejl, hvis konsekvenser var ret mærkbare, og som jeg var nødt til at forholde mig til.
Formålet med artiklen er at forhindre brugere i at gentage disse fejl. Nogle gange er en dårlig oplevelse endnu mere værdifuld end en positiv.
- Procent stigning af databasefiler
Da filvæksten i databasen er ret ressourcekrævende, kan det se ud til, at det kan være en god idé at indstille denne vækst i procent. Jeg er enig i, at mange retningslinjer anbefaler at indstille en fast stigning i MB i stedet for i procent. De forklarer dog ikke årsagerne. Baseret på praksis anbefales det ikke at indstille stigningen af en databasefil over 1 GB, da MS SQL Server vil allokere 1 GB 2 gange i stedet for 2 GB på én gang.
Hvis du også allokerer mindre end 32 MB , før eller siden vil databasen simpelthen blive langsommere. Så det er bedre at indstille en fast stigning på databasefiler fra 32 til 1024 MB. Men hvorfor er det umuligt at angive stigningen i databasefiler som en procentdel? Det viser sig, at så snart filen er mindre end 1 MB, runder DBMS denne værdi af til 0 MB og stopper med at øge denne fil. Som et resultat er systemet nede. For at finde ud af, hvor meget vi skal øge filen, skal du blot udføre en daglig analyse for at kontrollere, hvor meget hver fil vinder i MB og indstille det passende tal i området fra 32 til 1024 MB. Vi kan indsamle statistik om væksten af databasefiler på følgende måde. - Der er mange fremmednøgler til et bord
Har du nogensinde prøvet at tjekke planen, når du sletter mindst én række fra en tabel, der henvises til af næsten hundredvis af andre tabeller? Du vil blive overrasket over at vide, hvor mange indlejrede løkker der er. Alle af dem er udenlandsk nøglekontrol. Det er derfor, hvis tabeller er store (over en million poster), er det bedre at deaktivere fremmednøgler for en tabel, hvor data vil blive slettet. Derefter bliver du nødt til at slette alle nødvendige og relaterede data. Aktivér derefter fremmednøgler. En lignende situation opstår med cascading opdateringer og sletninger. Hvis der er mange eksterne links (hundredevis), kan sletning af blot én række føre til en lang og meget omfattende blokering. - Mange unødvendige indekser
Meget ofte kan du se i retningslinjer, at når du opretter fremmednøgler, er det nødvendigt at bygge indekser, især når du bruger disse nøgler til joins. Du skal kontrollere, at indekser bruges, ellers vil disse unødvendige indekser kun bremse enhver dataændringsoperation. For at kontrollere dette, brug følgende forespørgsel: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 brug af ressourcer
Det anbefales ofte at gemme transaktionsloggen og databasefilen på forskellige lagerenheder. Hvis du bruger RAID 10 med 4 eller flere SSD-diske, så er der ingen mening i at isolere filer fra hinanden. For en højere hastighed kan tempdb-databasen om nødvendigt gemmes på en disk, der er opdelt fra RAM. Også for store mængder RAM, der leveres til DBMS, vil få sidstnævnte til at fylde hele hukommelsen med irrelevante forespørgselsplaner. - Dårlige sikkerhedskopier
Det er altid nødvendigt ikke kun at kontrollere de oprettede sikkerhedskopier, men også at flytte dem på en teststand og gendanne dem. Alt dette skal automatiseres med yderligere meddelelse til administratorer om både problematiske og vellykkede gendannelser. - Dårlig fejltolerance
Før du laver en klynge af to eller flere servere, skal du sikre dig, at datalagringssystemet også er fejltolerant. Hvis sidstnævnte fejler, vil hele fejltolerancen blive reduceret til nul. - Kompliceret diagnostik uden simple kontroller
Hvis der er nedetid i systemet, skal du først tjekke MS SQL Server-logfiler og derefter grave dybere. Du bør først udføre enkle kontroller og derefter gå videre til en kompleks diagnostik. - Tabte borde
Tabeller kan udvides med unødvendige data, som skal arkiveres i en separat database eller slettes. Derudover må tabellerne ikke længere bruges.
Det er de situationer, jeg er stødt på. Derfor vil jeg gerne anbefale ikke at gentage ovenstående fejl.
Kunne du tænke dig at dele dine erfaringer eller sådanne fejl, når du administrerer databaser, er du velkommen til at fortælle mig det - jeg vil med glæde diskutere dem.