Nie jestem dobry w SQL, ale mam bazę danych do utrzymania.
Prawie nie ma już na to miejsca, więc postanowiłem usunąć wszystkie dane, powiedzmy, z roku 2008. Po wykonaniu skasowanego zapytania (wyczyszczono około 10 000 000 wierszy) i wyczyszczeniu dziennika transakcji dowiedziałem się, że mój akcje nie miały wpływu na rozmiar bazy danych. Czy jest coś jeszcze do zrobienia?
Odpowiedzi:
Chociaż kurczenie się jest rzeczywiście niebezpieczne z powodów wymienionych tutaj. Pomiędzy odpowiedzią Jimbo a odpowiedzią Johna jest szczęśliwy środek ... Zawsze powinieneś poważnie rozważyć, czy chcesz zmniejszyć bazę danych.
W idealnym świecie - stworzyłbyś DB z dużą ilością wolnego miejsca, w którym mógłbyś rosnąć. Nazywam to „właściwym dopasowaniem” do swojej bazy danych. Pozwoliłbyś, aby ta wolna przestrzeń była na miejscu i nie starała się jej oddać i utrzymywała swój całkowity rozmiar dokładnie na użytym rozmiarze. Ponieważ twoja baza danych w końcu znów wzrośnie .. Wtedy znowu się skurczysz .. I utkniesz w tym okropnym wzorze bezużytecznych skurczów, po których następują wzrosty - i przez cały czas, jak niektórzy zauważyli, będziesz zwiększenie fragmentacji indeksu.
Napisałem o tym na blogu, gdzie napominałem ludzi, by „ Nie dotykaj tego przycisku zmniejszania! ”, Ale czasami… Czasami musisz. Jeśli masz dużą bazę danych, po prostu zwolniłeś znaczną ilość miejsca i nie spodziewaj się, że odrośnie w niej - cóż, możesz rozważyć skurczenie się jako operację jednorazową, o ile będziesz w stanie zająć się fragmentacją indeksu po odbudowie im. Operacja obkurczania może być czasochłonna, dlatego warto zaplanować ją na czas, w którym można zapłacić tę cenę za obkurczanie. Podejście polegające na tworzeniu pustej bazy danych i kopiowaniu do niej danych działa - ale może to stać się bardzo trudne w przypadku większych baz danych i dużej ilości danych.
Jeśli planujesz dodać tę przestrzeń z powrotem do bazy danych poprzez normalne wykorzystanie i wzorce wzrostu w przyszłości, możesz po prostu zostawić to miejsce.
Również
Powiedziałeś, że „wyczyściłeś” swój dziennik transakcji. Byłbym ciekawy, jak to zrobiłeś, ale kiedy czytasz post, który udostępniłem i inne w serii, zobaczysz kilka wskazówek na temat zarządzania dziennikiem transakcji. Ale w skrócie - jeśli jesteś w trybie pełnego odzyskiwania, powinieneś regularnie wykonywać kopie zapasowe dziennika, aby dziennik sam się nie używał. W przeciwnym razie - bez tworzenia kopii zapasowych dziennika w trybie pełnym - plik dziennika stale rośnie i rośnie i zawsze rośnie i zawsze zapisuje to, co zrobiłeś, ponieważ powiedziałeś SQLowi, że nie chcesz tylko utrzymywać tego dziennika w celu przywrócenia go po awarii, ale chcesz zachować ręczne tworzenie kopii zapasowej, aby odtworzyć transakcje / cofnąć transakcje, aby odzyskać dane do określonego momentu w celu odzyskania ... Jeśli jesteś prosty i widzisz nadmierny wzrost dziennika,BEGIN TRAN ... do work.... COMMIT TRANlub czy wydałeś tylko jedną dużą DELETEinstrukcję i usunąłeś cały bałagan danych w jednej niejawnej transakcji).
Zakładam również, że szukasz wolnego miejsca w systemie plików. Jeśli szukasz go w SQL i w tym dużym pliku, który masz - być może czekasz na zakończenie czyszczenia duchów, jeśli patrzysz bezpośrednio po operacji. Paul Randal bloguje o Ghost Cleanup .
Usunięcie wierszy w bazie danych nie zmniejszy rzeczywistego rozmiaru pliku bazy danych.
Musisz usunąć bazę danych po usunięciu wiersza.
SQL Server 2005 DBCC SHRINKDATABASE (Transact-SQL)
Po uruchomieniu tego będziesz chciał odbudować indeksy. Zmniejszenie zwykle powoduje fragmentację indeksu, co może być znaczącym kosztem wydajności.
Poleciłbym również, aby po zmniejszeniu pliki zostały ponownie powiększone, aby uzyskać trochę wolnego miejsca. W ten sposób, gdy pojawiają się nowe wiersze, nie wywołują automatycznego wzrostu. Autogrowth ma koszt wydajności i jest to coś, czego chciałbyś uniknąć (poprzez odpowiedni dobór bazy danych), gdy tylko jest to możliwe.
NIE WSTRZĄSUJ SWOJEJ BAZY DANYCH!
„Dlaczego tak się dzieje? Operacja zmniejszania plików danych działa pojedynczo na jednym pliku i wykorzystuje mapy bitowe GAM (patrz Inside The Storage Engine: GAM, SGAM, PFS i inne mapy alokacji), aby znaleźć najwyższą stronę przydzieloną w Następnie przesuwa go jak najdalej do przodu pliku, jak to możliwe, itd. W powyższym przypadku całkowicie odwrócił kolejność indeksu klastrowego, zmieniając go z idealnie zdefragmentowanego na idealnie rozdrobniony. „
http://www.sqlskills.com/BLOGS/PAUL/post/Why-you-should-not-shrink-your-data-files.aspx
„Spójrz na ironię kurczącej się bazy danych. Jedna osoba zmniejsza bazę danych, aby zyskać miejsce (myśląc, że zwiększy wydajność), co prowadzi do zwiększenia fragmentacji (zmniejszenia wydajności). Aby zmniejszyć fragmentację, odbudowuje się indeks, który prowadzi do wielkości bazy danych, aby zwiększyć ją znacznie bardziej niż pierwotny rozmiar bazy danych (przed zmniejszeniem). Cóż, zmniejszając, nie uzyskano tego, czego zwykle szukał. ”
Po usunięciu danych SQL Server rezerwuje miejsce do późniejszego wykorzystania do wstawiania nowych danych. Musisz zmniejszyć bazę danych. Więcej informacji znajdziesz tutaj .
Znalazłem to, ponieważ właśnie usunąłem kilka tabel kopii zapasowych, ponieważ moja baza danych „osiągnęła maksymalny poziom”. Patrzyłem na właściwość „Rozmiar”, zastanawiając się, dlaczego to się nie zmniejsza? . Po przeczytaniu tego nie nie chcę zmniejszać bazy danych. Chcę „odzyskać” miejsce na śmieci, które właśnie usunąłem. Musiałem się przyjrzeć „Dostępnej przestrzeni”. Myślę, że może to też ktoś inny może na to patrzeć .?*
Warto również zauważyć, że jeśli tabela zawiera indeksy, fragmentacja może istnieć po usunięciu dużych obszarów danych. Miałem dzisiaj stolik, który zawierał około 70 milionów rekordów, zajmując około 13 GB. Wyczyściłem go do 1639 rekordów (resztę wygenerował pojedynczy błąd), ale tabela nadal zajmowała około 4,5 GB. Po przebudowaniu wszystkich indeksów na stole zajmowało tylko 85 stron (680 kb). Następnie użyłem przyrostowego pliku zmniejszania, aby odzyskać miejsce (i naprawiłem błąd w systemie, aby zapobiec powtórzeniu).