Przenoszenie bazy danych SQL Server na nowy dysk w trybie online

Mam bazę danych SQL Server 1,4 TB, która zmaga się z dyskowymi operacjami wejścia / wyjścia. Zainstalowaliśmy nową macierz SSD na serwerze, która rozwiąże wszystkie nasze problemy, właśnie debatujemy nad najlepszym sposobem przenoszenia bazy danych. Najlepiej, jeśli możemy to zrobić bez przestojów. Ale w przypadku wyboru między dwoma dniami niskiej wydajności (np. Podczas kopiowania danych) a 2 godzinami przestoju, ten drugi może być lepszy.

Do tej pory proponowane przez nas rozwiązania to:

• Prosta kopia. Przełącz DB w tryb offline, skopiuj pliki, zmień lokalizacje w SQL Server i przywróć go do trybu online. Szacunkowe liczby szacują, że zajmie to do pięciu godzin, co nie jest do zaakceptowania, ale jest to najłatwiejsze rozwiązanie.

• Kopia na poziomie bloku. Używając narzędzia podobnego do rsync, kopiujemy pliki w tle, gdy DB jest włączony. Kiedy jesteśmy gotowi do migracji, wyłączamy bazę danych w trybie offline, wykonujemy kopię różnicową za pomocą tego narzędzia, a następnie kierujemy serwer SQL na nowe pliki i przełączamy w tryb online. Czas tutaj nie jest znany. Nie wiemy, ile czasu zajmie przeprowadzenie analizy różnicowej 1,4 TB i skopiowanie jej. Naszym drugim problemem jest to, że kopia na poziomie bloku pozostawi pliki w pewnym stanie nieczytelnym dla SQL Server i będziemy marnować nasz czas.

• Migracja SQL. Utwórz nowy plik danych SQL 1,4 TB na nowym dysku i wyłącz autogrowth na wszystkich innych plikach. Następnie uruchom kolejno DBBC SHRINKFILE (-nazwa_pliku-, EMPTYFILE) na wszystkich innych plikach danych. Gdy wszystkie dane będą już dostępne, w pewnym momencie wykonam zaplanowane okno, aby przenieść plik MDF na dysk SSD i usunąć inne nieużywane pliki. Podoba mi się to, ponieważ minimalizuje przestoje. Ale nie mam pojęcia, ile czasu to zajmie i czy spowoduje pogorszenie wydajności podczas jej trwania.

Nie mamy żadnego środowiska obciążenia i wydajności, aby to przetestować. Mogę zweryfikować, czy strategie będą działać w naszym środowisku testowym, ale nie wpływ, a nie wydajność.

Jedną z metod przenoszenia całej bazy danych jest użycie BACKUPi RESTORE. Baza danych będzie niedostępna podczas ostatniej zmiany, ale przestoje powinny być minimalne przy planowaniu. Ta procedura zakłada model odzyskiwania FULLlub BULK_LOGGED:

1) Wykonaj PEŁNĄ kopię zapasową (lub użyj istniejącej).

2) Przywróć najnowszą pełną kopię zapasową do innej nazwy bazy danych, określając WITH MOVEopcję przeniesienia plików na dysk SSD zgodnie z potrzebami oraz NORECOVERYopcję umożliwiającą przywrócenie kolejnych różnicowych i dzienników kopii zapasowych.

3) Zastosuj zmiany przyrostowe do nowej bazy danych do czasu ostatecznego przejścia z kopiami zapasowymi dziennika transakcji i RESTORE...WITH NORECOVERY. Pozwoli to zminimalizować czas przestoju dla ostatecznego przejścia do nowej bazy danych.

4) Aby przełączyć się na nową bazę danych, przełącz aplikację w tryb offline, wykonaj kopię zapasową dziennika transakcji końcowych i zastosuj się do nowej bazy danych WITH RECOVERY. Na koniec zmień nazwę oryginalnej bazy danych na inną nazwę i zmień nazwę przeniesionej bazy danych na oryginalną. Upuść starą bazę danych według własnego uznania.

W modelu odzyskiwania SIMPLE można zastosować podobny proces, ale bez tworzenia kopii zapasowej / przywracania dziennika transakcji kroku 3. Zamiast tego w ostatnim kroku użyj różnicowej kopii zapasowej / przywracania bazy danych. Może to wymagać dłuższych przestojów, w zależności od liczby zmian od początkowej FULLkopii zapasowej.

Good approach is to use SQL REPLICATION between two server
once all data replicated on SSD server then take current server offline 
and switch to SSD server.