Uruchamianie poleceń DBCC Shrink jest dość kontrowersyjnym problemem w społeczności SQL Server. W tym artykule przejrzymy szczegóły dotyczące tego polecenia i przedstawimy krótki przegląd jego użycia, a także ostrzeżemy o ryzyku związanym z uruchomieniem tego polecenia. Jako administratorzy baz danych wiele baz danych zostało przekazanych od innych zespołów lub dostawców i nie zawsze zarządzamy bazami danych, które stworzyliśmy. Jako administratorzy baz danych, za każdym razem, gdy jesteśmy zaangażowani w migracje lub nowe projekty, musimy upewnić się, że starannie planujemy płynne przejście bazy danych do środowiska produkcyjnego i do regularnego użytkowania. Na tym etapie musimy uwzględnić rozmiar bazy danych. Czy możesz sobie wyobrazić, że konfigurujesz aplikację bazodanową bez uwzględniania prognozy wzrostu na pierwszy rok. Co powiesz na utworzenie bazy danych SQL Server o tak małym rozmiarze, że musi rosnąć co drugi dzień, zwiększając liczbę alertów dotyczących pojemności dysku w środku nocy? Może to zabrzmieć głupio, ale w rzeczywistości tak się dzieje i czasami może to nie być pod Twoją kontrolą.
Kilka punktów do rozważenia w przypadku proaktywnego DBA
Przed przejęciem obsługi produkcyjnych baz danych koniecznie sprawdź ze swoim poprzednikiem, jakie są prognozy wzrostu bazy danych. Czy początkowy rozmiar baz danych, którymi będziesz zarządzał, jest odpowiednio dopasowany? Nie przejmuj się zbytnio, jeśli obecny rozmiar bazy danych jest znacznie większy niż dane, które obecnie posiada. Pamiętaj, że nie chcesz, aby rozmowy dotyczące pojemności dysku odbywały się o 3:00 nad ranem, kiedy mógłbyś tego całkowicie uniknąć, mając bazę danych o odpowiednim rozmiarze. Jest to ogólna tendencja dla administratorów baz danych w całej branży do poświęcania życia późno w nocy z powodu przyziemnych problemów, które w ogóle nie powinny mieć miejsca. Oprócz rozmiaru bazy danych należy również wziąć pod uwagę pojemność dysku serwera. Nie chcesz, aby rozmiar dysku był zbyt mały, niż może pomieścić baza danych. To wszystko są proste rzeczy, które przydają się podczas planowania. Jednak, jak wiadomo, nie zawsze jest to specjalista od baz danych, który w pierwszej kolejności instaluje lub konfiguruje bazy danych. Ważnym punktem, na który należy zwrócić uwagę, jest prawidłowe opanowanie bazy danych pod względem rozmiaru i może nie być konieczne uruchamianie tego polecenia. Jednak, jak zawsze, jako administrator baz danych, zdarzają się sytuacje, w których sprawy mogą nie być pod twoją kontrolą i w tym czasie możesz używać poleceń pliku DBCC Shrink w celu efektywnego wykorzystania.
Kiedy mogę używać DBCC ShrinkFile?
Właśnie otrzymałeś powiadomienie o miejscu na dysku w środku snu i masz do spełnienia ścisłe SLA. Poziom priorytetu to P2 i umowa SLA może wkrótce zostać naruszona. I zdajesz sobie sprawę, że rozszerzenie dysku nie nastąpi w najbliższym czasie, cóż, w takim przypadku miej pod ręką polecenia DBCC ShrinkFile, abyś mógł ich użyć do odzyskania miejsca. Jak sama nazwa wskazuje, zmniejsza plik danych lub plik dziennika bazy danych. Ale zanim zaczniesz uruchamiać polecenia DBCC ShrinkFile, spróbuj najpierw sprawdzić, dlaczego plik bazy danych rośnie.
- Czy plik urósł z powodu jakiejś długotrwałej transakcji?
- Czy na serwerze jest jakieś blokowanie?
- Czy wydarzy się jakaś ważna wersja aplikacji, o której nie zostałeś poinformowany? (Dzieje się tak przez większość czasu)
- Czy istnieje jakiś problem z replikacją lub dublowaniem bazy danych powodującym wzrost bazy danych?
Ważne jest, aby jak najszybciej uzyskać odpowiedzi na te pytania. Generalnie istnieje jedna odpowiedź na wszystkie te pytania i jest to świetne darmowe narzędzie o nazwie sp_whoisactive. Nie ma słów, aby opisać ogromne wykorzystanie tego narzędzia i wielokrotnie używałem go do rozwiązywania wielu problemów związanych z produkcją. Możesz pobrać najnowszy kod z tego linku:http://whoisactive.com/ . Jest łatwy i prosty w użyciu i zwraca dane wyjściowe w krótkim czasie. Jeśli jesteś doświadczonym DBA, będziesz już miał to do swojej dyspozycji.
DBCC ShrinkFile z przykładami
Składnia DBCC ShrinkFile jest prosta i nieskomplikowana, zapoznaj się z poniższym przykładem.
use YOURDATABASE go DBCC Shrinkfile(FileName,1024)
Powyższy przykład zmniejsza nazwę pliku należącą do bazy danych YOURDATABASE do 1024 MB. Tę samą operację można wykonać przy użyciu programu SQL Server Management Studio (SSMS). Kliknij bazę danych prawym przyciskiem myszy, przejdź do Zadania , wybierz Zmniejsz , a następnie Pliki .
Po kliknięciu Pliki , otrzymasz to okno.
Tutaj masz możliwość wybrania typu pliku:Dane, Dziennik lub Dane strumienia plików i wykonanie czynności „Zmniejsz” zgodnie z wymaganiami. Łatwiej jest użyć samego polecenia DBCC do celów zmniejszania.
Korzystanie z DBCC ShrinkFile z dodatkowymi opcjami
Możesz uruchomić polecenie DBCC ShrinkFile z dodatkowymi opcjami – emptyfile, notruncate lub truncateonly.
Pusty plik
Możesz użyć polecenia emptyfile, jak poniżej.
use YOURDATABASE go dbcc shrinkfile(FileName,emptyfile)
Pomoże to przenieść dane do innych plików w tej samej grupie plików. Po zakończeniu będziesz mógł usunąć plik bazy danych, jeśli nie jest już potrzebny. Jest jednak kilka rzeczy, na które należy zwrócić uwagę w przypadku tej opcji emptyfile, ponieważ nie można wiele zrobić, aby opróżnić zawartość podstawowego pliku danych z identyfikatorem pliku 1. Aby uzyskać numer identyfikatora pliku, uruchom ten skrypt.
select file_id, name,physical_name from sys.database_files
W tym przykładzie nazwa pliku to „mo”, a identyfikator_pliku to 1. Gdy spróbujesz opróżnić plik mo, który ma identyfikator_pliku 1, pojawi się ten komunikat o błędzie.
Dzieje się tak, ponieważ w oryginalnym pliku znajdują się informacje systemowe, których nie można usunąć. Ale jeśli spróbujesz tego samego polecenia na innym pliku danych „mo2data”, polecenie pustego pliku powiedzie się.
Nieskanuj
Jak sama nazwa wskazuje, nie ma miejsca zwolnionego z powrotem do systemu operacyjnego. Przypomina to bardziej wewnętrzną operację w pliku, w której strony są rozprowadzane w samym pliku bez zmiany całkowitego rozmiaru pliku bazy danych. Z tego powodu istnieje duże prawdopodobieństwo wprowadzenia fragmentacji. Zobacz przykład poniżej.
-- Example only Use YourDatabase go DBCC SHRINKFILE (filename,notruncate); GO
Tylko skróć
Jak sama nazwa wskazuje, wolne miejsce zostanie zwolnione z powrotem do systemu operacyjnego od końca pliku. Jest to zdecydowanie najbezpieczniejsza operacja, jaką można uruchomić za pomocą DBCC ShrinkFile. Zobacz przykład poniżej.
-- Example only Use YourDatabase go DBCC SHRINKFILE (filename,truncateonly); GO
Co zrobić, gdy DBCC ShrinkFile w dzienniku transakcji nie działa zgodnie z oczekiwaniami? Skorzystaj z tej bezpiecznej metody, aby rozwiązać problem
Czasami to polecenie może nie działać zgodnie z oczekiwaniami. Zakładając, że masz sytuację, w której próbujesz zmniejszyć plik dziennika bazy danych i wydaje się, że to nie działa. Poniżej znajduje się kilka kroków, które możesz podjąć, aby zrozumieć, dlaczego kurczenie nie działa zgodnie z oczekiwaniami. Zauważysz, że plik zmniejszania będzie wyświetlany jako pomyślny, jednak nie ma zmniejszenia rozmiaru pliku dziennika. W takim przypadku uruchom to polecenie, aby sprawdzić kilka rzeczy dotyczących użycia pliku dziennika.
select name,log_reuse_wait_desc,* from sys.databases
Na zrzucie ekranu widać, że kolumna log_reuse_wait_desc czeka na utworzenie kopii zapasowej dziennika.
Tutaj widać, że kopia zapasowa dziennika bazy danych musi zostać wykonana, zanim naprawdę można zmniejszyć plik dziennika. Jeśli znajduje się to w produkcyjnej bazie danych, spróbuj wykonać kopię zapasową dziennika na innym dysku, na którym jest dostępne miejsce. Aby wykonać kopię zapasową dziennika, użyj przykładowego polecenia poniżej.
backup log DBName to disk='C:\Program Files\Microsoft SQL Server\MSSQL15.A1\MSSQL\Backup\DBName.trn' with init,stats,compression
Po uruchomieniu polecenia kopii zapasowej uruchom ponownie poniższe polecenie, aby zobaczyć stan kolumny log_reuse_wait_desc.
select name,log_reuse_wait_desc,* from sys.databases
Na zrzucie ekranu widać, że status kolumny log_reuse_wait_desc zmienił się na „Nic”.
Tutaj możesz zobaczyć, że status kolumny „log_reuse_wait_desc” zmienił się na „Nic”. W Twoim przypadku może nadal wyświetlać się jako „LOG_BACKUP”. Kontynuuj wykonywanie kopii zapasowych dziennika bazy danych, aż stan zmieni się na „Nic”. Powodem, dla którego nadal możesz widzieć status „LOG_BACKUP”, nawet po wykonaniu kopii zapasowej dziennika transakcji, jest to, że po wykonaniu kopii zapasowej dziennika transakcji nie zostały wyczyszczone żadne pliki VLF. VLF oznacza wirtualne pliki dziennika i jest częścią wewnętrznej architektury dziennika transakcji. Pliki dziennika transakcji składają się z tych plików VLF. Możesz uzyskać informacje o VLF, uruchamiając to polecenie.
select * from sys.dm_db_log_info(5)
Tutaj 5 reprezentuje database_id. Wyświetlany jest zrzut ekranu z danymi wyjściowymi. Liczba zwróconych wierszy reprezentuje rzeczywistą liczbę wirtualnych plików dziennika (VLF) w bazie danych. Możesz sprawdzić kolumnę „vlf_status”, aby sprawdzić stan wirtualnego pliku dziennika. Wartość 2 oznacza, że jest aktywny. Za pomocą tego polecenia możesz sprawdzić wewnętrzne flagi w pliku dziennika transakcji, aby zrozumieć, dlaczego dziennik transakcji nie jest zwalniany nawet po wykonaniu kopii zapasowej dziennika.
Wcześniej użyto polecenia DBCC LOGINFO, które dostarczało podobnych informacji.
Co zrobić, gdy DBCC ShrinkFile w dzienniku transakcji nie działa zgodnie z oczekiwaniami? Coś, co możesz wykonać w środowisku nieprodukcyjnym. Jednak nie jest to zalecane w środowisku produkcyjnym
Na wielu stronach internetowych można by natknąć się na ludzi zalecających zmianę modelu odzyskiwania na prosty, a następnie uruchomienie pliku zmniejszającego, aby zwolnić miejsce z powrotem do systemu operacyjnego. Należy pamiętać, że zmiana modelu odzyskiwania na prosty wpłynie na odzyskiwanie bazy danych, ponieważ nie będzie możliwe odzyskanie do określonego momentu. To znowu zależy od Twojej biznesowej umowy SLA. Możesz zmienić model odzyskiwania za pomocą T-SQL (poniżej) lub za pomocą GUI.
alter database DB_NAME set recovery simple
Korzystając z GUI, zmień model odzyskiwania, jak pokazano. Kliknij prawym przyciskiem myszy bazę danych, przejdź do „Właściwości”, kliknij „Opcje”. W sekcji „Opcje” wybierz „Model odzyskiwania”.
Zauważysz, że sama zmiana modelu odzyskiwania na Simple nie zwolni miejsca z powrotem do systemu operacyjnego. Musisz jawnie uruchomić polecenie DBCC ShrinkFile, aby zmniejszyć plik i odzyskać miejsce. Zobacz przykładowy skrypt poniżej. To polecenie zmniejszy nazwę pliku do 1024 MB.
use YOURDATABASE go DBCC Shrinkfile(FileName,1024)
Opcja bazy danych automatycznego zmniejszania
Zauważysz, że we właściwościach bazy danych istnieje opcja znana jako „Automatyczne zmniejszanie”. Wystarczy kliknąć prawym przyciskiem myszy bazę danych, aby wyświetlić właściwość bazy danych. W sekcji opcji zobaczysz tę opcję, jak pokazano. Z ustawienia bazy danych modelu widać, że opcja „Automatyczne zmniejszanie” jest domyślnie wyłączona. Tak więc za każdym razem, gdy tworzona jest jakakolwiek nowa baza danych, ta opcja również jest wyłączona. W niektórych przypadkach specjaliści od baz danych mogą nieświadomie pozostawić tę opcję włączoną, nie zdając sobie sprawy z negatywnych konsekwencji pozostawienia jej włączonej.
Uruchom to polecenie, aby sprawdzić stan tej opcji dla baz danych na serwerze.
select name,is_auto_shrink_on,* from sys.databases
Zobaczysz to wyjście.
Jeśli przypadkiem zauważysz, że jest włączony, możesz go wyłączyć za pomocą GUI lub możesz uruchomić poniższe polecenie w bazie danych.
ALTER DATABASE YOUR_DATABASE set AUTO_SHRINK OFF
Inne sugestie dotyczące konserwacji
Zapoznaj się z tymi kilkoma dodatkowymi wskazówkami, aby uniknąć problemu ze wzrostem bazy danych, z powodu którego musisz uruchamiać polecenia DBCC ShrinkFile.
- Upewnij się, że model odzyskiwania Twoich baz danych jest zgodny z biznesowymi umowami SLA. Jeśli Twoja firma nie wymaga odzyskiwania testowych baz danych do określonego momentu, po prostu pozostaw je w modelu odzyskiwania prostego. Widziałem wiele okazji, w których model odzyskiwania baz danych był kompletny, gdy wszystko było w porządku z odzyskiwaniem przy użyciu najnowszej pełnej kopii zapasowej
- Zapewnij właściwe monitorowanie, zwłaszcza w przypadku wzrostu bazy danych. Powinieneś zostać ostrzeżony, gdy wykorzystanie pliku dziennika osiągnie 85%. To da ci trochę czasu na rozwiązanie problemu z kosmosem
- Upewnij się, że regularne kopie zapasowe dziennika są tworzone, jeśli baza danych jest w modelu pełnego odzyskiwania i powinieneś zostać ostrzeżony, jeśli którakolwiek z kopii zapasowych dziennika nie powiedzie się
- Upewnij się, że na dyskach bazy danych jest wystarczająca ilość miejsca, aby uniknąć problemów z brakiem miejsca
- W przypadku baz danych, które można archiwizować, opracuj kilka strategii archiwizacji, aby móc przenieść starsze dane do innej bazy danych w celu tworzenia raportów i uczynić tę bazę tylko do odczytu. Zapewni to większą kontrolę w zakresie rozmiaru bazy danych
- Upewnij się, że regularnie przeprowadzasz kontrole integralności bazy danych za pomocą DBCC CheckDB. Więcej informacji można znaleźć w tym artykule:https://codingsight.com/dbcc-checkdb-overview/
Wniosek
- Z tego artykułu dobrze rozumiesz używanie polecenia DBCC ShrinkFile
- Poznałeś ryzyko związane z uruchamianiem poleceń DBCC ShrinkFile
- Poznałeś różne opcje, które możemy zapewnić za pomocą poleceń DBCC ShrinkFile
- Widziałeś opcje, które możemy wypróbować, jeśli dziennik transakcji nie zmniejsza się za pomocą poleceń DBCC ShrinkFile
- Poznałeś domyślne ustawienie automatycznego zmniejszania we właściwości bazy danych
- Poznałeś również inne sugestie dotyczące konserwacji bazy danych, aby utrzymać bazy danych w dobrym stanie
- Na koniec upewnij się, że jesteś gotowy w każdym przypadku na te dni OFF, które mogą nie być pod Twoją kontrolą
