sql >> Database teknologi >  >> RDS >> Sqlserver

Almindelige fejl i DBA i MS SQL Server

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.

  1. 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.
  2. 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.
  3. 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

  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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.


  1. Sådan konverteres store bogstaver til små bogstaver i MySQL

  2. HubSpot ODBC-driver

  3. Gør et stykke tid / loop for at få 10 tilfældige resultater

  4. Gå med SQL Server-driveren kan ikke oprette forbindelse, login mislykkes