Przywróć bazę danych z pliku kopii zapasowej innej wersji / edycji

Przeczytałem, że możliwe jest przywrócenie bazy danych w SQL Server, o ile przywracasz ze starszej wersji do nowszej, ze względu na kompatybilność wsteczną.

Czy ktoś wie od razu, czy można przywrócić bazę danych z pliku * .bak dla różnych wersji programu SQL Server? Przenosimy bardzo dużą bazę danych przez FTP, która zajmie kilka dni, więc wolimy to zrobić tylko raz. Jeśli do czasu przesłania bazy danych przez FTP nikt nie odpowie, oczywiście to wypróbujemy i sprawdzimy, czy działa, testując, i odpowiemy na własne pytanie.

Poniżej znajduje się zapytanie, aby uzyskać szczegółowe informacje o wersji programu SQL Server. productversionJest w formacie {major revision}.{minor revision}.{release revision}.{build number}. W moim przypadku wartość {release revision}ma wartość 5500źródłową i 5512docelową. Więc to wygląda dobrze. Jednak editionjest inaczej.

Pytanie:

SELECT 
  SERVERPROPERTY('productversion'), 
  SERVERPROPERTY('productlevel'), 
  SERVERPROPERTY('edition')

Źródło danych:

10.0.5500.0
SP3
Developer Edition (64-bit)

Docelowa baza danych:

10.0.5512.0
SP3
Enterprise Edition (64-bit)

Od dewelopera do przedsiębiorstwa będzie dobrze, po prostu upewnij się, że jeśli korzystasz z licencjonowania procesorów, masz licencje na serwerze docelowym na wszystkie procesory. I nie wystarczy po prostu ukryć je przed SQL, jeśli są one fizycznie podłączone do komputera, jesteś za nie odpowiedzialny.

Również po przejściu z niższej kompilacji na wyższą kompilację zwiększy się wersja bazy danych. Istnieje kilka scenariuszy, w których może to być problematyczne - np. Jeśli korzystasz z 15 000 partycji w konkretnej kompilacji z 2008 r., To nie będzie działać po uaktualnieniu do konkretnej kompilacji z 2008 R2. Możesz także polegać na optymalizacjach (i mieć obejścia), które w rzeczywistości są błędami w starszej wersji, ale zostały naprawione w nowej wersji, co może prowadzić do gorszej wydajności. Konieczne jest również przejrzenie wszystkich flag śledzenia używanych w źródle i określenie, czy powinny one być również włączone w miejscu docelowym. Nieważne zadania, loginy itp.

Oczywiście nie możesz cofnąć się. Nigdy nie próbowałem pomniejszej wersji, takiej jak 10.0.5512 -> 10.0.5500, ale zdecydowanie nie można przejść do wersji Service Pack lub wersji. Jeśli więc masz bazę danych 2012 na instancji Developer Edition i chcesz umieścić ją na instancji 2008 w wersji produkcyjnej, Twoja praca zostanie dla Ciebie odcięta (patrz tutaj i tutaj ) - szczególnie jeśli korzystałeś z funkcji 2012 .

Ale aby objąć inne przypadki, które mogą spotkać ludzi na to pytanie (np. Ktoś chce przejść z Deweloper -> Standard lub Enterprise -> Express lub co masz) ...

Istnieją inne wydania -> uaktualnienia wydania, które nie pójdą tak dobrze, np. Od programisty -> Express, jeśli korzystasz z funkcji, które nie są obsługiwane w Express (tak samo jest w przypadku każdej edycji innej niż Enterprise). Niektóre przykłady funkcji, których nie będziesz mógł używać w wersjach niższych (w takim przypadku przywracanie umrze w momencie, gdy spróbuje przełączyć bazę danych do trybu online):

• Partycjonowanie
• Zmień przechwytywanie danych
• Kompresja danych
• Przejrzyste szyfrowanie danych

Nie wiem, czy istnieje sposób, aby powiedzieć to bezpośrednio z pliku .BAK (jestem pewien, że jest trochę magii, którą można wyodrębnić z nagłówków stron, lub jeśli masz weekend do wypalenia za pomocą edytora szesnastkowego) , ale chociaż baza danych jest nadal nienaruszona w instancji źródłowej, zawsze możesz wykonać następujące czynności, aby sprawdzić, czy korzystasz z funkcji dostępnych z powodu jednostki SKU:

SELECT feature_name FROM sys.dm_db_persisted_sku_features;

Nie jestem pewien, czy SQL Server Audit powinien znajdować się na tej liście - zmieniła się wyłączność edycji tej funkcji, więc prawdopodobnie zależy to od tego, co z nią zrobisz. Są inne rzeczy, których możesz używać, ale nie pojawią się w DMV (niektóre dlatego, że znajdują się w kodzie, którego DMV nie analizuje, a niektóre dlatego, że twoja baza danych polega na zewnętrznych rzeczach, takich jak SQL Server Agent , Service Broker itp.):

• dublowanie
• niektóre formy replikacji
• wysyłanie dziennika
• migawki bazy danych
• indeksowanie online
• uaktualniane rozproszone widoki na partycje
• kompresja zapasowa
• zarządzanie oparte na polityce
• prowadź plan
• poczta bazy danych
• plany konserwacji
• wyszukiwanie pełnotekstowe

Są też przypadki, w których nie będziesz mógł przejść z Dewelopera na Express z powodu ograniczeń rozmiaru pliku (bazy danych Express są ograniczone do 10 GB całkowitego rozmiaru pliku danych).

Oczywiście mogą istnieć inne problemy, o których nie będziesz ostrzegany - nie zapobiegną migracji, ale mogą doprowadzić do bardzo różnej wydajności w celu. Przykłady:

1. Różne ograniczenia pamięci / procesora w docelowej edycji (lub nawet bazowy system operacyjny na docelowym). To trochę wielu ludzi, którzy przeszli od 2008 R2 Enterprise do 2012 Enterprise (CAL), gdzie usługa jest sztucznie ograniczona do pierwszych 20 rdzeni). Może to prowadzić do prostych różnic w wydajności (na przykład za mało pamięci, aby zaspokoić zapytanie lub znacznie wolniejsze działanie równoległych zapytań); do bardziej subtelnych należą wybory planów, które są dokonywane z powodu różnego sprzętu.
2. Poleganie na funkcjach, takich jak indeksowane dopasowanie widoku w źródle, nie będzie automatycznie respektowane w celu bez zmiany używanego kodu źródłowego NOEXPAND. I możesz nawet nie zdawać sobie sprawy z tego, że ta funkcja nagle spowalnia twoje zapytania.
3. To samo dotyczy operacji indeksowania równoległego i prawdopodobnie wielu innych optymalizacji, które nie przychodzą mi teraz na myśl (na szczęście pracuję prawie wyłącznie w przestrzeni Enterprise, więc w większości przypadków nie muszę się martwić ograniczeniami niższych wersji) ).

AKTUALIZACJA na podstawie tego duplikatu :

Mogą wystąpić sytuacje, w których próbujesz przywrócić bazę danych z określonej edycji do mniejszej wersji (nawet w tej samej wersji) i otrzymujesz błędy, które są mniej niż pomocne :

PRZYWRACANIE nie powiodło się dla serwera „server \ instance”.
PRZYWRACANIE nie może uruchomić bazy danych „nazwa bazy danych”.

To nie jest bardzo intuicyjne. Jeśli jednak zajrzysz głębiej w dzienniki zdarzeń programu SQL Server, zobaczysz bardziej przydatne błędy (tylko jeden przykład):

Nie można uruchomić bazy danych „nazwa bazy danych”, ponieważ niektóre funkcje bazy danych nie są dostępne w bieżącej wersji programu SQL Server.
Bazy danych „nazwa bazy danych” nie można uruchomić w tej edycji programu SQL Server, ponieważ zawiera ona funkcję partycji „_dta_pf__9987”. Tylko wersja SQL Server Enterprise obsługuje funkcje partycji.

To nie do końca prawda - możesz także przywrócić wersję ewaluacyjną lub wersję dla programistów, ale to nie ma znaczenia. Aby przywrócić tę bazę danych, w zasadzie masz dwie opcje:

1. Przywróć odpowiednią wersję programu SQL Server - co będzie oznaczać lokalizację lub instalację nowej instancji.
2. Przywróć kopię zapasową na serwerze źródłowym jako nową bazę danych o innej nazwie, usuń wszystkie funkcje Enterprise, a następnie ponownie wykonaj kopię zapasową bazy danych i przywróć ją w mniejszej wersji. (W tym konkretnym przypadku zostawiłem nazwę funkcji partycji w komunikacie o błędzie, ponieważ i tak wydaje się to czymś możliwym do odrzucenia - została stworzona przez Doradcę dostrajania aparatu bazy danych i mogła być wykonana przez kogoś, kto nie do końca wiedzą, co robili. Nie zawsze tak jest.)

Wariacją na (2) byłoby po prostu usunięcie partycjonowania i innych funkcji ze źródłowej bazy danych i zrobienie kolejnej kopii zapasowej. Ale jeśli się nie zepsuło ...

Deweloper i Enterprise to to samo oprogramowanie, z różnymi umowami licencyjnymi.

Przywracanie tej bazy danych w miejscu docelowym powinno być w porządku.