Non sono bravo in SQL, ma ho un database da mantenere.
Non c'è quasi più posto per questo, quindi ho deciso di eliminare tutti i dati per, diciamo, l'anno 2008. Dopo aver eseguito la query di eliminazione (sono state pulite circa 10.000.000 di righe) e aver pulito il registro delle transazioni ho scoperto che il mio le azioni non hanno avuto alcun effetto sulla dimensione del database. C'è qualcos'altro che devo fare?
Risposte:
Mentre restringersi è davvero pericoloso per i motivi menzionati qui. C'è un mezzo felice tra la risposta di Jimbo e la risposta di John ... Dovresti sempre considerare seriamente se vuoi ridurre il tuo database o meno.
In un mondo ideale, creeresti il tuo DB con molto spazio libero in cui crescere. Chiamo questo "dimensionamento corretto" il tuo database. Permetteresti a questo spazio libero di essere lì e non sforzarti di restituirlo e mantenere la dimensione totale giusta alla dimensione usata .. Perché? Perché alla fine il tuo database crescerà di nuovo .. Poi ti ridurrai di nuovo .. E rimarrai bloccato in questo orribile schema di inutili riduzioni seguite da crescite - e per tutto il tempo, come alcuni hanno sottolineato, sarai aumentando la frammentazione dell'indice.
Ho scritto un blog su questo in cui ho ammonito la gente a " Non toccare quel pulsante di restringimento! " Ma a volte ... A volte è necessario. Se disponi di un database di grandi dimensioni, hai appena liberato spazio significativo e non prevedi di ricrescerti mai - beh, allora va bene considerare la riduzione come operazione unica una volta che puoi occuparti della frammentazione dell'indice in seguito attraverso la ricostruzione loro. L'operazione di restringimento può richiedere molto tempo, quindi ti consigliamo di pianificarla per un periodo in cui puoi pagare quel prezzo di una corsa di contrazione. L'approccio della creazione di un DB vuoto e della copia dei dati in esso funziona, ma ciò può diventare molto difficile con database più grandi e molti dati.
Se hai intenzione di aggiungere di nuovo quello spazio al DB attraverso l'utilizzo normale e i modelli di crescita in futuro, allora potresti voler lasciare lo spazio lì.
Anche
Hai detto di aver "cancellato" il registro delle transazioni. Sarei curioso di sapere come hai fatto, ma mentre leggi il post che ho condiviso e gli altri della serie vedrai alcuni suggerimenti sulla gestione del registro delle transazioni. Ma in breve: se si è in modalità di ripristino completo, è necessario eseguire backup regolari del registro per mantenere il registro stesso in uso. Altrimenti, senza backup di log in modalità Completa, il file di registro continua a crescere e crescere e crescere e salva sempre ciò che hai fatto perché hai detto a SQL che non vuoi solo mantenere quel registro per il recupero da crash ma vuoi mantenere un backup manuale di esso per ripetere le transazioni / annullare le transazioni per ripristinare in un determinato momento nel tempo a fini di recupero ... Se si è semplici e si vede crescere eccessivamente il registro,BEGIN TRAN ... do work.... COMMIT TRANo se hai appena rilasciato una grande DELETEdichiarazione e cancellato un intero casino di dati in una transazione implicita.)
Suppongo anche che tu stia cercando questo spazio libero sul tuo file system. Se lo stai cercando in SQL e all'interno di quel file di grandi dimensioni che hai - potrebbe essere che stai aspettando il completamento della pulizia fantasma se stai cercando immediatamente dopo l'operazione. Blog di Paul Randal su Ghost Cleanup .
L'eliminazione di righe in un database non riduce le dimensioni effettive del file di database.
È necessario compattare il database dopo l'eliminazione della riga.
DBCC SHRINKDATABASE di SQL Server 2005 (Transact-SQL)
Dopo aver eseguito questo, ti consigliamo di ricostruire gli indici. La riduzione in genere causa la frammentazione dell'indice e ciò potrebbe comportare un costo significativo per le prestazioni.
Vorrei anche raccomandare che dopo aver ridotto, si ri-crescere i file in modo da avere un po 'di spazio libero. In questo modo, quando arrivano nuove file, non attivano la crescita automatica. La crescita automatica ha un costo in termini di prestazioni ed è qualcosa che vorresti evitare (attraverso un corretto dimensionamento del database) ogni volta che è possibile.
NON SHRINK IL TUO DATABASE!
"Perché succede? Un'operazione di riduzione dei file di dati funziona su un singolo file alla volta e utilizza le bitmap GAM (vedi Inside The Storage Engine: GAM, SGAM, PFS e altre mappe di allocazione) per trovare la pagina più alta allocata nella quindi lo sposta il più possibile verso la parte anteriore del file, e così via, e così via. Nel caso sopra, inverte completamente l'ordine dell'indice cluster, portandolo da perfettamente deframmentato a perfettamente frammentato. "
http://www.sqlskills.com/BLOGS/PAUL/post/Why-you-should-not-shrink-your-data-files.aspx
"Guarda l'ironia del database Shrinking. Una persona riduce il database per guadagnare spazio (pensando che aiuterà le prestazioni), il che porta ad aumentare la frammentazione (riducendo le prestazioni). Per ridurre la frammentazione, si ricostruisce l'indice, che porta alla dimensione di il database per aumentare di molto di più rispetto alle dimensioni originali del database (prima di ridursi). Bene, con la riduzione, non si è ottenuto quello che cercava di solito ".
Quando si eliminano dati, SQL Server si riserva il suo spazio per un utilizzo successivo per l'inserimento di nuovi dati. È necessario ridurre il database. Puoi trovare maggiori informazioni qui .
Ho trovato questo perché ho appena eliminato un sacco di tabelle di backup perché il mio database era "al massimo". Ho continuato a guardare la proprietà "Dimensioni", pensando perché non si riduce? . Dopo aver letto questo, no, non voglio ridurre il database. Quello che voglio fare è "recuperare" lo spazio per la spazzatura che ho appena eliminato. Quello che dovevo guardare era "Spazio disponibile". Sto pensando che forse è quello che qualcun altro potrebbe aver bisogno di guardare anche quello.
Vale anche la pena notare che se la tabella contiene indici, può esistere una frammentazione dopo l'eliminazione di grandi quantità di dati. Oggi avevo un tavolo che conteneva circa 70 milioni di dischi in circa 13 GB. L'ho pulito fino a 1639 record (il resto è stato generato da un singolo bug) ma la tabella occupava ancora circa 4,5 GB. Dopo aver ricostruito tutti gli indici sul tavolo, sono state necessarie solo 85 pagine (680 KB). Dopodiché, ho usato il file di restringimento incrementale per recuperare lo spazio (e risolto il bug sul sistema per impedire una ripetizione).