Dela via

Hantera metadata när du gör en databas tillgänglig på en annan server

Gäller för:SQL Server

Den här artikeln är relevant i följande situationer:

  • Konfigurera tillgänglighetsreplikerna för en Always On-tillgänglighetsgrupp.

  • Konfigurera databasspegling för en databas.

  • När du förbereder att ändra rollerna mellan huvudserver och sekundär server i en loggöverföringskonfiguration.

  • Återställa en databas till en annan serverinstans.

  • Bifoga en kopia av en databas på en annan serverinstans.

  • Utför uppgradering av databasmotorn med hjälp av metoden – migrera till en ny installation.

  • Migrera databaser till Azure SQL (virtuell dator eller hanterad instans).

Vissa program är beroende av information, entiteter och/eller objekt som ligger utanför omfånget för en enskild användardatabas. Vanligtvis har ett program beroenden av master och msdb databaser, och även på användardatabasen. Allt som lagras utanför en användardatabas som krävs för att databasen ska fungera korrekt måste göras tillgängligt på målserverinstansen. Till exempel lagras inloggningarna för ett program som metadata i master-databasen och de måste återskapas på målservern. Om en program- eller databasunderhållsplan är beroende av SQL Server Agent-jobb, vars metadata lagras i msdb-databasen, måste du återskapa jobben på målserverinstansen. På samma sätt lagras metadata för en utlösare på servernivå i master.

När du flyttar databasen för ett program till en annan serverinstans måste du återskapa alla metadata för de beroende entiteterna och objekten i master och msdb på målserverinstansen. Om ett databasprogram till exempel använder utlösare på servernivå räcker det inte att bara koppla eller återställa databasen i det nya systemet. Databasen fungerar inte som förväntat om du inte manuellt återskapar metadata för dessa utlösare i master databasen.

Information, entiteter och objekt som lagras utanför användardatabaser

Resten av den här artikeln sammanfattar de potentiella problem som kan påverka en databas som görs tillgänglig på en annan serverinstans. Du kan behöva återskapa en eller flera av de typer av information, entiteter eller objekt som anges i följande lista. Om du vill se en sammanfattning väljer du länken för objektet.

Inställningar för serverkonfiguration

SQL Server 2005 (9.x) och senare versioner installerar selektivt och startar viktiga tjänster och funktioner. Detta hjälper till att minska den attackerbara ytan i ett system. I standardkonfigurationen för nya installationer är många funktioner inte aktiverade. Om databasen förlitar sig på någon tjänst eller funktion som är avstängd som standard måste den här tjänsten eller funktionen vara aktiverad på målserverinstansen.

Mer information om de här inställningarna och hur du aktiverar eller inaktiverar dem finns i Serverkonfigurationsalternativ (SQL Server).

Credentials

En autentiseringsuppgift är en post som innehåller den autentiseringsinformation som krävs för att ansluta till en resurs utanför SQL Server. De flesta autentiseringsuppgifterna består av en Windows-inloggning och ett lösenord.

Mer information om den här funktionen finns i Autentiseringsuppgifter (databasmotor).

Anmärkning

SQL Server Agent Proxy-konton använder autentiseringsuppgifter. Om du vill lära dig autentiserings-ID för ett proxykonto använder du systemtabellen sysproxies .

Frågor mellan databaser

Databasalternativen DB_CHAINING och TRUSTWORTHY är AV som standard. Om någon av dessa anges till PÅ för den ursprungliga databasen kan du behöva aktivera dem på databasen på målserverinstansen. Mer information finns i ALTER DATABASE (Transact-SQL).

Åtgärderna "koppla och koppla bort" inaktiverar "cross-database ownership chaining" för databasen. Information om hur du aktiverar länkning finns i alternativet serverkonfiguration för korsdatabasägarlänkning.

Mer information finns i Konfigurera en speglingsdatabas för att använda egenskapen Trustworthy (Transact-SQL)

Databasägarskap

När en databas återställs på en annan dator blir SQL Server-inloggningen eller Windows-användaren som initierade återställningsåtgärden ägare till den nya databasen automatiskt. När databasen har återställts kan systemadministratören eller den nya databasägaren ändra databasägarskapet.

Distribuerade frågor och länkade servrar

Distribuerade frågor och länkade servrar stöds för OLE DB-program. Distribuerade frågor får åtkomst till data från flera heterogena datakällor på samma eller olika datorer. Med en länkad serverkonfiguration kan SQL Server köra kommandon mot OLE DB-datakällor på fjärrservrar. Mer information om dessa funktioner finns i Länkade servrar (databasmotor).

Krypterade data

Om databasen som du gör tillgänglig på en annan serverinstans innehåller krypterade data och om databashuvudnyckeln skyddas av tjänstens huvudnyckel på den ursprungliga servern kan det vara nödvändigt att återskapa krypteringen av tjänstens huvudnyckel. Huvudnyckeln för databasen är en symmetrisk nyckel som används för att skydda de privata nycklarna för certifikat och asymmetriska nycklar i en krypterad databas. När den skapas krypteras databashuvudnyckeln med hjälp av Triple DES-algoritmen och ett lösenord som tillhandahålls av användaren.

Om du vill aktivera automatisk dekryptering av databashuvudnyckeln på en serverinstans krypteras en kopia av den här nyckeln med hjälp av tjänstens huvudnyckel. Den här krypterade kopian lagras i både databasen och i master. Normalt uppdateras kopian som lagras i master tyst när huvudnyckeln ändras. SQL Server försöker först dekryptera databashuvudnyckeln med tjänsthuvudnyckeln för instansen. Om dekrypteringen misslyckas söker SQL Server i autentiseringsarkivet efter autentiseringsuppgifter för huvudnyckeln som har samma familje-GUID som databasen som den kräver huvudnyckeln för. SQL Server försöker sedan dekryptera databashuvudnyckeln med varje matchande autentiseringsuppgift tills dekrypteringen lyckas eller så finns det inga fler autentiseringsuppgifter. En huvudnyckel som inte krypteras av tjänstens huvudnyckel måste öppnas med ÖPPNA HUVUDNYCKEL och ett lösenord.

När en krypterad databas kopieras, återställs eller kopplas till en ny instans av SQL Server lagras inte en kopia av databashuvudnyckeln som krypteras av tjänsthuvudnyckeln på master målserverinstansen. På målserverinstansen måste du öppna huvudnyckeln för databasen. Öppna huvudnyckeln genom att köra följande kommando: OPEN MASTER KEY DECRYPTION BY PASSWORD ='password'. Vi rekommenderar att du sedan aktiverar automatisk dekryptering av databashuvudnyckeln genom att köra följande instruktion: ÄNDRA HUVUDNYCKEL LÄGG TILL KRYPTERING EFTER TJÄNSTHUVUDNYCKEL. Den här ALTER MASTER KEY-instruktionen etablerar serverinstansen med en kopia av databashuvudnyckeln som är krypterad med tjänstens huvudnyckel. Mer information finns i OPEN MASTER KEY (Transact-SQL) och ALTER MASTER KEY (Transact-SQL).

Information om hur du aktiverar automatisk dekryptering av databashuvudnyckeln för en speglingsdatabas finns i Konfigurera en krypterad speglingsdatabas.

Mer information finns också:

Användardefinierade felmeddelanden

Användardefinierade felmeddelanden finns i katalogvyn sys.messages . Den här katalogvyn lagras i master. Om ett databasprogram är beroende av användardefinierade felmeddelanden och databasen görs tillgänglig på en annan serverinstans använder du sp_addmessage för att lägga till de användardefinierade meddelandena på målserverinstansen.

Händelsemeddelanden och WMI-händelser (Windows Management Instrumentation) (på servernivå)

Serverhändelsemeddelanden

Händelsemeddelanden på servernivå lagras i msdb. Om ett databasprogram förlitar sig på ett händelsemeddelande på servernivå måste därför händelsemeddelandet återskapas på målserverinstansen. Om du vill visa händelseaviseringar på en serverinstans använder du sys.server_event_notifications katalogvyn. Mer information finns i Händelsemeddelanden.

Dessutom levereras händelseaviseringar med hjälp av Service Broker. Vägar för inkommande meddelanden ingår inte i databasen som innehåller en tjänst. I stället lagras explicita vägar i msdb. Om tjänsten använder en explicit väg i msdb databasen för att dirigera inkommande meddelanden till tjänsten måste du återskapa den här vägen när du kopplar en databas i en annan instans.

Windows Management Instrumentation (WMI)-händelser

Med WMI-providern för serverhändelser kan du använda Windows Management Instrumentation (WMI) för att övervaka händelser i SQL Server. Alla program som förlitar sig på händelser på servernivå som exponeras via den WMI-provider som en databas förlitar sig på måste definieras datorn för målserverinstansen. WMI-händelseprovidern skapar händelsemeddelanden med en måltjänst som definieras i msdb.

Anmärkning

Mer information finns i WMI Provider for Server Events Concepts (WMI-provider för serverhändelser).

Skapa en WMI-avisering med SQL Server Management Studio

Så här fungerar händelsemeddelanden för en speglad databas

Leverans mellan databaser av händelsemeddelanden som omfattar en speglad databas är per definition fjärr, eftersom den speglade databasen kan växla över. Service Broker ger särskilt stöd för speglade databaser i form av speglade vägar. En speglad väg har två adresser: en för huvudserverinstansen och en för speglingsserverinstansen.

Genom att konfigurera speglade vägar gör du Service Broker-routning medveten om databasspegling. De speglade vägarna gör det möjligt för Service Broker att transparent omdirigera konversationer till den aktuella huvudserverinstansen. Anta till exempel att en tjänst, Service_A, som hanteras av en speglad databas, Database_A. Anta att du behöver en annan tjänst, Service_B, som hanteras av Database_B, för att ha en dialogruta med Service_A. För att den här dialogrutan ska vara möjlig måste Database_B innehålla en speglad väg för Service_A. Dessutom måste Database_A innehålla en icke-krypterad TCP-transportväg till Service_B, som till skillnad från en lokal väg förblir giltig efter redundansväxling. Dessa rutter möjliggör för ACK:ar att återkomma efter en felövergång. Eftersom avsändarens tjänst alltid namnges på samma sätt måste rutten ange brokerinstansen.

Kravet på speglade vägar gäller oavsett om tjänsten i den speglade databasen är initierartjänsten eller måltjänsten:

  • Om måltjänsten finns i den speglade databasen måste initierartjänsten ha en speglad väg tillbaka till målet. Målet kan dock ha en vanlig väg tillbaka till initieraren.

  • Om initierartjänsten finns i den speglade databasen måste måltjänsten ha en speglad väg tillbaka till initieraren för att leverera bekräftelser och svar. Initieraren kan dock ha en vanlig väg till målet.

Utökade lagrade procedurer

Viktigt!

Den här funktionen tas bort i en framtida version av SQL Server. Undvik att använda den här funktionen i nytt utvecklingsarbete och planera att ändra program som för närvarande använder den här funktionen. Använd CLR-integrering i stället.

Utökade lagrade procedurer programmeras med hjälp av API:et för utökad lagrad procedur i SQL Server. En medlem i den fasta sysadmin-serverrollen kan registrera en utökad lagrad procedur med en instans av SQL Server och ge användarna behörighet att utföra proceduren. Utökade lagrade procedurer kan bara läggas till i master databasen.

Utökade lagrade procedurer körs direkt i adressutrymmet för en instans av SQL Server, och de kan orsaka minnesläckor eller andra problem som minskar serverns prestanda och tillförlitlighet. Du bör överväga att lagra utökade lagrade procedurer i en instans av SQL Server som är separat från den instans som innehåller de refererade data. Du bör också överväga att använda distribuerade frågor för att komma åt databasen.

Viktigt!

Innan du lägger till utökade lagrade procedurer på servern och beviljar EXECUTE-behörigheter till andra användare bör systemadministratören noggrant granska varje utökad lagrad procedur för att se till att den inte innehåller skadlig eller skadlig kod.

Mer information finns i BEVILJA objektbehörigheter (Transact-SQL), NEKA objektbehörigheter (Transact-SQL)och ÅTERKALLA objektbehörigheter (Transact-SQL).

Full-Text Engine för SQL Servers egenskaper

Egenskaper anges i Full-Text Engine av sp_fulltext_service. Kontrollera att målserverinstansen har de inställningar som krävs för dessa egenskaper. Mer information om dessa egenskaper finns i FULLTEXTSERVICEPROPERTY (Transact-SQL).

Dessutom, om komponenten för ordbrytare och stemmers eller fulltextsökningsfilter har olika versioner på original- och målserverinstanserna, kan fulltextindex och frågor bete sig annorlunda. Dessutom lagras synonymordlistan i instansspecifika filer. Du måste antingen överföra en kopia av filerna till en motsvarande plats på målserverinstansen eller återskapa dem på en ny instans.

Anmärkning

När du kopplar en SQL Server 2005-databas (9.x) som innehåller katalogfiler i fulltext till en SQL Server-serverinstans, kopplas katalogfilerna från den tidigare platsen tillsammans med de andra databasfilerna, samma som i SQL Server 2005 (9.x). För mer information, se Uppgradera Full-Text Sök.

Mer information finns också:

Jobb

Om databasen förlitar sig på SQL Server Agent-jobb måste du återskapa dem på målserverinstansen. Jobben är beroende av deras miljöer. Om du planerar att återskapa ett befintligt jobb på målserverinstansen kan målserverinstansen behöva ändras för att matcha miljön för jobbet på den ursprungliga serverinstansen. Följande miljöfaktorer är betydande:

  • Inloggningen som används av jobbet

    Om du vill skapa eller köra SQL Server Agent-jobb måste du först lägga till de SQL Server-inloggningar som krävs av jobbet i målserverinstansen. Mer information finns i Konfigurera en användare att skapa och hantera SQL Server Agent-jobb.

  • Startkonto för SQL Server Agent-tjänsten

    Startkontot för tjänsten definierar det Microsoft Windows-konto där SQL Server-agenten körs och dess nätverksbehörigheter. SQL Server-agenten körs som ett angivet användarkonto. Agenttjänstens kontext påverkar inställningarna för jobbet och dess körningsmiljö. Kontot måste ha åtkomst till de resurser, till exempel nätverksresurser, som krävs av jobbet. Information om hur du väljer och ändrar tjänstens startkonto finns i Välj ett konto för SQL Server Agent Service.

    För att fungera korrekt måste tjänstens startkonto konfigureras för att ha rätt domän-, filsystem- och registerbehörigheter. Ett jobb kan också kräva en resurs för delat nätverk som måste konfigureras för tjänstkontot. Mer information finns i Konfigurera Windows-tjänstkonton och -behörigheter.

  • SQL Server Agent-tjänsten, som är associerad med en specifik instans av SQL Server, har en egen registreringsdatafil och dess jobb har vanligtvis beroenden för en eller flera av inställningarna i den här registerdatafilen. För att fungera som avsett kräver ett jobb dessa registerinställningar. Om du använder ett skript för att återskapa ett jobb i en annan SQL Server Agent-tjänst kanske registret inte har rätt inställningar för jobbet. För att återskapade jobb ska fungera korrekt på en målserverinstans bör sql Server Agent-tjänsterna för original och mål ha samma registerinställningar.

    Försiktighet

    Det kan vara problematiskt att ändra registerinställningarna för SQL Server Agent-måltjänsten för att hantera ett nytt jobb om de aktuella inställningarna krävs av andra jobb. Dessutom kan felaktig redigering av registret allvarligt skada systemet. Innan du gör ändringar i registret rekommenderar vi att du säkerhetskopierar alla värdefulla data på datorn.

  • SQL Server-agentproxier

    En SQL Server Agent-proxy definierar säkerhetskontexten för ett angivet jobbsteg. För att ett jobb ska kunna köras på målserverinstansen måste alla proxyservrar som krävs återskapas manuellt på den instansen. Mer information finns i Skapa en SQL Server-agentproxy och Felsöka multiserverjobb som använder proxyservrar.

Mer information finns också:

Visa befintliga jobb och deras egenskaper

Skapa ett jobb

Metodtips för att använda ett skript för att återskapa ett jobb

Vi rekommenderar att du börjar med att skripta ett enkelt jobb, återskapa jobbet på den andra SQL Server Agent-tjänsten och köra jobbet för att se om det fungerar som avsett. På så sätt kan du identifiera inkompatibiliteter och försöka lösa dem. Om ett skriptjobb inte fungerar som avsett i den nya miljön rekommenderar vi att du skapar ett motsvarande jobb som fungerar korrekt i den miljön.

Inloggningar

För att logga in på en instans av SQL Server krävs en giltig SQL Server-inloggning. Den här inloggningen används i autentiseringsprocessen som verifierar om huvudkontot kan ansluta till SQL Server-instansen. En databasanvändare för vilken motsvarande SQL Server-inloggning är odefinierad eller felaktigt definierad på en serverinstans kan inte logga in på instansen. En sådan användare sägs vara en överbliven användare av databasen på den serverinstansen. En databasanvändare kan bli föräldralös om en databas blir återställd, kopplad eller kopierad till en annan instans av SQL Server.

Om du vill generera ett skript för vissa eller alla objekt i den ursprungliga kopian av databasen kan du använda guiden Generera skript och i dialogrutan Välj skriptalternativ anger du alternativet Skriptinloggningar till Sant.

Anmärkning

Information om hur du konfigurerar inloggningar för en speglad databas finns i Konfigurera inloggningskonton för databasspegling eller AlwaysOn-tillgänglighetsgrupper (SQL Server) och hantering av inloggningar och jobb efter rollväxling (SQL Server).

Permissions

Följande typer av behörigheter kan påverkas när en databas görs tillgänglig på en annan serverinstans.

  • BEVILJA, ÅTERKALLA eller NEKA behörigheter för systemobjekt

  • BEVILJA, ÅTERKALLA eller NEKA behörigheter för serverinstanser (behörigheter på servernivå)

Bevilja, återkalla och neka behörigheter för systemobjekt

Behörigheter för systemobjekt som lagrade procedurer, utökade lagrade procedurer, funktioner och vyer lagras i master databasen och måste konfigureras på målserverinstansen.

Om du vill generera ett skript för vissa eller alla objekt i den ursprungliga kopian av databasen kan du använda guiden Generera skript och i dialogrutan Välj skriptalternativ anger du alternativet Skript Object-Level Behörigheter till Sant.

Viktigt!

Om du använder skriptinloggningar skrivs inte lösenorden i skript. Om du har inloggningar som använder SQL Server-autentisering måste du ändra skriptet på målet.

Systemobjekt visas i sys.system_objects katalogvy. Behörigheterna för systemobjekt visas i sys.database_permissions katalogvyn i master databasen. Information om hur du frågar efter dessa katalogvyer och beviljar systemobjektbehörigheter finns i BEVILJA systemobjektbehörigheter (Transact-SQL). Mer information finns i ÅTERKALLA systemobjektbehörigheter (Transact-SQL) och NEKA systemobjektbehörigheter (Transact-SQL).

BEVILJA, ÅTERKALLA och NEKA behörigheter på en serverinstans

Behörigheter i serveromfånget master lagras i databasen och måste konfigureras på målserverinstansen. Om du vill ha information om serverbehörigheterna för en serverinstans, frågar du katalogvyn sys.server_permissions. För information om serverprincipaler frågar du katalogvyn sys.server_principals, och för information om medlemskap i serverroller frågar du katalogvyn sys.server_role_members.

Mer information finns i BEVILJA serverbehörigheter (Transact-SQL), ÅTERKALLA serverbehörigheter (Transact-SQL), och NEKA serverbehörigheter (Transact-SQL).

Server-Level behörigheter för ett certifikat eller en asymmetrisk nyckel

Behörigheter på servernivå kan inte beviljas direkt till ett certifikat eller en asymmetrisk nyckel. I stället beviljas behörigheter på servernivå till en mappad inloggning som skapas exklusivt för ett specifikt certifikat eller en asymmetrisk nyckel. Därför kräver varje certifikat eller asymmetrisk nyckel som kräver behörigheter på servernivå sin egen certifikatmappade inloggning eller asymmetriska nyckelmappade inloggningar. Om du vill bevilja behörigheter på servernivå för ett certifikat eller en asymmetrisk nyckel beviljar du behörigheterna till den mappade inloggningen.

Anmärkning

En mappad inloggning används endast för auktorisering av kod signerad med motsvarande certifikat eller asymmetrisk nyckel. Mappade inloggningar kan inte användas för autentisering.

Den mappade inloggningen och dess behörigheter finns båda i master. Om ett certifikat eller en asymmetrisk nyckel finns i en annan databas än mastermåste du återskapa det och master mappa det till en inloggning. Om du flyttar, kopierar eller återställer databasen till en annan serverinstans måste du återskapa dess certifikat eller asymmetriska nyckel i databasen för master målserverinstansen, mappa till en inloggning och ge inloggningen nödvändiga behörigheter på servernivå.

Skapa ett certifikat eller en asymmetrisk nyckel

Mappa ett certifikat eller en asymmetrisk nyckel till en inloggning

Tilldela behörigheter till den mappade inloggningen

Mer information om certifikat och asymmetriska nycklar finns i Krypteringshierarki.

Betrodd egenskap

Egenskapen TRUSTWORTHY-databas används för att ange om den här instansen av SQL Server litar på databasen och innehållet i den. När en databas är ansluten, som standard och för säkerhet, är det här alternativet inställt på AV, även om det här alternativet har angetts till PÅ på den ursprungliga servern. Mer information om den här egenskapen finns i TRUSTWORTHY-databasegenskapen och information om hur du aktiverar det här alternativet finns i ALTER DATABASE (Transact-SQL).

Replikeringsinställningar

Om du återställer en säkerhetskopia av en replikerad databas till en annan server eller databas kan replikeringsinställningarna inte bevaras. I det här fallet måste du återskapa alla publikationer och prenumerationer när säkerhetskopiorna har återställts. För att göra den här processen enklare skapar du skript för dina aktuella replikeringsinställningar och även för aktivering och inaktivering av replikering. För att återskapa replikeringsinställningarna kopierar du skripten och ändrar servernamnreferenserna så att de fungerar för målserverinstansen.

Mer information finns i Säkerhetskopiera och återställa replikerade databaser, databasspegling och replikering (SQL Server) och Loggöverföring och replikering (SQL Server).

Service Broker-applikationer

Många aspekter av ett Service Broker-program flyttas med databasen. Vissa aspekter av programmet måste dock återskapas eller konfigureras om på den nya platsen. Som standard och för säkerhet, när en databas är ansluten från en annan server, är alternativen för is_broker_enabled och is_honoor_broker_priority_on inställda på OFF. Information om hur du anger dessa alternativ PÅ finns i ALTER DATABASE (Transact-SQL).

Startprocedurer

En startprocedur är en lagrad procedur som är markerad för automatisk körning och körs varje gång SQL Server startar. Om databasen är beroende av några startprocedurer måste de definieras på målserverinstansen och konfigureras för att köras automatiskt vid start.

Utlösare (på servernivå)

DDL utlöser utlösande lagrade procedurer som svar på flera DDL-händelser (Data Definition Language). Dessa händelser motsvarar främst Transact-SQL -instruktioner som börjar med nyckelorden CREATE, ALTER och DROP. Vissa system lagrade procedurer som utför DDL-liknande åtgärder kan också utlösa DDL-utlösare.

Mer information om den här funktionen finns i DDL-utlösare.

Se även

inneslutna databaser
Kopiera databaser till andra servrar
Databas Koppla från och ansluta (SQL Server)
Redundansväxling till en sekundär loggleverans (SQL Server)
Övergång av roller under en databasspeglingssession (SQL Server)
Konfigurera en krypterad speglingsdatabas
Konfigurationshanteraren för SQL Server (SQL Server Configuration Manager)
Felsöka överblivna användare (SQL Server)
Migrera till en ny installationMigreringsöversikt: SQL Server till SQL Server på virtuell Azure-dator

  • Last updated on