Max udzielił przyzwoitej odpowiedzi, którą będę głosować, gdy skończę pisać ten alternatywny widok.
Nie jestem fanem przywracania systemowych baz danych podczas migracji uaktualnień i wolę przeprowadzać migracje zamiast uaktualnień w miejscu, o czym mówiłem w tej długiej odpowiedzi na inne pytanie.
Zasadniczo lubię zaczynać „świeżo” podczas migracji. Uważam, że granie z migracjami systemowych baz danych i aktualizacjami poprzez przywracanie czasami powoduje frustrację przywracaniem i może przenosić potencjalne grzechy.
Pytałeś także o indeksy, procedury składowane, widoki. Wszystkie elementy na poziomie bazy danych powinny znajdować się w bazie danych użytkowników. Kiedy więc przywrócisz bazę danych X na nowy serwer, wszystkie obiekty bazy danych (tabele, użytkownicy, widoki, procesy, funkcje itp.) Również tam będą.
W systemowych bazach danych znajdują się zadania, dane logowania, alerty, połączone serwery, klucze szyfrowania itp. Elementy poziomu instancji.
Lubię je przeglądać i migrować ponad to, czego potrzebuję, używając różnych skryptów - ostatnio są to skrypty DBATools.Io PowerShell. Lubię używać ich skryptu do kopiowania loginów SQL, zwłaszcza, że obsługuje on uwierzytelnionych użytkowników SQL, zachowując ich hasła i identyfikatory bezpieczeństwa tak, aby użytkownicy bazy danych z tych loginów działali. Mają także całe polecenie migracji programu SQL Server, które uruchamia polecenia podrzędne, aby skopiować elementy, które zwykle kopiowałbym.
Nie wierzę, że Max się myli z tą odpowiedzią, stąd opinia. Właśnie odniosłem większy sukces i więcej szczęścia i czuję się bardziej swobodnie migrując do nowego zamiast próbować przywracać systemowe bazy danych między wersjami. Powiedziałbym, że szczerze mówiąc, nie pamiętam, kiedy po raz ostatni przeprowadziłem migrację aktualizacji wersji i nie zrobiłem tego w ten sposób zamiast przywracania systemowych baz danych.