DBCC SHRINKDATABASE (Transact-SQL)

  • 07/17/2017
  • 8 minut na przeczytanie
    • p
    • M
    • .

    • j
    • i
    • K
    • +12

Applies to: SQL Server (wszystkie obsługiwane wersje) Azure SQL Database Azure Synapse Analytics

Zmniejsza rozmiar plików danych i dziennika we wskazanej bazie danych.

Konwencje składni języka Transact-SQL

Syntaktyka

DBCC SHRINKDATABASE ( database_name | database_id | 0 ) 
-- Azure Synapse AnalyticsDBCC SHRINKDATABASE ( database_name ) 

Uwaga

Aby wyświetlić składnię języka Transact-SQL dla programu SQL Server 2014 i wcześniejszych, zobacz Dokumentacja poprzednich wersji.

Argumenty

database_name | database_id | 0
Jest nazwą lub identyfikatorem bazy danych, która ma zostać zmniejszona. 0 określa, że używana jest bieżąca baza danych.

target_percent
Jest to procent wolnego miejsca w pliku bazy danych po zmniejszeniu bazy danych.

NOTRUNCATE
Przesuwa przypisane strony z końca pliku na nieprzypisane strony z przodu pliku. Ta akcja powoduje zagęszczenie danych w pliku. target_percent jest opcjonalne. Azure Synapse Analytics nie obsługuje tej opcji.

Wolne miejsce na końcu pliku nie jest zwracane do systemu operacyjnego, a fizyczny rozmiar pliku nie ulega zmianie. W związku z tym wydaje się, że baza danych nie zmniejsza się po określeniu opcji NOTRUNCATE.

NOTRUNCATE dotyczy tylko plików danych. NOTRUNCATE nie ma wpływu na plik dziennika.

TRUNCATEONLY
Zwalnia całe wolne miejsce na końcu pliku do systemu operacyjnego. Nie przesuwa żadnych stron wewnątrz pliku. Plik danych kurczy się tylko do ostatniego przydzielonego zakresu. Ignoruje wartość target_percent, jeśli została określona za pomocą TRUNCATEONLY. Program Azure Synapse Analytics nie obsługuje tej opcji.

TRUNCATEONLY wpływa na plik dziennika. Aby przyciąć tylko plik danych, należy użyć polecenia DBCC SHRINKFILE.

WITH NO_INFOMSGS
Wyłącza wszystkie komunikaty informacyjne, które mają poziomy dotkliwości od 0 do 10.

Zestawy wyników

W poniższej tabeli opisano kolumny w zestawie wyników.

Nazwa kolumny Opis
DbId Numer identyfikacyjny bazy danych pliku, który silnik bazy danych próbował zmniejszyć.
FileId Numer identyfikacyjny pliku, który próbował zmniejszyć silnik bazy danych.
CurrentSize Liczba stron 8-KB, które obecnie zajmuje plik.
MinimumSize Liczba stron 8-KB, które mógłby zajmować plik, przy minimalnym rozmiarze. Ta wartość odpowiada minimalnemu rozmiarowi lub oryginalnie utworzonemu rozmiarowi pliku.
UsedPages Liczba stron 8-KB obecnie używanych przez plik.
EstimatedPages Liczba stron 8-KB, do których według szacunków Database Engine plik mógłby zostać zmniejszony.

Uwaga

Maszyna bazy danych nie wyświetla wierszy dla plików, które nie zostały zmniejszone.

Uwagi

Uwaga

Wykonanie tego polecenia nie jest zalecane, ponieważ jest to operacja wymagająca i/o i może spowodować wyłączenie hurtowni danych. Ponadto po uruchomieniu tego polecenia migawki hurtowni danych będą miały wpływ na koszty.

Aby zmniejszyć wszystkie pliki danych i dziennika dla określonej bazy danych, wykonaj polecenie DBCC SHRINKDATABASE. Aby zmniejszyć jeden plik danych lub plik dziennika na raz dla określonej bazy danych, wykonaj polecenie DBCC SHRINKFILE.

Aby wyświetlić bieżącą ilość wolnego (nieprzydzielonego) miejsca w bazie danych, uruchom polecenie sp_spaceused.

Operacje DBCC SHRINKDATABASE można zatrzymać w dowolnym momencie procesu, a wszelkie zakończone prace są zachowywane.

Baza danych nie może być mniejsza niż skonfigurowany minimalny rozmiar bazy danych. Minimalny rozmiar jest określany podczas pierwotnego tworzenia bazy danych. Lub, minimalny rozmiar może być ostatnim rozmiarem ustawionym jawnie przez użycie operacji zmiany rozmiaru pliku. Operacje takie jak DBCC SHRINKFILE lub ALTER DATABASE są przykładami operacji zmiany rozmiaru pliku.

Powiedzmy, że baza danych jest pierwotnie utworzona z rozmiarem 10 MB. Następnie rozrasta się ona do 100 MB. Najmniejsza baza danych, do jakiej można ją zmniejszyć, to 10 MB, nawet jeśli wszystkie dane w bazie danych zostały usunięte.

Podać opcję NOTRUNCATE lub opcję TRUNCATEONLY podczas uruchamiania DBCC SHRINKDATABASE. Jeśli tego nie zrobisz, wynik będzie taki sam, jak w przypadku uruchomienia operacji DBCC SHRINKDATABASE z opcją NOTRUNCATE, a następnie operacji DBCC SHRINKDATABASE z opcją TRUNCATEONLY.

Obkurczona baza danych nie musi być w trybie jednego użytkownika. Inni użytkownicy mogą pracować na bazie danych, gdy jest ona zmniejszana, włączając w to systemowe bazy danych.

Nie można zmniejszać bazy danych podczas wykonywania kopii zapasowej. I odwrotnie, nie można wykonać kopii zapasowej bazy danych, gdy trwa operacja zmniejszania bazy danych.

Jak działa DBCC SHRINKDATABASE

DBCC SHRINKDATABASE zmniejsza pliki danych na podstawie pojedynczych plików, ale zmniejsza pliki dziennika tak, jakby wszystkie pliki dziennika istniały w jednym ciągłym zbiorze dziennika. Pliki są zawsze obkurczane od końca.

Załóżmy, że masz kilka plików dziennika, plik danych i bazę danych o nazwie mydb. Pliki danych i dziennika mają po 10 MB każdy, a plik danych zawiera 6 MB danych. Silnik bazy danych oblicza rozmiar docelowy dla każdego pliku. Wartość ta jest rozmiarem, do którego plik ma zostać zmniejszony. Jeśli DBCC SHRINKDATABASE jest określone z target_percent, silnik bazy danych oblicza rozmiar docelowy jako docelowy_percent ilości wolnego miejsca w pliku po zmniejszeniu.

Na przykład, jeśli określisz target_percent 25 dla zmniejszania mydb, silnik bazy danych oblicza rozmiar docelowy dla pliku danych jako 8 MB (6 MB danych plus 2 MB wolnego miejsca). Silnik bazy danych przenosi dane z ostatnich 2 MB do wolnego miejsca w pierwszych 8 MB, a następnie zmniejsza plik.

Załóżmy, że plik danych mydb zawiera 7 MB danych. Określenie target_percent na 30 pozwala na zmniejszenie tego pliku danych do wolnej wartości procentowej 30. Jednak określenie wartości target_percent równej 40 nie zmniejszy pliku danych, ponieważ Database Engine nie zmniejszy pliku do rozmiaru mniejszego niż dane aktualnie zajmowane.

Można również pomyśleć o tym problemie w inny sposób: 40 procent poszukiwanej wolnej przestrzeni + 70 procent pełnego pliku danych (7 MB z 10 MB) to więcej niż 100 procent. Jakikolwiek target_size większy niż 30 nie zmniejszy pliku danych. Nie zmniejszy się, ponieważ procent wolnego miejsca, który chcesz plus bieżący procent, który zajmuje plik danych jest ponad 100 procent.

Dla plików dziennika, silnik bazy danych używa target_percent do obliczenia rozmiaru docelowego dla całego dziennika. Dlatego target_percent jest ilością wolnego miejsca w dzienniku po operacji zmniejszania. Rozmiar docelowy dla całego dziennika jest następnie tłumaczony na rozmiar docelowy dla każdego pliku dziennika.

DBCC SHRINKDATABASE próbuje zmniejszyć każdy fizyczny plik dziennika do jego rozmiaru docelowego natychmiast. Powiedzmy, że żadna część dziennika logicznego nie pozostaje w dziennikach wirtualnych poza docelowym rozmiarem pliku dziennika. Wtedy plik zostanie pomyślnie obcięty, a DBCC SHRINKDATABASE zakończy pracę bez żadnych komunikatów. Jeśli jednak część logu logicznego pozostanie w logach wirtualnych poza rozmiarem docelowym, silnik bazy danych zwolni tyle miejsca, ile to możliwe, a następnie wyświetli komunikat informacyjny. Komunikat opisuje, jakie czynności należy wykonać, aby usunąć dziennik logiczny z dzienników wirtualnych na koniec pliku. Po wykonaniu tych czynności można użyć polecenia DBCC SHRINKDATABASE, aby zwolnić pozostałe miejsce.

Plik dziennika może zostać zmniejszony tylko do granicy wirtualnego pliku dziennika. Z tego powodu zmniejszenie pliku dziennika do rozmiaru mniejszego niż rozmiar wirtualnego pliku dziennika może nie być możliwe. Może to nie być możliwe nawet jeśli nie jest używany. Rozmiar wirtualnego pliku dziennika jest wybierany dynamicznie przez silnik bazy danych podczas tworzenia lub rozszerzania plików dziennika.

Najlepsze praktyki

Podczas operacji zmniejszania bazy danych należy wziąć pod uwagę następujące informacje:

  • Operacja zmniejszania jest najbardziej efektywna po operacji, która tworzy niewykorzystane miejsce, takiej jak operacja przycinania tabeli lub upuszczania tabeli.
  • Większość baz danych wymaga pewnej ilości wolnego miejsca dostępnego dla zwykłych codziennych operacji. Możesz wielokrotnie zmniejszać bazę danych i zauważyć, że jej rozmiar ponownie rośnie. Wzrost ten wskazuje na to, że zmniejszona przestrzeń jest wymagana do regularnych operacji. W takich przypadkach wielokrotne zmniejszanie bazy danych jest niepotrzebną operacją.
  • Operacja zmniejszania nie zachowuje stanu fragmentacji indeksów w bazie danych i ogólnie zwiększa fragmentację do pewnego stopnia. Ten wynik jest kolejnym powodem, aby nie zmniejszać wielokrotnie bazy danych.
  • Bez szczególnych wymagań nie należy ustawiać opcji bazy danych AUTO_SHRINK na ON.

Rozwiązywanie problemów

Możliwe jest zablokowanie operacji zmniejszania przez transakcję, która działa na poziomie izolacji opartym na wersjonowaniu wierszy. Na przykład, duża operacja usuwania działająca na poziomie izolacji opartym na wersjonowaniu wierszy jest w toku, gdy wykonywana jest operacja DBCC SHRINK DATABASE. Gdy taka sytuacja ma miejsce, operacja zmniejszania będzie czekać na zakończenie operacji usuwania, zanim zmniejszy pliki. Gdy operacja zmniejszania czeka, operacje DBCC SHRINKFILE i DBCC SHRINKDATABASE drukują komunikat informacyjny (5202 dla SHRINKDATABASE i 5203 dla SHRINKFILE). Komunikat ten drukuje się do dziennika błędów SQL Server co pięć minut w pierwszej godzinie, a następnie co następną godzinę. Na przykład, jeśli log błędów zawiera następujący komunikat:

DBCC SHRINKDATABASE for database ID 9 is waiting for the snapshot transaction with timestamp 15 and other snapshot transactions linked to timestamp 15 or with timestamps older than 109 to finish. 

Błąd ten oznacza, że transakcje snapshot, które mają znaczniki czasowe starsze niż 109 blokują operację zmniejszania. Ta transakcja jest ostatnią transakcją, która zakończyła operację zmniejszania. Wskazuje również, że kolumny transaction_sequence_num lub first_snapshot_sequence_num w dynamicznym widoku zarządzania sys.dm_tran_active_snapshot_database_transactions (Transact-SQL) zawierają wartość 15. Kolumna transaction_sequence_num lub first_snapshot_sequence_num w widoku może zawierać liczbę, która jest mniejsza niż ostatnia transakcja zakończona przez operację zmniejszania (109). Jeśli tak, operacja zmniejszania będzie czekać na zakończenie tych transakcji.

Aby rozwiązać problem, można wykonać jedno z następujących zadań:

  • Zakończ transakcję, która blokuje operację zmniejszania.
  • Zakończ operację zmniejszania. Wszelkie zakończone prace są zachowywane.
  • Nie rób nic i pozwól operacji kurczenia czekać, aż zakończy się blokująca transakcja.

Uprawnienia

Wymaga członkostwa w stałej roli serwera sysadmin lub stałej roli bazy danych db_owner.

Przykłady

A. Zmniejszanie bazy danych i określanie procentu wolnego miejsca

Następujący przykład zmniejsza rozmiar plików danych i dziennika w bazie danych użytkownika UserDB, aby zapewnić 10 procent wolnego miejsca w bazie danych.

DBCC SHRINKDATABASE (UserDB, 10); GO 

B. Przycinanie bazy danych

Następujący przykład zmniejsza pliki danych i dziennika w przykładowej bazie danych AdventureWorks do ostatniego przypisanego zakresu.

DBCC SHRINKDATABASE (AdventureWorks2012, TRUNCATEONLY); 

C. Zmniejszanie bazy danych Azure Synapse Analytics

DBCC SHRINKDATABASE (database_A);DBCC SHRINKDATABASE (database_B, 10); 

Zobacz także

ALTER DATABASE (Transact-SQL)
DBCC (Transact-SQL)
DBCC SHRINKFILE (Transact-SQL)
Shrink a Database

.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.