Microsoft heeft tegenwoordig niet de gewoonte om dingen af te schaffen, maar als ze dat doen, is dat met een reden - en het is zeker niet omdat ze je leven moeilijker willen maken. Integendeel, het is bijna altijd omdat ze betere en modernere manieren hebben ontwikkeld om diezelfde problemen op te lossen.
Maar gewoonten zijn moeilijk te doorbreken; vraag me hoe ik dat weet. Maar al te vaak zie ik mensen vasthouden aan een oudere manier om een taak te volbrengen, ook al bestaat er een betere manier.
Ik wil graag een paar recente voorbeelden met u delen die illustreren hoe het gebruik van verouderde SQL Server-functies ons blijft bijten. In dit eerste deel wil ik het hebben over...
sysprocesses
De systeemtabel sys.sysprocesses werd lang geleden in SQL Server 2005 vervangen door een reeks dynamische beheerweergaven (DMV's), met name sys.dm_exec_requests , sys.dm_exec_sessions , en sys.dm_exec_connections . De officiële documentatie voor sys.sysprocesses waarschuwt:
Een recent voorbeeld
Onlangs onderzocht een van onze teams een latentieprobleem met loglezers. We besteden hier veel aandacht aan latentie, samen met eventuele langlopende transacties, vanwege de downstream-impact op technologieën die de logreader gebruiken, zoals beschikbaarheidsgroepen en transactiereplicatie. Onze eerste waarschuwingen worden meestal opgemerkt op een dashboard dat de latentie van de lezer in kaart brengt tegen de transactieduur (ik zal de tijdstippen uitleggen die ik t0 en t1 binnenkort):
Ze bepaalden, laten we zeggen op tijd t0 , dat een bepaalde sessie een open transactie had die het loglezerproces blokkeerde. Ze controleerden eerst de uitvoer van DBCC INPUTBUFFER , om te proberen te bepalen wat deze sessie deed, maar de resultaten gaven eenvoudig aan dat ze tijdens hun transactie ook andere batches hebben uitgegeven:
event_type parameters event_info -------------- ---------- --------------- Language Event 0 SET ROWCOUNT 0;
Merk op dat DBCC INPUTBUFFER heeft ook een meer capabele vervanging in moderne versies:sys.dm_exec_input_buffer . En hoewel er geen expliciete waarschuwing voor beëindiging is, is de officiële documentatie voor de DBCC commando heeft dit zachte duwtje:
Nadat ze niets uit de invoerbuffer hadden gekregen, vroegen ze sys.sysprocesses :
SELECT spid, [status], open_tran, waittime, [cpu], physical_io, memusage, last_batch FROM sys.sysprocesses WHERE spid = 107;
De resultaten waren even nutteloos, althans om te bepalen wat de sessie had gedaan om hun transactie open te houden en de loglezer te verstoren:
Ik markeer de physical_io kolom omdat deze waarde een discussie op gang bracht over het al dan niet riskeren van het beëindigen van de slaapsessie. De gedachte was dat, in het geval dat al die fysieke I/O's schrijfbewerkingen zijn, het beëindigen van de transactie zou kunnen resulteren in een langdurige en ontwrichtende rollback, waardoor het probleem mogelijk nog erger wordt. Ik ga hier geen werkelijke tijden op plakken, maar laten we zeggen dat dit een langdurig gesprek is geworden en het systeem vanaf tijd t0 naar tijd t1 in de bovenstaande grafiek.
Waarom dit een probleem is
Het probleem in dit specifieke geval is dat ze die tijd hebben besteed aan het nadenken over een beslissing op basis van onvolledige informatie. Zijn die I/O's lezen of schrijven? Als de gebruiker een openstaande transactie heeft en alleen maar veel gegevens heeft gelezen, heeft het terugdraaien van die transactie veel minder impact dan wanneer ze veranderd zijn geweest veel gegevens. Dus in plaats van sys.sysprocesses , laten we eens kijken wat de modernere DMV, sys.dm_exec_sessions , kan ons over deze sessie laten zien:
SELECT session_id, [status], open_transaction_count, cpu_time, [reads], writes, logical_reads, last_request_start_time, last_request_end_time FROM sys.dm_exec_sessions WHERE session_id = 107;
Resultaten:
Hier zien we dat sys.dm_exec_sessions verdeelt de fysieke I/O afzonderlijk in lezen en schrijven. Hierdoor kunnen we een veel beter geïnformeerde beslissing nemen, veel sneller dan t1 - t0 , over de impact van een mogelijke terugdraaiing. Als de I/O allemaal schrijft, en afhankelijk van hoe hoog het aantal is, kunnen we wat meer aarzelen en misschien de tijd besteden aan het proberen de gebruiker te lokaliseren (zodat we op hun knokkels kunnen slaan of hen kunnen vragen waarom ze een open transactie hebben ). Als we weten dat het meestal gelezen wordt, kunnen we in plaats daarvan leunen op het beëindigen van de sessie en het dwingen van de transactie om terug te draaien.
Natuurlijk, sys.sysprocesses heeft dbid en waittime . Maar dbid is onbetrouwbaar en sowieso marginaal nuttig, vooral voor query's tussen databases; er is veel betere info in sys.dm_tran_locks . Wachtinformatie (tijd en laatste wachttype) is te vinden in sys.dm_exec_requests , maar veel meer gedetailleerde informatie wordt aangeboden in sys.dm_exec_session_wait_stats (toegevoegd in SQL Server 2016). Een excuus dat ik vaak hoorde, was dat sys.dm_exec_sessions ontbrak open_tran , maar open_transaction_count is weer toegevoegd in SQL Server 2012. Er is dus weinig reden om zelfs maar na te denken over het gebruik van sys.sysprocesses vandaag.
Als je wilt weten hoe vaak sys.sysprocesses waarnaar wordt verwezen sinds SQL Server voor het laatst opnieuw is opgestart, kunt u deze query uitvoeren op de prestatiemeteritems DMV:
SELECT instance_name, cntr_value
FROM sys.dm_os_performance_counters
WHERE [object_name] LIKE N'%:Deprecated Features%'
AND instance_name = N'sysprocesses'
ORDER BY cntr_value DESC;
Als je vannacht echt niet wilt slapen, of als je gewoon constant dingen wilt toevoegen aan de waslijst waar je je zorgen over maakt, verwijder dan het predikaat tegen instance_name . Dit geeft je een angstaanjagend idee op hoog niveau van hoeveel dingen je instanties draaien die je uiteindelijk moet veranderen.
Download in de tussentijd sp_WhoIsActive , de uiterst nuttige opgeslagen procedure van Adam Machanic voor het in realtime bewaken en oplossen van problemen met SQL Server-processen. We hebben deze opgeslagen procedure op elke instantie in onze omgeving geïmplementeerd, en dat zou u ook moeten doen, ongeacht welke andere geavanceerde monitoringtools u ook gebruikt.
Volgende keer
In deel 2 ga ik het hebben over SQL Server Profiler, een applicatie die mensen meer gebruiken vanwege hun vertrouwdheid dan wat dan ook - zonder te beseffen hoe gevaarlijk het kan zijn.