Dołącz / odłącz od kopii zapasowej / przywracania

Muszę przenieść bazę danych (jako całość) na inny serwer, aby utworzyć zduplikowaną bazę danych, aby skonfigurować inne środowisko testowe.

Mam dwie możliwości:

1. Wykonaj pełną kopię zapasową na serwerze źródłowym / przywróć na serwerze docelowym;
2. Odłącz na serwerze źródłowym / dołącz na serwerze docelowym.

Jakie są zalety i wady obu rozwiązań zgodnie z moimi wymaganiami?

Używam SQL Server 2008 Enterprise.

Kopia zapasowa / przywracanie powinno zwykle być Twoją wybraną metodą. W większości sytuacji będzie szybciej.

Możesz używać go konsekwentnie, także do testowania produkcji.

Zobacz także podobne pytanie, w którym wspomniano o tworzeniu kopii zapasowych / przywracaniu vs odłączaniu / dołączaniu:

Migracja programu SQL Server przywraca kopie zapasowe vs kopiowanie danych i plików dziennika

Upewnij się, że dodałeś WITH COPY_ONLYopcję do kopii zapasowej, aby nie zepsuła ona istniejącego łańcucha kopii zapasowych planu konserwacji.

1. Odłączenie bazy danych spowoduje przejście do trybu offline. Wykonaj kopię zapasową, jeśli chcesz, aby baza danych pozostała online podczas kopiowania jej na inny serwer.
2. Przenoszenie i przywracanie pliku kopii zapasowej (.bak) może być prostsze / łatwiejsze niż przenoszenie i dołączanie wielu plików mdf / ldf (tak jak w przypadku odłączenia bazy danych).
3. Na papierze odłączanie / dołączanie bazy danych może być technicznie szybsze, ale w praktyce tworzenie kopii zapasowych / przywracanie może być szybsze i łatwiejsze. Po odłączeniu bazy danych najpierw musisz przełączyć oryginalną bazę danych w tryb offline (odłącz wszystkich i wszystko), a następnie baza danych będzie niedostępna do momentu ponownego podłączenia. Musisz także śledzić wszystkie pliki, a podczas tworzenia kopii zapasowej wszystkie pliki są grupowane.

Jeśli zdecydujesz się na wykonanie kopii zapasowej / przywrócenie, użyj opcji Z KOPIOWĄ TYLKO podczas tworzenia kopii zapasowej, aby upewnić się, że łańcuch kopii zapasowych istniejącego planu konserwacji nie jest uszkodzony.

Plik .bak dobrze się kompresuje, więc jeśli zdecydujesz się na zrobienie kopii zapasowej, kompresowanie kopii zapasowej przed przeniesieniem może zaoszczędzić trochę czasu przesyłania.

Poszedłbym do tworzenia kopii zapasowych / przywracania, ponieważ pozostawia oryginalną bazę danych w stanie operacyjnym.

Zwłaszcza jeśli wykonujesz konwersję „produkcyjną do testowania”, ważne jest, aby produkcyjna baza danych pozostała online.

Kopia zapasowa / przywracanie jest również bezpieczniejszą opcją: co się stanie, jeśli plik zostanie uszkodzony gdzieś pomiędzy rozpoczęciem odłączania, kopiowania, załączania itp.? Przynajmniej jeśli wykonasz kopię zapasową, a plik ulegnie uszkodzeniu, możesz zacząć od nowa. Jeśli tak się stanie z odłączeniem, Twoja baza danych zniknie.

Ponadto, dla mnie (chociaż jest to bardziej uczucie niż cokolwiek innego), tworzenie kopii zapasowych / przywracanie to „codzienna praca”, podczas gdy odłączanie / dołączanie to coś, co robisz w wyjątkowych okolicznościach. Nie pytaj mnie jednak, skąd mam ten pomysł ;-)

Zawsze miałem problemy z częścią „przywracania” kopii zapasowej / przywracania. Nie mogę przytoczyć szczegółów, ponieważ ostatecznie zrezygnowałem z niego i od tego czasu odkładam / kopiuję / dołączam.

Jedyną rzeczą w odłączaniu jest to, że MUSISZ mieć pewność, że DBMS również nie usunie bazy danych. Tak się stało i nie jest to ładny widok.

Polecam copy_onlytworzenie kopii zapasowej przy użyciu tej metody z powłoki DOS (aby nie przerywać dzienników transakcji) :

Uruchom z C:\Program Files\Microsoft SQL Server\MSSQL10.SQLEXPRESS\MSSQL\Backupkatalogu:

backup.bat SQLDBNAME

Gdzie backup.batzawiera (dodano podział linii dla czytelności) :

sqlcmd.exe -U username -P xxxxxxx -S SQL-SERVERNAME 
    -Q "BACKUP DATABASE %1 TO DISK = '%1_COPYONLY.BAK' WITH COPY_ONLY,INIT;"