- Skrócony czas podtrzymania
- Równoległe wykorzystanie wielu dysków i plików.
- Korzystanie z wielu kart sieciowych
- Zalecenia dotyczące całkowitej liczby używanych plików
- Dodatkowe sposoby optymalizacji i rekomendacji
- Duże ramki
- BLOCKSIZE
- BUFFERCOUNT i MAXTRANSFERSIZE
- Kompresja kopii zapasowej
- Zalecenia sprzętowe dla serwerów do przechowywania plików
- Konfiguracja kontrolera nalotu
- Konfiguracja HBA
- Systemy oparte na NUMA
- Obliczanie czasu potrzebnego do utworzenia kopii zapasowej i przywrócenia bazy danych
- Wniosek
Kopiowanie dwubajtowej bazy danych na lokalne dyski twarde, a następnie przywracanie jej, spełnia tymczasowe wymagania przywracania naszego systemu SQL Server. Jednak ten prosty proces nie może zapewnić odpowiedniej ochrony przed kompletnymi scenariuszami awarii sformalizowanymi w umowie SLA. Z drugiej strony, skopiowanie bazy danych przez sieć do zdalnego repozytorium może zapewnić ochronę przed całkowitą awarią. Problem może być spowodowany ograniczeniem wynikającym z przepustowości sieci, która zwykle nie przekracza 1 Gigabit na sekundę (Gbps). Kiedy badaliśmy tę sytuację, głównym kryterium porównywania wydajności było kopiowanie danych przez sieć 1 Gb / s na odległość 10 mil do innego centrum danych. Proces ten trwał ponad 24 godziny, co było całkowicie nie do przyjęcia. Konieczne było znalezienie rozwiązania, które umożliwiłoby wykonywanie kopii zapasowych w oknie czasowym odzyskiwania określonym w umowie SLA.
Dzięki kompleksowemu przemyśleniu wszystkich aspektów problemu redundancji w sieci i przeprowadzeniu wielu testów udało nam się zmniejszyć bazę danych kopii zapasowej w 2 TB do 36 minut. Rozwiązanie, które nazwaliśmy „wielowątkową kopią zapasową przez sieć” (w oryginale: „wieloprzetworzone kopie zapasowe przez sieć”), wykorzystywało osiem połączeń sieciowych po 1 Gb / s. Powiększony rozmiar ramki został określony w ustawieniach każdej karty sieciowej, a każda karta sieciowa została podłączona do linii 10GE (10Gbit Ethernet), która została zduplikowana przez drugi przełącznik poziomu, który rozciągnął się na drugą stronę. Sam backup trwał 2 godziny i 25 minut. Pojawił się w SQL Server 2008 kompresja kopii zapasowej pozwolono skrócić ten czas do 36 minut. Baza danych składała się z 32 plików danych i jednego pliku dziennika transakcji, które zajmowały około 2,5 terabajta na 9 dyskach logicznych (pliki danych znajdowały się w pamięci dyskowej klasy korporacyjnej - SAN, a dzienniki transakcji na dyskach lokalnych - DAS). Poniższa tabela pokazuje czas trwania kopii zapasowej w zwykły sposób oraz dwa najszybsze sposoby tworzenia kopii zapasowej przez sieć. Szczegółowy opis każdego wdrożenia znajduje się poniżej.
Próba Czas trwania sieci Zwykły sposób Jedna karta sieciowa 1 Gb / s, konfiguracja domyślna> 24 godziny Wielowątkowa kopia zapasowa sieci dla kart sieciowych 8x1 Gb / s, gigantyczna ramka 2 godziny 25 minut Wielowątkowa kopia zapasowa sieci z kompresją kart sieciowych 8x1 Gb / s, gigantyczna ramka 36 minut
Tabela 1: Czas trwania kopii zapasowej 2 TB na serwer 10 mil w sieci
Skrócony czas podtrzymania
Istnieją dwa sposoby zwiększenia szybkości wykonywania kopii zapasowej: optymalizacja i równoległość.
Najpierw spójrzmy na wewnętrzne urządzenie do tworzenia kopii zapasowych. Liczba wątków obsługujących kopię zapasową zależy od liczby dysków logicznych - woluminów używanych dla plików bazy danych i liczby urządzeń do tworzenia kopii zapasowych. Jest to bardzo ważne, ponieważ ten fakt pozwala kontrolować stopień równoległości kopii zapasowej. Do tej pory polegaliśmy na schemacie alokacji plików pokazanym na poniższym rysunku. Jednym ze sposobów poprawy wydajności tego schematu jest zwiększenie liczby dysków i plików umieszczonych na różnych dyskach, co zostanie opisane w następnej sekcji.
Równoległe wykorzystanie wielu dysków i plików.
Jednym ze sposobów poprawy wydajności jest zwiększenie liczby umieszczonych na nich dysków i plików. Zobaczmy, co się stanie, jeśli dodamy dyski logiczne (oddzielne jednostki LUN) dla każdego serwera i umieścimy bazę danych i pliki kopii zapasowych na tych dodatkowych dyskach logicznych.
Poniżej znajduje się polecenie, które wykonuje kopię zapasową w dwóch plikach.
BACKUP DATABASE MyVLDB
TO DISK = 'BAK01 backup MyVLDB00000001_1.bak',
DISK = 'BAK01 backup MyVLDB00000001_2.bak'
Z CHECKSUM, INIT;
To użycie polecenia tworzenia kopii zapasowej powoduje pewien wzrost wydajności, ale nie w czterokrotnym wzroście, którego można się spodziewać (podwójny przyrost odczytu i podwójny przyrost zapisu). Aby w pełni wyobrazić sobie możliwe wzmocnienie, należy wziąć pod uwagę przepustowość sieci.
Korzystanie z wielu kart sieciowych
Podczas tworzenia kopii zapasowej przez sieć sieć często staje się wąskim gardłem. Zwiększenie przepustowości sieci powyżej 1 Gb / s nie jest tanie, ale zwiększenie liczby gigabitowych kart sieciowych na serwerze jest stosunkowo niedrogą opcją.
Jeśli chcesz wykonać kopię zapasową, dodaj dwie karty sieciowe na serwerze bazy danych i dwie na serwerze plików, na którym będzie przechowywana kopia zapasowa.
Wielu producentów sprzętu sieciowego oferuje obecnie rozwiązania, które umożliwiają połączenie kilku kart sieciowych w jeden logiczny interfejs sieciowy. Rozwiązanie to działa dobrze na serwerach, które mają setki połączeń klienckich z sieci, co pozwala na stosowanie algorytmów równoważenia obciążenia, w zależności od tego, którzy klienci pracują z serwerem. W naszym przypadku musimy zwiększyć prędkość między dwoma wysoce wyspecjalizowanymi serwerami. Aby to zrobić, użyliśmy separacji sieci do podsieci logicznych. Poniższa tabela pokazuje podsieci dla każdej karty sieciowej dwóch serwerów.
Serwer kart sieciowych SQL01 Serwer BAK01 Dostęp 192.168.1.1 MASK 255.255.255.0 192.168.1.2 MASK 255.255.255.0 Kopia zapasowa 01 192.168.2.1 MASK 255.255.255.0 192.168.2.2 MASK 255.255.255.0 Kopia zapasowa 02 192.168.3.1 MASK 255.255.255.2.2.2 255.255.255.0
Tabela 2: Podsieci
Każda karta sieciowa znajduje się we własnej podsieci (192.168.1.0/24, 192.168.3. 0/24). Teraz możesz wprowadzić niewielkie zmiany w poleceniu tworzenia kopii zapasowej, określając tam adresy IP zamiast nazw serwerów. W ten sposób łatwo jest kontrolować, która podsieć, a co za tym idzie, która karta sieciowa będzie używana do przesyłania danych. Fakt, że wszystkie podsieci logiczne będą na tym samym drugim poziomie sieci fizycznej, nie będzie miał żadnego negatywnego wpływu na tę decyzję.
BACKUP DATABASE MyVLDB
TO DISK = '192.168.2.2 backup MyVLDB00000001_1.bak',
DISK = '192.168.3.2 backup MyVLDB00000001_2.bak'
Z CHECKSUM, INIT;
W przypadku odzyskiwania działa w ten sam sposób.
RESTORE DATABASE MyVLDB
FROM DISK = '192.168.2.2 backup MyVLDB00000001_1.bak',
DISK = '192.168.3.2 backup MyVLDB00000001_2.bak'
Z CHECKSUM, NORECOVERY;
Podobnie wszystko będzie działać z dużą liczbą kart sieciowych. Eksperymenty opisane w artykule testowały równoległą pracę 16 kart sieciowych.
Zwiększona wydajność będzie również obserwowana, gdy kilka plików jest przesyłanych jednocześnie przez sieć za pomocą jednej karty sieciowej.
BACKUP DATABASE MyVLDB
TO DISK = '192.168.2.2 backup MyVLDB00000001_1.bak',
DISK = '192.168.3.2 backup MyVLDB00000001_2.bak',
DISK = '192.168.2.2 backup MyVLDB00000001_3.bak',
DISK = '192.168.3.2 backup MyVLDB00000001_4.bak'
Z CHECKSUM, INIT;
Wykazano empirycznie, że w zależności od wydajności wykorzystywanych zasobów (głównie serwerów i kart sieciowych), od dwóch do czterech plików jest przesyłanych całkiem dobrze przez jedną kartę sieciową. Jednak tylko testy w określonych warunkach klienta mogą pomóc w znalezieniu optymalnej liczby plików przesyłanych przez kartę sieciową.
Zalecenia dotyczące całkowitej liczby używanych plików
Na podstawie wyników wielu eksperymentów opracowano zalecenia dotyczące optymalizacji tworzenia kopii zapasowych. W domyśle okazało się również, że kopia zapasowa działa lepiej w przypadku równomiernego załadowania wszystkich zasobów. Aby uzyskać optymalne wyniki, należy zachować wszystkie poniższe równości. Równania są wymienione w kolejności ważności, z reprezentacją zalecanych wartości dla n, które są pogrubione.
Pliki bazy danych powinny być równomiernie rozmieszczone na dyskach logicznych, a pliki kopii zapasowych powinny być równomiernie rozłożone między kartami sieciowymi.
Tabela 3 przedstawia przykłady zrównoważonego rozmieszczenia plików i użycia dysku, które zapewniają dobrą wydajność tworzenia kopii zapasowych. Te wartości są optymalne tylko dla poprawy wydajności tworzenia kopii zapasowych. Podobny wzrost wydajności we / wy zwykłej bazy danych nie nastąpi, jeśli zamiast czterech plików danych na tych samych dyskach logicznych zostanie umieszczonych osiem plików danych.
W kontekście powyższych wzorów istnieje kilka przykładów dobrych kombinacji rdzeni procesorów, plików, dysków logicznych i kart sieciowych.
Przetwarzaj
zarośnięty
logika jądra
dyski
dla
pliki
Sieć danych
opłaty
dla
backup
Kopiuj pliki
Pliki danych
rezerwa
kopie 2 1 1 2 2 4 2 2 2 4 4 4 4 4 8 2 2 2 8 8 4 2 4 8 16 2 2 8 8 4 4 8 8 16 4 4 16 16 16 8 8 16 16 8 8 4 16 16 32 8 8 16 32 32 16 8 16 32 64 16 8 32 32 64 32 16 32 64
Tabela 3: Dystrybucja zbilansowanych plików
Dodatkowe sposoby optymalizacji i rekomendacji
Rozdzielenie sieci w celu tworzenia kopii zapasowych i udostępniania
Zawsze możesz liczyć na dobry efekt oddzielenia sieci publicznej od sieci w celu utworzenia kopii zapasowej w fizycznie niezależnych, różnych sieciach. Ze względu na odmienny charakter współdzielonego ruchu sieciowego i sieci zapasowej, przełączniki nie zawsze mogą optymalnie obsługiwać te dwa rodzaje ruchu w tym samym czasie. Ponadto, aby uzyskać szybki ruch backupowy, często wymagana jest większość zasobów przełącznika.
Ogólnie rzecz biorąc, zawsze dobrą praktyką było nie wypuszczanie dużego ruchu poza pojedynczy przełącznik (jeśli przełącznik ma kilka modułów, nie zwalniaj ruchu poza granice pojedynczego modułu, jeśli to możliwe).
Duże ramki
Maksymalny rozmiar pakietu sieci Ethernet w normalnych warunkach wynosi 15 000 bajtów (równy rozmiarowi ramki). Oznacza to, że aby przesłać 1 megabajt przez sieć, będzie musiał zostać podzielony na 700 pakietów, które będą przesyłane jeden po drugim.
Obecnie można kupić takie karty sieciowe i przełączniki, które obsługują pakiety Ethernet o dużych rozmiarach ramek. W przypadku takich ramek kart sieciowych i przełączników istnieje nawet specjalna nazwa - „ jumbo frames ”.
Im większy rozmiar ramki, tym szybszy transfer danych, ponieważ wymiana między serwerami będzie wymagała mniejszej liczby iteracji.
Najczęstsze rozmiary dużych ramek to około 4088 i 9016 bajtów (w tym nagłówki Ethernet i duże ramki). Na przykład, jeśli rozmiar ramki wynosi 9016 bajtów, to do przesłania 1 megabajta wymagane będzie tylko 117 pakietów.
Badania empiryczne wykazały, że zwiększając rozmiar ramki do 9016 bajtów, wydajność sieci jest prawie podwojona.
BLOCKSIZE
Parametr określający rozmiar bloku używany przez komendę BACKUP musi być zgodny z rozmiarem bloku urządzenia pamięci trwałej. Podczas zapisywania na oddzielnym dysku nawet domyślna wartość rozmiaru bloku równa 512 będzie działać całkiem dobrze.Jeśli nagranie jest kierowane do macierzy RAID lub do sieci SAN, należy upewnić się, że wartość domyślna jest nie mniejsza niż na przykład 65536.
Podczas tworzenia kopii zapasowej przez sieć musisz wybrać wartość, która pozwoli ci najbardziej wypełnić pakiety sieciowe. Pamiętaj, że dzielenie danych na pakiety działa w obu kierunkach. Wybranie 512 bajtów jako rozmiaru bloku spowoduje umieszczenie dwóch bloków w pakiecie sieciowym (biorąc pod uwagę fakt, że rozmiar ramki Ethernet wynosi 1500 bajtów). Tak aby przesłać jedną stronę bazy danych, będziesz potrzebować 8 pakietów sieciowych. Z drugiej strony, rejestracja w blokach 4096 bajtów zostanie umieszczona w 3 pakietach sieciowych, a do przesłania jednej strony bazy danych potrzebne będzie 6 pakietów sieciowych.
Dodatkowe przykłady można przytoczyć w wyniku testów przeprowadzonych podczas pisania tego artykułu; gdy używa się dużych ramek o rozmiarze 9016 bajtów, najlepsze wyniki uzyskano przy rozmiarze bloku 8192 bajtów, a przy dużych ramkach o rozmiarze 4088 bajtów najlepsze wyniki uzyskano przy rozmiarze bloku 65536 bajtów.
BUFFERCOUNT i MAXTRANSFERSIZE
Z parametrów polecenia BACKUP można wybrać te, które mają również bardzo silny wpływ na wydajność tworzenia kopii zapasowych, są to parametry BUFFERCOUNT i MAXTRANSFERSIZE. Niestety, nawet tygodnie testów nie mogły pomóc w ustaleniu zasady wyboru optymalnych wartości dla tych parametrów, dlatego też trzeba będzie znaleźć optymalne wartości, testując je w swoim środowisku. Jako rada. dla wartości parametru MAXTRANSFERSIZE, jeśli masz system x64 lub IA64 z wystarczającą ilością pamięci RAM, możesz rozpocząć testowanie z maksymalnym rozmiarem bufora 4 MB (4194304). Więcej informacji na temat parametru BUFFERCOUNT i innych parametrów optymalizacyjnych można znaleźć w zaleceniach dotyczących strojenia wydajności kompresji kopii zapasowej w artykule technicznym: Dostrajanie SQL Server 2008
W niektórych przypadkach podczas przeprowadzania testów dla tego artykułu najlepsze wyniki uzyskano przy znacznie mniejszych wartościach parametrów, ale wybór wartości był nieprzewidywalny. W zastosowaniach przemysłowych warto przeprowadzić kompleksowe testy różnych opcji i upewnić się, że najlepsze wyniki są dobrze odtworzone. Jeśli nie można wykonać tej pracy, lepiej zapisać ustawienia domyślne.
Kompresja kopii zapasowej
Kompresja kopii zapasowej (nowa funkcja wprowadzona w SQL Server 2008) daje możliwość zwiększenia wydajności tworzenia kopii zapasowych i jednocześnie znacznego zmniejszenia miejsca na dysku przeznaczonego na przechowywanie kopii zapasowych. Aby włączyć kompresję kopii zapasowej, należy dodać opcję WITH COMPRESSION w poleceniu BACKUP.
Poniższe przykładowe zapytanie pokazuje, jak włączyć kompresję kopii zapasowej.
BACKUP DATABASE MyVLDB
TO DISK = 'BAK01 backup MyVLDB.bak'
Z CHECKSUM, INIT, COMPRESSION;
Stopień kompresji zależy w rzeczywistości od danych przechowywanych w bazie danych. W przypadku większości baz danych (informacje cyfrowe, operacje pieniężne, data i godzina, zwykły tekst) współczynnik kompresji będzie wynosił od 1: 4 do 1: 6. W przypadku baz danych zawierających inne typy danych, na przykład obrazy, które są już w formacie skompresowanym, można oczekiwać gorszych wyników. Aby uzyskać więcej informacji na temat używania kompresji z różnymi typami danych, zobacz artykuł w dokumentacji SQL Server Books Online: Kompresja kopii zapasowej .
W testach przeprowadzonych dla tego artykułu skrócono czas tworzenia kopii zapasowej ze 125 do 36 minut, a kompresując plik o 20 procent oryginalnego rozmiaru.
Kompresja danych ma jedną wadę - większe wykorzystanie zasobów procesora.
SQL Server wykonuje kompresję na jednym wątku, który zapisuje dane do pliku kopii zapasowej, więc liczba plików kopii zapasowych jest określana przez liczbę rdzeni procesorów, które będą wykonywać kompresję równolegle. Aby ograniczyć użycie procesorów do tworzenia kopii zapasowych, można użyć Resource Governor (Resource Governor), dzięki któremu można uzyskać więcej połączeń z innymi połączeniami.
Jeśli używasz przezroczystego szyfrowania bazy danych (TDE), nie powinieneś próbować używać kompresji do szyfrowanej bazy danych, ponieważ zaszyfrowane dane są wystarczająco skompresowane. Jeśli określenie opcji kompresji podczas generowania każdego polecenia tworzenia kopii zapasowej jest niewygodne, można użyć procedury przechowywanej systemu sp_configure, aby ustawić automatyczną kompresję podczas tworzenia wszystkich kopii zapasowych na serwerze:
sp _ skonfigurować 'domyślną kompresję kopii zapasowej', 1
przekonfiguruj
Powinieneś być ostrożny, ponieważ jeśli kompresja jest włączona na poziomie całego serwera, będzie używana zarówno dla kopii różnicowych, jak i kopii dziennika transakcji. A jeśli zwiększone wykorzystanie procesorów z powodu kompresji nie będzie stanowiło problemu dla pełnych kopii zapasowych (takie kopie zwykle nie są planowane dla czasów obciążenia szczytowego), użycie kompresji kopii dziennika może powodować problemy podczas aktywnej pracy użytkownika.
Zalecenia sprzętowe dla serwerów do przechowywania plików
Urządzenia dyskowe
Dyski używane do przechowywania i weryfikacji możliwości odzyskania plików kopii zapasowych nie podlegają tym samym wysokim wymaganiom, co w przypadku przemysłowych dysków serwerowych. Dzieje się tak, ponieważ prawie wszystkie operacje we / wy są wykonywane sekwencyjnie i nie są losowe. Dlatego dyski SATA są w większości przypadków bardzo dobrze dostosowane do tego celu.
Konfiguracja kontrolera nalotu
Wybierz duży rozmiar segmentu (64 Kb, 128 Kb, 256 Kb i wyższy). Ważne jest również pełne buforowanie zapisu, buforowanie odczytu można całkowicie wyłączyć. Mozesz takze aktywować Pamięć podręczną zapisu poszczególnych wrzecion, ponieważ jeśli podczas tworzenia kopii zapasowej wystąpi awaria zasilania, kopia zapasowa I tak powyżej tygodnia SIĘ bezużyteczna AW Tym przypadku Nie ma znaczenia, CZY Jakieś bajty zostały utracone w Pamięci podręcznej zapisu, CZY NIE.
Dla tych dysków logiczne, które są używane w próbach odzyskania bazy danych z kopii zapasowej, rozmiar segmentu jest na 64 kb, stosowana jest 100-procentowa zasada buforowania zapisu, przy użyciu sposobu wyrazu, dla obrazu, wykorzystując sposób na wykorzystanie koncepcji firmy, za pomocą menu
Wybór poziomu RAID (1, 10, 5, 6 ...) zależy od możliwości używanego kontrolera RAID lub używanego systemu pamięci masowej. Ponieważ obciążenie serwera plików podczas tworzenia kopii zapasowej / przywracania jest sekwencyjnym zapisywaniem i odczytywaniem danych, kontroler buforuje dane, dopóki nie zakończy pisania całego paska, w którym to przypadku można użyć dowolnego poziomu RAID. Jeśli kontroler zachowuje się inaczej, a wydajność jest parametrem krytycznym, macierze RAID1 lub RAID10 będą jedyną opcją.
Konfiguracja HBA
Jeśli podsystem dyskowy jest podsystemem dyskowym typu SAN, maksymalna głębokość kolejki dla adapterów używanych w połączeniu SAN powinna zostać zwiększona tak bardzo, jak to możliwe. Wartość domyślna to 32, ale tworzenie kopii zapasowych i przywracanie będzie działało znacznie lepiej przy wartościach bliskich 256. Aby uzyskać więcej informacji, zobacz artykuł Konfigurowanie systemu Windows Server 2008/2003 x64 do obsługi programu SQL Server 2008 , w sekcji „NumberOfRequests and MaximumSGList”.
Karty sieciowe
Powinno być bardzo jasne, co do wyboru kart sieciowych, które mają być używane na serwerach. Liczba portów nie gwarantuje jeszcze odpowiedniej wydajności we / wy dla wszystkich tych portów jednocześnie. Tak się składa, że dwa adaptery czteroportowe mogą być bardziej wydajne niż pojedynczy adapter z czterema portami. Ilość czasu procesora wykorzystywanego przez sterownik interfejsu sieciowego jest również bardzo ważna. Są takie karty sieciowe, które zużywają do 50 procent zasobów jednego procesora, a jednocześnie są inni, którzy używają tylko 3-5 procent.
Jeśli kilka kopii kart sieciowych jest używanych do tworzenia kopii zapasowych, bardzo ważne jest, aby korzystali z różnych procesorów, tj. tak, że ich przerwania są powiązane z różnymi rdzeniami procesora.
Systemy oparte na NUMA
Jeśli serwer korzysta z architektury niejednolitego dostępu do pamięci (NUMA), należy upewnić się, że wszystkie adaptery wejścia / wyjścia (na przykład NIC, RAID i HBA) są rozmieszczone wśród wszystkich węzłów NUMA w systemie.
Obliczanie czasu potrzebnego do utworzenia kopii zapasowej i przywrócenia bazy danych
Jednym z kluczowych elementów umowy SLA jest przedział czasowy na zadania tworzenia kopii zapasowych, tj. konieczne będzie obliczenie i zaplanowanie czasu, jaki zajmie cały proces. Pomoże to spełnić wymagania specyfikacji dotyczące czasu przywracania, a także pomoże utworzyć inne ważne punkty planu awaryjnego, takie jak częstotliwość tworzenia kopii zapasowych i parametry kompresji. Określanie czasu potrzebnego na procesy tworzenia kopii zapasowych i odzyskiwania odbywa się w kilku krokach. Najpierw musisz obliczyć ilość skopiowanych danych.
Następnie musisz określić maksymalny czas równoległego, sekwencyjnego odczytu i zapisu używanych podsystemów dyskowych. Aby zmierzyć te wartości podczas testowania kopii zapasowych i przywracania, można użyć narzędzia systemowego Monitor wydajności (znanego w niektórych wersjach systemu operacyjnego Windows jako Monitor systemu).
W rezultacie powinno być 5 wartości. Jeśli istnieje wiele dysków logicznych i kart sieciowych, wartości te mogą się różnić i należy zawsze stosować najgorsze wyniki obliczeń.
- Wydajność karty sieciowej (MB / s);
- Wydajność dysku logicznego repozytorium dla sekwencyjnego odczytu (MB / s);
- Wydajność dysku logicznego repozytorium podczas zapisu sekwencyjnego (MB / s);
- Wydajność dysku logicznego pliku bazy danych z odczytem sekwencyjnym (MB / s);
- Wydajność pliku bazy danych dysku logicznego podczas sekwencyjnego zapisu (MB / s).
Następnie, na podstawie danych o liczbie dysków logicznych do równoległej pracy z plikami bazy danych, o liczbie dysków logicznych używanych do pracy równoległej z plikami kopii zapasowych i liczbą używanych kart sieciowych. Jeśli kompresja nie zostanie użyta, spowoduje to, że współczynnik kompresji stanie się: CompressionFactor = 1.
W większości przypadków nieskompresowana kopia zapasowa będzie miała najniższą wydajność sieci w porównaniu z wydajnością odczytu i zapisu na dysku, ale po włączeniu kompresji głównym ograniczeniem może być odczyt z bazy danych: DatabaseReadPerformance lub inne składniki, które nie są brane pod uwagę, takie jak rdzenie procesorów z kompresją .
Obliczenia do obliczenia czasu odzyskiwania będą trudniejsze. Najpierw musisz wiedzieć, czy Twój system obsługuje natychmiastową inicjalizację plików. Ta funkcja umożliwia SQL Server tworzenie plików danych na woluminach NTFS bez resetowania przestrzeni zajmowanej przez pliki podczas tworzenia lub rozszerzenia pliku. Ponieważ ten mechanizm ma zagrożenia bezpieczeństwa, możesz skorzystać z tej możliwości tylko wtedy, gdy konto, na którym uruchomiona jest usługa SQL Server, ma prawo do „Wykonywania konserwacji zbiorczej” w lokalnych zasadach. Jeśli konto użytkownika znajduje się w lokalnej grupie administratorów, prawo to zostanie mu przyznane domyślnie (Uwaga: czas inicjalizacji pliku dziennika transakcji może ograniczać wydajność, ponieważ miejsca zajmowanego przez ten plik nie można wypełnić zerami).
Jeśli RestoreTime lub BackupTime jest wyższy niż określone wartości SLA, można użyć wcześniej opisanych zaleceń w celu zmniejszenia tych wartości. Równoległość operacji zwykle przyspiesza proces bardziej niż przyspieszenie pracy jednego z komponentów w całym łańcuchu. W scenariuszach o bardzo wysokiej wydajności warto zastanowić się nad wykorzystaniem obu podejść.
Uwaga: wykonanie polecenia CHECKBD może trwać dłużej niż czas potrzebny na odczyt z dysku. Zależy to od złożoności schematu bazy danych iz pewnością nie będzie mniejsza niż czas czytania.
Wniosek
Microsoft i bezpośrednio zespół SQL Server stale ulepszają technologie przetrwania systemów, które mają pomóc klientom i partnerom w realizacji zadań tworzenia kopii zapasowych i odzyskiwania danych w skali całego przedsiębiorstwa. SQL Server 2008 jest dostarczany do tych zadań ze wszystkimi niezbędnymi funkcjami, na których mogą polegać specjaliści i który pomaga skutecznie radzić sobie z nieodłącznymi wymaganiami zarządzania danymi i ich ochrony. Dzięki ulepszeniom w kluczowych obszarach SQL Server 2008 stał się solidną platformą do obsługi bardzo dużych baz danych.
Ten artykuł techniczny zawiera jedynie krótki przegląd możliwości tworzenia kopii zapasowych i przywracania, a także niektóre funkcje SQL Server 2008.
