Övervaka och felsöka accelererad databasåterställning
gäller för: SQL Server 2019 (15.x) och senare versioner
Azure SQL Database
Azure SQL Managed Instance
SQL-databas i Microsoft Fabric
Den här artikeln hjälper dig att övervaka, diagnostisera och lösa problem med accelererad databasåterställning (ADR) i SQL Server 2019 (15.x) och senare Azure SQL Managed Instance, Azure SQL Database och SQL Database i Microsoft Fabric.
Granska storleken på PVS
Använd sys.dm_tran_persistent_version_store_stats DMV för att identifiera om PVS-storleken (Persistent Version Store) är större än förväntat.
Följande exempeldiagnostikfråga visar information om den aktuella PVS-storleken, rensningsprocesserna och annan information i alla databaser där PVS-storleken är större än noll:
SELECT pvss.database_id,
DB_NAME(pvss.database_id) AS database_name,
pvss.persistent_version_store_size_kb / 1024. / 1024 AS persistent_version_store_size_gb,
100 * pvss.persistent_version_store_size_kb / df.total_db_size_kb AS pvs_percent_of_database_size,
df.total_db_size_kb / 1024. / 1024 AS total_db_size_gb,
pvss.online_index_version_store_size_kb / 1024. / 1024 AS online_index_version_store_size_gb,
pvss.current_aborted_transaction_count,
pvss.aborted_version_cleaner_start_time,
pvss.aborted_version_cleaner_end_time,
pvss.oldest_aborted_transaction_id,
pvss.oldest_active_transaction_id,
dt.database_transaction_begin_time AS oldest_transaction_begin_time,
asdt.session_id AS active_transaction_session_id,
asdt.elapsed_time_seconds AS active_transaction_elapsed_time_seconds,
pvss.pvs_off_row_page_skipped_low_water_mark,
pvss.pvs_off_row_page_skipped_min_useful_xts,
pvss.pvs_off_row_page_skipped_oldest_aborted_xdesid
FROM sys.dm_tran_persistent_version_store_stats AS pvss
CROSS APPLY (
SELECT SUM(size * 8.) AS total_db_size_kb
FROM sys.master_files AS mf
WHERE mf.database_id = pvss.database_id
AND
mf.state = 0
AND
mf.type = 0
) AS df
LEFT JOIN sys.dm_tran_database_transactions AS dt
ON pvss.oldest_active_transaction_id = dt.transaction_id
AND
pvss.database_id = dt.database_id
LEFT JOIN sys.dm_tran_active_snapshot_database_transactions AS asdt
ON pvss.min_transaction_timestamp = asdt.transaction_sequence_num
OR
pvss.online_index_min_transaction_timestamp = asdt.transaction_sequence_num
WHERE pvss.persistent_version_store_size_kb > 0
ORDER BY persistent_version_store_size_kb DESC;
Kontrollera kolumnen pvs_percent_of_database_size
för att se storleken på PVS i förhållande till den totala databasstorleken. Observera eventuella skillnader mellan den typiska PVS-storleken och de baslinjer som visas under typiska perioder av programaktivitet. PVS anses vara stort om det är betydligt större än baslinjen eller om det är nära 50% av databasstorleken.
Om storleken på PVS inte minskar använder du följande felsökningssteg för att hitta och lösa orsaken till den stora PVS-storleken.
Tips
Kolumner som nämns i följande felsökningssteg refererar till kolumnerna i resultatuppsättningen för diagnostikfrågan i det här avsnittet.
Stor PVS-storlek kan orsakas av någon av följande orsaker:
- långvariga aktiva transaktioner
- Långvariga aktiva ögonblicksbildsgenomsökningar
- Långvariga sökfrågor på sekundära repliker
- avbrutna transaktioner
Sök efter långvariga aktiva transaktioner
Långvariga aktiva transaktioner kan förhindra PVS-rensning i databaser som har ADR aktiverat. Kontrollera starttiden för den äldsta aktiva transaktionen med hjälp av kolumnen oldest_transaction_begin_time
. Om du vill hitta långvariga transaktioner använder du följande exempelfråga. Du kan ange tröskelvärden för transaktionsvaraktighet och mängden genererad transaktionslogg:
DECLARE @LongTxThreshold int = 900; /* The number of seconds to use as a duration threshold for long-running transactions */
DECLARE @LongTransactionLogBytes bigint = 1073741824; /* The number of bytes to use as the generated log threshold for long-running transactions */
SELECT dbtr.database_id,
DB_NAME(dbtr.database_id) AS database_name,
st.session_id,
st.transaction_id,
atr.name,
sess.login_time,
dbtr.database_transaction_log_bytes_used,
CASE WHEN GETDATE() >= DATEADD(second, @LongTxThreshold, tr.transaction_begin_time) THEN 'DurationThresholdExceeded'
WHEN dbtr.database_transaction_log_bytes_used >= @LongTransactionLogBytes THEN 'LogThresholdExceeded'
ELSE 'Unknown'
END
AS reason
FROM sys.dm_tran_active_transactions AS tr
INNER JOIN sys.dm_tran_session_transactions AS st
ON tr.transaction_id = st.transaction_id
INNER JOIN sys.dm_exec_sessions AS sess
ON st.session_id = sess.session_id
INNER JOIN sys.dm_tran_database_transactions AS dbtr
ON tr.transaction_id = dbtr.transaction_id
INNER JOIN sys.dm_tran_active_transactions AS atr
ON atr.transaction_id = st.transaction_id
WHERE GETDATE() >= DATEADD(second, @LongTxThreshold, tr.transaction_begin_time)
OR
dbtr.database_transaction_log_bytes_used >= @LongTransactionLogBytes;
När sessionerna har identifierats kan du överväga att döda sessionen om det tillåts. Granska programmet för att fastställa typen av problematiska transaktioner för att undvika problemet i framtiden.
Mer information om hur du felsöker långvariga frågor finns i:
- Felsöka frågor som körs långsamt i SQL Server
- Identifieringsbara typer av flaskhalsar för frågeprestanda i Azure SQL Database
- Identifieringsbara typer av flaskhalsar för frågeprestanda i SQL Server och Azure SQL Managed Instance
Sök efter långvariga aktiva ögonblicksbildsgenomsökningar
Långvariga aktiva ögonblicksbildsgenomsökningar kan förhindra PVS-rensning i databaser som har ADR aktiverat. Uttalanden som använder READ COMMITTED
ögonblicksbildisolering (RCSI) eller SNAPSHOT
isoleringsnivåer får tidsstämplar på instansnivå. En ögonblicksbildsgenomsökning använder tidsstämpeln för att fastställa versionsradens synlighet för RCSI- eller SNAPSHOT
-transaktionen. Varje instruktion som använder RCSI har en egen tidsstämpel, medan SNAPSHOT
isolering har en tidsstämpel på transaktionsnivå.
De här transaktionstidsstämplarna på instansnivå används även i transaktioner med en databas, eftersom alla transaktioner kan höjas upp till en transaktion mellan databaser. Genomsökningar av ögonblicksbilder kan därför förhindra PVS-rensning i alla databaser på samma databasmotorinstans. På samma sätt, även om ADR inte är aktiverat, kan genomsökningar av ögonblicksbilder förhindra rensning av versionslagret i tempdb
. Därför kan PVS växa i storlek när långvariga transaktioner som använder SNAPSHOT
eller RCSI finns.
Kolumnen pvs_off_row_page_skipped_min_useful_xts
visar antalet sidor som hoppades över under rensningen på grund av en lång genomsökning av ögonblicksbilder. Om denna kolumn visar ett högt värde innebär det att en långvarig ögonblicksbildskanning förhindrar PVS-rensning.
Använd följande exempelfråga för att hitta sessioner med den långvariga SNAPSHOT
- eller RCSI-transaktionen:
SELECT sdt.transaction_id,
sdt.transaction_sequence_num,
s.database_id,
s.session_id,
s.login_time,
GETDATE() AS query_time,
s.host_name,
s.program_name,
s.login_name,
s.last_request_start_time
FROM sys.dm_tran_active_snapshot_database_transactions AS sdt
INNER JOIN sys.dm_exec_sessions AS s
ON sdt.session_id = s.session_id;
Så här förhindrar du PVS-rensningsfördröjningar:
- Överväg att ta bort den långa aktiva transaktionssessionen som fördröjer PVS-rensningen, om möjligt.
- Justera långvariga sökfrågor för att minska körtiden för frågorna.
- Granska programmet för att fastställa typen av problematisk aktiv ögonblicksbildsgenomsökning. Överväg en annan isoleringsnivå, till exempel
READ COMMITTED
, i stället förSNAPSHOT
eller RCSI för långvariga frågor som fördröjer PVS-rensningen. Det här problemet uppstår oftare medSNAPSHOT
isoleringsnivå. - I elastiska pooler i Azure SQL Database borde du överväga att flytta databaser som har långvariga transaktioner med hjälp av
SNAPSHOT
-isolering eller RCSI från den elastiska poolen för att undvika förseningar i PVS-rensningen i andra databaser i samma pool.
Kontrollera om det finns frågor som körs länge på sekundära repliker
Om databasen har sekundära repliker kontrollerar du om den sekundära lågvattenstämpeln avancerar.
Ett stort värde i kolumnen pvs_off_row_page_skipped_low_water_mark
kan vara en indikation på en rensningsfördröjning orsakad av en långvarig förfrågan på en sekundär replik. Förutom att fördröja PVS-rensningen kan en långvarig sökfråga på en sekundär replik också fördröja spökrensning.
Du kan använda följande exempelsökningar på primärrepliken för att ta reda på om långkörande sökningar på sekundära repliker kan förhindra PVS-rensning. Om en skrivarbetsbelastning körs på den primära repliken, men värdet i kolumnen low_water_mark_for_ghosts
inte ökar från en körning av exempelfrågan till nästa, kan PVS och spökrensning försenas av en långvarig fråga på en sekundär replik.
SELECT database_id,
DB_NAME(database_id) AS database_name,
low_water_mark_for_ghosts,
synchronization_state_desc,
synchronization_health_desc,
is_suspended,
suspend_reason_desc,
secondary_lag_seconds
FROM sys.dm_hadr_database_replica_states
WHERE is_local = 1
AND
is_primary_replica = 1;
För mer information, se beskrivningen av kolumnen low_water_mark_for_ghosts
i sys.dm_hadr_database_replica_states.
Anslut till varje läsbar sekundär replik, hitta sessionen med den långvariga frågeställningen och överväg att avsluta sessionen om det tillåts. Mer information finns i Hitta långsamma frågor.
Sök efter ett stort antal avbrutna transaktioner
Kontrollera kolumnerna aborted_version_cleaner_start_time
och aborted_version_cleaner_end_time
för att se om den senaste avbrutna transaktionsrensningen har slutförts. När den avbrutna transaktionsrensningen har avslutats, bör oldest_aborted_transaction_id
röra sig uppåt. Om oldest_aborted_transaction_id
är mycket lägre än oldest_active_transaction_id
och värdet för current_abort_transaction_count
är stort finns det förmodligen en gammal avbruten transaktion som förhindrar PVS-rensning.
Tänk på följande för att lösa PVS-rensningsfördröjningen på grund av ett stort antal avbrutna transaktioner:
- Om du använder SQL Server 2022 (16.x) ökar du värdet för
ADR Cleaner Thread Count
serverkonfiguration. Mer information finns i Serverkonfiguration: ADR Cleaner Thread Count. - Stoppa om möjligt arbetsbelastningen för att versionsrensaren ska kunna fortsätta.
- Granska applikationen för att identifiera och åtgärda problemet med hög frekvens av avbrutna transaktioner. Avbrotten kan komma från en hög frekvens av deadlock, duplicerade nycklar, begränsningsöverträdelser eller förfrågningstidbegränsningar.
- Optimera arbetsbelastningen för att minska lås som är inkompatibla med de
IX
lås på objektnivå eller partitionsnivå som krävs av PVS-rensaren. Mer information finns i Lås kompatibilitet. - Om du använder SQL Server inaktiverar du ADR som ett steg endast för nödsituationer för att kontrollera PVS-storleken. Se Inaktivera ADR.
- Om du använder SQL Server, och om den avbrutna transaktionsrensningen inte har slutförts framgångsrikt nyligen, kontrollerar du felloggen för meddelanden som rapporterar
VersionCleaner
problem. - Om PVS-storleken inte minskas som förväntat, även efter att en rensning har slutförts, bör du kontrollera kolumnen
pvs_off_row_page_skipped_oldest_aborted_xdesid
. Stora värden anger att utrymme fortfarande används av radversioner från avbrutna transaktioner.
Kontrollera PVS-storlek
Om du har en arbetsbelastning med en hög volym DML-instruktioner (INSERT
, UPDATE
, DELETE
, MERGE
), till exempel OLTP med hög volym och observerar att PVS-storleken är stor, kan du behöva öka värdet för ADR Cleaner Thread Count
serverkonfiguration för att hålla PVS-storleken under kontroll. Mer information finns i Server-konfiguration: ADR Cleaner Thread Count, som är tillgänglig från SQL Server 2022 (16.x).
I SQL Server 2019 (15.x) eller om en ökning av värdet för ADR Cleaner Thread Count
konfiguration inte bidrar till att minska PVS-storleken tillräckligt kan arbetsbelastningen kräva en period av vila/återställning för PVS-rensningsprocessen för att frigöra utrymme.
Om du vill aktivera PVS-rensningsprocessen manuellt mellan arbetsbelastningar eller under underhållsperioder använder du den system lagrade proceduren sys.sp_persistent_version_cleanup.
Till exempel:
EXEC sys.sp_persistent_version_cleanup [WideWorldImporters];
Fånga upp städningsfel
Från och med SQL Server 2022 (16.x) registreras anmärkningsvärda PVS-rensningsmeddelanden i felloggen. Rensningsstatistik rapporteras också av tx_mtvc2_sweep_stats
extended event.