Sintomi
Si supponga di avere installato Microsoft SQL Server 2014, 2016 o 2017. Potresti riscontrare uno o più dei problemi seguenti:
-
L'istanza di SQL Server non risponde e si verifica un errore "utilità di pianificazione non cedente". Potrebbe essere necessario riavviare il server per recuperarlo.
-
Il rollback di una transazione può richiedere molto tempo per il completamento. Nella maggior parte dei casi il riavvio dell'istanza consentirà al database di recuperare molto più velocemente del rollback. Tieni presente che per il completamento di un rollback può essere necessario molto tempo, vedi la sezione "altre informazioni" per informazioni dettagliate sul monitoraggio dei rollback prima di provare a riavviare il computer.
-
È possibile che vengano visualizzate attese elevate per gli spinlock, ad esempio SOS_OBJECT_STORE.
Risoluzione
Questo problema è stato risolto negli aggiornamenti cumulativi seguenti per SQL Server:
Ogni nuovo aggiornamento cumulativo per SQL Server contiene tutti gli hotfix e tutti gli aggiornamenti della sicurezza inclusi nell'aggiornamento cumulativo precedente. Vedere gli ultimi aggiornamenti cumulativi per SQL Server:
Ultimo aggiornamento cumulativo per SQL Server 2017
Informazioni sui Service Pack per SQL Server
Questo aggiornamento è risolto nel Service Pack seguente per SQL Server:
I Service Pack sono cumulativi. Ogni nuovo Service Pack contiene tutte le correzioni che si trovano nei Service Pack precedenti, insieme a tutte le nuove correzioni. La nostra raccomandazione consiste nell'applicare il Service Pack più recente e l'ultimo aggiornamento cumulativo per tale Service Pack. Non è necessario installare un Service Pack precedente prima di installare il Service Pack più recente. Usare la tabella 1 nell'articolo seguente per trovare altre informazioni sul Service Pack più recente e l'ultimo aggiornamento cumulativo.
Ulteriori informazioni
Esistono molti motivi per cui un rollback può richiedere molto tempo, ad esempio una transazione a esecuzione prolungata, un numero elevato di VLF nel file di log delle transazioni, I/O lenta e così via. Per verificare che il problema descritto in questo articolo sia la causa radice di un rollback lento, è consigliabile usare le tecniche seguenti per monitorare lo stato di avanzamento dell'operazione di rollback:
-
Da sys.dm_exec_requestsidentificare il session_id il cui comando è impostato su "Killed/rollback" e verificare che la sessione stia accumulando sia io che il tempo della CPU che indicano lo stato di avanzamento. Se IO non cambia, può essere un'indicazione che si incontra il problema descritto in questo articolo.
-
Eseguire una query sys.dm_tran_database_transactions per identificare lo stato corrente del rollback usando una query simile alla seguente:
Selezionare GETDATE () come CurrentTime, database_transaction_next_undo_lsn, database_transaction_begin_lsn, t.transaction_id, database_transaction_begin_time, database_transaction_log_record_count, db_name (t.database_id)
DA sys.dm_tran_database_transactions t
PARTECIPARE sys.dm_exec_requests s IN t.transaction_id = s.transaction_id
DOVE t.database_id = db_id (' <nome database') e s.session_id =<session_id eseguire l'operazione di rollback>
Nota:
Nella query precedente
database_transaction_next_undo_lsn è l'LSN del record successivo da annullare. database_transaction_begin_lsn è l'LSN del record Begin per la transazione nel log delle transazioni.
database_transaction_next_undo_lsn deve diminuire con ogni snapshot della query. Il rollback verrà completato correttamente quando la database_transaction_next_undo_lsn raggiunge database_transaction_begin_lsn.
L'obiettivo è quello di eseguire alcune istantanee della query precedente in un intervallo predeterminato e quindi usare il Delta del LSN elaborato in database_transaction_next_undo_lsn all'interno di tale intervallo ed estrapolare il tempo necessario per stimare il tempo necessario per il database_transaction_next_undo_lsn per raggiungere l' database_transaction_begin_lsn.
Se il rollback sta procedendo a un tasso decente tra ogni snapshot, è consigliabile che il rollback sia consentito per il completamento autonomo senza riavviare l'istanza di SQL Server.
Per altre informazioni sul ripristino a lunga durata, vedere gli articoli seguenti:
-
SQL Server (2000, 2005, 2008): recupero/rollback che richiede più tempo del previsto
-
Come una struttura di file di log può influire sul tempo di recupero del database
-
Verifica dello stato di ripristino del database tramite informazioni dalla DMV
Stato
Microsoft ha confermato che questo problema si verifica nei prodotti elencati nella sezione "Si applica a".
Riferimenti
Informazioni sulla terminologiautilizzata da Microsoft per descrivere gli aggiornamenti software.
