Delen via

Metagegevens beheren bij het beschikbaar maken van een database op een andere server

Van toepassing op:SQL Server

Dit artikel is relevant in de volgende situaties:

  • De beschikbaarheidsreplica's van een AlwaysOn-beschikbaarheidsgroep configureren.

  • Databasespiegeling instellen voor een database.

  • Bij het voorbereiden van het wijzigen van rollen tussen primaire en secundaire servers in een configuratie voor logboekverzending.

  • Een database herstellen naar een andere serverinstantie.

  • Een kopie van een database aan een ander serverexemplaar koppelen.

  • Het uitvoeren van een upgrade van de database-engine met behulp van de methode: migreren naar een nieuwe installatie.

  • Databases migreren naar Azure SQL (virtuele machine of beheerd exemplaar).

Sommige toepassingen zijn afhankelijk van informatie, entiteiten en/of objecten die buiten het bereik van één gebruikersdatabase vallen. Een toepassing heeft doorgaans afhankelijkheden van de master- en msdb-databases, en ook van de gebruikersdatabase. Alles wat buiten een gebruikersdatabase is opgeslagen dat vereist is voor de juiste werking van die database, moet beschikbaar worden gesteld op het doelserverexemplaar. De aanmeldingen voor een toepassing worden bijvoorbeeld opgeslagen als metagegevens in de master-database en moeten opnieuw worden gemaakt op de doelserver. Als een onderhoudsplan voor toepassingen of databases afhankelijk is van SQL Server Agent-taken waarvan de metagegevens zijn opgeslagen in de msdb-database, moet u deze taken opnieuw maken op het doelserverexemplaren. Op dezelfde manier worden de metagegevens voor een trigger op serverniveau opgeslagen in master.

Wanneer u de database voor een toepassing naar een ander serverexemplaren verplaatst, moet u alle metagegevens van de afhankelijke entiteiten en objecten in master en msdb opnieuw maken op het doelserverexemplaren. Als een databasetoepassing bijvoorbeeld triggers op serverniveau gebruikt, is alleen het koppelen of herstellen van de database op het nieuwe systeem niet genoeg. De database werkt niet zoals verwacht, tenzij u de metagegevens voor deze triggers handmatig opnieuw maakt in de master database.

Informatie, entiteiten en objecten die buiten gebruikersdatabases worden opgeslagen

In de rest van dit artikel vindt u een overzicht van de mogelijke problemen die van invloed kunnen zijn op een database die beschikbaar wordt gesteld op een ander serverexemplaren. Mogelijk moet u een of meer van de typen gegevens, entiteiten of objecten die in de volgende lijst worden vermeld, opnieuw maken. Als u een samenvatting wilt zien, selecteert u de koppeling voor het item.

Serverconfiguratie-instellingen

SQL Server 2005 (9.x) en latere versies installeren en starten selectief belangrijke services en functies. Dit helpt het aan te vallen oppervlak van een systeem te verminderen. In de standaardconfiguratie van nieuwe installaties zijn veel functies niet ingeschakeld. Als de database afhankelijk is van een service of functie die standaard is uitgeschakeld, moet deze service of functie zijn ingeschakeld op het doelserverexemplaren.

Zie Serverconfiguratieopties (SQL Server) voor meer informatie over deze instellingen en het in- of uitschakelen ervan.

Credentials

Een referentie is een record die de verificatiegegevens bevat die nodig zijn om verbinding te maken met een resource buiten SQL Server. De meeste verificatiegegevens bestaan uit een Windows-aanmelding en -wachtwoord.

Zie Referenties (Database Engine) voor meer informatie over deze functie.

Opmerking

SQL Server Agent Proxy-accounts gebruiken referenties. Gebruik de systeemtabel sysproxies om de referentie-id van een proxyaccount te leren.

Query's tussen databases

De DB_CHAINING- en TRUSTWORTHY-databaseopties zijn standaard uitgeschakeld. Als een van beide is ingesteld op AAN voor de oorspronkelijke database, moet u deze mogelijk inschakelen voor de database op het doelserverexemplaar. Zie ALTER DATABASE (Transact-SQL)voor meer informatie.

Bijvoegings- en loskoppelbewerkingen schakelen het koppelen van eigendom tussen databases voor de database uit. Zie voor meer informatie over het inschakelen van cross db ownership chaining, Server Configuration Option.

Zie ook Een gespiegelde database instellen voor het gebruik van de betrouwbare eigenschap (Transact-SQL) voor meer informatie

Eigendom van de database

Wanneer een database op een andere computer wordt hersteld, wordt de SQL Server-aanmelding of Windows-gebruiker die de herstelbewerking heeft gestart automatisch de eigenaar van de nieuwe database. Wanneer de database is hersteld, kan de systeembeheerder of de nieuwe database-eigenaar het eigendom van de database wijzigen.

Gedistribueerde query's en gekoppelde servers

Gedistribueerde query's en gekoppelde servers worden ondersteund voor OLE DB-toepassingen. Gedistribueerde query's hebben toegang tot gegevens uit meerdere heterogene gegevensbronnen op dezelfde of verschillende computers. Met een gekoppelde serverconfiguratie kan SQL Server opdrachten uitvoeren op OLE DB-gegevensbronnen op externe servers. Zie Gekoppelde servers (Database Engine) voor meer informatie over deze functies.

Versleutelde gegevens

Als de database die u beschikbaar maakt op een ander serverexemplaren versleutelde gegevens bevat en als de hoofdsleutel van de database wordt beveiligd door de hoofdsleutel van de service op de oorspronkelijke server, is het mogelijk nodig om de hoofdsleutelversleuteling van de service opnieuw te maken. De hoofdsleutel van de database is een symmetrische sleutel die wordt gebruikt om de persoonlijke sleutels van certificaten en asymmetrische sleutels in een versleutelde database te beveiligen. Wanneer de databasehoofdsleutel is gemaakt, wordt deze versleuteld met behulp van het Triple DES-algoritme en een door de gebruiker opgegeven wachtwoord.

Als u de automatische ontsleuteling van de databasehoofdsleutel op een serverexemplaar wilt inschakelen, wordt een kopie van deze sleutel versleuteld met behulp van de hoofdsleutel van de service. Deze versleutelde kopie wordt opgeslagen in zowel de database als in master. Normaal gesproken wordt de kopie die is master opgeslagen, op de achtergrond bijgewerkt wanneer de hoofdsleutel wordt gewijzigd. SQL Server probeert eerst de hoofdsleutel van de database te ontsleutelen met de servicehoofdsleutel van het exemplaar. Als deze ontsleuteling mislukt, zoekt SQL Server in het referentiearchief naar hoofdsleutelreferenties met dezelfde familie-GUID als de database waarvoor de hoofdsleutel is vereist. SQL Server probeert vervolgens de hoofdsleutel van de database met elke overeenkomende referentie te ontsleutelen totdat de ontsleuteling slaagt of er zijn geen referenties meer. Een hoofdsleutel die niet door de service hoofdsleutel is versleuteld, moet worden geopend met de instructie OPEN MASTER KEY en een wachtwoord.

Wanneer een versleutelde database wordt gekopieerd, hersteld of gekoppeld aan een nieuw exemplaar van SQL Server, wordt een kopie van de hoofdsleutel van de database die is versleuteld door de hoofdsleutel van de service niet opgeslagen in master het doelserverexemplaar. Op het doelserverexemplaar moet u de mastersleutel van de database openen. Als u de master key wilt openen, voert u de volgende commando uit: OPEN MASTER KEY DECRYPTION BY PASSWORD ='wachtwoord'. U wordt aangeraden vervolgens automatische ontsleuteling van de hoofdsleutel van de database in te schakelen door de volgende instructie uit te voeren: ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY. Met deze instructie ALTER MASTER KEY wordt het serverexemplaar voorzien van een kopie van de databasehoofdsleutel die is versleuteld met de hoofdsleutel van de service. Zie OPEN MASTER KEY (Transact-SQL) en ALTER MASTER KEY (Transact-SQL)voor meer informatie.

Zie Een versleutelde gespiegelde database instellen voor informatie over het inschakelen van automatische ontsleuteling van de hoofdsleutel van de database van een gespiegelde database.

Zie ook voor meer informatie:

Door de gebruiker gedefinieerde foutberichten

Door de gebruiker gedefinieerde foutberichten bevinden zich in de catalogusweergave sys.messages . Deze catalogusweergave wordt opgeslagen in master. Als een databasetoepassing afhankelijk is van door de gebruiker gedefinieerde foutberichten en de database beschikbaar wordt gesteld op een ander serverexemplaren, gebruikt u sp_addmessage om deze door de gebruiker gedefinieerde berichten toe te voegen aan het doelserverexemplaren.

Gebeurtenismeldingen en WMI-gebeurtenissen (Windows Management Instrumentation) (op serverniveau)

Serverniveau gebeurtenismeldingen

Gebeurtenismeldingen op serverniveau worden opgeslagen in msdb. Als een databasetoepassing afhankelijk is van een gebeurtenismelding op serverniveau, moet die gebeurtenismelding daarom opnieuw worden gemaakt op het doelserverexemplaren. Om de gebeurtenismeldingen op een serverexemplaar weer te geven, gebruikt u de sys.server_event_notifications catalogusweergave. Zie Gebeurtenismeldingen voor meer informatie.

Daarnaast worden gebeurtenismeldingen geleverd met behulp van Service Broker. Routes voor binnenkomende berichten worden niet opgenomen in de database die een service bevat. In plaats daarvan worden expliciete routes opgeslagen in msdb. Als uw service een expliciete route in de msdb database gebruikt om binnenkomende berichten naar de service te routeren wanneer u een database in een ander exemplaar koppelt, moet u deze route opnieuw maken.

WMI-gebeurtenissen (Windows Management Instrumentation)

Met de WMI-provider voor server gebeurtenissen kunt u WMI (Windows Management Instrumentation) gebruiken om gebeurtenissen in SQL Server te bewaken. Elke toepassing die afhankelijk is van gebeurtenissen op serverniveau die worden weergegeven via de WMI-provider waarop een database is gebaseerd, moet op de computer van het doelserverexemplaar worden gespecificeerd. WMI Event Provider maakt gebeurtenismeldingen met een doelservice die is gedefinieerd in msdb.

Opmerking

Zie WMI-provider voor concepten van serverevenementen voor meer informatie.

Een WMI-waarschuwing maken met BEHULP van SQL Server Management Studio

Hoe gebeurtenismeldingen werken voor een gespiegelde database

De bezorging tussen databases van gebeurtenismeldingen waarbij een gespiegelde database is betrokken, is per definitie extern, omdat de gespiegelde database een failover kan uitvoeren. Service Broker biedt speciale ondersteuning voor gespiegelde databases, in de vorm van gespiegelde routes. Een gespiegelde route heeft twee adressen: één voor het principal-serverexemplaar en één voor het mirror-serverexemplaar.

Door gespiegelde routes in te stellen, maakt u Service Broker-routering bewust van databasespiegeling. Met gespiegelde routes kan Service Broker gesprekken transparant omleiden naar de huidige principeel serverinstantie. Denk bijvoorbeeld aan een service, Service_A, die wordt gehost door een gespiegelde database, Database_A. Stel dat u een andere service nodig hebt, Service_B, die wordt gehost door Database_B, om een dialoogvenster met Service_A te hebben. Om dit dialoogvenster mogelijk te maken, moet Database_B een gespiegelde route voor Service_A bevatten. Bovendien moet Database_A een niet-gemirrored TCP-transportroute bevatten naar Service_B, die, in tegenstelling tot een lokale route, geldig blijft na een failover. Met deze routes kunnen ACK's na een failover terugkomen. Omdat de service van de afzender altijd op dezelfde manier wordt genoemd, moet de route de broker instantie opgeven.

De vereiste voor gespiegelde routes is van toepassing, ongeacht of de service in de gespiegelde database de initiatorservice of de doelservice is:

  • Als de doelservice zich in de gespiegelde database bevindt, moet de initiatorservice een gespiegelde route terug naar het doel hebben. Het doel kan echter een reguliere route terug naar initiator hebben.

  • Als de initiatorservice zich in de gespiegelde database bevindt, moet de doelservice een gespiegelde route terug hebben naar de initiator om bevestigingen en antwoorden te leveren. De initiator kan echter een reguliere route naar het doel hebben.

Uitgebreide opgeslagen procedures

Belangrijk

Deze functie wordt verwijderd in een toekomstige versie van SQL Server. Vermijd het gebruik van deze functie in nieuwe ontwikkelwerkzaamheden en plan om toepassingen te wijzigen die momenteel gebruikmaken van deze functie. Gebruik in plaats daarvan CLR-integratie .

Uitgebreide opgeslagen procedures worden geprogrammeerd met behulp van de API voor uitgebreide opgeslagen procedures van SQL Server. Een lid van de vaste serverfunctie sysadmin kan een uitgebreide opgeslagen procedure registreren bij een exemplaar van SQL Server en gebruikers toestemming geven om de procedure uit te voeren. Uitgebreide opgeslagen procedures kunnen alleen worden toegevoegd aan de master database.

Uitgebreide opgeslagen procedures worden rechtstreeks uitgevoerd in de adresruimte van een exemplaar van SQL Server en ze kunnen geheugenlekken of andere problemen veroorzaken die de prestaties en betrouwbaarheid van de server verminderen. U moet overwegen uitgebreide opgeslagen procedures op te slaan in een exemplaar van SQL Server dat gescheiden is van het exemplaar dat de gegevens bevat waarnaar wordt verwezen. U moet ook overwegen om gedistribueerde query's te gebruiken voor toegang tot de database.

Belangrijk

Voordat u uitgebreide opgeslagen procedures toevoegt aan de server en EXECUTE-machtigingen verleent aan andere gebruikers, moet de systeembeheerder elke uitgebreide opgeslagen procedure grondig controleren om ervoor te zorgen dat deze geen schadelijke of schadelijke code bevat.

Zie voor meer informatie Objectmachtigingen verlenen (Transact-SQL), Objectmachtigingen weigeren (Transact-SQL) en Objectmachtigingen intrekken (Transact-SQL).

Full-Text Engine voor SQL Server-eigenschappen

Eigenschappen worden ingesteld op de Full-Text Engine door sp_fulltext_service. Zorg ervoor dat het doelserverexemplaar de vereiste instellingen voor deze eigenschappen heeft. Zie FULLTEXTSERVICEPROPERTY (Transact-SQL) voor meer informatie over deze eigenschappen.

Als de componenten woordonderbrekers en stemmers of zoekfilters voor volledige tekst verschillende versies hebben op de oorspronkelijke en doelserverinstantie, kunnen indexen en query's voor volledige tekst anders werken. De synoniemenlijst wordt ook opgeslagen in exemplaarspecifieke bestanden. U moet een kopie van deze bestanden overdragen naar een equivalente locatie op het doelserverexemplaar of deze opnieuw maken op een nieuw exemplaar.

Opmerking

Wanneer u een SQL Server 2005-database (9.x) koppelt die volledige-tekstcatalogusbestanden bevat aan een SQL Server-serverexemplaren, worden de catalogusbestanden gekoppeld vanaf hun vorige locatie, samen met de andere databasebestanden, hetzelfde als in SQL Server 2005 (9.x). Voor meer informatie, zie Upgrade Full-Text Search.

Zie ook voor meer informatie:

Jobs

Als de database afhankelijk is van SQL Server Agent-taken, moet u deze opnieuw maken op het doelserverexemplaar. Taken zijn afhankelijk van hun omgevingen. Als u van plan bent om een bestaande taak opnieuw te maken op het doelserverexemplaar, moet het doelserverexemplaar mogelijk worden aangepast aan de omgeving van die taak op het oorspronkelijke serverexemplaar. De volgende omgevingsfactoren zijn belangrijk:

  • De inloggegevens die door de taak worden gebruikt

    Als u SQL Server Agent-taken wilt maken of uitvoeren, moet u eerst de voor de taak vereiste SQL Server-aanmeldingen toevoegen aan het doelserverexemplaar. Zie Een gebruiker configureren voor het maken en beheren van SQL Server Agent-taken voor meer informatie.

  • Opstartaccount voor sql Server Agent-service

    Het opstartaccount van de service definieert het Microsoft Windows-account waarin SQL Server Agent wordt uitgevoerd en de bijbehorende netwerkmachtigingen. SQL Server Agent wordt uitgevoerd als een opgegeven gebruikersaccount. De context van de agentservice is van invloed op de instellingen voor de taak en de uitvoeringsomgeving. Het account moet toegang hebben tot de resources, zoals netwerkshares, die vereist zijn voor de taak. Zie Een account selecteren voor de SQL Server Agent-service voor informatie over het selecteren en wijzigen van het opstartaccount van de service.

    Om correct te functioneren, moet het serviceaccount zodanig zijn geconfigureerd dat het de juiste machtigingen voor domein, bestandssysteem en register heeft. Voor een taak is mogelijk ook een gedeelde netwerkresource vereist die moet worden geconfigureerd voor het serviceaccount. Zie Windows-serviceaccounts en -machtigingen configureren voor meer informatie.

  • SQL Server Agent-service, die is gekoppeld aan een specifiek exemplaar van SQL Server, heeft een eigen register hive en de bijbehorende taken hebben doorgaans afhankelijkheden van een of meer van de instellingen in deze register hive. Als u zich wilt gedragen zoals bedoeld, vereist een taak die registerinstellingen. Als u een script gebruikt om een taak opnieuw te maken in een andere SQL Server Agent-service, beschikt het register mogelijk niet over de juiste instellingen voor die taak. Voor opnieuw gemaakte taken om correct te functioneren op een doelserverexemplaar, moeten de oorspronkelijke en doel-SQL Server Agent-services dezelfde registerinstellingen hebben.

    Waarschuwing

    Het wijzigen van registerinstellingen in de sql Server Agent-doelservice voor het afhandelen van een opnieuw gemaakte taak kan problematisch zijn als de huidige instellingen vereist zijn voor andere taken. Bovendien kan het onjuist bewerken van het register uw systeem ernstig beschadigen. Voordat u wijzigingen aanbrengt in het register, raden we u aan een back-up te maken van waardegegevens op de computer.

  • SQL Server Agent-proxies

    Een SQL Server Agent-proxy definieert de beveiligingscontext voor een opgegeven taakstap. Voor een taak die moet draaien op het doelserverexemplaar, moeten alle proxy's die nodig zijn, handmatig opnieuw worden gemaakt op dat exemplaar. Zie Een SQL Server Agent-proxy maken en problemen met multiservertaken oplossen die proxy's gebruiken voor meer informatie.

Zie ook voor meer informatie:

Bestaande taken en hun eigenschappen weergeven

Een taak maken

Aanbevolen procedures voor het gebruik van een script om een taak opnieuw te maken

Het is raadzaam om te beginnen met het uitvoeren van een script voor een eenvoudige taak, het opnieuw maken van de taak in de andere SQL Server Agent-service en het uitvoeren van de taak om te zien of deze werkt zoals bedoeld. Hiermee kunt u incompatibiliteit identificeren en deze proberen op te lossen. Als een scripttaak niet werkt zoals bedoeld in de nieuwe omgeving, raden we u aan een gelijkwaardige taak te maken die correct werkt in die omgeving.

Aanmeldingen

Voor het aanmelden bij een exemplaar van SQL Server is een geldige SQL Server-aanmelding vereist. Deze aanmelding wordt gebruikt in het verificatieproces waarmee wordt gecontroleerd of de principal verbinding kan maken met het exemplaar van SQL Server. Een databasegebruiker waarvoor de bijbehorende SQL Server-aanmelding niet is gedefinieerd of onjuist is gedefinieerd op een serverexemplaren, kan zich niet aanmelden bij het exemplaar. Een dergelijke gebruiker wordt geacht een zwevende gebruiker van de database op dat serverexemplaren te zijn. Een databasegebruiker kan wees worden als blijkt dat nadat een database is hersteld, gekoppeld of gekopieerd naar een ander exemplaar van SQL Server.

Als u een script wilt genereren voor sommige of alle objecten in de oorspronkelijke kopie van de database, kunt u de wizard Scripts genereren gebruiken en in het dialoogvenster Scriptopties kiezen de optie Scriptaanmelding instellen op Waar.

Opmerking

Zie Aanmeldingsaccounts instellen voor databasespiegeling of AlwaysOn-beschikbaarheidsgroepen (SQL Server) en beheer van aanmeldingen en taken na functiewisseling (SQL Server) voor meer informatie over het instellen van aanmeldingen voor een gespiegelde database.

Permissions

De volgende typen machtigingen kunnen worden beïnvloed wanneer een database beschikbaar wordt gesteld op een ander serverexemplaren.

  • Machtigingen verlenen, intrekken of weigeren voor systeemobjecten

  • Machtigingen verlenen, intrekken of weigeren op serverexemplaren (machtigingen op serverniveau)

Machtigingen verlenen, intrekken en weigeren voor systeemobjecten

Machtigingen voor systeemobjecten, zoals opgeslagen procedures, uitgebreide opgeslagen procedures, functies en weergaven, worden opgeslagen in de master database en moeten worden geconfigureerd op het doelserverexemplaren.

Als u een script wilt genereren voor sommige of alle objecten in de originele database, kunt u de wizard 'Scripts genereren' gebruiken en in het dialoogvenster Scriptopties de optie Script Object-Level Machtigingen op True instellen.

Belangrijk

Als u aanmeldingen met scripts uitvoert, worden de wachtwoorden niet gescript. Als u aanmeldingen hebt die gebruikmaken van SQL Server-verificatie, moet u het script op de bestemming wijzigen.

Systeemobjecten zijn zichtbaar in de catalogusweergave sys.system_objects . De machtigingen voor systeemobjecten zijn zichtbaar in de sys.database_permissions catalogusweergave in de master database. Zie GRANT System Object Permissions (Transact-SQL) voor meer informatie over het uitvoeren van query's op deze catalogusweergaven en het verlenen van machtigingen voor systeemobjecten. Zie MACHTIGINGEN voor systeemobjecten intrekken (Transact-SQL) en MACHTIGINGEN voor systeemobjecten weigeren (Transact-SQL) voor meer informatie.

Rechten verlenen, intrekken en weigeren op een serverexemplaar

Machtigingen op de serverscope worden opgeslagen in de master database en moeten worden geconfigureerd op de doelserverinstantie. Voor informatie over de servermachtigingen van een serverexemplaar voert u een query uit op de sys.server_permissions catalogusweergave, voor informatie over server-principals voert u een query uit op de sys.server_principals catalogusweergave en voor informatie over het lidmaatschap van serverfuncties voert u een query uit op de sys.server_role_members catalogusweergave.

Voor meer informatie, zie Servermachtigingen verlenen (Transact-SQL), Servermachtigingen intrekken (Transact-SQL) en Servermachtigingen weigeren (Transact-SQL).

Server-Level machtigingen voor een certificaat of asymmetrische sleutel

Machtigingen op serverniveau kunnen niet rechtstreeks worden verleend aan een certificaat of asymmetrische sleutel. In plaats daarvan worden machtigingen op serverniveau verleend aan een toegewezen aanmelding die uitsluitend wordt gemaakt voor een specifiek certificaat of asymmetrische sleutel. Daarom vereist elk certificaat of asymmetrische sleutel waarvoor machtigingen op serverniveau zijn vereist, een eigen aanmelding met een certificaattoewijzing of asymmetrische sleuteltoewijzing. Als u machtigingen op serverniveau wilt verlenen voor een certificaat of asymmetrische sleutel, verleent u de machtigingen aan de bijbehorende login.

Opmerking

Een toegewezen aanmelding wordt alleen gebruikt voor de autorisatie van code die is ondertekend met het bijbehorende certificaat of asymmetrische sleutel. Gemapte aanmeldingen kunnen niet worden gebruikt voor authenticatie.

De toegewezen aanmelding en de bijbehorende machtigingen bevinden zich beide in master. Als een certificaat of asymmetrische sleutel zich in een andere database bevindt dan master, moet u deze opnieuw maken in master en aan een aanmelding koppelen. Als u de database naar een ander serverexemplaar verplaatst, kopieert of herstelt, moet u het certificaat of de asymmetrische sleutel opnieuw maken in de master database van het doelserverexemplaar, deze aan een aanmelding koppelen en de vereiste machtigingen op serverniveau aan de aanmelding verlenen.

Om een certificaat of asymmetrische sleutel te maken

Een certificaat of asymmetrische sleutel toewijzen aan een aanmelding

Machtigingen toewijzen aan de gekoppelde login

Zie Versleutelingshiërarchie voor meer informatie over certificaten en asymmetrische sleutels.

Betrouwbare eigenschap

De eigenschap TRUSTWORTHY-database wordt gebruikt om aan te geven of deze instantie van SQL Server de database en de inhoud erin vertrouwt. Wanneer een database standaard en voor beveiliging is gekoppeld, is deze optie ingesteld op UIT, zelfs als deze optie is ingesteld op AAN op de oorspronkelijke server. Zie TRUSTWORTHY-eigenschap van de database voor meer informatie over deze eigenschap en voor informatie over het inschakelen van deze optie, zie ALTER DATABASE (Transact-SQL).

Replicatie-instellingen

Als u een back-up van een gerepliceerde database herstelt naar een andere server of database, kunnen replicatie-instellingen niet worden bewaard. In dit geval moet u alle publicaties en abonnementen opnieuw maken nadat de back-ups zijn hersteld. Om dit proces eenvoudiger te maken, maakt u scripts voor uw huidige replicatie-instellingen en voor het in- en uitschakelen van replicatie. Als u uw replicatie-instellingen opnieuw wilt maken, kopieert u deze scripts en wijzigt u de servernaamverwijzingen zodat deze werken voor het doelserverexemplaar.

Zie Back-ups maken en herstellen van gerepliceerde databases, databasespiegeling en replicatie (SQL Server) en logboekverzending en replicatie (SQL Server) voor meer informatie.

Service Broker-toepassingen

Veel aspecten van een Service Broker-toepassing verhuizen samen met de database. Sommige aspecten van de toepassing moeten echter opnieuw worden gemaakt of opnieuw worden geconfigureerd op de nieuwe locatie. Wanneer een database is gekoppeld vanaf een andere server, worden de opties voor is_broker_enabled en is_honoor_broker_priority_on standaard ingesteld op UIT. Zie ALTER DATABASE (Transact-SQL) voor informatie over het instellen van deze opties AAN.

Opstartprocedures

Een opstartprocedure is een opgeslagen procedure die is gemarkeerd voor automatische uitvoering en wordt uitgevoerd telkens wanneer SQL Server wordt gestart. Als de database afhankelijk is van opstartprocedures, moeten deze worden gedefinieerd op het doelserverexemplaren en worden geconfigureerd om automatisch bij het opstarten uit te voeren.

Triggers (op serverniveau)

DDL activeert opgeslagen procedures als reactie op verschillende DDL-gebeurtenissen (Data Definition Language). Deze gebeurtenissen komen voornamelijk overeen met Transact-SQL instructies die beginnen met de trefwoorden CREATE, ALTER en DROP. Bepaalde door het systeem opgeslagen procedures die DDL-achtige bewerkingen uitvoeren, kunnen ook DDL-triggers activeren.

Zie DDL-triggers voor meer informatie over deze functie.

Zie ook

ingesloten databases
Databases kopiëren naar andere servers
Database los- en aankoppelen in SQL Server
Failover naar een secundaire server voor logboekverzending (SQL Server)
Rolwisseling tijdens een databasespiegelingssessie (SQL Server)
Een versleutelde mirror-database configureren
SQL Server Configuration Manager
Problemen met weesgebruikers oplossen (SQL Server)
Migreren naar een nieuwe installatieMigratieoverzicht: SQL Server naar SQL Server op Azure-VM's

  • Last updated on