Spazio disponibile database sql 2005

venerdì 18 marzo 2011 - 12.43
Tag Elenco Tags  SQL Server Express

massimo1965 Profilo | Junior Member

Ciao
non riesco a capire una cosa : se faccio tasto destro su proprieta di un database, generale, in sql exp 2005, ho queste due righe :
dimensioni : 176 MB e penso che siano riferite allo stato del file MDF del database
spazio disponibile : 0,60 MB , questo dato a cosa si riferisce ?
sia il file di dati che il file di log hanno aumento illimitato uno in MB (mdf) mentre l'altro in %

questo perchè oggi è nato un problema di dimensionamento raggiunto e di conseguenza ho dovuto ridimensionare il file con i comandi :

use <dbname>
go
backup log <dbname> with truncate_only
go
DBCC SHRINKFILE (<dbname>_Log, 1)
GO

i database hanno :
modello di recupero : registrazione minima
livello di compatibilita : sql server 2000, forse è meglio metterli a 2005 ?

Chi mi puoi spiegare dove sbaglio e come parametrizzare al meglio il tutto.
Grazie

alx_81 Profilo | Guru

>Ciao
ciao

>dimensioni : 176 MB e penso che siano riferite allo stato del file MDF del database
dipende, se hai solo un mdf e nessun ndf, dovrebbe essere la somma delle occupazioni del mdf e del t-log.

>spazio disponibile : 0,60 MB , questo dato a cosa si riferisce ?
a quello che manca prima di raggiungere la dimensione che gli è stata attribuita su disco (anche dopo un'eventuale crescita)

>questo perchè oggi è nato un problema di dimensionamento raggiunto e di conseguenza ho dovuto ridimensionare il file con i comandi:
diciamo che puoi predimensionare i file in modo che non crescano, se non hai problemi di spazio.

>livello di compatibilita : sql server 2000, forse è meglio metterli a 2005 ?
dipende da come stai usando t-sql e da che funzionalità ti servono. Diciamo che così è retrocompatibile, ma se non hai fatto cose proprio legacy di 2000, puoi cambiare.
Ci sono tool che ti aiutano nella migrazione, come l'upgrade advisor(http://www.microsoft.com/downloads/en/details.aspx?FamilyID=1470e86b-7e05-4322-a677-95ab44f12d75&displaylang=en)

>Grazie
di nulla!
--
Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

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

lbenaglia Profilo | Guru

>questo perchè oggi è nato un problema di dimensionamento raggiunto
>e di conseguenza ho dovuto ridimensionare il file con i comandi
>:
>
>use <dbname>
>go
>backup log <dbname> with truncate_only
>go
>DBCC SHRINKFILE (<dbname>_Log, 1)
>GO
>
>i database hanno :
>modello di recupero : registrazione minima
>livello di compatibilita : sql server 2000, forse è meglio metterli
>a 2005 ?
>
>Chi mi puoi spiegare dove sbaglio e come parametrizzare al meglio
>il tutto.

Con molta probabilità Il problema si è verificato a causa del Recovery Model impostato a bulk-logged e alla mancanza di una policy di backup del t-log.
In questo caso le dimensioni del t-log continueranno a crescere fino a causare il problema che hai riscontrato.
Se non hai intenzione o non c'è l'esigenza di eseguire costantemente il backup del t-log imposta il Recovery Model a Simple, risolvendo alla radice il problema.

Per maggiori info dai una lettura al seguente paragrafo dei Books Online:
http://msdn.microsoft.com/en-us/library/ms189275.aspx

>Grazie
Prego.

Ciao!
--
Lorenzo Benaglia
Microsoft MVP - SQL Server
http://blogs.dotnethell.it/lorenzo/

alx_81 Profilo | Guru

>modello di recupero : registrazione minima

>Con molta probabilità Il problema si è verificato a causa del
>Recovery Model impostato a bulk-logged e alla mancanza di una
>policy di backup del t-log.
avevo capito fosse simple, registrazione minima non è simple?
--
Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

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

massimo1965 Profilo | Junior Member

Ciao
il tipo di modello è su registrazione minima che penso sia uguale a dire simple, quindi dovrebbe fare il minimo indispensabile delle registrazioni nel t-log. Tra l'altro il database in questione , che si chiama REPORTS, lo uso in appoggio alla realizzazione di report, da qui penso il problema incorso.
Quindi se ho ben capito dovrei, per evitare magari problemi di questo tipo :
- aumentare la dimensione iniziale in modo ottimale , al posto di 1 MB lo porto a 10 MB, non ci sono problemi di spazio (al momento)
USE [master]
GO
ALTER DATABASE [Reports] MODIFY FILE ( NAME = N'nomedatabase_Log', SIZE = 10240KB )
GO
- creare una azione pianificata che salvi il t-log e lo riporti alle condizioni iniziali
use reports
go
backup log reports with truncate_only
go
DBCC SHRINKFILE (reports_Log, 10)
GO

Corretto ?
Grazie a tutti.
-

alx_81 Profilo | Guru

>Quindi se ho ben capito dovrei, per evitare magari problemi di questo tipo :
>- aumentare la dimensione iniziale in modo ottimale , al posto di 1 MB lo porto a 10 MB, non ci sono problemi di spazio (al momento)
questo concordo, tu sai quanto serve preallocare

>- creare una azione pianificata che salvi il t-log e lo riporti alle condizioni iniziali
no, non puoi fare backup del t-log in simple recovery model. Proprio perchè lo riusi e perdi la possibilità di restorarlo..

>backup log reports with truncate_only
questo è un comando deprecato da 2008, non usarlo se puoi appena

>DBCC SHRINKFILE (reports_Log, 10)
fai senza se imposti una dimensione per cui il log non cresce, io farei solo il preallocamento. E poi non dovresti più avere problemi.
--
Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

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

massimo1965 Profilo | Junior Member

Grazie Alessandro, e anche agli altri,
faccio come mi avete suggerito. Però quello che non capisco è perche si sia verificato l'errore.
Mi spiego : uso il database Reports e le sue tabelle come db d'appoggio per la realizzazione di reports, quindi inserisco, cancello continuamente delle tabelle, oggi mi dice nel mezzo della creazione di un report, che ho più spazio anche se il modello e simple e ho l'aumento illimitato.

Faccio il dbcc SHRINKFILE per file di log, ne aumento la capacita iniziale e funziona il tutto.
Ma non doveva espandersi automaticamente ?

Grazie
e scusate la mia ignoranza.

lbenaglia Profilo | Guru

>Mi spiego : uso il database Reports e le sue tabelle come db
>d'appoggio per la realizzazione di reports, quindi inserisco,
>cancello continuamente delle tabelle, oggi mi dice nel mezzo
>della creazione di un report, che ho più spazio anche se il modello
>e simple e ho l'aumento illimitato.
Si, ma se tutti gli INSERT vengono eseguiti in un'unica transazione il t-log non può riutilizzare i virtual log ancora in uso dalla transazione.
Per evitare questo puoi eseguire gli inserimenti mediante transazioni più piccole.

>Faccio il dbcc SHRINKFILE per file di log, ne aumento la capacita
>iniziale e funziona il tutto.
I comandi DBCC SHRINK* non dovresti mai utilizzarli dato che non fanno altro che aumentare la frammentazione fisica del t-log e data files.

>Ma non doveva espandersi automaticamente ?
I file sono in grado di autoespandersi se nella loro definizione è stato specificato il parametro FILEGROWTH seguito da un fattore di incremento % oppure fisso.

>Grazie
Prego.

Ciao!
--
Lorenzo Benaglia
Microsoft MVP - SQL Server
http://blogs.dotnethell.it/lorenzo/

alx_81 Profilo | Guru

>Faccio il dbcc SHRINKFILE per file di log, ne aumento la capacita
>iniziale e funziona il tutto.
>Ma non doveva espandersi automaticamente ?
se hai impostato l'autogrowth sì, ma potrebbe essere che la crescita impostata non regga l'impatto dello spazio che essa necessita..

> Si, ma se tutti gli INSERT vengono eseguiti in un'unica transazione il t-log non può riutilizzare i virtual log ancora in uso dalla transazione.
> Per evitare questo puoi eseguire gli inserimenti mediante transazioni più piccole.
Quoto

--
Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

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

massimo1965 Profilo | Junior Member

Grazie Lorenzo e Alessandro,
avete ragione. Probabilmente non è riuscito a risolvere il dimensionamento in tempo utile, penso di aumentare il file di log e la % di aumento.
Solo una conferma a quello che mi avete detto / capito : mettendo come modello simple non dovrei il problema di un file di log che aumenta in modo esponziale e un back up di tale file avrebbe poco senso.

Al momento per fare il back del database uso questo comando :

BACKUP DATABASE [nomedatabase] TO DISK = N'E:\TMP\database.bak'
WITH NOFORMAT, INIT, NAME = N'database-Completo Database Backup',
SKIP, NOREWIND, NOUNLOAD, STATS = 10

Vi ringrazio per la pazienza.
Ciao

alx_81 Profilo | Guru

>Solo una conferma a quello che mi avete detto / capito : mettendo
>come modello simple non dovrei il problema di un file di log
>che aumenta in modo esponziale e un back up di tale file avrebbe poco senso.
se cresce, crescerà raramente mentre il backup proprio non si può fare al massimo solo full e differenziale del database, ma non del log.

>Al momento per fare il back del database uso questo comando :
>BACKUP DATABASE [nomedatabase] TO DISK = N'E:\TMP\database.bak'
>WITH NOFORMAT, INIT, NAME = N'database-Completo Database Backup',
>SKIP, NOREWIND, NOUNLOAD, STATS = 10
questo è un full, se il tuo database non cambia praticamente mai, è ottimo, se ti serve un backup più frequente puoi pensare anche ai differenziali.

--
Alessandro Alpi | SQL Server MVP
MCP|MCITP|MCTS|MCT

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

massimo1965 Profilo | Junior Member

Ti ringrazio.
Massimo
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 !
Copyright © dotNetHell.it 2002-2017
Running on Windows Server 2008 R2 Standard, SQL Server 2012 & ASP.NET 3.5