Jak wykluczyć indeksy z kopii zapasowych w SQL Server 2008


19

Nasze nocne kopie zapasowe pełne (i okresowe różnicowe) stają się dość duże, głównie ze względu na liczbę indeksów na naszych stołach; mniej więcej połowa wielkości kopii zapasowej składa się z indeksów.

Do tworzenia kopii zapasowych używamy prostego modelu odzyskiwania.

Czy istnieje jakiś sposób, za pomocą FileGroupsinnej metody partycjonowania plików, aby wykluczyć indeksy z kopii zapasowych?

Byłoby miło, gdyby można to rozszerzyć również na katalogi pełnotekstowe.

Odpowiedzi:


15

Jeśli przełączysz się do trybu pełnego odzyskiwania, możesz to zrobić za pomocą aplikacjami, ale to naprawdę, naprawdę niezgrabne. Pozostaw dane w podstawowej grupie plików i umieść indeksy w osobnej (nie domyślnej, to jest kluczowej) grupie plików.

Następnie rozsuwasz kopie zapasowe, tak że co wieczór wykonujesz kopie zapasowe grupy plików i kopie zapasowe dziennika transakcji co X minut.

Po katastrofie przywracasz samą podstawową grupę plików. Dane są nagle w trybie online, ale indeksy nie. Aby jednak wrócić do normalności, musisz wyeksportować te dane do nowej czystej bazy danych i stamtąd dodać indeksy. Nie można całkowicie przełączyć bazy danych w tryb online bez przywracania wszystkich grup plików i nie można powiedzieć „I tak już nie potrzebuję tej innej grupy plików”.

Aby uzyskać więcej informacji o tym, jak to działa, zapoznaj się z moim samouczkiem wideo na temat przywracania aplikacjami.


Hehe, przeniosłem indeksy nieklastrowane do ich własnej grupy plików; model Simple Recovery całkowicie mnie zahamował. Indeksy były w rzeczywistości większe niż dane - jak mnie to drażniło! No cóż, być może trzecia strona wyda magiczną wskazówkę dotyczącą pocisku :)
Jarrod Dixon

1
Być może dostaniesz za to bezpłatne licencje. ;-)
Brent Ozar

5

Szczerze mówiąc, naprawdę nie chcesz tego robić, nawet jeśli rozwiążesz inne problemy, które poruszają inni.

Podczas przywracania kopii zapasowej w sytuacji awaryjnej nie chcesz czekać na przebudowanie indeksów, a do tego czasu będziesz odczuwać okropną wydajność.

Nie mogę wymyślić sytuacji, w której chciałbyś przywrócić kopię zapasową bez indeksów, więc we wszystkich przypadkach naprawdę będziesz chciał wykonać kopię zapasową w tym samym czasie.

Prawdopodobnie będziesz musiał poszukać innych rozwiązań tego problemu ...

-Adam


1
„nie chcesz czekać na odbudowanie indeksów” bardzo przypuszczalnie, IMO
Jeff Atwood

2
Tak, ale pamiętaj, że uogólniam tutaj. Nie byłem przekonany, że jest więcej sytuacji, w których lepiej jest porzucić indeksy i odbudować niż są sytuacje, w których lepiej jest wykonać kopię zapasową indeksów i uniknąć przebudowy. Innymi słowy, jeden przypadek jest generalnie lepszy i chyba że wymaga tego konkretna sytuacja, należy się pomylić ze strony jej tworzenia kopii zapasowej. Biorąc to pod uwagę, każda sytuacja jest inna. Jestem ciekawy, jak długo trwa odbudowanie indeksów SO i jak bardzo wydajność strony cierpi, dopóki nie zostaną ukończone (zakładając, że jest gotowa podczas przebudowy).
Adam Davis

Długoterminowe archiwizowanie kopii zapasowych to szczególny przypadek użycia, na który patrzę teraz, który doprowadził mnie do tego pytania. Mam projekt, który jest kompletny i nie chcę już bazy danych online, ale nie muszę też zaśmiecać naszego dysku sieciowego większym plikiem kopii zapasowej niż to konieczne. Nie chcę stracić definicji indeksu, ale nie miałbym nic przeciwko przebudowaniu ich, gdybym kiedykolwiek musiał to przywrócić.
richardtallent,

3

Brzmi tak, jakby to nie było obsługiwane. Z informacji o tym błędzie :

Wiele się w nim interesowało, więc przedstawię nieco więcej szczegółów na temat tego, co dzieje się za kulisami i co oznaczałoby wdrożenie tej funkcjonalności. Niektóre typy stron indeksu są podzielone na osobne jednostki alokacji, podczas gdy inne są pomieszane ze stronami danych. Tam, gdzie obecnie patrzymy tylko na mapę bitową alokacji, aby sprawdzić, czy zakres jest przydzielony, teraz musielibyśmy wejść i zinterpretować, co jest przechowywane w każdej jednostce alokacji. Co więcej, nie moglibyśmy teraz wykonać liniowego skanowania plików danych kopiujących dane, pomijalibyśmy ten plik. Cała ta interpretacja struktur danych drastycznie spowolniłaby tworzenie kopii zapasowych. Przywracanie staje się jeszcze bardziej interesujące, ponieważ istnieje wiele struktur, które trzeba będzie naprawić, aby uwzględnić luki w kopii zapasowej. W przeciwnym razie mapy alokacji wskazywałyby na strony, których nie utworzono kopii zapasowej, a więc zawierałyby śmieci itp. Itd. Tak więc wdrożenie tego oznaczałoby, że zaoszczędzilibyśmy mniej danych, zajęlibyśmy to dłużej i zajęlibyśmy dużo czasu już go przywracam. Innym aspektem, który należy wziąć pod uwagę, jest to, że potrzeba dużo wysiłku inżynierskiego, aby wszystko było w porządku. Chociaż na pozór nie stanowi to problemu, należy pamiętać, że oznacza to, że inne funkcje, które warto zobaczyć, nie zostaną zbudowane.


Nie byłoby to problemem w przypadku indeksów pełnotekstowych, prawda? Te wydają się być dość duże.
Michael Teper

1

może być szalonym pomysłem, ale proszę bardzo.

  1. upuść indeksy nieklastrowe, które zajmują dużo miejsca
  2. wykonać kopię zapasową
  3. ponownie utworzyć upuszczone indeksy

Oczywiście można to naprawdę zrobić tylko wtedy, gdy baza danych pozwala na pewne przestoje w ciągu dnia.

Ponadto nie upuszczaj indeksów klastrowych, ponieważ SQL Server marnuje dużo czasu na ich przekształcanie w stertę.

Czy zakup dodatkowej przestrzeni dyskowej wydaje się jeszcze łatwiejszym rozwiązaniem?

Czy rozważałeś robienie skompresowanych kopii zapasowych ? jest to nowa funkcja z 2008 roku, może być dla Ciebie opcją.


Tak, włączyliśmy kompresję dla kopii zapasowych, ale wbudowana kompresja nie jest taka świetna. W rzeczywistości wykonaliśmy nieskompresowaną kopię zapasową na koniec tygodnia, a następnie 7zip, aby nasi twórcy mogli ją obniżyć; ma rozmiar około 1/3, ale uruchomienie zajmuje trochę czasu!
Jarrod Dixon

Jeśli chodzi o przestoje DB, czy naprawdę moglibyśmy żyć bez serwerafault.com i stackoverflow.com w jak największym stopniu? Drżę na samą myśl :)
Jarrod Dixon

Sam tego nie testowałem, ale podejrzewałem tyle samo. Nie jest bardzo konfigurowalny. Jeśli nadal patrzysz na kompresję jako opcję, spójrz na SQL Lightspeed (droga, ale niesamowita, ale cena bardzo do negocjacji) i SQL Backup firmy RedGate. Bardzo konfigurowalne i doskonałe wyniki
Nick Kavadias
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.