Transazioni trapelate da SQL Server

9

Ho un database a cui accedono circa 50 client tramite TDS su TCP che non sembra rilasciare spazio nel registro. Il numero di processi rimane intorno ai 50 previsti e alcuni di essi hanno una durata abbastanza lunga (> 120 giorni).

Il database ora ha 40 GB di spazio nel registro (contiene solo 14 GB di dati), 39 GB di spazio libero. A causa delle limitazioni di spazio sull'unità, vorrei ridurre a qualcosa di più ragionevole (10 GB-ish). Quando eseguo DBCC SHRINKFILE('db_log', 10000), viene restituito un errore che indica che la fine del registro è in uso.

Per liberare l'accesso alla fine del registro, ho tentato di posizionare il database in modalità utente singolo con quanto segue:

ALTER DATABASE db SET SINGLE_USER WITH ROLLBACK IMMEDIATE
GO
ALTER DATABASE db SET MULTI_USER
GO

ma lo script restituisce il seguente messaggio ripetuto centinaia di volte:

Nonqualified transactions are being rolled back. Estimated rollback completion: 100%.

Il che mi porta a credere che da qualche parte, lascerò alcune transazioni senza impegno. Non sono a conoscenza di alcun processo che possa intenzionalmente aprire così tante transazioni contemporaneamente, quindi penso che debbano accumularsi nel tempo, senza mai essere chiusi.

Domanda: Come posso individuare il processo o lo script offensivo o perché il registro non viene rilasciato?

sys.dm_tran_active_transactionssta mostrando un ragionevole 18 transazioni con scopi comprensibili. sp_whomostra solo i processi di cui sono a conoscenza.

Versione di SQL Server:

Microsoft SQL Server 2008 R2 (RTM) - 10.50.1600.1 (X64) 
Apr  2 2010 15:48:46 
Copyright (c) Microsoft Corporation
Enterprise Edition (64-bit) on Windows NT 6.1 <X64> (Build 7601: Service Pack 1) (Hypervisor)

Versione server:

Windows Server 2008 R2 x64 - Datacenter 4 vCPU, 16 GB di memoria, disco pass-through per dati e registro, il disco del sistema operativo è VHD

su Hyper-V (Windows Server 2008 R2 SP1 x64 Datacenter) Dual Intel X5650 (6 core, 12 thread a 2,67 GHz) memoria da 72 GB

Hypervisor ha solo tre macchine virtuali e non mostra un elevato utilizzo delle risorse. SQL Server VM mostra ~ 40% di CPU sotto carico e 99% di riscontri nella cache.

sql-server

— Mitch
fonte

Non sono un sql dba ma hai eseguito il backup del log? serverfault.com/questions/54958/…

@rene, Sì, avrei dovuto dirlo, ma il database ha un backup completo eseguito quotidianamente e un backup del registro ogni sei ore.

Ciao Mitch, probabilmente non correlato a questo problema, ma non sarei stato sorpreso se questo fosse stato responsabile. La tua versione è RTM (Release to Manufacture). Microsoft, come altri praticamente tutti i produttori di software, spingerà per rilasciare la prossima versione principale con una serie di piccoli difetti nel prodotto. [link] microsoft.com/en-us/download/details.aspx?id=44271 Questo è il link all'ultimo Service Pack per SQL 2008 R2. È meglio mantenere aggiornati i server per motivi di sicurezza, correzione di errori e prestazioni.

— DamagedGoods

4

C'è un comando SQL che mostrerà le transazioni APERTE. (DBCC OPENTRAN)

http://msdn.microsoft.com/en-us/library/ms182792.aspx

Visualizza le informazioni sulla transazione attiva meno recente e sulle transazioni replicate distribuite e non distribuite meno recenti, se presenti, all'interno del database specificato. I risultati vengono visualizzati solo se è presente una transazione attiva o se il database contiene informazioni sulla replica

— Richard Vivian
fonte

4

Per qualsiasi motivo, non sembrava esserci nulla che contenesse il file di registro aperto. Eseguendo più backup del registro (> 10), è stata rilasciata la fine del registro e potrebbe verificarsi la riduzione. Non so perché ... ma ha funzionato.

backup log db to disk = '\\l-backup1\drop\2012-12-23_db_log.bak' with stats = 1
go 15
dbcc shrinkfile('db_log', 10240)
go

— Mitch
fonte

3

Se capisco correttamente la tua domanda, hai un registro delle transazioni da 40 GB con 39 GB gratuito? Il registro è una struttura circolare, composta da file di registro virtuali più piccoli. Ogni volta che un VLF è pieno, SQL inizia a utilizzare il VLF successivo. (Non necessariamente nello stesso ordine in cui sono presenti i file VLF). Quando si restringe il file di registro, questo rilascia spazio libero dalla fine del registro. Se la parte attiva del registro si trova alla fine, non è possibile liberare spazio, se si trova nel mezzo da qualche parte, sarà possibile recuperare solo parte dello spazio. DBCC LOGINFO mostrerà tutti i VLF nel registro e uno stato che indica che il VLF contiene attualmente qualsiasi registro attivo. Credo che lo stato 2 sia attivo e 0 sia inattivo. Sono sicuro che Google può fornire ulteriori informazioni se necessario.

Se il tuo problema è solo che la parte attiva è attualmente alla fine, la tua scommessa migliore è solo aspettare che rotoli di nuovo all'inizio, quindi riduci il registro. Questo può richiedere una sorprendente quantità di tempo, sii paziente. Ci arriverà.
Ricorda inoltre che se QUALSIASI parte di un VLF è attualmente attiva, l'intero VLF viene mantenuto attivo.

Tuttavia, è necessario monitorare le dimensioni del file di registro, se aumenta di nuovo in modo imprevisto, è necessario effettuare alcune indagini sulla causa. Dovresti evitare un inutile restringimento del file di registro, quando cresce di nuovo può rallentare le prestazioni.

Maggiori informazioni sui VLF sono disponibili nel post del blog di Kimberly Tripps qui .

— pipTheGeek
fonte

grazie per il DBCC LOGINFOcomando, non ero a conoscenza di quello. Detto questo, sono a conoscenza della struttura del registro e non penso di ridurre il file in modo non necessario. Come accennato, utilizziamo regolarmente circa 1 GB di log nella nostra attuale struttura di backup e vorrei recuperare parte dello spazio libero. Il problema è che lo spazio di registro alla fine del registro non viene rilasciato anche dopo diverse settimane di attesa. Durante quel periodo, il database ha avuto molti backup completi e di log che mi portano a credere che qualcosa impedisca la cerchia naturale.