Udostępnij za pośrednictwem

Zarządzanie metadanymi podczas udostępniania bazy danych na innym serwerze

  • Artykuł

Dotyczy:programu SQL Server

Ten artykuł ma zastosowanie w następujących sytuacjach:

  • Konfigurowanie replik dostępności w grupach dostępności Always On.

  • Konfigurowanie dublowania bazy danych dla bazy danych.

  • Podczas przygotowywania do zmiany ról między serwerami podstawowymi i pomocniczymi w konfiguracji wysyłania dziennika.

  • Przywracanie bazy danych do innego wystąpienia serwera.

  • Dołączanie kopii bazy danych na innym wystąpieniu serwera.

  • Uaktualnianie silnika bazy danych przy użyciu metody migracji do nowej instalacji.

  • Migrowanie baz danych do usługi Azure SQL (maszyna wirtualna lub wystąpienie zarządzane).

Niektóre aplikacje zależą od informacji, jednostek i/lub obiektów, które znajdują się poza zakresem pojedynczej bazy danych użytkownika. Zazwyczaj aplikacja ma zależności od baz danych master i msdb, a także bazy danych użytkowników. Wszystkie elementy przechowywane poza bazą danych użytkownika, które są wymagane do prawidłowego funkcjonowania tej bazy danych, muszą być udostępniane w wystąpieniu serwera docelowego. Na przykład identyfikatory logowania aplikacji są przechowywane jako metadane w bazie danych master i muszą zostać ponownie utworzone na serwerze docelowym. Jeśli plan konserwacji aplikacji lub bazy danych zależy od zadań agenta programu SQL Server, których metadane są przechowywane w bazie danych msdb, należy ponownie utworzyć te zadania w wystąpieniu serwera docelowego. Podobnie metadane wyzwalacza na poziomie serwera są przechowywane w master.

Podczas przenoszenia bazy danych dla aplikacji do innego wystąpienia serwera należy ponownie utworzyć wszystkie metadane jednostek zależnych i obiektów w master i msdb w wystąpieniu serwera docelowego. Jeśli na przykład aplikacja bazy danych używa wyzwalaczy na poziomie serwera, samo dołączenie lub przywrócenie bazy danych w nowym systemie nie wystarczy. Baza danych nie będzie działać zgodnie z oczekiwaniami, chyba że ręcznie utworzysz ponownie metadane dla tych wyzwalaczy w bazie danych master.

Informacje, jednostki i obiekty przechowywane poza bazami danych użytkowników

W pozostałej części tego artykułu podsumowano potencjalne problemy, które mogą mieć wpływ na bazę danych udostępnioną w innym wystąpieniu serwera. Może być konieczne ponowne utworzenie jednego lub większej liczby typów informacji, jednostek lub obiektów wymienionych na poniższej liście. Aby wyświetlić podsumowanie, wybierz link dla elementu.

Ustawienia konfiguracji serwera

PROGRAM SQL Server 2005 (9.x) i nowsze wersje selektywnie instalują i uruchamiają kluczowe usługi i funkcje. Pomaga to zmniejszyć obszar powierzchni narażony na ataki systemu. W domyślnej konfiguracji nowych instalacji wiele funkcji nie jest włączonych. Jeśli baza danych korzysta z dowolnej usługi lub funkcji, która jest domyślnie wyłączona, ta usługa lub funkcja musi być włączona w wystąpieniu serwera docelowego.

Aby uzyskać więcej informacji na temat tych ustawień i ich włączania lub wyłączania, zobacz Opcje konfiguracji serwera (SQL Server).

Dane uwierzytelniające

Poświadczenie to rekord zawierający informacje uwierzytelniania wymagane do nawiązania połączenia z zasobem poza programem SQL Server. Większość poświadczeń składa się z nazwy logowania i hasła systemu Windows.

Aby uzyskać więcej informacji na temat tej funkcji, zobacz Credentials (Aparat bazy danych).

Notatka

Konta agenta serwera proxy programu SQL Server używają poświadczeń. Aby poznać identyfikator poświadczeń konta serwera proxy, użyj tabeli systemu sysproxies.

Zapytania obejmujące wiele baz danych

Opcje bazy danych DB_CHAINING i TRUSTWORTHY są domyślnie wyłączone. Jeśli dla oryginalnej bazy danych ustawiono te opcje na WŁ., może być konieczne włączenie tych ustawień w instancji serwera docelowego bazy danych. Aby uzyskać więcej informacji, zobacz ALTER DATABASE (Transact-SQL).

Operacje dołączania i odłączania wyłączają tworzenie łańcuchów własności między bazami danych. Aby uzyskać informacje o tym, jak włączyć łańcuchowanie własności między bazami danych, zobacz opcję konfiguracji serwera.

Aby uzyskać więcej informacji, zobacz również Skonfiguruj bazę danych lustrzaną, aby używać Właściwości Godnej Zaufania (Transact-SQL)

Własność bazy danych

Po przywróceniu bazy danych na innym komputerze identyfikator logowania programu SQL Server lub użytkownik systemu Windows, który zainicjował operację przywracania, automatycznie staje się właścicielem nowej bazy danych. Po przywróceniu bazy danych administrator systemu lub nowy właściciel bazy danych może zmienić własność bazy danych.

Zapytania rozproszone i połączone serwery

Zapytania rozproszone i połączone serwery są obsługiwane w przypadku aplikacji OLE DB. Zapytania rozproszone uzyskują dostęp do danych z wielu heterogenicznych źródeł danych na tych samych lub różnych komputerach. Konfiguracja serwera połączonego umożliwia programowi SQL Server wykonywanie poleceń względem źródeł danych OLE DB na serwerach zdalnych. Aby uzyskać więcej informacji na temat tych funkcji, zobacz Połączone Serwery (Silnik Bazy Danych).

Zaszyfrowane dane

Jeśli baza danych udostępniana w innym wystąpieniu serwera zawiera zaszyfrowane dane, a klucz główny bazy danych jest chroniony przez klucz główny usługi na oryginalnym serwerze, może być konieczne ponowne utworzenie szyfrowania klucza głównego usługi. klucz główny bazy danych jest kluczem symetrycznym używanym do ochrony kluczy prywatnych certyfikatów i kluczy asymetrycznych w zaszyfrowanej bazie danych. Po utworzeniu klucz główny bazy danych jest szyfrowany przy użyciu algorytmu Triple DES i hasła dostarczonego przez użytkownika.

Aby włączyć automatyczne odszyfrowywanie klucza głównego bazy danych w wystąpieniu serwera, kopia tego klucza jest szyfrowana przy użyciu klucza głównego usługi. Ta zaszyfrowana kopia jest przechowywana zarówno w bazie danych, jak i w master. Zazwyczaj kopia przechowywana w master jest w trybie dyskretnym aktualizowana za każdym razem, gdy klucz główny zostanie zmieniony. Program SQL Server najpierw próbuje odszyfrować klucz główny bazy danych za pomocą klucza głównego serwisu instancji. Jeśli to odszyfrowywanie nie powiedzie się, program SQL Server przeszukuje magazyn poświadczeń dla poświadczeń klucza głównego, które mają ten sam identyfikator GUID rodziny co baza danych, dla której wymaga klucza głównego. Następnie program SQL Server próbuje odszyfrować klucz główny bazy danych z każdym pasującym poświadczeniem, dopóki odszyfrowanie nie powiedzie się lub nie będzie więcej poświadczeń. Klucz główny, który nie jest zaszyfrowany przez klucz główny usługi, musi zostać otwarty przy użyciu instrukcji OPEN MASTER KEY i hasła.

Gdy zaszyfrowana baza danych zostanie skopiowana, przywrócona lub dołączona do nowego wystąpienia programu SQL Server, kopia klucza głównego bazy danych zaszyfrowana przez klucz główny usługi nie jest przechowywana w master w wystąpieniu serwera docelowego. W wystąpieniu serwera docelowego należy otworzyć klucz główny bazy danych. Aby otworzyć klucz główny, wykonaj następującą instrukcję: OPEN MASTER KEY DECRYPTION BY PASSWORD ='password'. Zalecamy, aby następnie włączyć automatyczne odszyfrowywanie klucza głównego bazy danych przez wykonanie następującej instrukcji: ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY. Instrukcja ALTER MASTER KEY zapewnia wystąpieniu serwera kopię klucza głównego bazy danych, która jest zaszyfrowana kluczem głównym usługi. Aby uzyskać więcej informacji, zobacz OPEN MASTER KEY (Transact-SQL) i ALTER MASTER KEY (Transact-SQL).

Aby uzyskać informacje na temat włączania automatycznego odszyfrowywania klucza głównego bazy danych dublowanej bazy danych, zobacz Konfigurowanie zaszyfrowanej dublowanej bazy danych.

Aby uzyskać więcej informacji, zobacz również:

Komunikaty o błędach zdefiniowane przez użytkownika

Komunikaty o błędach zdefiniowane przez użytkownika znajdują się w widoku katalogu sys.messages. Ten widok wykazu jest przechowywany w master. Jeśli aplikacja bazy danych zależy od komunikatów o błędach zdefiniowanych przez użytkownika, a baza danych zostanie udostępniona w innym wystąpieniu serwera, użyj sp_addmessage, aby dodać te komunikaty zdefiniowane przez użytkownika w wystąpieniu serwera docelowego.

Powiadomienia o zdarzeniach i zdarzenia Instrumentacji Zarządzania Windows (WMI) (na poziomie serwera)

powiadomienia o zdarzeniach Server-Level

Powiadomienia o zdarzeniach na poziomie serwera są przechowywane w msdb. W związku z tym jeśli aplikacja bazy danych korzysta z powiadomienia o zdarzeniu na poziomie serwera, to powiadomienie o zdarzeniu musi zostać ponownie utworzone w wystąpieniu serwera docelowego. Aby wyświetlić powiadomienia o zdarzeniach w wystąpieniu serwera, użyj widoku katalogu sys.server_event_notifications. Aby uzyskać więcej informacji, zobacz Powiadomienia o wydarzeniach.

Ponadto powiadomienia o zdarzeniach są dostarczane przy użyciu usługi Service Broker. Trasy dla komunikatów przychodzących nie są uwzględniane w bazie danych zawierającej usługę. Zamiast tego jawne trasy są przechowywane w msdb. Jeśli usługa używa jawnej trasy w bazie danych msdb do kierowania komunikatów przychodzących do usługi, podczas dołączania bazy danych w innym wystąpieniu należy ponownie utworzyć tę trasę.

Zdarzenia Windows Management Instrumentation (WMI)

Dostawca WMI dla zdarzeń serwera umożliwia monitorowanie zdarzeń programu SQL Server za pomocą instrumentacji zarządzania Windows (WMI). Każda aplikacja, która opiera się na zdarzeniach na poziomie serwera uwidocznionych za pośrednictwem dostawcy WMI, na którym opiera się baza danych, musi być zdefiniowana na komputerze docelowego wystąpienia serwera. Dostawca zdarzeń usługi WMI tworzy powiadomienia o zdarzeniach z usługą docelową zdefiniowaną w msdb.

Notatka

Aby uzyskać więcej informacji, zobacz Dostawca WMI dla koncepcji dotyczących zdarzeń serwera.

Aby utworzyć alert usługi WMI przy użyciu programu SQL Server Management Studio

Jak działają powiadomienia o zdarzeniach dla dublowanej bazy danych

Dostarczanie między bazami danych powiadomień o zdarzeniach obejmujących dublowaną bazę danych jest zdalne, z definicji, ponieważ dublowana baza danych może przejść w tryb failover. Usługa Service Broker zapewnia specjalną obsługę zduplikowanych baz danych w postaci zduplikowanych tras . Trasa dublowana ma dwa adresy: jeden dla wystąpienia głównego serwera i jeden dla wystąpienia serwera dublowanego.

Konfigurując trasy lustrzane, powodujesz, że routing usługi Service Broker uwzględnia dublowanie bazy danych. Trasy lustrzane umożliwiają brokerowi usługi przekierowywanie konwersacji w sposób przejrzysty do bieżącego głównego wystąpienia serwera. Rozważmy na przykład usługę Service_A hostowaną przez dublowaną bazę danych Database_A. Załóżmy, że potrzebujesz innej usługi, Service_B, która jest hostowana przez Database_B, aby mieć okno dialogowe z Service_A. Aby ten dialog był możliwy, Database_B musi zawierać lustrzaną trasę dla Service_A. Ponadto Database_A musi zawierać niemirrorowaną trasę transportu TCP do Service_B, która, w przeciwieństwie do trasy lokalnej, pozostaje prawidłowa po przejściu w tryb failover. Te trasy umożliwiają powrót zestawów ACL po przejściu w tryb failover. Ponieważ usługa nadawcy jest zawsze nazywana w ten sam sposób, ścieżka musi określać instancję brokera.

Wymaganie dotyczące tras dublowanych ma zastosowanie niezależnie od tego, czy usługa w dublowanej bazie danych jest usługą inicjatora, czy usługą docelową:

  • Jeśli usługa docelowa znajduje się w dublowanej bazie danych, usługa inicjatora musi mieć dublowaną trasę z powrotem do miejsca docelowego. Jednak obiekt docelowy może mieć regularną trasę z powrotem do inicjatora.

  • Jeśli usługa inicjatora znajduje się w zmirrowanej bazie danych, usługa docelowa musi mieć zmirrowaną trasę z powrotem do inicjatora w celu dostarczenia potwierdzeń i odpowiedzi. Jednak inicjator może mieć regularną trasę do obiektu docelowego.

Rozszerzone procedury składowane

Ważny

Ta funkcja zostanie usunięta w przyszłej wersji programu SQL Server. Unikaj używania tej funkcji w nowych pracach programistycznych i zaplanuj modyfikowanie aplikacji, które obecnie korzystają z tej funkcji. Zamiast tego użyj integracji CLR.

Procedury składowane rozszerzone są programowane przy użyciu API rozszerzonych procedur składowanych SQL Server. Członek sysadmin stałej roli serwera może zarejestrować rozszerzoną procedurę składowaną z wystąpieniem programu SQL Server i udzielić użytkownikom uprawnień do wykonania procedury. Rozszerzone procedury składowane można dodawać tylko do bazy danych master.

Rozszerzone procedury składowane są uruchamiane bezpośrednio w przestrzeni adresowej wystąpienia programu SQL Server i mogą powodować przecieki pamięci lub inne problemy, które zmniejszają wydajność i niezawodność serwera. Należy rozważyć przechowywanie rozszerzonych procedur składowanych w wystąpieniu programu SQL Server, które jest oddzielone od wystąpienia zawierającego przywołyane dane. Należy również rozważyć użycie zapytań rozproszonych w celu uzyskania dostępu do bazy danych.

Ważny

Przed dodaniem rozszerzonych procedur składowanych na serwerze i udzieleniu uprawnień EXECUTE innym użytkownikom administrator systemu powinien dokładnie przejrzeć każdą rozszerzoną procedurę składowaną, aby upewnić się, że nie zawiera szkodliwego lub złośliwego kodu.

Aby uzyskać więcej informacji, zobacz PRZYZNAJ uprawnienia obiektu (Transact-SQL), ODMÓW uprawnienia obiektu (Transact-SQL)i ODWOŁAJ uprawnienia obiektu (Transact-SQL).

Full-Text Engine for SQL Server Properties (Aparat Full-Text dla właściwości programu SQL Server)

Właściwości są ustawiane na Full-Text Engine przez sp_fulltext_service. Upewnij się, że instancja serwera docelowego ma wymagane ustawienia dla tych właściwości. Aby uzyskać więcej informacji na temat tych właściwości, zobacz FULLTEXTSERVICEPROPERTY (Transact-SQL).

Ponadto, jeśli moduły dzielenia wyrazów i składnika stemmerów lub filtry wyszukiwania pełnotekstowego mają różne wersje w wystąpieniach oryginalnego i docelowego serwera, indeks pełnotekstowy i zapytania pełnotekstowe mogą zachowywać się inaczej. Ponadto tezaurusa są przechowywane w plikach specyficznych dla wystąpienia. Należy przenieść kopię tych plików do równoważnej lokalizacji w wystąpieniu serwera docelowego lub utworzyć je ponownie w nowym wystąpieniu.

Notatka

Po dołączeniu bazy danych programu SQL Server 2005 (9.x) zawierającej pliki wykazu pełnotekstowego do wystąpienia serwera programu SQL Server pliki wykazu są dołączane z poprzedniej lokalizacji wraz z innymi plikami bazy danych, tak samo jak w programie SQL Server 2005 (9.x). Aby uzyskać więcej informacji, zobacz Upgrade Full-Text Search.

Aby uzyskać więcej informacji, zobacz również:

Zadania

Jeśli baza danych opiera się na zadaniach agenta programu SQL Server, należy je ponownie utworzyć w wystąpieniu serwera docelowego. Zadania zależą od ich środowisk. Jeśli planujesz ponownie utworzyć istniejące zadanie w wystąpieniu serwera docelowego, może być konieczne zmodyfikowanie wystąpienia serwera docelowego w celu dopasowania środowiska tego zadania w oryginalnym wystąpieniu serwera. Istotne są następujące czynniki środowiskowe:

  • Dane logowania używane przez zadanie

    Aby utworzyć lub wykonać zadania agenta programu SQL Server, należy najpierw dodać wszystkie identyfikatory logowania programu SQL Server wymagane przez zadanie do wystąpienia serwera docelowego. Aby uzyskać więcej informacji, zobacz Configure a User to Create and Manage SQL Server Agent Jobs (Konfigurowanie użytkownika do tworzenia zadań agenta programu SQL Server i zarządzania nimi).

  • Konto uruchamiania usługi SQL Server Agent

    Konto uruchamiania usługi definiuje konto systemu Microsoft Windows, na którym działa program SQL Server Agent i jego uprawnienia sieciowe. Agent programu SQL Server działa jako określone konto użytkownika. Kontekst usługi Agent wpływa na ustawienia zadania i środowiska, w którym jest uruchamiane. Konto musi mieć dostęp do zasobów, takich jak udziały sieciowe, wymagane przez zadanie. Aby uzyskać informacje o sposobie wybierania i modyfikowania konta uruchamiania usługi, zobacz Select an Account for the SQL Server Agent Service(Wybieranie konta usługi SQL Server Agent Service).

    Aby działało poprawnie, konto uruchamiania usługi musi być skonfigurowane tak, aby miało odpowiednie uprawnienia do domeny, systemu plików i rejestru. Ponadto zadanie może wymagać udostępnionego zasobu sieciowego, który musi być skonfigurowany dla konta usługi. Aby uzyskać informacje, zobacz Konfigurowanie kont i uprawnień usług w systemie Windows.

  • Usługa SQL Server Agent, która jest skojarzona z określonym wystąpieniem programu SQL Server, ma własną gałąź rejestru, a jej zadania zwykle mają zależności od co najmniej jednego ustawienia w tej gałęzi rejestru. Aby zachowywać się zgodnie z oczekiwaniami, zadanie wymaga tych ustawień rejestru. Jeśli użyjesz skryptu do ponownego utworzenia zadania w innej usłudze agenta programu SQL Server, jego rejestr może nie mieć poprawnych ustawień dla tego zadania. Aby ponownie utworzone zadania działały prawidłowo w wystąpieniu serwera docelowego, oryginalne i docelowe usługi agenta programu SQL Server powinny mieć te same ustawienia rejestru.

    Ostrożność

    Zmiana ustawień rejestru w docelowej usłudze agenta programu SQL Server w celu obsługi ponownie utworzonego zadania może być problematyczna, jeśli bieżące ustawienia są wymagane przez inne zadania. Ponadto niepoprawne edytowanie rejestru może spowodować poważne uszkodzenie systemu. Przed wprowadzeniem zmian w rejestrze zalecamy wykonanie kopii zapasowej wszystkich wartościowych danych na komputerze.

  • Proxy agenta programu SQL Server

    Serwer proxy agenta programu SQL Server definiuje kontekst zabezpieczeń dla określonego kroku zadania. Aby zadanie mogło zostać uruchomione na wystąpieniu serwera docelowego, wszystkie wymagane przez nie proxy muszą zostać ręcznie odtworzone na tym wystąpieniu. Aby uzyskać więcej informacji, zobacz Utwórz pełnomocnika agenta SQL Server oraz Rozwiązywanie problemów z zadaniami wieloserwerowymi używającymi serwerów proxy.

Aby uzyskać więcej informacji, zobacz również:

Aby wyświetlić istniejące zadania i ich właściwości

Aby utworzyć zadanie

Najlepsze rozwiązania dotyczące ponownego tworzenia zadania za pomocą skryptu

Zalecamy rozpoczęcie od utworzenia skryptu prostego zadania, ponownego utworzenia zadania w innej usłudze agenta programu SQL Server i uruchomienia zadania w celu sprawdzenia, czy działa zgodnie z oczekiwaniami. Pozwoli to zidentyfikować niezgodności i spróbować je rozwiązać. Jeśli zadanie skryptowe nie działa zgodnie z oczekiwaniami w nowym środowisku, zalecamy utworzenie równoważnego zadania, które działa poprawnie w tym środowisku.

Logowania

Zalogowanie się do wystąpienia programu SQL Server wymaga prawidłowego logowania do programu SQL Server. Ten login jest używany w procesie uwierzytelniania, który sprawdza, czy użytkownik może nawiązać połączenie z instancją SQL Server. Użytkownik bazy danych, dla którego login SQL Server jest niezdefiniowany lub niesłusznie zdefiniowany na wystąpieniu serwera, nie może zalogować się na to wystąpienie. Taki użytkownik jest podobno użytkownikiem oddzielonym bazy danych w tym wystąpieniu serwera. Użytkownik bazy danych może zostać osierocony, jeśli po przywróceniu, dołączeniu lub skopiowaniu bazy danych do innego wystąpienia programu SQL Server.

Aby wygenerować skrypt dla niektórych lub wszystkich obiektów w oryginale bazy danych, możesz użyć Kreatora generowania skryptów, a w oknie dialogowym Wybierz opcje skryptu ustaw opcję Skrypty logowania na True.

Notatka

Aby uzyskać informacje o sposobie konfigurowania kont logowania dla dublowanej bazy danych, zobacz Konfigurowanie kont logowania na potrzeby dublowania bazy danych lub Always On Availability Groups (SQL Server) i Zarządzanie nazwami logowania i zadaniami po przełączeniu roli (SQL Server).

Uprawnienia

Następujące typy uprawnień mogą ulec zmianie, gdy baza danych jest udostępniana w innym wystąpieniu serwera.

  • PRZYZNAWANIE, ODWOŁYWANIE lub ODMAWIANIE uprawnień do obiektów systemowych

  • Przyznawanie, cofanie lub odmowa uprawnień w instancji serwera (uprawnienia na poziomie serwera)

PRZYZNAJ, ODWOŁAJ i ODRZUĆ uprawnienia na obiektach systemowych

Uprawnienia do obiektów systemowych, takich jak procedury składowane, rozszerzone procedury składowane, funkcje i widoki, są przechowywane w bazie danych master i muszą być skonfigurowane w wystąpieniu serwera docelowego.

Aby wygenerować skrypt dla niektórych lub wszystkich obiektów w oryginalnej kopii bazy danych, możesz użyć Kreatora generowania skryptów, a w oknie dialogowym Wybierz opcje skryptów ustaw opcję Skrypt Object-Level uprawnienia na True.

Ważny

Jeśli skryptujesz logowania, hasła nie są skryptowane. Jeśli masz identyfikatory logowania korzystające z uwierzytelniania programu SQL Server, musisz zmodyfikować skrypt w miejscu docelowym.

Obiekty systemowe są widoczne w widoku wykazu sys.system_objects. Uprawnienia do obiektów systemowych są widoczne w widoku katalogu sys.database_permissions w bazie danych master. Aby uzyskać informacje na temat zapytań dotyczących tych widoków wykazu i udzielania uprawnień do obiektów systemowych, zobacz GRANT System Object Permissions (Transact-SQL). Aby uzyskać więcej informacji, zobacz ODWOŁAJ uprawnienia obiektu systemowego (Transact-SQL) i ODMAWIAJ uprawnień obiektu systemowego (Transact-SQL).

UDZIELANIE, ODWOŁYWANIE i ODMAWIANIE uprawnień na instancji serwera

Uprawnienia w zakresie serwera są przechowywane w bazie danych master i muszą być skonfigurowane w instancji serwera docelowego. Aby uzyskać informacje o uprawnieniach instancji serwera, wykonaj zapytanie w widoku wykazu sys.server_permissions, aby uzyskać informacje o jednostkach serwera, wykonaj zapytanie w widoku wykazu sys.server_principals, a aby uzyskać informacje o członkostwie ról serwera, wykonaj zapytanie w widoku wykazu sys.server_role_members.

Aby uzyskać więcej informacji, zobacz GRANT Server Permissions (Transact-SQL), ODWOŁAJ uprawnienia serwera (Transact-SQL)i ODMAWIAJ uprawnień serwera (Transact-SQL).

Server-Level uprawnienia certyfikatu lub klucza asymetrycznego

Nie można udzielić uprawnień na poziomie serwera bezpośrednio do certyfikatu lub klucza asymetrycznego. Zamiast tego uprawnienia na poziomie serwera są przyznawane mapowanemu identyfikatorowi logowania, które jest tworzone wyłącznie dla określonego certyfikatu lub klucza asymetrycznego. W związku z tym każdy certyfikat lub klucz asymetryczny, który wymaga uprawnień na poziomie serwera, wymaga własnego logowania mapowanego certyfikatem lub logowania zamapowanego klucza asymetrycznego. Aby udzielić uprawnień na poziomie serwera dla certyfikatu lub klucza asymetrycznego, przyznaj uprawnienia do jego zamapowanego logowania.

Notatka

Mapowane dane logowania są używane tylko do autoryzacji kodu podpisanego przy użyciu odpowiedniego certyfikatu lub klucza asymetrycznego. Mapowane nazwy logowania nie mogą być używane do uwierzytelniania.

Mapowany login i uprawnienia znajdują się w master. Jeśli certyfikat lub klucz asymetryczny znajduje się w bazie danych innej niż master, należy utworzyć go ponownie w master i zamapować go na identyfikator logowania. W przypadku przenoszenia, kopiowania lub przywracania bazy danych do innego wystąpienia serwera należy ponownie utworzyć jej certyfikat lub klucz asymetryczny w bazie danych master wystąpienia serwera docelowego, przypisać do logowania i udzielić wymaganych uprawnień na poziomie serwera logowaniu.

Aby utworzyć certyfikat lub klucz asymetryczny

Aby zamapować certyfikat lub klucz asymetryczny do konta logowania

Aby przypisać uprawnienia do mapowanego logowania

Aby uzyskać więcej informacji na temat certyfikatów i kluczy asymetrycznych, zobacz hierarchia szyfrowania.

Nieruchomość Godna Zaufania

Właściwość TRUSTWORTHY służy do wskazania, czy ta instancja programu SQL Server ufa bazie danych i jej zawartości. Gdy baza danych jest dołączona domyślnie i dla zabezpieczeń, ta opcja jest ustawiona na WYŁ., nawet jeśli ta opcja została ustawiona na WŁ. na oryginalnym serwerze. Aby uzyskać więcej informacji na temat tej właściwości, zobacz właściwość bazy danych TRUSTWORTHY i aby uzyskać informacje na temat włączania tej opcji, zobacz ALTER DATABASE (Transact-SQL).

Ustawienia replikacji

W przypadku przywrócenia kopii zapasowej replikowanej bazy danych na inny serwer lub bazę danych nie można zachować ustawień replikacji. W takim przypadku należy ponownie utworzyć wszystkie publikacje i subskrypcje po przywróceniu kopii zapasowych. Aby ułatwić ten proces, należy utworzyć skrypty dla bieżących ustawień replikacji, a także włączyć i wyłączyć replikację. Aby ułatwić ponowne utworzenie ustawień replikacji, skopiuj te skrypty i zmień odwołania do nazwy serwera, aby działały dla wystąpienia serwera docelowego.

Aby uzyskać więcej informacji, zobacz Tworzenie kopii zapasowych i przywracanie replikowanych baz danych, dublowanie i replikacja bazy danych (SQL Server)oraz wysyłanie i replikacja dzienników (SQL Server).

Aplikacje brokera usług

Wiele aspektów aplikacji Service Broker przenosi się z bazą danych. Jednak niektóre aspekty aplikacji muszą zostać ponownie utworzone lub ponownie skonfigurowane w nowej lokalizacji. Domyślnie i w przypadku zabezpieczeń, gdy baza danych jest dołączona z innego serwera, opcje dla is_broker_enabled i is_honoor_broker_priority_on są ustawione na WYŁ. Aby uzyskać informacje na temat włączenia tych opcji, zobacz ALTER DATABASE (Transact-SQL).

Procedury uruchamiania

Procedura uruchamiania to procedura składowana oznaczona do automatycznego wykonywania i wykonywana za każdym razem, gdy program SQL Server jest uruchamiany. Jeśli baza danych zależy od procedur uruchamiania, należy je zdefiniować w wystąpieniu serwera docelowego i skonfigurować do automatycznego wykonywania podczas uruchamiania.

Wyzwalacze (na poziomie serwera)

Wyzwalacze DDL uruchamiają procedury składowane w odpowiedzi na kilka zdarzeń języka definiowania danych (DDL - Data Definition Language). Te zdarzenia odpowiadają przede wszystkim instrukcjom Transact-SQL rozpoczynającym się od słów kluczowych CREATE, ALTER i DROP. Niektóre systemowe procedury składowane, które wykonują operacje DDL, mogą również uruchamiać wyzwalacze DDL.

Aby uzyskać więcej informacji na temat tej funkcji, zobacz wyzwalacze DDL.

Zobacz też

zawarte bazy danych
kopiowanie baz danych na inne serwery
Odłączanie i Podłączanie Bazy Danych (SQL Server)
Przełączenie awaryjne na sekundarny serwer w procesie Log Shipping (SQL Server)
Przełączanie roli podczas sesji dublowania bazy danych (SQL Server)
Konfigurowanie zaszyfrowanej lustrzanej bazy danych
SQL Server Configuration Manager
Rozwiązywanie problemów z osieroconymi użytkownikami (SQL Server)
Migracja do nowej instalacjiOmówienie migracji: SQL Server do SQL Server na maszynach wirtualnych platformy Azure