none
MSSQLServer 2012 - Tempdb composto da piu Database File. RRS feed

  • Domanda

  • Ciao a tutti.

    Durante un tentativo di shrink "fallito" di un TempDB giudicato "enorme" su nuova macchina MSSQLServer 2012 non creata da me, mi sono ritrovato una configurazione tale che il TempDb , creato con più DatabaseFile, sia impostato per avere già inizialmente oltre 50 GB :

    Non avevo mai trovato una configurazione simile. 

    Credete abbia un qualche senso di "performance" o altro ?  L'istanza possiede un unico grande DB applicativo di circa 500 GB.

    Grazie a tutti anticipatamente, ciao.


    Hunternet

    giovedì 8 settembre 2016 09:43

Risposte

  • Ciao

    L'utilizzo di più file datafile per il tempDB (tutti con stessa dimensione) è giustificabile per alleviare problemi di contention su tempDB. In particolare se dalla sys.dm_os_wait_stats risulta prevalemtemente un wait di  tipo PAGELATCH_XX  sul tempDB si può valutare l'adozione di più datafile per questo DB.

    Cfr: http://www.sqlskills.com/blogs/paul/a-sql-server-dba-myth-a-day-1230-tempdb-should-always-have-one-data-file-per-processor-core/

    e

    http://www.sqlskills.com/blogs/paul/correctly-adding-data-files-tempdb/


    • Modificato FrenesisDBAj giovedì 8 settembre 2016 10:41 correzioni
    • Contrassegnato come risposta HunterNet79 giovedì 8 settembre 2016 12:55
    giovedì 8 settembre 2016 10:39
  • Ciao Hunternet,

    Per valutare lo spazio occupato di ciascun datafile puoi usare questa query:

    select 
    	physical_name
    	, size / 128.0 as size
    	, CONVERT(int, FILEPROPERTY([name],'SpaceUsed')) / 128.0 as used
    	, (size - CONVERT(int, FILEPROPERTY([name],'SpaceUsed'))) / 128.0 as free
    	, growth / 128.0 as grow_size
    	, is_percent_growth
    from
    	sys.database_files

    Lo shrink cercherei di evitarlo il più possibile. Nel caso tu abbia tanto spazio inutilizzato, dovresti cercare di capirne il motivo: se è dovuto ad un sovradimensionamento del DB allora non ci sono problemi, ma se lo spazio è stato allocato da diverse operazioni di autogrow, significa che SQL Server ha dovuto espandere il datafile perché la dimensione allocata non era sufficiente, ed, in generale, è sempre meglio limitare il più possibile gli autogrow.

    Per iniziare, potresti fare uno shrink e verificare a periodi regolari la variazione della dimensione dei datafile e capire, volta per volta, che cosa ha provocato il cambiamento.

    Altro consiglio, non imposterei l'autogrow dei datafile in percentuale, ma terrei sempre una dimensione di crescita fissa (nella query precedente, il campo is_percent_growth = 1 indica un datafile con autogrow in percentuale).

    HTH


    Alberto Dallagiacoma
    My Italian Blog: http://blogs.ugidotnet.org/alby
    Twitter: http://twitter.com/albertodall
    DotDotNet - User Group .NET Emilia Romagna: http://www.dotdotnet.org

    • Contrassegnato come risposta HunterNet79 giovedì 8 settembre 2016 12:55
    giovedì 8 settembre 2016 12:47
  • Buongiorno in alcune configurazioni si usa configurare 1 temp db per ogni Core , in questo caso occorre aggiungere anche dei parametri di startup per far inizializzare contemporaneamente i files .

    In genere conviene non eseguire lo shrink, sui temp db meno che mai , per un database applicativo la cosa va valutata , considerando che le operazioni più lente sono quelle che avvengono quando viene utilizzato il disco rigido , se tu esegui lo shrink periodicamente e il database poi ha bisogno di riallocare spazio ti trovi un effetto fisarmonica in cui te lo restringi lui ricresce e magari lo fa nel periodo di esercizio dell'applicazione provocando dei cali di performance che possono essere anche considerevoli.

    Per i backup la compressione ti consente di risparmiare spazio , sicuramente è buona norma con periodicità eseguire dei test di restore , per ridurre al minimo rischi relativi a file danneggiati magari in qualche operazione di copia per locarli in sicurezza su supporti esterni e/o comunque fuori dal server.


    QuirinoS

    • Contrassegnato come risposta HunterNet79 venerdì 9 settembre 2016 10:17
    venerdì 9 settembre 2016 09:55

Tutte le risposte

  • Integrazione riguardo il DB di produzione :

    E' vero che su disco risulta essere circa 500 GB, ma ho scoperto due cose : 

    1. che i backup FULL (che già mi hanno fatto insospettire) anche se con l'opzione di compressione arrivano ad essere al massimo 40 GB (?).

    2. che il DB nelle proprietà ha il valore "Initial Size" impostato a 399400 MB , motivo per cui ovviamente lo Shrink ha "poco effetto" ...

    Riguardo a quanto sopra, potrei pensare di cambiare il valore "initial size" ad un valore più basso con la certezza di non compromettere niente alle funzionalità del  DB  ? 

    Il fatto però che lo Shrink risulti possibile in questi termini (con solo l'1% libero), significa che sicuramente il DB è comunque pieno, che posso evitare di abbassare il parametro di "initial size"  e che quindi  la compressione dei Backup è fenomenale ?? 

    Penseri di agire sull' "Initial size" sia del TempDB che del DB applicativo ma vorrei la certezza di poterlo fare senza compromettere i DB e che sia una operazione davvero "necessaria" . Che ne pensate ??? Grazie ragazzi ... !


    Hunternet

    giovedì 8 settembre 2016 10:38
  • Ciao

    L'utilizzo di più file datafile per il tempDB (tutti con stessa dimensione) è giustificabile per alleviare problemi di contention su tempDB. In particolare se dalla sys.dm_os_wait_stats risulta prevalemtemente un wait di  tipo PAGELATCH_XX  sul tempDB si può valutare l'adozione di più datafile per questo DB.

    Cfr: http://www.sqlskills.com/blogs/paul/a-sql-server-dba-myth-a-day-1230-tempdb-should-always-have-one-data-file-per-processor-core/

    e

    http://www.sqlskills.com/blogs/paul/correctly-adding-data-files-tempdb/


    • Modificato FrenesisDBAj giovedì 8 settembre 2016 10:41 correzioni
    • Contrassegnato come risposta HunterNet79 giovedì 8 settembre 2016 12:55
    giovedì 8 settembre 2016 10:39
  • Bene, ti ringrazio. 

    Riguardo invece il DB Applicativo ? Vale la pena pensare di abbassare il parametro di dimensione iniziale ? Il DB è veramente 400 GB o ci sono presupposti per pensare che possa essere "pieno" solo per 40 GB ? La valutazione della funzione di Shrink file è attendibile ? posso utilizzare altri metodi di verifica ? 

    GRAZIE.


    Hunternet

    giovedì 8 settembre 2016 11:52
  • Ciao Hunternet,

    Per valutare lo spazio occupato di ciascun datafile puoi usare questa query:

    select 
    	physical_name
    	, size / 128.0 as size
    	, CONVERT(int, FILEPROPERTY([name],'SpaceUsed')) / 128.0 as used
    	, (size - CONVERT(int, FILEPROPERTY([name],'SpaceUsed'))) / 128.0 as free
    	, growth / 128.0 as grow_size
    	, is_percent_growth
    from
    	sys.database_files

    Lo shrink cercherei di evitarlo il più possibile. Nel caso tu abbia tanto spazio inutilizzato, dovresti cercare di capirne il motivo: se è dovuto ad un sovradimensionamento del DB allora non ci sono problemi, ma se lo spazio è stato allocato da diverse operazioni di autogrow, significa che SQL Server ha dovuto espandere il datafile perché la dimensione allocata non era sufficiente, ed, in generale, è sempre meglio limitare il più possibile gli autogrow.

    Per iniziare, potresti fare uno shrink e verificare a periodi regolari la variazione della dimensione dei datafile e capire, volta per volta, che cosa ha provocato il cambiamento.

    Altro consiglio, non imposterei l'autogrow dei datafile in percentuale, ma terrei sempre una dimensione di crescita fissa (nella query precedente, il campo is_percent_growth = 1 indica un datafile con autogrow in percentuale).

    HTH


    Alberto Dallagiacoma
    My Italian Blog: http://blogs.ugidotnet.org/alby
    Twitter: http://twitter.com/albertodall
    DotDotNet - User Group .NET Emilia Romagna: http://www.dotdotnet.org

    • Contrassegnato come risposta HunterNet79 giovedì 8 settembre 2016 12:55
    giovedì 8 settembre 2016 12:47
  • Ciao e grazie della risposta. Questo il risultato che , a quanto pare, conferma che il DB è veramente utilizzato.

    A questo punto mi viene da pensare che il parametro di "dimensione iniziale" sia stato ereditato dal primo restore del DB allora e che posso tranquillamente lasciarlo tale.

    Il fatto che i backup siano "solo" di 40 GB allora ?? possibile che la compressione funzioni cosi "bene"?  vi risulta per vostra esperienza ? 

    GRAZIE ANCORA.


    Hunternet

    giovedì 8 settembre 2016 12:54
  • Direi che ci potrebbe anche stare; dipende molto dai dati che hai all'interno del database.

    Per esperienza personale, ho un DB di circa 120 Gb il cui il backup compresso è poco più di 11 Gb.

    HTH,


    Alberto Dallagiacoma
    My Italian Blog: http://blogs.ugidotnet.org/alby
    Twitter: http://twitter.com/albertodall
    DotDotNet - User Group .NET Emilia Romagna: http://www.dotdotnet.org



    giovedì 8 settembre 2016 13:03
  • Ah beh, allora ci può stare sicuramente ! Avevo sempre sottovalutato questa possibilità che se "SICURA" (in caso di restore) inizierò sicuramente ad utilizzare... magari al posto di backup differenziali ... o sono da preferirsi comunque i secondi ??  Grazie. 

    Hunternet

    giovedì 8 settembre 2016 13:11
  • Io ho sempre fatto restore di database compressi senza problemi, ma è sempre buona pratica testare ogni tanto il ripristino di un backup per non trovarsi nei pasticci quando il restore serve davvero... :-)

    Se un backup compresso è da preferirsi al backup differenziale, dipende. Sicuramente gli scopi sono diversi: la compressione di un backup la abiliti essenzialmente per risparmiare spazio su disco, il backup differenziale lo fai come parte di un piano di disaster recovery.

    Se il tuo piano di disaster recovery prevede solo backup full, allora compressione tutta la vita! ;-)

    HTH


    Alberto Dallagiacoma
    My Italian Blog: http://blogs.ugidotnet.org/alby
    Twitter: http://twitter.com/albertodall
    DotDotNet - User Group .NET Emilia Romagna: http://www.dotdotnet.org

    giovedì 8 settembre 2016 13:28
  • Grazie infinite dell'aiuto e "formazione" :-) ciao e alla prossima.

    Hunternet

    giovedì 8 settembre 2016 13:31
  • Di nulla, alla prossima! :-)

    Alberto Dallagiacoma
    My Italian Blog: http://blogs.ugidotnet.org/alby
    Twitter: http://twitter.com/albertodall
    DotDotNet - User Group .NET Emilia Romagna: http://www.dotdotnet.org

    giovedì 8 settembre 2016 13:41
  • Buongiorno in alcune configurazioni si usa configurare 1 temp db per ogni Core , in questo caso occorre aggiungere anche dei parametri di startup per far inizializzare contemporaneamente i files .

    In genere conviene non eseguire lo shrink, sui temp db meno che mai , per un database applicativo la cosa va valutata , considerando che le operazioni più lente sono quelle che avvengono quando viene utilizzato il disco rigido , se tu esegui lo shrink periodicamente e il database poi ha bisogno di riallocare spazio ti trovi un effetto fisarmonica in cui te lo restringi lui ricresce e magari lo fa nel periodo di esercizio dell'applicazione provocando dei cali di performance che possono essere anche considerevoli.

    Per i backup la compressione ti consente di risparmiare spazio , sicuramente è buona norma con periodicità eseguire dei test di restore , per ridurre al minimo rischi relativi a file danneggiati magari in qualche operazione di copia per locarli in sicurezza su supporti esterni e/o comunque fuori dal server.


    QuirinoS

    • Contrassegnato come risposta HunterNet79 venerdì 9 settembre 2016 10:17
    venerdì 9 settembre 2016 09:55
  • GRAZIE!

    Hunternet

    venerdì 9 settembre 2016 10:17