Sdílet prostřednictvím

Správa metadat při zpřístupnění databáze na jiném serveru

  • Článek

platí pro:SQL Server

Tento článek je relevantní v následujících situacích:

  • Konfigurace replik dostupnosti skupiny dostupnosti AlwaysOn

  • Nastavení zrcadlení pro databázi.

  • Při přípravě na výměnu rolí mezi primárním a sekundárním serverem v konfiguraci přenosu protokolů.

  • Obnovení databáze do jiné instance serveru

  • Připojení kopie databáze na jiné instanci serveru

  • Provedení upgradu databázového stroje pomocí metody – migrace na novou instalaci

  • Migrace databází do Azure SQL (virtuální počítač nebo spravovaná instance)

Některé aplikace závisí na informacích, entitách a/nebo objektech, které jsou mimo rozsah databáze jednoho uživatele. Aplikace má obvykle závislosti na master a msdb databázích a také v uživatelské databázi. Vše, co je uloženo mimo uživatelskou databázi, která je nutná pro správné fungování této databáze, musí být zpřístupněno v instanci cílového serveru. Například přihlášení aplikace se ukládají jako metadata v databázi master a musí se znovu vytvořit na cílovém serveru. Pokud plán údržby aplikace nebo databáze závisí na úlohách agenta SQL Serveru, jejichž metadata jsou uložena v msdb databázi, musíte tyto úlohy znovu vytvořit v instanci cílového serveru. Podobně jsou metadata triggeru na úrovni serveru uložena v master.

Když přesunete databázi aplikace do jiné instance serveru, musíte znovu vytvořit všechna metadata závislých entit a objektů v master a msdb v instanci cílového serveru. Pokud například databázová aplikace používá triggery na úrovni serveru, pouze připojit nebo obnovit databázi v novém systému nestačí. Databáze nebude fungovat podle očekávání, pokud ručně znovu nevytváříte metadata pro tyto triggery v databázi master.

Informace, entity a objekty uložené mimo uživatelské databáze

Zbývající část tohoto článku shrnuje potenciální problémy, které můžou mít vliv na databázi, která je zpřístupněna v jiné instanci serveru. Je možné, že budete muset znovu vytvořit jeden nebo více typů informací, entit nebo objektů uvedených v následujícím seznamu. Pokud chcete zobrazit souhrn, vyberte odkaz na položku.

Nastavení konfigurace serveru

SQL Server 2005 (9.x) a novější verze selektivně nainstalují a spustí klíčové služby a funkce. To pomáhá snížit útočnou plochu systému. Ve výchozí konfiguraci nových instalací není povoleno mnoho funkcí. Pokud databáze spoléhá na jakoukoli službu nebo funkci, která je ve výchozím nastavení vypnutá, musí být tato služba nebo funkce povolena v instanci cílového serveru.

Další informace o těchto nastaveních a jejich povolení nebo zakázání naleznete v tématu Možnosti konfigurace serveru (SQL Server).

Pověření

Přihlašovací údaje jsou záznam, který obsahuje ověřovací informace potřebné pro připojení k prostředku mimo SQL Server. Většina přihlašovacích údajů se skládá z přihlášení a hesla windows.

Další informace o této funkci naleznete v tématu Přihlašovací údaje (databázový stroj).

Poznámka

Účty proxy agenta SQL Serveru používají přihlašovací údaje. Pokud chcete zjistit ID přihlašovacích údajů účtu proxy, použijte systémovou tabulku sysproxies.

Dotazy napříč databázemi

Možnosti databáze DB_CHAINING a TRUSTWORTHY jsou ve výchozím nastavení vypnuté. Pokud je pro původní databázi u některé z těchto možností nastavená hodnota ZAPNUTO, možná je budete muset povolit na databázi v instanci cílového serveru. Další informace naleznete v tématu ALTER DATABASE (Transact-SQL).

Operace připojení a odpojení deaktivují propojení vlastnictví mezi databázemi pro danou databázi. Informace o tom, jak povolit řetězení vlastnictví mezi databázemi, najdete v odstavci Možnost konfigurace serveru.

Pro více informací viz také Nastavení zrcadlové databáze pro použití vlastnosti Důvěryhodný (Transact-SQL)

Vlastnictví databáze

Po obnovení databáze na jiném počítači se automaticky stane vlastníkem nové databáze přihlášení SQL Serveru nebo uživatele systému Windows, který operaci obnovení zahájil. Po obnovení databáze může správce systému nebo nový vlastník databáze změnit vlastnictví databáze.

Distribuované dotazy a propojené servery

Distribuované dotazy a odkazované servery jsou podporovány pro aplikace OLE DB. Distribuované dotazy přistupují k datům z více heterogenních zdrojů dat na stejných nebo různých počítačích. Konfigurace propojeného serveru umožňuje SQL Serveru spouštět příkazy pro zdroje dat OLE DB na vzdálených serverech. Více informací o těchto funkcích naleznete v části Propojené servery (databázový modul).

Šifrovaná data

Pokud databáze, kterou zpřístupňujete v jiné instanci serveru, obsahuje šifrovaná data a pokud je hlavní klíč databáze chráněný hlavním klíčem služby na původním serveru, může být nutné znovu vytvořit šifrování hlavního klíče služby. hlavní klíč databáze je symetrický klíč, který slouží k ochraně privátních klíčů certifikátů a asymetrických klíčů v šifrované databázi. Při vytváření se hlavní klíč databáze zašifruje pomocí algoritmu Triple DES a hesla zadaného uživatelem.

Pokud chcete povolit automatické dešifrování hlavního klíče databáze v instanci serveru, je kopie tohoto klíče šifrovaná pomocí hlavního klíče služby. Tato šifrovaná kopie je uložena v databázi i v master. Kopie uložená v master se obvykle bezobslužně aktualizuje při každé změně hlavního klíče. SQL Server se nejprve pokusí dešifrovat hlavní klíč databáze pomocí hlavního klíče služby instance. Pokud se toto dešifrování nezdaří, SQL Server vyhledá v úložišti přihlašovacích údajů hlavního klíče přihlašovací údaje, které mají stejný identifikátor GUID rodiny jako databáze, pro kterou vyžaduje hlavní klíč. SQL Server se pak pokusí dešifrovat hlavní klíč databáze s jednotlivými odpovídajícími přihlašovacími údaji, dokud dešifrování nebude úspěšné nebo nebudou k dispozici žádné další přihlašovací údaje. Hlavní klíč, který není šifrovaný hlavním klíčem služby, musí být otevřen pomocí příkazu OPEN MASTER KEY a hesla.

Při zkopírování, obnovení nebo připojení šifrované databáze k nové instanci SQL Serveru se kopie hlavního klíče databáze zašifrované hlavním klíčem služby neuloží do master v instanci cílového serveru. V instanci cílového serveru musíte otevřít hlavní klíč databáze. Pokud chcete otevřít hlavní klíč, spusťte následující příkaz: OPEN MASTER KEY DECRYPTION BY HESLO = 'heslo'. Doporučujeme, abyste poté povolili automatické dešifrování hlavního klíče databáze tím, že spustíte následující příkaz: ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY. Tento příkaz ALTER MASTER KEY zřídí instanci serveru s kopií hlavního klíče databáze, která je šifrovaná pomocí hlavního klíče služby. Další informace naleznete v tématu OPEN MASTER KEY (Transact-SQL) a ALTER MASTER KEY (Transact-SQL).

Informace o tom, jak povolit automatické dešifrování hlavního klíče zrcadlové databáze, naleznete v tématu Nastavení šifrované zrcadlové databáze.

Další informace najdete také:

Uživatelem definované chybové zprávy

Uživatelem definované chybové zprávy se nacházejí v zobrazení katalogu sys.messages. Toto zobrazení katalogu je uloženo v master. Pokud databázová aplikace závisí na uživatelem definovaných chybových zprávách a databáze je dostupná v jiné instanci serveru, použijte sp_addmessage k přidání těchto uživatelem definovaných zpráv do instance cílového serveru.

Oznámení událostí a události služby WMI (Windows Management Instrumentation) (na úrovni serveru)

Oznámení událostí Server-Level

Oznámení událostí na úrovni serveru jsou uložena v msdb. Proto pokud databázová aplikace spoléhá na oznámení událostí na úrovni serveru, musí být toto oznámení události znovu vytvořeno v instanci cílového serveru. Pokud chcete zobrazit oznámení událostí v instanci serveru, použijte zobrazení katalogu sys.server_event_notifications. Další informace najdete v tématu Oznámení událostí.

Oznámení událostí se navíc doručují pomocí služby Service Broker. Trasy pro příchozí zprávy nejsou zahrnuté v databázi, která obsahuje službu. Místo toho jsou explicitní trasy uloženy v msdb. Pokud vaše služba používá k směrování příchozích zpráv do služby explicitní trasu v databázi msdb, musíte při připojení databáze v jiné instanci tuto trasu znovu vytvořit.

Události služby WMI (Windows Management Instrumentation)

Zprostředkovatel rozhraní WMI pro serverové události umožňuje pomocí rozhraní WMI (Windows Management Instrumentation) monitorovat události na SQL Serveru. Každá aplikace, která spoléhá na události na úrovni serveru vystavené prostřednictvím zprostředkovatele služby WMI, na kterém databáze spoléhá, musí být definován počítač instance cílového serveru. Zprostředkovatel událostí rozhraní WMI vytvoří oznámení událostí s cílovou službou definovanou v msdb.

Poznámka

Další informace naleznete v tématu Zprostředkovatele rozhraní WMI pro koncepty událostí serveru.

Vytvoření výstrahy rozhraní WMI pomocí aplikace SQL Server Management Studio

Jak fungují oznámení událostí pro zrcadlenou databázi

Doručování oznámení událostí mezi databázemi, která zahrnují zrcadlenou databázi, je vzdálené podle definice, protože zrcadlená databáze může přejít v případě selhání. Service Broker poskytuje speciální podporu zrcadlených databází ve formě zrcadlených tras. Zrcadlovaná trasa má dvě adresy: jednu pro instanci hlavního serveru a jednu pro instanci zrcadlového serveru.

Nastavením zrcadlených tras umožníte směrování služby Service Broker zohledňovat zrcadlení databáze. Zrcadlené trasy umožňují službě Service Broker transparentně přesměrovat konverzace na aktuální instanci hlavního serveru. Představte si například službu, Service_A, která je hostovaná zrcadlovou databází Database_A. Předpokládejme, že potřebujete jinou službu, Service_B, která je hostovaná Database_B, abyste měli dialogové okno s Service_A. Aby bylo možné toto dialogové okno, musí Database_B obsahovat zrcadlenou trasu pro Service_A. Kromě toho musí Database_A obsahovat nezrcadlenou transportní cestu TCP do Service_B, která na rozdíl od místní trasy zůstává i po selhání platná. Tyto trasy umožňují, aby se sady ACL vrátily po převzetí služeb při selhání. Protože je služba odesílatele vždy pojmenována stejným způsobem, musí trasa specifikovat instanci zprostředkovatele.

Požadavek na zrcadlené trasy platí bez ohledu na to, jestli je služba v zrcadlené databázi iniciátorem nebo cílovou službou:

  • Pokud je cílová služba v zrcadlené databázi, musí mít služba iniciátoru zrcadlenou trasu zpět do cíle. Cíl ale může mít obvyklou trasu zpátky k iniciátorovi.

  • Pokud je služba iniciátoru v zrcadlené databázi, musí mít cílová služba zrcadlenou trasu zpět do iniciátoru, aby doručovala potvrzení a odpovědi. Iniciátor ale může mít běžnou trasu k cíli.

Rozšířené uložené procedury

Důležitý

Tato funkce bude odebrána v budoucí verzi SQL Serveru. Nepoužívejte tuto funkci v nové vývojové práci a naplánujte úpravu aplikací, které tuto funkci aktuálně používají. Místo toho použijte integraci CLR.

Rozšířené uložené procedury jsou naprogramovány pomocí rozhraní API rozšířené uložené procedury SQL Serveru. Člen správce systému pevné role serveru může zaregistrovat rozšířenou uloženou proceduru s instancí SQL Serveru a udělit uživatelům oprávnění ke spuštění procedury. Rozšířené uložené procedury lze přidat pouze do master databáze.

Rozšířené uložené procedury běží přímo v adresních prostorech instance SQL Serveru a mohou způsobit nevracení paměti nebo jiné problémy, které snižují výkon a spolehlivost serveru. Měli byste zvážit uložení rozšířených uložených procedur do instance SQL Serveru, která je oddělená od instance obsahující odkazovaná data. Měli byste také zvážit použití distribuovaných dotazů pro přístup k databázi.

Důležitý

Před přidáním rozšířených uložených procedur na server a udělením oprávnění EXECUTE jiným uživatelům by měl správce systému důkladně zkontrolovat každou rozšířenou uloženou proceduru a ujistit se, že neobsahuje škodlivý nebo škodlivý kód.

Další informace naleznete v tématu UDĚLIT oprávnění objektu (Transact-SQL), odepřít oprávnění objektu (Transact-SQL)a ODVOLAT oprávnění objektu (Transact-SQL).

Engine Full-Text pro vlastnosti SQL Serveru

Vlastnosti jsou nastaveny na modulu Full-Text pomocí sp_fulltext_service. Ujistěte se, že instance cílového serveru má požadovaná nastavení pro tyto vlastnosti. Další informace o těchto vlastnostech naleznete v tématu FULLTEXTSERVICEPROPERTY (Transact-SQL).

Kromě toho platí, že pokud mají komponenty breakery slov a stemmers a komponenty fulltextové vyhledávací filtry různé verze na původních a cílových instancích serveru, může se fulltextový index a dotazy chovat jinak. tesaurus je také uložen v souborech specifických pro instanci. Buď musíte přenést kopii těchto souborů do ekvivalentního umístění v instanci cílového serveru nebo je znovu vytvořit v nové instanci.

Poznámka

Když připojíte databázi SYSTÉMU SQL Server 2005 (9.x), která obsahuje soubory fulltextového katalogu k instanci serveru SQL Server, soubory katalogu jsou připojeny z předchozího umístění spolu s ostatními databázovými soubory, stejně jako v SYSTÉMU SQL Server 2005 (9.x). Další informace naleznete v tématu Upgrade Full-Text Vyhledávání.

Další informace najdete také:

Pracovní místa

Pokud databáze spoléhá na úlohy agenta SQL Serveru, budete je muset znovu vytvořit v instanci cílového serveru. Úlohy závisí na jejich prostředích. Pokud plánujete znovu vytvořit existující úlohu v instanci cílového serveru, může být potřeba upravit instanci cílového serveru tak, aby odpovídala prostředí této úlohy v původní instanci serveru. Důležité jsou následující faktory prostředí:

  • Přihlášení používané úlohou

    Pokud chcete vytvořit nebo spustit úlohy agenta SQL Serveru, musíte nejprve přidat všechna přihlášení SQL Serveru vyžadovaná úlohou do instance cílového serveru. Další informace najdete v tématu Konfigurace uživatele pro vytváření a správu úloh agenta SQL Serveru.

  • Spouštěcí účet služby agenta SQL Serveru

    Spouštěcí účet služby definuje účet Systému Microsoft Windows, ve kterém běží agent SQL Serveru a jeho síťová oprávnění. Agent SQL Serveru běží jako zadaný uživatelský účet. Kontext služby agenta ovlivňuje nastavení úlohy a její prostředí pro spuštění. Účet musí mít přístup k prostředkům, které vyžaduje úloha, jako jsou síťové sdílené složky. Informace o tom, jak vybrat a upravit spouštěcí účet služby, naleznete v tématu Vybrat účet pro službu agenta SYSTÉMU SQL Server.

    Aby správně fungoval, musí být spouštěcí účet služby nakonfigurovaný tak, aby měl správná oprávnění k doméně, systému souborů a registru. Úloha může také vyžadovat sdílený síťový prostředek, který musí být nakonfigurovaný pro účet služby. Informace naleznete v tématu Konfigurace účtů a oprávnění služby systému Windows.

  • Služba agenta SQL Serveru, která je přidružená ke konkrétní instanci SQL Serveru, má vlastní podregistr registru a jeho úlohy obvykle mají závislosti na jednom nebo několika nastaveních v tomto podregistru registru. Aby se úloha chovala podle očekávání, vyžaduje tato nastavení registru. Pokud k opětovnému vytvoření úlohy v jiné službě agenta SQL Serveru použijete skript, nemusí mít jeho registr správné nastavení pro tuto úlohu. Aby se znovu vytvořené úlohy mohly správně chovat v instanci cílového serveru, měly by původní a cílové služby agenta SQL Serveru mít stejná nastavení registru.

    Opatrnost

    Změna nastavení registru v cílové službě agenta SQL Serveru tak, aby zpracovávala znovu vytvořenou úlohu, může být problematická, pokud jsou aktuální nastavení vyžadována jinými úlohami. Nesprávná úprava registru může navíc vážně poškodit váš systém. Před provedením změn registru doporučujeme zálohovat všechna hodnotná data v počítači.

  • Proxy agenta SQL Serveru

    Proxy agenta SQL Serveru definuje kontext zabezpečení pro zadaný krok úlohy. Aby úloha běžela na instanci cílového serveru, musí být všechny proxy servery, které vyžaduje, ručně znovu vytvořeny v této instanci. Další informace najdete v tématu Vytvořte proxy agenta služby SQL Server a Odstraňte problémy s úlohami na více serverech, které používají proxy.

Další informace najdete také:

Zobrazení existujících úloh a jejich vlastností

Vytvořit úlohu

Osvědčené postupy pro opětovné vytvoření úlohy pomocí skriptu

Doporučujeme začít skriptováním jednoduché úlohy, opětovným vytvořením úlohy v jiné službě agenta SQL Serveru a spuštěním úlohy zjistit, jestli funguje podle očekávání. To vám umožní identifikovat nekompatibility a pokusit se je vyřešit. Pokud skriptovaná úloha v novém prostředí nefunguje tak, jak má, doporučujeme vytvořit ekvivalentní úlohu, která v daném prostředí funguje správně.

Přihlášení

Přihlášení k instanci SQL Serveru vyžaduje platné přihlášení k SQL Serveru. Toto přihlášení se používá v procesu ověřování, který zjišťuje, jestli se objekt zabezpečení může připojit k instanci serveru SQL. Uživatel databáze, pro který není definováno odpovídající přihlášení k SQL Serveru nebo je nesprávně definován v instanci serveru, se nemůže přihlásit k instanci. Takový uživatel se označuje jako nepřiřazený uživatel databáze na této serverové instanci. Uživatel databáze se může stát osamocený, pokud po obnovení, připojení nebo zkopírování databáze do jiné instance SQL Serveru.

Chcete-li vygenerovat skript pro některé nebo všechny objekty v původní kopii databáze, můžete použít Průvodce generováním skriptů a v dialogovém okně Zvolit možnosti skriptu nastavit možnost Přihlášení skriptů možnost True.

Poznámka

Informace o nastavení přihlášení pro zrcadlenou databázi najdete v tématu Nastavení přihlašovacích účtů pro zrcadlení databáze nebo skupiny dostupnosti AlwaysOn (SQL Server) a Správa přihlášení a úloh po přepnutí role (SQL Server).

Dovolení

Při zpřístupnění databáze v jiné instanci serveru můžou být ovlivněny následující typy oprávnění.

  • Oprávnění UDĚLIT, ODVOLAT nebo ODEPŘÍT u systémových objektů

  • Oprávnění udělit, odvolat nebo odepřít pro instanci serveru (oprávnění na úrovni serveru)

Oprávnění udělit, odvolat a odepřít u systémových objektů

Oprávnění k systémovým objektům, jako jsou uložené procedury, rozšířené uložené procedury, funkce a zobrazení, jsou uložena v databázi master a musí být nakonfigurována v instanci cílového serveru.

Chcete-li vygenerovat skript pro některé nebo všechny objekty v původní kopii databáze, můžete použít Průvodce generováním skriptů a v dialogovém okně Zvolit možnosti skriptu nastavit možnost Skript Object-Level Oprávnění na True.

Důležitý

Pokud se přihlásíte pomocí skriptu, hesla nejsou skriptována. Pokud máte přihlášení, která používají ověřování SQL Serveru, musíte upravit skript v cíli.

Systémové objekty jsou viditelné v zobrazení katalogu sys.system_objects. Oprávnění k systémovým objektům jsou viditelná v zobrazení katalogu sys.database_permissions v databázi master. Informace o dotazování těchto zobrazení katalogu a udělení oprávnění objektu systému naleznete v tématu GRANT System Object Permissions (Transact-SQL). Další informace naleznete v tématu REVOKE System Object Permissions (Transact-SQL) a ODEPŘÍT oprávnění systémového objektu (Transact-SQL).

Udělení, odvolání a odepření oprávnění na instanci serveru

Oprávnění v oboru serveru jsou uložena v databázi master a musí být nakonfigurována v instanci cílového serveru. Pro informace o oprávněních instance serveru použijte dotaz na zobrazení katalogu sys.server_permissions, pro informace o objektech zabezpečení serveru použijte dotaz na zobrazení katalogu sys.server_principals a pro informace o členství v serverových rolích použijte dotaz na zobrazení katalogu sys.server_role_members.

Další informace naleznete v části GRANT Server Permissions (Transact-SQL), části REVOKE Server Permissions (Transact-SQL)a části DENY Server Permissions (Transact-SQL).

Server-Level oprávnění pro certifikát nebo asymetrický klíč

Oprávnění na úrovni serveru nelze udělit přímo certifikátu nebo asymetrickému klíči. Místo toho jsou oprávnění na úrovni serveru udělena mapovanému přihlášení vytvořenému výhradně pro konkrétní certifikát nebo asymetrický klíč. Proto každý certifikát nebo asymetrický klíč, který vyžaduje oprávnění na úrovni serveru, vyžaduje vlastní přihlašovací jméno mapované na certifikát nebo přihlašovací jméno mapované na asymetrický klíč. Pokud chcete udělit oprávnění na úrovni serveru pro certifikát nebo asymetrický klíč, udělte oprávnění k namapovanému přihlášení.

Poznámka

Mapované přihlášení se používá pouze k autorizaci kódu podepsaného odpovídajícím certifikátem nebo asymetrickým klíčem. Mapovaná přihlášení nelze použít k ověřování.

Namapované přihlášení a jeho oprávnění se nacházejí v master. Pokud se certifikát nebo asymetrický klíč nachází v jiné databázi než master, musíte ho znovu vytvořit v master a namapovat ho na přihlášení. Pokud přesunete, zkopírujete nebo obnovíte databázi do jiné instance serveru, musíte znovu vytvořit certifikát nebo asymetrický klíč v databázi master cílové instance serveru, namapovat na přihlášení a udělit požadovaná oprávnění na úrovni serveru pro přihlášení.

Vytvoření certifikátu nebo asymetrického klíče

Mapování certifikátu nebo asymetrického klíče na přihlašovací účet

Přiřazení oprávnění k mapovanému přihlašovacímu

Další informace o certifikátech a asymetrických klíčích najdete v tématu hierarchii šifrování.

Důvěryhodný majetek

Vlastnost databáze TRUSTWORTHY slouží k označení, zda tato instance SQL Serveru důvěřuje databázi a obsahu v ní. Pokud je databáze připojena, ve výchozím nastavení a pro zabezpečení je tato možnost nastavena na vypnuto, i když byla tato možnost nastavena na zapnuto na původním serveru. Další informace o této vlastnosti naleznete v tématu vlastnost databáze TRUSTWORTHY, a jak tuto možnost zapnout, naleznete v tématu ALTER DATABASE (Transact-SQL).

Nastavení replikace

Pokud obnovíte zálohu replikované databáze na jiný server nebo databázi, nastavení replikace se nedá zachovat. V takovém případě je nutné po obnovení záloh znovu vytvořit všechny publikace a předplatná. Pro usnadnění tohoto procesu vytvořte skripty pro aktuální nastavení replikace a také pro povolení a zakázání replikace. Abyste mohli znovu vytvořit nastavení replikace, zkopírujte tyto skripty a změňte odkazy na názvy serverů tak, aby fungovaly pro cílovou instanci serveru.

Další informace naleznete v tématu Zálohování a obnovení replikovaných databází, Zrcadlení a replikace databáze (SQL Server)a Přenášení protokolu a replikace (SQL Server).

Aplikace Service Broker

Mnoho aspektů aplikace Service Broker se přesouvá s databází. Některé aspekty aplikace však musí být znovu vytvořeny nebo znovu nakonfigurovány v novém umístění. Pokud je databáze připojená z jiného serveru, ve výchozím nastavení a pro zabezpečení jsou možnosti pro is_broker_enabled a is_honoor_broker_priority_on vypnuté. Informace o tom, jak aktivovat tyto možnosti, viz ALTER DATABASE (Transact-SQL).

Procedury po spuštění

Spouštěcí procedura je uložená procedura, která je označena k automatickému spuštění a spouští se při každém spuštění SQL Serveru. Pokud databáze závisí na jakýchkoli spouštěcích postupech, musí být definovány v instanci cílového serveru a musí být nakonfigurovány tak, aby se spouštěly automaticky při spuštění.

Spouštěče (na úrovni serveru)

DDL aktivuje uložené procedury v reakci na několik událostí DDL (Data Definition Language). Tyto události primárně odpovídají příkazům Transact-SQL, které začínají klíčovými slovy CREATE, ALTER a DROP. Některé systémové uložené procedury, které provádějí operace podobné DDL, mohou také aktivovat triggery DDL.

Další informace o této funkci najdete v tématu DDL triggery.

Viz také

izolované databáze
kopírování databází na jiné servery
Odpojení a připojení databáze (SQL Server)
Přepnutí při selhání na sekundární server s přenosem protokolu (SQL Server)
přepínání rolí během relace zrcadlení databáze (SQL Server)
Nastavení šifrované zrcadlové databáze
SQL Server Configuration Manager
řešení potíží s osamocenými uživateli (SQL Server)
Migrace na novou instalaci– přehled migrace: SQL Server na SQL Server na virtuálních počítačích Azure