Czy przywrócenie bazy danych SQL z kopii zapasowej odbudowuje jej indeksy?

10

Czy przywrócenie bazy danych SQL z kopii zapasowej odbudowuje jej tabele i indeksy od zera? Czy też utrzymuje go w tym samym wewnętrznym porządku fizycznym, w którym znajdował się w momencie tworzenia kopii zapasowej?

Używamy SQL 2000 z kompresowaną kopią zapasową Quest Lightspeed, jeśli to robi jakąkolwiek różnicę.

sql-server restore BradC
źródło

Odpowiedzi:

16

Odpowiedź brzmi: nie, niezależnie od używanego oprogramowania do tworzenia kopii zapasowych.

Kopia zapasowa jest operacją fizyczną, a nie logiczną. Odczytuje wszystkie zakresy zawierające przydzielone strony (tzn. Nawet jeśli przydzielona jest tylko jedna strona z 8-stronicowego zakresu, utworzy kopię zapasową całego zakresu 64K) i robi to w kolejności fizycznej.

Przywracanie jest operacją fizyczną, a nie logiczną. Określa zakresy w odpowiednich miejscach w plikach danych.

Odbudowanie indeksu (lub czegoś podobnego) jest logiczną operacją, którą należy zarejestrować. Kopie zapasowe i przywracanie manipulują plikami danych bezpośrednio, bez przechodzenia przez pulę buforów, co jest jednym z powodów, dla których nie można tego zrobić. Innym powodem, dla którego nie można tego zrobić, jest to, że tworzenie kopii zapasowych i przywracanie nie rozumieją, co zawiera dane, których kopie zapasowe wykonano.

Głównym powodem, dla którego nie można tego zrobić, jest to, że przenoszenie stron podczas operacji przywracania spowodowałoby uszkodzenie wskaźników b-drzewa. Jeśli strona A wskazuje stronę B, ale strona A jest przenoszona przez proces przywracania, w jaki sposób strona B jest aktualizowana, aby wskazywała stronę A? Jeśli zostanie zaktualizowany od razu, może zostać zastąpiony przez resztę procesu przywracania. Jeśli zostanie odroczona aktualizacja, co się stanie, jeśli proces przywracania przywróci dziennik transakcji, który usunął stronę A lub stronę B? Po prostu nie da się tego zrobić.

Konkluzja - tworzenie kopii zapasowych i przywracanie to operacje fizyczne, które nigdy nie zmieniają danych.

Mam nadzieję że to pomoże!

PS Chociaż nie odnosi się to bezpośrednio do tego pytania, sprawdź artykuł, który napisałem dla lipcowego magazynu TechNet, który wyjaśnia, w jaki sposób różne kopie zapasowe działają wewnętrznie: Zrozumienie kopii zapasowych SQL Server . Wrześniowy magazyn będzie miał kolejny z serii poświęconej przywracaniu zrozumienia.

Paul Randal
źródło
2
Podoba mi się to, że wyjaśniłeś, że indeksowanie jest operacją logiczną.
Jim B
Ach, to ma sens. Kopia zapasowa pobiera pełne 64k fizyczne zakresy, a nie 8k stron danych.
BradC
To nonsens. Operacje tworzenia kopii zapasowych często kompresują dane, których kopie zapasowe, o których mówimy: o tym, że indeksy można ponownie utworzyć z tabel, są to dane nadmiarowe (pod warunkiem, że kopia zapasowa schematu jest utworzona , oczywiście). Prawdziwym powodem jest lenistwo twórców baz danych.
John
1
@John Co mówisz, to bzdury? Nigdzie nie wspomina się tutaj o kompresji - po prostu odbudowuje indeksy, co nie jest w żaden sposób tożsame z kompresją (która nie zmienia stron ani ich lokalizacji w bazie danych podczas przywracania, podczas gdy przebudowa robi). Odtwarzanie indeksów od zera podczas przywracania byłoby niewiarygodnie wolne w porównaniu z przywracaniem ich bezpośrednio z kopii zapasowej. Myślę, że coś tu nie rozumiesz.
Paul Randal
Usuwanie i przebudowywanie indeksów jest rodzajem kompresji, a kompresja może zmienić wszystko, w zależności od rodzaju kompresji. Kompresja stratna w przetwarzaniu obrazu jest nadal nazywana kompresją. Każdy mechanizm reprezentujący dane informacje w mniejszej przestrzeni jest formą kompresji, a upuszczanie indeksów jest tego trywialnym przykładem. Powolny czas przebudowy może być rzeczywiście prawdziwym argumentem, przynajmniej wbrew temu, aby wdrożenie było wartościowym przedsięwzięciem.
John
6

Rodzimy backup SQL jest po prostu nora strona po stronie z plików kopii zapasowych, więc odpowiedzią jest „nie”. Kopia zapasowa Quest Lightspeed prawdopodobnie używa pewnego rodzaju algorytmu kompresji kompresji, ale nadal nie „odbuduje” plików danych lub indeksów, co zajęłoby strasznie dużo czasu w dużej bazie danych.

Aaron Alton
źródło
Tak, ale i tak musi zapisać każdą stronę na dysk. Dlaczego nie napisać ich w logicznej kolejności, zamiast w pofragmentowanej kolejności? (Być może jest to raczej pytanie o kopię zapasową niż pytanie o przywracanie : czy kopia zapasowa zapisuje strony w kolejności fizycznej, czy w kolejności logicznej?)
BradC,
zakładając, że istniał produkt, który zapisywał dane w kolejności indeksowej, w jakiej kolejności chciałbyś zapisać tabelę? Powiedzmy, że mam tabelę z 3 kolumnami id_produktu, nazwa produktu i cena. Którą kolumnę należy posortować, aby zapisać strony w indeksowanej kolejności? BTW, nic nie powstrzymuje Cię przed indeksowaniem całej tabeli (indeks klastrowany) lub każdego wiersza (indeks złożony).
Jim B
@ Jim B: To proste. Tabele byłyby zapisywane w kolejności indeksów klastrowych. Indeksy nieklastrowane byłyby przechowywane w kolejności kluczy. Sterty będą przechowywane w oryginalnej (nieposortowanej) kolejności. (Aaron i Paul podali uzasadnione powody, dla których kopia zapasowa / przywracanie tego nie robią. Brak możliwości ustalenia „preferowanej kolejności” nie jest jednym z tych powodów. W przeciwnym razie wykonanie pełnej przebudowy indeksu miałoby ten sam problem. )
BradC
Kopie zapasowe danych są wykonywane dokładnie w tej samej fizycznej kolejności stron, w której są zapisane w plikach bazy danych. Gdy dane są przywracane, są one przywracane w tej samej kolejności stron, w której zostały zapisane. SQL nie przenosi danych z różnych powodów. Włącznie z tym, że mogą występować problemy z transakcjami przywracającymi dzienniki i problemy z łańcuchem stron, nie wspominając o ogromnej ilości dodatkowego czasu potrzebnego do przetasowania danych w bazach danych o wielu TB.
mrdenny
2

Tworzenie kopii zapasowej odbywa się regularnie i bardzo często (mam nadzieję). Dlatego projektanci zadbali o to, aby tworzenie kopii zapasowych było jak najszybsze. Jakie jest najszybsze we / wy? Sekwencyjny. Czytasz bloki z dysków w dokładnie fizycznej kolejności, masz najlepszą wydajność.

Dlaczego, u licha, baza danych powinna wykonywać uciążliwą losową operację we / wy każdej nocy , niszcząc głowy dysków w każdym miejscu? Różnica wynosiłaby około dwóch rzędów wielkości. Nie ma w tym możliwego zysku.

kubańczyk
źródło
Zgadzam się z twoim ogólnym punktem, ale w zależności od podstawowej konfiguracji pamięci losowe operacje we / wy mogą nie być o rząd wielkości gorsze niż sekwencyjne operacje we / wy (na przykład dysk SAN rozłożony na dziesiątki wrzecion). W rzeczywistości, jeśli plik danych jest pofragmentowany na dysku twardym, to nawet „sekwencyjne” operacje wejścia / wyjścia wcale nie są sekwencyjne. Ale punkty Pawła i tak przesłaniają to (problem z aktualizacją wskaźników i defragmentacja powinna być
logowaną
0

Hmmm. BradC, czy pracowałeś już wcześniej z Firebird / Interbase - gdzie główne narzędzie do tworzenia kopii zapasowych / przywracania / API jest bardziej podobne do „Kopiuj bazę danych ...” SSMS / EM? Jeśli tak, wiedz, że MS SQL Server NIE jest podobny.

Kopia zapasowa SQLServer jest bardziej zrzutem bazy danych, który jest przywracany „TAK JAK JEST” - jest więc bardziej wygodnym skrótem online do operacji „odłącz-kopiuj-podłącz ponownie w innym miejscu”. Przywrócona baza danych jest prawie dokładną kopią oryginalnego pliku bazy danych (prawie dlatego, że można zmienić położenie plików bazy danych przywróconej bazy danych) ...

Fabricio Araujo
źródło