Kiedyś prawie zawsze przenosiłem bazy danych z powodu rekonfiguracji SAN i migracji.
Zakładając, że przenosisz cały serwer na raz, wybrałbym coś w rodzaju ścieżki 2. (Jeśli przenosisz jedną bazę danych na raz i ostatecznie robisz każdą bazę danych na serwerze, byłoby to bardziej problematyczne, ponieważ musiałbyś zmieniać ścieżki do plików.)
Pamiętaj, że „single_user” niekoniecznie oznacza CIEBIE. Możesz przejść do bazy danych DBCC CHECKDB i nie możesz wejść, ponieważ ktoś już tam jest. Przygotuj skrypt, który możesz uruchomić, aby uruchomić bazę „wszyscy oprócz ciebie” z bazy danych i trzymaj ją w poręcznym miejscu. Zauważ, że SQL 2000 nie ma takich samych funkcji „trzymaj wszystkich na dystans”, co nowsze wersje.
Jedną ze starych sztuczek jest wstrzymanie usługi SQL Server. Zapobiegnie to nowym logowaniom, ale każdy, kto jest już podłączony, może kontynuować jak zwykle. Więc: połącz przez okno SSMS, abyś mógł wykonać pracę, a następnie wstrzymaj usługę, a następnie wykasuj niepożądane połączenia, zrób to za pomocą okna poleceń SSMS (nie GUI, tworzy i zrywa wiele połączeń), a następnie anuluj pauzę Serwis. Ostrzeżenie: nie jestem pewien, jak to by się rozegrało w klastrze. Może być konieczne przełączenie awaryjne.
Przydaje się mieć sposób na powstrzymanie wszystkich użytkowników aplikacji od serwera, dopóki nie skończysz swojej pracy. W przeciwnym razie połączenia mogą zacząć pojawiać się podczas próby wykonania różnych czynności, co może prowadzić do rywalizacji o zasoby i / lub spowolnienia. W przeszłości korzystałem z następujących sposobów, w zależności od dokładnej sytuacji: Wyłączanie serwerów aplikacji Korzystanie z ALTER DATABASE .. SET RESTRICTED_USER (Jeśli konta aplikacji należą do ról db_owner, sysadmin lub dbcreator, to problem. ) Informowanie użytkowników, że system będzie w trybie offline o określonej godzinie, na przykład w niedzielę rano. (To nie będzie działać w „prawdziwym” środowisku 24x7). Odłączanie karty sieciowej, która jest skierowana do serwerów aplikacji lub użytkowników. (W takim przypadku mogłem wejść przez inną kartę sieciową podłączoną do sieci tylko dla administratora lub przez ILO).
Odłączanie dużej liczby baz danych i ponowne ich podłączanie może być bardzo pracochłonne. Jeśli to zrobisz, upewnij się, że masz wcześniej napisany skrypt „załącz”.
Miałem wiele sukcesów, zatrzymując SQL Server, kopiując wszystko, zmieniając litery dysków i uruchamiając SQL Server. Bez odłączania / dołączania. Tak długo, jak SQL Server jest wyłączony i kopiujesz pliki (nie MOVING), nie możesz wpakować się w zbyt duże problemy, nawet jeśli przenosisz systemowe bazy danych. Ponieważ ścieżki są takie same, SQL Server nie zda sobie sprawy, że nic się nie zmieniło, gdy usługa była wyłączona. Upewnij się tylko, że litery dysków są skierowane z powrotem do odpowiednich woluminów, w przeciwnym razie wszystko pójdzie źle.
Moim najczęstszym problemem było niepoprawne sprawdzenie list ACL w katalogach plików. Nowocześniejsze wersje SQL Server lepiej ustawiają tylko uprawnienia, których potrzebuje konto usługi, podczas gdy starsze wersje wydają się mniej wybredne. Jeśli zapomnisz ustawić listy ACL, a konto usługi nie jest administratorem lokalnym (nie polecam tego), jedna lub więcej baz danych może się nie otworzyć podczas uruchamiania instancji. Nie panikuj, po prostu zmień listy ACL i dołącz bazę danych.
Generalnie używam ROBOCOPY do wykonywania tego rodzaju pracy. Istnieje przełącznik linii poleceń, aby zachować listy ACL.
Korzystanie z obliczeń / weryfikacji CRC nie jest złym pomysłem, ale nigdy tego nie zrobiłem. Kiedy bazy danych wrócą, uruchamiam CHECKDB () na wszystkich z nich. Zazwyczaj przygotowuję skrypt na ten temat z wyprzedzeniem, zamiast polegać na ręcznym rozpoczęciu prac konserwacyjnych. W ten sposób mogę najpierw sprawdzić kilka mniejszych baz danych, zanim sprawdzę dużą bazę danych, której uruchomienie może zająć wiele minut lub godzin. Wątpię, aby kontrola CRC (lub narzędzie do porównywania danych Redgate) znalazła coś, czego nie sprawdziłby CHECKDB (), a gdyby tak się stało, SQL Server nie byłby w stanie tego naprawić.
Po skopiowaniu plików, ale przed ponownym uruchomieniem instancji, przejdę i nieznacznie zmienię ścieżkę plików folderów OLD, zmieniając nazwę jednego z folderów. Jest to dodatkowe sprawdzenie problemu „ups, serwer nadal wskazuje stare pliki”.
Nie spiesz się, aby upuścić stare pliki i odzyskać miejsce na starej pamięci i upewnij się, że Twoje pełne kopie zapasowe zostały pomyślnie uruchomione. Przetestuj przywróć kilka kopii zapasowych w innym miejscu. Gdy masz już dobre polecenia checkdb () i dobre pełne kopie zapasowe, możesz pomyśleć o porzuceniu starej pamięci i wyłączeniu Lefthand.
Najgorsze problemy z tymi migracjami miały miejsce po tym, jak myślałem, że to koniec. To byłby administrator SAN, który powiedziałby mi, że coś się stało, a moje systemy plików zostały zaszyfrowane. (Ponownie podzielony, sformatowany, ponownie skopiowany).
Innym zabawnym problemem jest powolna sieć SAN bez wyraźnego powodu. Jeśli uważasz, że skopiowanie danych potrwa 10 godzin, a kopiowanie odbywa się w 30% o godzinie 9, masz problem. Obserwuj czasy przesyłania (robocopy pokazuje% skopiowanych i podaje szacunkowe czasy, lub możesz użyć Perfmon) i mieć plan awaryjny, jeśli coś pójdzie nie tak.
Nie jestem również pewien, czy woluminy zostaną podzielone na partycje, ale możesz mieć pewność, że używają przesunięcia o 1 MB. W systemie Windows Server 2008 i nowszych nie powinno to stanowić problemu. Tak jest w starszych systemach operacyjnych. Jest w tym mnóstwo rzeczy do przejrzenia, a twoi ludzie z magazynu powinni o tym wiedzieć, ale zapytam.