In dit artikel gaan we de fouten van DBA's bekijken, waarvan de gevolgen vrij waarneembaar waren en waarmee ik te maken had.
Het doel van het artikel is om te voorkomen dat gebruikers deze fouten herhalen. Soms is een slechte ervaring zelfs waardevoller dan een positieve.
- Percentage toename van databasebestanden
Aangezien de bestandsgroei van de database een behoorlijk arbeidsintensieve operatie is, lijkt het misschien een goed idee om deze groei in procentuele verhoudingen in te stellen. Ik ben het ermee eens dat veel richtlijnen aanbevelen om een vaste toename in MB in te stellen in plaats van een percentage. Ze geven echter geen verklaring voor de redenen. Op basis van de praktijk wordt het niet aanbevolen om de toename van een databasebestand in te stellen op meer dan 1 GB, aangezien MS SQL Server 2 keer 1 GB toewijst in plaats van 2 GB tegelijk.
Ook als u minder dan 32 MB toewijst , vroeg of laat zal de database gewoon vertragen. Het is dus beter om een vaste verhoging in te stellen voor databasebestanden van 32 tot 1024 MB. Waarom is het echter onmogelijk om de toename van databasebestanden als een percentage op te geven? Het blijkt dat zodra het bestand kleiner is dan 1 MB, de DBMS deze waarde afrondt naar 0 MB en stopt met het vergroten van dit bestand. Als gevolg hiervan ligt het systeem plat. Om erachter te komen hoeveel we nodig hebben om het bestand te vergroten, voert u eenvoudig een dagelijkse analyse uit om te controleren hoeveel elk bestand in MB toeneemt en stelt u het juiste aantal in tussen 32 en 1024 MB. We kunnen op de volgende manier statistieken verzamelen over de groei van databasebestanden. - Er zijn veel buitenlandse sleutels voor een tabel
Heb je ooit geprobeerd het plan te controleren bij het verwijderen van ten minste één rij uit een tabel waarnaar wordt verwezen door bijna honderden andere tabellen? Het zal je verbazen hoeveel geneste lussen er zijn. Het zijn allemaal buitenlandse sleutelcontroles. Dat is de reden waarom als tabellen groot zijn (meer dan een miljoen records), het beter is om externe sleutels uit te schakelen voor een tabel waarin gegevens worden verwijderd. Vervolgens moet u alle benodigde en gerelateerde gegevens verwijderen. Schakel daarna externe sleutels in. Een vergelijkbare situatie doet zich voor bij trapsgewijze updates en verwijderingen. Als er veel externe links zijn (honderden), kan het verwijderen van zelfs één rij al leiden tot een lange en zeer uitgebreide blokkering. - Veel onnodige indexen
Heel vaak kun je in richtlijnen zien dat het bij het maken van externe sleutels noodzakelijk is om indexen te bouwen, vooral wanneer deze sleutels voor joins worden gebruikt. U moet controleren of er indexen worden gebruikt, anders zullen deze onnodige indexen de bewerkingen voor het wijzigen van gegevens alleen maar vertragen. Gebruik de volgende vraag om dit te controleren: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
- Inefficiënt gebruik van middelen
Het wordt vaak aanbevolen om het transactielogboek en het databasebestand op verschillende opslagapparaten op te slaan. Gebruik je RAID 10 met 4 of meer SSD-schijven, dan heeft het geen zin om bestanden van elkaar te isoleren. Voor een hogere snelheid kan, indien nodig, de tempdb-database worden opgeslagen op een schijf die is gesplitst van RAM. Ook zullen te grote hoeveelheden RAM die aan DBMS worden geleverd, ervoor zorgen dat de laatste het hele geheugen vult met irrelevante queryplannen. - Slechte back-ups
Het is altijd nodig om niet alleen de gemaakte back-ups te controleren, maar ook om ze op een proefbank te verplaatsen en te herstellen. Dit alles moet worden geautomatiseerd met verdere kennisgeving aan beheerders van zowel problematische als succesvolle herstelacties. - Slechte fouttolerantie
Voordat u een cluster van twee of meer servers maakt, moet u ervoor zorgen dat het gegevensopslagsysteem ook fouttolerant is. Als de laatste faalt, wordt de volledige faaltolerantie teruggebracht tot nul. - Ingewikkeld diagnose zonder eenvoudige controles
Als er een systeemuitval is, moet u eerst de MS SQL Server-logboeken controleren en vervolgens dieper graven. U moet eerst eenvoudige controles uitvoeren en vervolgens overgaan tot een complexe diagnose. - Tafels kwijt
Tabellen kunnen worden uitgebreid met onnodige gegevens die in een aparte database moeten worden gearchiveerd of verwijderd. Daarnaast mogen de tabellen niet meer gebruikt worden.
Dit zijn de situaties die ik ben tegengekomen. Daarom zou ik willen aanraden de bovenstaande fouten niet te herhalen.
Wilt u uw ervaring of dergelijke fouten bij het beheren van databases delen, laat het me dan gerust weten - ik zal ze graag bespreken.