siquellando

Un log che non cresce anche in FULL logging

Posto una particolarita' del comportamento del file di log la cui utilita' pratica rasenta lo zero, ma puo' essere utilizzata per vincere un caffe' facendo una scommessa

Domanda: e' possibile che un database in cui vengono effettuate numerose operazioni di scrittura, settato in modalita'di recovery FULL e per cui non venga mai effettuato un backup del log  non presenti un aumento delle dimensioni del suo file di log  (o per lo meno esso non tenda ad "esplodere") ?

Risposta: (sorprendente):  SI.

Capita in una condizione piuttosto particolare: se non e' mai stato effettuato un backup completo dei dati da quando il database e' in recovery model FULL.

Questo e' dovuto al fatto che, in realta',  la condizione che il log "non cresca", ovvero che recuperi via via lo spazio utilizzato dalle transazioni committate ed effettivamente scritte nel database (truncation del log) non e' legata "esattamente" al modello di recovery , ma piu' precisamente al fatto che SQL Server abbia dedotto che, per quel database, non viene mantenuta una sequenza di backup del log.

In altre parole, se SQL capisce che non abbiamo intenzione di utilizzare il log nella nostra strategia di backup-restore, correttamente non si preoccupa (se ne frega...)  di salvare le transazioni gia' scritte nel database (dato che non ci servono per il restore) e recupera appena puo', con un bel truncate, lo spazio a loro allocato.

Ok, e quando SQL puo' essere sicuro che non ci interessa il restore dal log ??? Nei seguenti tre casi:

• Lo richiediamo espressamente scegliendo il modello di recovery SIMPLE
• Buttiamo via i dati del log con l'istruzione backup log with no_log ( opzione deprecata che non sara' piu' supportata nelle prossime versioni)

e, dulcis in fundo...

• Non abbiamo MAI fatto un backup full dei dati.
  (se non abbiamo il back up di base come facciamo ad applicargli il restore del log !!??!!) 

Eh, si, c'e' poco da fare SqlServer e' ... furbo !!

PS: vi interessa sapere (in Sql2005) quali database sono in questa situazione (ovvero in autotruncate mode) ?  Lo vedete da questa select:

SELECT db_name(database_id)

FROM sys.database_recovery_status

WHERE last_log_backup_lsn is NULL