Prima di contrassegnare immediatamente come duplicato , ho letto Perché il registro delle transazioni continua a crescere o esaurire lo spazio di Mike Walsh ? , ma non credo che abbia dato una risposta alla mia situazione. Ho esaminato una dozzina di domande simili, ma quelle pertinenti per lo più hanno semplicemente detto "duplicato" e indicato la domanda di Mike.
Dettagli: ho un sacco di database ~ 500 MB su SQL Server 2008 R2, tutti in modalità di ripristino SEMPLICE (non la mia scelta), backup completi notturni, con file di dati di ~ 200 MB e file di registro di ~ 300 MB. Il registro non raggiunge i 300 MB immediatamente, ma piuttosto lentamente nel corso di un paio di mesi. Non ci sono transazioni aperte su nessuno di essi, almeno secondo sp_who2 e il monitor delle attività. Se faccio clic con il pulsante destro del mouse sul database e seleziono le proprietà, mi dice che ci sono ~ 50 MB gratuiti. Soprattutto dopo un backup, l'intero registro non dovrebbe essere libero? In modalità SEMPLICE il registro non dovrebbe essere libero fintanto che non c'è una transazione aperta?
log_reuse_wait_descda sys.databasesdice "NIENTE", che in base alla domanda e alla risposta di cui sopra dice che non dovrebbe aspettare nulla per riutilizzare lo spazio.
Se eseguo "DBCC SHRINKFILE", il file di registro si riduce a 1 MB, quindi è disposto a recuperare lo spazio. Posso impostare qualcosa che restringe i registri settimanalmente e impedisce alle cose di sfuggire al controllo, ma sono confuso sul perché SQL Server mi costringerebbe a farlo.
Riesco a capire se ci fosse una transazione folle che aveva bisogno di 300 MB per registrarlo, ma non stiamo facendo nulla di estremo, solo OLTP di base. Dalla domanda / risposta di Mike:
Modello di recupero semplice - Quindi, con l'introduzione di cui sopra, è più semplice parlare prima del modello di recupero semplice. In questo modello, stai dicendo a SQL Server: sto bene usando il tuo file di registro delle transazioni per il crash e il riavvio del ripristino (Non hai davvero scelta lì. Cerca le proprietà ACID e questo dovrebbe avere senso rapidamente), ma una volta che no serve più a tale scopo di recupero crash / riavvio, andare avanti e riutilizzare il file di registro.
SQL Server ascolta questa richiesta in Simple Recovery e conserva solo le informazioni necessarie per eseguire il crash / riavvio del ripristino. Una volta che SQL Server è sicuro che possa essere ripristinato poiché i dati sono induriti nel file di dati (più o meno), i dati che sono stati induriti non sono più necessari nel registro e sono contrassegnati per il troncamento, il che significa che vengono riutilizzati.
Continua a dire che lo spazio del registro dovrebbe essere riutilizzato, ma con questa crescita lenta nel corso dei mesi, non sembra che lo sia.
Cosa mi sto perdendo? Qualcosa impedisce a SQL Server di riconoscere i dati come "rafforzati" e di liberare il registro?
(modifica) The After Action Report - AKA un po 'di conoscenza è pericolosa
Dopo aver scoperto che questa è una "domanda popolare", mi è sembrato di dover una spiegazione di ciò che è accaduto 7 mesi fa e di ciò che ho imparato a sperare di salvare un po 'di dolore ad altre persone.
Innanzitutto, lo spazio disponibile visualizzato in SSMS quando si visualizzano le proprietà su un database è lo spazio disponibile nel file di dati. Puoi visualizzarlo eseguendo quanto segue su un database e scoprirai che lo spazio disponibile segnalato da SSMS è la differenza tra FileSizeMB e UsedSpaceMB:
SELECT
DB.name,
MF.physical_name,
MF.type_desc AS FileType,
MF.size * 8 / 1024 AS FileSizeMB,
fileproperty(MF.name, 'SpaceUsed') * 8/ 1024 AS UsedSpaceMB,
mf.name LogicalName
FROM
sys.master_files MF
JOIN sys.databases DB ON DB.database_id = MF.database_id
WHERE DB.name = 'yourdatabasename'Ciò ha confermato che in circostanze normali stavamo usando pochissimo spazio di registro (20 MB o meno), ma questo porta al secondo elemento ...
In secondo luogo, la mia percezione della crescita dei tronchi era quella di lentamente nel tempo. Tuttavia, in realtà i registri crescevano rapidamente nelle notti in cui il responsabile dell'applicazione delle patch per questa applicazione di terze parti stava applicando le patch. La patch è stata eseguita come una singola transazione, quindi a seconda della patch i dati da 200 MB richiedevano 300 MB di log. La chiave per rintracciarla era la query di Aaron Bertrand su https://sqlblog.org/2007/01/11/reviewing-autogrow-events-from-the-default-trace
DECLARE @path NVARCHAR(260);
SELECT
@path = REVERSE(SUBSTRING(REVERSE([path]),
CHARINDEX('\', REVERSE([path])), 260)) + N'log.trc'
FROM sys.traces
WHERE is_default = 1;
SELECT
DatabaseName,
[FileName],
SPID,
Duration,
StartTime,
EndTime,
FileType = CASE EventClass
WHEN 92 THEN 'Data'
WHEN 93 THEN 'Log'
END
FROM sys.fn_trace_gettable(@path, DEFAULT)
WHERE
EventClass IN (92,93)
ORDER BY
StartTime DESC;Ciò ha dimostrato che il registro cresceva in determinate serate, quando il cliente non utilizzava il database. Ciò ha portato alla conversazione con il ragazzo che applicava le patch e la risposta al mistero.
Grazie ancora per le persone che mi hanno fornito aiuto per ottenere la risposta.