salve,
budaioni wrote:

Buongiorno.
Per la mia azienda ho la necessità di caricare con cadenza
giornaliera una serie di dati che mi arrivano da mainframe host come file txt, in alcune tabelle sql.
Per il caricamento ho creato una serie di DTS che non fanno altro che fare la truncate delle tabelle e il caricamento dati utilizzando il bulk insert.

Il db prima del caricamento è circa 24 Giga.
I dati da caricare tutti i giorni sono 25 Giga circa.
Le tabelle da caricare sono 5 e i DTS sono schedulati per essere eseguiti in sequenza.
Al termine del processo di caricamento mi aspetterei un DB con dimensioni di circa 25 Giga.. (facendo la truncate delle tabelle faccio spazio) invece al mattino mi trovo sempre un DB che ha come dimensione totale 50 Giga di cui 25 occupato e il resto libero. Non riesco a capire perchè... potete aiutarmi?
Per adesso, per tamponare la falla e recuperare lo spazio disco al termine di tutto faccio fare lo shrink del db, ma farlo su 25 giga mi dura veramente tanto e vorrei evitarlo..

non indichi se la dimensione del database sia dei soli file di dati ovvero anche del transaction log..
"parto"presupponendo trattarsi dei soli file dati.. indichi che effettui un truncate delle tabelle, e questo ovviamente rilascia spazio all'interne delle pagine di dati.. indichi anche che effettui un bulkinsert.. mi viene da pensare che le righe da inserire non siano in effetti "ordinate" secondo la chiave clustered al momento dell'esecuzione.. come ben sai, ogni pagina di SQL Server e' pari a 8kb e, in base alle politiche di fillfactor degli indici/chiavi puo' esistere uno spazio minimo che SQL Server deve riservare vuoto all'interno della pagina.. piu' basso tale valore, piu' grande lo spazio che SQL Server cerca di mantenere libero.. ma non penso sia proprio questo il problema.. come dicevo, potrebbe trattarsi di inserimenti di righe non ordinate.. questo comporta il riempimento della pagina e, al momento dell'inserimento di una nuova riga che debba inserirsi in una pagina che contenga anche altre righe con valori di chiave successivi a quella in esame, la necessita' di eseguire un page split.. questo consta nella divisione della pagina in 2 pagine (sempre di 8kb l'una) con la migrazione di circa meta' delle righe dalla vecchia pagina alla nuova pagina, che verra' linkata immediatamente successivamente a quella di origine.. cio' fa si che, se in una pagina possono potenzialmente essere archiviate 8 righe e gia' 8 siano presenti, l'inserimento di una nuova riga con valore di chiave rientrante nel range di chiave presente nella pagina, questa subisca un page split... meta' delle righe originali restera' nella pagine di origine, e circa meta' migrera' sulla nuova pagina.. ottenendo, alla fine dell'operazione, 2 pagine potenzialmente mezze vuote... l'inserimento di righe in valore monotonicamente crescente secondo l'indice/chiave clusterizzato puo' ovviamente limitare tale impatto..
saluti