Megosztás a következőn keresztül:

Metaadatok kezelése, amikor egy adatbázist elérhetővé tesz egy másik kiszolgálón

A következőkre vonatkozik:SQL Server

Ez a cikk a következő helyzetekben releváns:

  • Always On elérhetőségi csoport rendelkezésre állási replikáinak konfigurálása.

  • Adatbázis-tükrözés beállítása egy adatbázishoz.

  • Amikor előkészíti a szerepkörök módosítását az elsődleges és a másodlagos kiszolgálók között a naplószállítási konfigurációban.

  • Adatbázis visszaállítása egy másik kiszolgálópéldányra.

  • Adatbázis másolatának csatolása egy másik kiszolgálópéldányhoz.

  • Adatbázismotor-frissítés végrehajtása a módszerrel – áttelepítés új telepítésre.

  • Adatbázisok migrálása az Azure SQL-be (virtuális gép vagy felügyelt példány).

Egyes alkalmazások olyan információktól, entitásoktól és/vagy objektumoktól függnek, amelyek nem tartoznak egyetlen felhasználói adatbázis hatókörébe. Az alkalmazások általában függenek a master és msdb adatbázisoktól, valamint a felhasználói adatbázistól is. A felhasználói adatbázison kívül tárolt, az adatbázis megfelelő működéséhez szükséges adatokat elérhetővé kell tenni a célkiszolgáló-példányon. Egy alkalmazás bejelentkezései például metaadatokként vannak tárolva az master adatbázisban, és ezeket újra létre kell hozni a célkiszolgálón. Ha egy alkalmazás- vagy adatbázis-karbantartási terv az SQL Server Agent-feladatoktól függ, amelyek metaadatai a msdb adatbázisban vannak tárolva, újra létre kell hoznia ezeket a feladatokat a célkiszolgáló-példányon. Hasonlóképpen, a kiszolgálószintű eseményindító metaadatait a rendszer mastertárolja.

Amikor egy alkalmazás adatbázisát egy másik kiszolgálópéldányra helyezi át, újra létre kell hoznia a függő entitások és objektumok metaadatait a master és msdb a célkiszolgáló-példányon. Ha például egy adatbázis-alkalmazás kiszolgálószintű eseményindítókat használ, az adatbázis csatolása vagy visszaállítása az új rendszeren nem elegendő. Az adatbázis csak akkor működik a várt módon, ha manuálisan hozza létre újra a metaadatokat az master adatbázisban lévő eseményindítókhoz.

A felhasználói adatbázisokon kívül tárolt információk, entitások és objektumok

A cikk további része összefoglalja azokat a lehetséges problémákat, amelyek egy másik kiszolgálópéldányon elérhetővé tett adatbázist érinthetnek. Előfordulhat, hogy újra létre kell hoznia az alábbi listában felsorolt információk, entitások vagy objektumok egy vagy több típusát. Az összegzés megtekintéséhez válassza ki az elem hivatkozását.

Kiszolgáló konfigurációs beállításai

Az SQL Server 2005 (9.x) és újabb verziói szelektíven telepítik és elindítják a legfontosabb szolgáltatásokat és funkciókat. Ez segít csökkenteni a rendszer támadható felületét. Az új telepítések alapértelmezett konfigurációjában számos funkció nincs engedélyezve. Ha az adatbázis olyan szolgáltatásra vagy funkcióra támaszkodik, amely alapértelmezés szerint ki van kapcsolva, ezt a szolgáltatást vagy funkciót engedélyezni kell a célkiszolgáló-példányon.

Ezekről a beállításokról és azok engedélyezéséről és letiltásáról további információt a Kiszolgáló konfigurációs beállításai (SQL Server) című témakörben talál.

Credentials

A hitelesítő adatok olyan rekordok, amelyek az SQL Serveren kívüli erőforráshoz való csatlakozáshoz szükséges hitelesítési adatokat tartalmazzák. A legtöbb hitelesítő adat windowsos bejelentkezésből és jelszóból áll.

A szolgáltatásról további információt a Hitelesítő adatok (adatbázismotor) című témakörben talál.

Megjegyzés:

Az SQL Server-ügynökproxy-fiókok hitelesítő adatokat használnak. A proxyfiók hitelesítő azonosítójának megismeréséhez használja a sysproxies rendszertáblát.

Adatbázisközi lekérdezések

A DB_CHAINING és a MEGBÍZHATÓ adatbázis beállításai alapértelmezés szerint ki vannak kapcsolva. Ha az eredeti adatbázisban ezek közül bármelyik ON-ra van állítva, előfordulhat, hogy engedélyeznie kell ezeket a célkiszolgáló példányának adatbázisában. További információ: ALTER DATABASE (Transact-SQL).

A csatolási és leválasztási műveletek letiltják az adatbázis tulajdonjogi láncolását. A láncolás engedélyezésével kapcsolatos információt az adatbázis-tulajdonjog láncolása kiszolgáló konfigurációs opcióban talál.

További információ: Tüköradatbázis beállítása a Megbízható tulajdonság használatára (Transact-SQL)

Adatbázis tulajdonjoga

Ha egy adatbázist egy másik számítógépen állít vissza, az SQL Server bejelentkezési vagy a visszaállítási műveletet kezdeményező Windows-felhasználó automatikusan az új adatbázis tulajdonosa lesz. Az adatbázis visszaállításakor a rendszergazda vagy az új adatbázis tulajdonosa módosíthatja az adatbázis tulajdonjogát.

Elosztott lekérdezések és csatolt kiszolgálók

Az elosztott lekérdezések és a csatolt kiszolgálók támogatottak az OLE DB-alkalmazásokhoz. Az elosztott lekérdezések ugyanazon vagy különböző számítógépeken több heterogén adatforrásból férnek hozzá az adatokhoz. A csatolt kiszolgáló konfigurációja lehetővé teszi, hogy az SQL Server parancsokat hajtson végre az OLE DB-adatforrásokon a távoli kiszolgálókon. Ezekről a funkciókról további információt a csatolt kiszolgálók (adatbázismotor) című témakörben talál.

Titkosított adatok

Ha a másik kiszolgálópéldányon elérhetővé tett adatbázis titkosított adatokat tartalmaz, és ha az adatbázis főkulcsát az eredeti kiszolgálón lévő szolgáltatás főkulcsa védi, előfordulhat, hogy újra létre kell hozni a szolgáltatás főkulcsának titkosítását. Az adatbázis főkulcsa egy szimmetrikus kulcs, amely a tanúsítványok és az aszimmetrikus kulcsok titkos kulcsainak védelmére szolgál egy titkosított adatbázisban. Létrehozáskor az adatbázis főkulcsa a Triple DES algoritmus és egy felhasználó által megadott jelszó használatával lesz titkosítva.

Az adatbázis-főkulcs automatikus visszafejtésének engedélyezéséhez a rendszer a szolgáltatás főkulcsával titkosítja a kulcs egy példányát. Ez a titkosított másolat mind az adatbázisban, mind master tárolva van. A tárolt master másolat általában csendesen frissül a főkulcs módosításakor. Az SQL Server először megpróbálja visszafejteni az adatbázis főkulcsát a példány szolgáltatás-főkulcsával. Ha a visszafejtés sikertelen, az SQL Server megkeresi a hitelesítőadat-tárolóban azokat a főkulcs-hitelesítő adatokat, amelyek családazonosítója megegyezik azzal az adatbázissal, amelyhez a főkulcsot igényli. Az SQL Server ezután megpróbálja visszafejteni az adatbázis főkulcsát az egyes egyező hitelesítő adatokkal, amíg a visszafejtés sikeres nem lesz, vagy nincs több hitelesítő adat. A szolgáltatás főkulcsa által nem titkosított főkulcsot az OPEN MASTER KEY utasítással és jelszóval kell megnyitni.

Ha egy titkosított adatbázist másolnak, visszaállítanak vagy egy új SQL Server-példányhoz csatolnak, a szolgáltatás főkulcsa által titkosított adatbázis-főkulcs másolatát a rendszer nem tárolja a célkiszolgáló példányán master . A cél szerver példányán meg kell nyitnia az adatbázis főkulcsát. A főkulcs megnyitásához hajtsa végre a következő utasítást: OPEN MASTER KEY DECRYPTION BY PASSWORD ='password'. Javasoljuk, hogy az adatbázis főkulcsának automatikus dekódolását engedélyezze a következő utasítás végrehajtásával: ALTER MASTER KEY ADD ENCRYPTION BY SERVICE MASTER KEY. Ez az ALTER MASTER KEY utasítás a kiszolgálópéldányt a szolgáltatás főkulcsával titkosított adatbázis-főkulcs másolatával helyezi üzembe. További információ: OPEN MASTER KEY (Transact-SQL) és ALTER MASTER KEY (Transact-SQL).

A tükrözött adatbázis adatbázis-főkulcsának automatikus visszafejtésének engedélyezéséről további információt a Titkosított tükrözött adatbázis beállítása című témakörben talál.

További információkért lásd még:

Felhasználó által definiált hibaüzenetek

A felhasználó által definiált hibaüzenetek a sys.messages katalógusnézetben találhatók. Ez a katalógusnézet a következő helyen van tárolva master: . Ha egy adatbázis-alkalmazás a felhasználó által megadott hibaüzenettől függ, és az adatbázis egy másik kiszolgálópéldányon érhető el, használja a sp_addmessage a felhasználó által definiált üzeneteket a célkiszolgáló-példányhoz való hozzáadásához.

Eseményértesítések és a Windows Management Instrumentation (WMI) eseményei (kiszolgálószinten)

Server-Level eseményértesítések

A kiszolgálószintű eseményértesítések tárolása a következő helyen msdbtörténik: . Ezért ha egy adatbázis-alkalmazás kiszolgálószintű eseményértesítésre támaszkodik, az eseményértesítést újra létre kell hozni a célkiszolgáló-példányon. A kiszolgálópéldány eseményértesítéseinek megtekintéséhez használja a sys.server_event_notifications katalógusnézetet. További információ: Eseményértesítések.

Emellett az eseményértesítések kézbesítése a Service Broker használatával történik. A bejövő üzenetek útvonalai nem szerepelnek a szolgáltatást tartalmazó adatbázisban. Ehelyett az útvonalakat kifejezetten a msdb tárolja. Ha a szolgáltatás az adatbázisban explicit útvonalon msdb irányítja a bejövő üzeneteket a szolgáltatáshoz, amikor egy másik példányhoz csatol egy adatbázist, újra létre kell hoznia ezt az útvonalat.

A Windows Management Instrumentation (WMI) eseményei

A Kiszolgáló eseményekhez tartozó WMI-szolgáltató lehetővé teszi a Windows Management Instrumentation (WMI) használatát az SQL Server eseményeinek figyelésére. Minden olyan alkalmazást, amely a WMI-szolgáltatón keresztül közzétett kiszolgálószintű eseményekre támaszkodik és amelyre az adatbázis is támaszkodik, meg kell határozni a célkiszolgáló példány számítógépén. A WMI eseményszolgáltatója eseményértesítéseket hoz létre egy célszolgáltatással, amely a következőben van definiálva msdb: .

Megjegyzés:

További információ: WMI Provider for Server Events Concepts.

WMI-riasztás létrehozása az SQL Server Management Studióval

Eseményértesítések működése tükrözött adatbázisokhoz

A tükrözött adatbázist érintő eseményértesítések adatbázisközi kézbesítése definíció szerint nem helyi, mert a tükrözött adatbázisnál feladatátvétel történhet. A Service Broker speciális támogatást nyújt a tükrözött adatbázisokhoz tükrözött útvonalak formájában. A tükrözött útvonal két címmel rendelkezik: egy az elsődleges kiszolgálópéldányhoz és egy pedig a tükrözött kiszolgálópéldányhoz.

Az útvonalak tükrözésének beállításával a Service Broker útválasztása tisztában lesz az adatbázis-tükrözéssel. A tükrözött útvonalak lehetővé teszik, hogy a Service Broker transzparens módon átirányítsa a beszélgetéseket az aktuális elsődleges kiszolgálópéldányra. Vegyünk például egy szolgáltatást, a Service_A-t, amelyet egy tükrözött adatbázis, a Database_A üzemeltet. Tegyük fel, hogy szüksége van egy másik szolgáltatásra, a Service_B-re, amelyet a Database_B üzemeltet, hogy párbeszédet folytasson a Service_A-val. Ahhoz, hogy ez a párbeszédpanel lehetséges legyen, Database_B tükrözött útvonalat kell tartalmaznia a Service_A számára. Ezenkívül a Database_A-nak tartalmaznia kell egy nem tükrözött TCP-átviteli útvonalat a Service_B-hez, amely a helyi útvonaltól eltérően a feladatátvétel után is érvényes marad. Ezek az útvonalak lehetővé teszik az ACK-k számára, hogy egy átállás után visszatérjenek. Mivel a feladó szolgáltatása mindig azonos módon van elnevezve, az útvonalnak meg kell adnia a közvetítőpéldányt.

A tükrözött útvonalakra vonatkozó követelmény attól függetlenül érvényes, hogy a tükrözött adatbázisban található szolgáltatás a kezdeményező szolgáltatás vagy a célszolgáltatás:

  • Ha a célszolgáltatás a tükrözött adatbázisban található, a kezdeményező szolgáltatásnak tükrözött útvonalsal kell rendelkeznie a célhoz. Azonban a célnak lehet egy szokásos útvonala vissza a kezdeményezőhöz.

  • Ha a kezdeményező szolgáltatás a tükrözött adatbázisban található, a célszolgáltatásnak tükrözött útvonalsal kell rendelkeznie a kezdeményezőhöz, hogy nyugtázásokat és válaszokat küldjön. A kezdeményezőnek azonban lehet egy normál útvonala a célhoz.

Kiterjesztett tárolt eljárások

Fontos

Ez a funkció az SQL Server egy későbbi verziójában lesz eltávolítva. Ne használja ezt a funkciót az új fejlesztési munkában, és tervezze meg a funkciót jelenleg használó alkalmazások módosítását. Használja inkább a CLR-integrációt .

A kiterjesztett tárolt eljárások az SQL Server bővített tárolt eljárás API-jának használatával vannak programozva. A sysadmin rögzített kiszolgálói szerepkör tagja regisztrálhat egy kiterjesztett tárolt eljárást az SQL Server egy példányán, és engedélyt adhat a felhasználóknak az eljárás végrehajtására. A kiterjesztett tárolt eljárások csak az master adatbázishoz vehetők fel.

A kiterjesztett tárolt eljárások közvetlenül az SQL Server egy példányának címterében futnak, és memóriavesztést vagy más problémákat okozhatnak, amelyek csökkentik a kiszolgáló teljesítményét és megbízhatóságát. Érdemes megfontolni a kiterjesztett tárolt eljárások tárolását az SQL Server azon példányában, amely eltér a hivatkozott adatokat tartalmazó példánytól. Érdemes megfontolnia az elosztott lekérdezések használatát is az adatbázis eléréséhez.

Fontos

Mielőtt kiterjesztett tárolt eljárásokat ad a kiszolgálóhoz, és végrehajtási engedélyeket ad a többi felhasználónak, a rendszergazdának alaposan át kell tekintenie az egyes kiterjesztett tárolt eljárásokat, hogy meggyőződjön arról, hogy nem tartalmaz káros vagy rosszindulatú kódot.

További információ: GRANT Object Permissions (Transact-SQL), DENY Object Permissions (Transact-SQL), és REVOKE Object Permissions (Transact-SQL).

Full-Text SQL Server-tulajdonságok motorja

A tulajdonságokat a sp_fulltext_service állítja be a Full-Text motoron. Győződjön meg arról, hogy a célkiszolgáló-példány rendelkezik a szükséges beállításokkal ezekhez a tulajdonságokhoz. További információ ezekről a tulajdonságokról: FULLTEXTSERVICEPROPERTY (Transact-SQL).

Továbbá, ha a szóhatárolók és a stemmers összetevő vagy a teljes szöveges keresési szűrők összetevő eltérő verziókkal rendelkezik az eredeti és a célkiszolgáló példányán, a teljes szöveges index és a lekérdezések eltérően viselkedhetnek. Emellett a szinonimaszótár példányspecifikus fájlokban van tárolva. A fájlok másolatát át kell vinnie a célkiszolgáló-példány egy egyenértékű helyére, vagy újra létre kell hoznia őket az új példányon.

Megjegyzés:

Amikor egy teljes szöveges katalógusfájlokat tartalmazó SQL Server 2005-ös (9.x) adatbázist csatol egy SQL Server-kiszolgálópéldányhoz, a katalógusfájlok a korábbi helyükről lesznek csatolva a többi adatbázisfájllal együtt, ugyanúgy, mint az SQL Server 2005 -ben (9.x). További információért lásd: Frissítés Full-Text keresés.

További információkért lásd még:

Jobs

Ha az adatbázis SQL Server Agent-feladatokra támaszkodik, újra létre kell hoznia őket a célkiszolgáló-példányon. A feladatok a környezetüktől függenek. Ha egy meglévő feladatot szeretne újra létrehozni a célkiszolgáló-példányon, előfordulhat, hogy a célkiszolgáló-példányt módosítani kell, hogy megfeleljen a feladat környezetének az eredeti kiszolgálópéldányon. A következő környezeti tényezők jelentősek:

  • A feladat által használt bejelentkezés

    Az SQL Server Agent-feladatok létrehozásához vagy végrehajtásához először hozzá kell adnia a feladathoz szükséges SQL Server-bejelentkezéseket a célkiszolgáló-példányhoz. További információ: Felhasználó konfigurálása SQL Server-ügynökfeladatok létrehozásához és kezeléséhez.

  • SQL Server Agent szolgáltatás indítási fiókja

    A szolgáltatásindítási fiók határozza meg azt a Microsoft Windows-fiókot, amelyben az SQL Server Agent fut, és annak hálózati engedélyeit. Az SQL Server Agent megadott felhasználói fiókként fut. Az Ügynökszolgáltatás környezete hatással van a feladat és a futtatási környezet beállításaira. A fióknak hozzáféréssel kell rendelkeznie a feladat által igényelt erőforrásokhoz, például hálózati megosztásokhoz. A szolgáltatás indítási fiókjának kiválasztásával és módosításával kapcsolatos információkért lásd : Fiók kiválasztása az SQL Server Agent Service-hez.

    A megfelelő működéshez a szolgáltatás indítási fiókját úgy kell konfigurálni, hogy a megfelelő tartomány- és fájlrendszer- és beállításjegyzék-engedélyekkel rendelkezzen. Emellett előfordulhat, hogy egy feladathoz megosztott hálózati erőforrásra van szükség, amelyet konfigurálni kell a szolgáltatásfiókhoz. További információt a Windows-szolgáltatásfiókok és -engedélyek konfigurálása című témakörben talál.

  • Az SQL Server egy adott példányához társított SQL Server Agent szolgáltatás saját beállításjegyzék-struktúrával rendelkezik, és a feladatai általában függenek a beállításjegyzék-hive egy vagy több beállításától. A feladat megfelelő működéséhez szükségesek ezek a beállításjegyzék-beállítások. Ha parancsfájl használatával hoz létre újra feladatot egy másik SQL Server Agent szolgáltatásban, előfordulhat, hogy a beállításjegyzék nem rendelkezik a feladat megfelelő beállításaival. Ahhoz, hogy az újra létrehozott feladatok megfelelően viselkedjenek a célkiszolgáló-példányon, az eredeti és a cél SQL Server Agent-szolgáltatásnak ugyanazokat a beállításjegyzék-beállításokat kell megadnia.

    Caution

    Az újra létrehozott feladatok kezeléséhez a cél SQL Server Agent szolgáltatás beállításjegyzék-beállításainak módosítása problémás lehet, ha az aktuális beállításokat más feladatok igénylik. Ezenkívül a beállításjegyzék helytelen szerkesztése súlyosan károsíthatja a rendszert. Mielőtt módosítanák a beállításjegyzéket, javasoljuk, hogy készítsen biztonsági másolatot a számítógépen lévő értékes adatokról.

  • SQL Server-ügynök proxyi

    Az SQL Server-ügynökproxy egy adott feladatlépés biztonsági környezetét határozza meg. Ahhoz, hogy egy feladat a célkiszolgáló-példányon fusson, az összes szükséges proxyt manuálisan újra létre kell hozni az adott példányon. További információ: SQL Server-ügynökproxy létrehozása és proxykat használó többkiszolgálós feladatok hibaelhárítása.

További információkért lásd még:

Meglévő feladatok és tulajdonságaik megtekintése

Feladat létrehozása

Ajánlott eljárások a feladat ismételt létrehozásához parancsfájl használatával

Javasoljuk, hogy először egy egyszerű feladat szkriptelésével hozza létre újra a feladatot a másik SQL Server Agent szolgáltatásban, és futtassa a feladatot, hogy lássa, a feladat a kívánt módon működik-e. Ezzel azonosíthatja a inkompatibilitásokat, és megpróbálhatja feloldani őket. Ha egy szkriptelt feladat nem a kívánt módon működik az új környezetében, javasoljuk, hogy hozzon létre egy, az adott környezetben megfelelően működő feladatot.

Bejelentkezések

Az SQL Server-példányba való bejelentkezéshez érvényes SQL Server-bejelentkezés szükséges. Ezt a bejelentkezést használja a hitelesítési folyamat, amely ellenőrzi, hogy az egyszerű felhasználó tud-e csatlakozni az SQL Server-példányhoz. Az adatbázis-felhasználó, amelyhez a megfelelő SQL Server-bejelentkezés nincs meghatározva, vagy helytelenül van definiálva egy kiszolgálópéldányon, nem tud bejelentkezni a példányba. Az ilyen felhasználóról azt mondják, hogy az adatbázis árva felhasználója az adott kiszolgálópéldányon. Egy adatbázis-felhasználó magányossá válhat, ha az adatbázis visszaállítása, csatolása vagy másolása után egy másik SQL Server példányhoz kerül.

Ha parancsfájlt szeretne létrehozni az adatbázis eredeti példányában található objektumok egy vagy több objektumához, használja a Szkriptek létrehozása varázslót, és a Szkriptbeállítások kiválasztása párbeszédpanelen állítsa a Szkriptbeléptetések beállítást True (Igaz) értékre.

Megjegyzés:

A tükrözött adatbázisok bejelentkezéseinek beállításával kapcsolatos információkért lásd: Bejelentkezési fiókok beállítása adatbázistükrözéshez vagy Mindig rendelkezésre állási csoportokhoz (SQL Server), valamint bejelentkezések és feladatok kezelése szerepkörváltás után (SQL Server) című témakörben.

Permissions

Az alábbi engedélytípusokat érintheti, ha egy adatbázis elérhetővé válik egy másik kiszolgálópéldányon.

  • GRANT, REVOKE vagy DENY engedélyek a rendszerobjektumokon

  • GRANT, REVOKE vagy DENY engedélyek a kiszolgálópéldányon (kiszolgálószintű engedélyek)

GRANT, REVOKE és DENY engedélyek a rendszerobjektumokon

A rendszerobjektumokra, például a tárolt eljárásokra, a kiterjesztett tárolt eljárásokra, a függvényekre és a nézetekre vonatkozó engedélyek az master adatbázisban vannak tárolva, és konfigurálva kell lenniük a célkiszolgáló-példányon.

Ha parancsfájlt szeretne létrehozni az adatbázis eredeti példányában lévő néhány vagy az összes objektumhoz, használja a Szkriptek létrehozása varázslót, és a Szkriptbeállítások kiválasztása párbeszédpanelen állítsa a Szkript Object-Level Engedélyek beállítást Igaz értékre.

Fontos

Ha bejelentkezéseket szkriptel, a jelszavak nem kerülnek bele a szkriptbe. Ha SQL Server-hitelesítést használó bejelentkezései vannak, módosítania kell a szkriptet a célhelyen.

A rendszerobjektumok sys.system_objects katalógusnézetben láthatók. A rendszerobjektumokra vonatkozó engedélyek az adatbázis sys.database_permissions katalógusnézetében master láthatók. A katalógusnézetek lekérdezéséről és a rendszerobjektum-engedélyek megadásáról a GRANT rendszerobjektum-engedélyek (Transact-SQL) című témakörben olvashat. További információ: REVOKE System Object Permissions (Transact-SQL) és DENY System Object Permissions (Transact-SQL).

Jogosultságok megadása, visszavonása és megtagadása a kiszolgálópéldányon

A kiszolgáló hatókörében lévő engedélyeket az master adatbázis tárolja, és a célkiszolgáló példányán kell konfigurálni. A kiszolgálópéldányok kiszolgálói engedélyeivel kapcsolatos információkért kérdezze le a sys.server_permissions katalógusnézetet, a kiszolgálónevekről a sys.server_principals katalógusnézetet, valamint a kiszolgálói szerepkörök tagságáról a sys.server_role_members katalógusnézetet.

További információ: GRANT Server Permissions (Transact-SQL), REVOKE Server Permissions (Transact-SQL), és DENY Server Permissions (Transact-SQL).

Server-Level tanúsítvány vagy aszimmetrikus kulcs engedélyei

A kiszolgálószintű engedélyek nem adhatóak közvetlenül tanúsítványhoz vagy aszimmetrikus kulcshoz. Ehelyett kiszolgálószintű engedélyeket kapnak egy leképezett bejelentkezéshez, amely kizárólag egy adott tanúsítványhoz vagy aszimmetrikus kulcshoz lett létrehozva. Ezért minden olyan tanúsítványhoz vagy aszimmetrikus kulcshoz, amely kiszolgálószintű engedélyeket igényel, saját tanúsítványleképezett bejelentkezést vagy aszimmetrikus kulcsleképezett bejelentkezést igényel. Ha kiszolgálószintű engedélyeket szeretne adni egy tanúsítványhoz vagy aszimmetrikus kulcshoz, adja meg az engedélyeket a hozzárendelt bejelentkezéshez.

Megjegyzés:

A leképezett bejelentkezés csak a megfelelő tanúsítvánnyal vagy aszimmetrikus kulccsal aláírt kód engedélyezéséhez használható. A megfeleltetett bejelentkezések nem használhatók hitelesítéshez.

A megfeleltetett bejelentkezés és az engedélyei is a(z) master helyen találhatók. Ha egy tanúsítvány vagy aszimmetrikus kulcs egy másik adatbázisban található, mint master, akkor újra létre kell hoznia azt master-ben, és hozzá kell rendelnie egy bejelentkezéshez. Ha áthelyezi, másolja vagy visszaállítja az adatbázist egy másik kiszolgálópéldányra, újra létre kell hoznia a tanúsítványát vagy az aszimmetrikus kulcsát a célkiszolgáló-példány adatbázisában master , le kell képeznie egy bejelentkezést, és meg kell adnia a szükséges kiszolgálószintű engedélyeket a bejelentkezéshez.

Tanúsítvány vagy aszimmetrikus kulcs létrehozása

Tanúsítvány vagy aszimmetrikus kulcs leképezése bejelentkezéshez

Engedélyek hozzárendelése a megfeleltetett bejelentkezéshez

A tanúsítványokról és az aszimmetrikus kulcsokról további információt a Titkosítási hierarchia című témakörben talál.

Megbízható tulajdonság

A TRUSTWORTHY adatbázistulajdonság jelzi, hogy az SQL Server ezen példánya megbízik-e az adatbázisban és a benne lévő tartalomban. Adatbázis csatolása esetén ez a beállítás alapértelmezés szerint ki van kapcsolva, még akkor is, ha ez a beállítás be van kapcsolva az eredeti kiszolgálón. A tulajdonságról további információt a TRUSTWORTHY adatbázistulajdonságban talál, és a beállítás bekapcsolásáról az ALTER DATABASE (Transact-SQL) című témakörben talál további információt.

Replikációs beállítások

Ha egy replikált adatbázis biztonsági másolatát egy másik kiszolgálóra vagy adatbázisra állítja vissza, a replikációs beállítások nem őrizhetők meg. Ebben az esetben a biztonsági másolatok visszaállítása után újra létre kell hoznia az összes kiadványt és előfizetést. A folyamat megkönnyítése érdekében hozzon létre szkripteket az aktuális replikációs beállításokhoz, valamint a replikáció engedélyezéséhez és letiltásához. A replikációs beállítások újbóli létrehozásához másolja ki ezeket a szkripteket, és módosítsa a kiszolgálónévhivatkozásokat a célkiszolgáló-példány működéséhez.

További információ: Replikált adatbázisok biztonsági mentése és visszaállítása, adatbázis-tükrözés és replikáció (SQL Server) és naplószállítás és replikáció (SQL Server).

Service Broker-alkalmazások

A Service Broker-alkalmazások számos aspektusa mozog az adatbázissal. Az alkalmazás bizonyos aspektusait azonban újra létre kell hozni vagy újra kell konfigurálni az új helyen. Alapértelmezés szerint és a biztonság érdekében, amikor egy adatbázist egy másik kiszolgálóról csatolnak, az is_broker_enabled és is_honor_broker_priority_on beállításai KI értékre vannak állítva. Az opciók bekapcsolásáról további információt az ALTER DATABASE (Transact-SQL) című témakörben talál.

Indítási eljárások

Az indítási eljárás egy tárolt eljárás, amely automatikus végrehajtásra van megjelölve, és minden alkalommal végrehajtja, amikor az SQL Server elindul. Ha az adatbázis bármilyen indítási eljárástól függ, azokat a célkiszolgáló példányán kell definiálni, és úgy kell konfigurálni, hogy indításkor automatikusan végrehajtsa őket.

Eseményindítók (kiszolgálószinten)

A DDL több adatdefiníciós nyelvi (DDL-) eseményre válaszul aktiválja a tárolt eljárásokat. Ezek az események elsősorban a CREATE, ALTER és DROP kulcsszavakkal kezdődő Transact-SQL utasításoknak felelnek meg. Bizonyos, DDL-hez hasonló műveleteket végző rendszer által tárolt eljárások DDL-eseményindítókat is aktiválhatnak.

A funkcióval kapcsolatos további információkért lásd a DDL-eseményindítókat.

Lásd még:

Adatbázisok, amelyeket tartalmaz
Adatbázisok másolása más kiszolgálókra
Adatbázis leválasztása és csatolása (SQL Server)
Átállás egy másodlagos log shipping szerverre (SQL Server)
Szerepkörváltás adatbázis-tükrözési munkamenet (SQL Server) során
Titkosított tüköradatbázis beállítása
SQL Server Configuration Manager
Árva felhasználók (SQL Server) hibaelhárítása
Migrálás új telepítésreMigrálás – áttekintés: SQL Serverről SQL Serverre Azure-beli virtuális gépeken

  • Last updated on