Disiabilitare il file di log

mercoledì 15 luglio 2009 - 10.30

Elenco Threads

Stanze Forum

Aggiungi ai Preferiti

Cerca nel forum

riky85 Profilo | Newbie

14 messaggi | Data Invio: mer 15 lug 2009 - 10:30

Ciao a tutti ho bisogno assoluto di disabilitare il file di log (quello .ldf) perchè mi raggiunge dimensioni spaventose e occupa tutto lo spazio dell'hard disk... In internet ho trovato una soluzione parziale usando il comando DBCC SHRINKFILE, ma questa soluzione mi crea parechi problemi perchè dovrei invocare il comando dopo un numero non conosciuto a priori di operazioni.... Spero che esista qualche altra soluzione!

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: mer 15 lug 2009 - 10:39

>Ciao a tutti
Ciao

>ho bisogno assoluto di disabilitare il file di log
>(quello .ldf) perchè mi raggiunge dimensioni spaventose e occupa
>tutto lo spazio dell'hard disk... In internet ho trovato una
>soluzione parziale usando il comando DBCC SHRINKFILE, ma questa
>soluzione mi crea parechi problemi perchè dovrei invocare il
>comando dopo un numero non conosciuto a priori di operazioni....
>Spero che esista qualche altra soluzione!
Assolutamente no!!! Non devi poter disabilitare il file di log!
Però, se non hai necessità di avere un disaster recovery preciso all'istante di un eventuale blocco totale del sistema, puoi pensare di impostare il Recovery Model del tuo database a SIMPLE. In questo modo, una volta scelta la dimensione del file del log delle transazioni, il tuo database utilizzerà sempre quello spazio andando a sovrascrivere di volta in volta le operazioni più "vecchie".
Ma dipende se te lo puoi permettere, in quanto perdi la possibilità di avere un piano di backup che ti consente il recovery all'istante prima dell'eventuale danno (non puoi fare il backup del log delle transazioni).

--

Alessandro Alpi | SQL Server MVP

http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.support.microsoft.com/profile/Alessandro.Alpi
http://italy.mvps.org

riky85 Profilo | Newbie

14 messaggi | Data Invio: mer 15 lug 2009 - 11:25

Ciao , grazie per la risposta, però il problema persiste, ho fatto come mi ha consigliato, ho impostato a SIMPLE il Recovery Model del database e impostato a 50 MB la dimensione massima del file del log ma viene fuori questo problema :

 Il codice sorgente non è stato renderizzato qui
perchè non c'è sufficiente spazio.
Clicca qui per visualizzarlo in una nuova finestra

Il problema è che per scrivere 20 MB nel Database il file di log supera 50 MB di dimensione.
Sto scrivendo un programma che simuli un filesystem e che scrive i dati in un database, quindi quando copio un file di 20 MB viene scritto cira 300 volte nel database perchè fa scritture di piccole quantità di byte e il file di log cresce smisuratamente....

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: mer 15 lug 2009 - 12:10

>Ciao , grazie per la risposta, però il problema persiste, ho
>fatto come mi ha consigliato, ho impostato a SIMPLE il Recovery
>Model del database e impostato a 50 MB la dimensione massima
>del file del log ma viene fuori questo problema :
devi trovare una dimensione che ti consenta di contenere le tue operazioni altrimenti, come hai potuto notare una singola operazione sfora.
Ma quanto spazio ti serve? e che operazioni devi fare?
--

Alessandro Alpi | SQL Server MVP

http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.support.microsoft.com/profile/Alessandro.Alpi
http://italy.mvps.org

riky85 Profilo | Newbie

14 messaggi | Data Invio: mer 15 lug 2009 - 12:26

Sinceramente non so quanto spazio mi serve, sono arrivato che il file era grande 47 GB ed è una cosa non ammisibile.
Le operazioni sono praticamente le classiche operazioni sul database lettura (che non penso influisca sulla dimensione del file di log), modifica, cancellazione e creazione. Avendo un file system virtuale, l'operazione di update è molto frequente forse è quella più usata, dopo la lettura, perchè a ogni modifica di un file viene modificato qualcosa nel database.
Ho notato anche che in Mircrosoft SQL Server Management Studio (la version 2005), c'è la possibilità di modificare la dimensionde dell'aumento automatico, io l'ho messa a 1 MB, ma quando copio un paio di file sul filesystem virtuale ( che vanno scritti sul database), dopo un po mi da il messaggio di errore di prima. La fase di scrittura sul database non è diretta, cioè non scrivo subito 8 MB,per esempio, sul database, ma scrivo piccole porzioni tipo 64 kb ogni volta, quindi le update sul database sono tante.
Non so prorprio cosa fare....

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: mer 15 lug 2009 - 15:34

>Sinceramente non so quanto spazio mi serve, sono arrivato che
>il file era grande 47 GB ed è una cosa non ammisibile.
Beh se non hai impostato una politica la dimensione è virtualmente infinita.

>Ho notato anche che in Mircrosoft SQL Server Management Studio
>(la version 2005), c'è la possibilità di modificare la dimensionde
>dell'aumento automatico, io l'ho messa a 1 MB, ma quando copio
>un paio di file sul filesystem virtuale ( che vanno scritti sul
>database), dopo un po mi da il messaggio di errore di prima.
>La fase di scrittura sul database non è diretta, cioè non scrivo
>subito 8 MB,per esempio, sul database, ma scrivo piccole porzioni
>tipo 64 kb ogni volta, quindi le update sul database sono tante.
Ma la transazione totalmente scrive 8MB giusto? oppure il massimo dei file è 64kb?

Sinceramente, la cosa migliore da fare a mio avviso è capire fino a quanto puoi perdere nell'arco di un determinato periodo, nel quale effettuerai backup. L'operazione di backup (del t-log), senza impostare un recovery model SIMPLE, è quella che ti consente di riutilizzare le sezioni di t-log poichè consolidate durante il backup stesso. Secondo me dovresti:

- Capire ogni quanto fare il backup full
- Capire se ti servono backup differenziali tra un full e l'altro
- Capire se ti servono backup di t-log (questo ti consente il ripristino all'istante in caso di blocco del sistema e "libera il t-log" marcandone le sezioni come riutilizzabili, ma non riducendo la dimensione)

Una volta capita la politica di backup, puoi facilmente dimensionare il tuo log delle transazioni evitandone addirittura la crescita, poichè sai che le operazioni fatte tra un BACKUP e l'altro non vanno a far accrescere il file più della dimensione che tu gli hai impostato. Quindi cerca di capire come puoi fare una politica di backup, controlla nella giornata di utilizzo massivo a quanto arriva il t-log al massimo e poi aggiungi un pochino di mega per essere sicuro che non sforerai mai. A quel punto, schedula i tuoi backup e non avrai più problemi.

--

Alessandro Alpi | SQL Server MVP

http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.support.microsoft.com/profile/Alessandro.Alpi
http://italy.mvps.org

riky85 Profilo | Newbie

14 messaggi | Data Invio: gio 16 lug 2009 - 15:44

Infatti è quello che ho fatto grazie mille per l'aiuto!
Comunque la scrittura funziona in questo modo : supponendo un file di 8 MB, la prima volta scrive 64 kb e viene chiusa la connesione, il secondo "giro" legge dal database il 64 kb scritti ne accoda altri 64 e sovrascrive il campo. Va avanti così finchè non ha scritto tutti e 8 MB.
Sto già pensado ad una cache che però non è semplicissima da realizzare perchè si molta concorrenza. Questo però è un altro discorso.
Grazie ancora per l'aiuto.

alx_81 Profilo | Guru

8.814 messaggi | Data Invio: gio 16 lug 2009 - 15:46

>Grazie ancora per l'aiuto.
figurati, se ritieni sia stato di aiuto accetta la risposta così chiudiamo il thread

ciao!

--

Alessandro Alpi | SQL Server MVP

http://www.alessandroalpi.net
http://blogs.dotnethell.it/suxstellino
http://mvp.support.microsoft.com/profile/Alessandro.Alpi
http://italy.mvps.org

Torna su

Stanze Forum

Elenco Threads

Partecipa anche tu! Registrati!

Hai bisogno di aiuto ?
Perchè non ti registri subito?

Dopo esserti registrato potrai chiedere
aiuto sul nostro Forum oppure aiutare gli altri

Consulta le Stanze disponibili.

Registrati ora !