Megosztás:

Csak olvasható teher áthelyezése egy Always On rendelkezésre állási csoport szekunder replikájára

A következőkre vonatkozik:SQL Server

Az Always On rendelkezésre állási csoportok aktív másodlagos képességei közé tartozik egy vagy több másodlagos replikához (olvasható másodlagos replikákhoz) való írásvédett hozzáférés támogatása. Az olvasható másodlagos replikák lehetnek szinkron véglegesítési módban, vagy aszinkron véglegesítési módban elérhetők. Az olvasható másodlagos replika csak olvasható hozzáférést tesz lehetővé az összes másodlagos adatbázishoz. Az olvasható másodlagos adatbázisok azonban nincsenek olvasásra kijelölve. Dinamikusak. Egy adott másodlagos adatbázis módosul, mivel a rendszer a megfelelő elsődleges adatbázis módosításait alkalmazza a másodlagos adatbázisra. Egy tipikus másodlagos replika esetében a másodlagos adatbázisokban lévő adatok , beleértve a tartós memóriaoptimalizált táblákat is, közel valós idejűek. Emellett a rendszer szinkronizálja a teljes szöveges indexeket a másodlagos adatbázisokkal. Az elsődleges adatbázis és a megfelelő másodlagos adatbázis közötti adatkésés sok esetben csak néhány másodperc.

Az elsődleges adatbázisokban előforduló biztonsági beállítások megmaradnak a másodlagos adatbázisokban. Ide tartoznak a felhasználók, az adatbázisszerepkörök és az alkalmazásszerepkörök a megfelelő engedélyekkel és transzparens adattitkosítással (TDE) együtt, ha engedélyezve van az elsődleges adatbázisban.

Megjegyzés:

Bár nem tud adatokat írni másodlagos adatbázisokba, írás-olvasási adatbázisokba írhat a másodlagos replikát üzemeltető kiszolgálópéldányon, beleértve a felhasználói adatbázisokat és a rendszeradatbázisokat, például a tempdb-t.

Az Always On rendelkezésre állási csoportok támogatják az olvasási szándékú kapcsolatkérések újrairányítását egy másodlagos olvasható másolatra (csak olvasható útválasztás). A csak olvasható útválasztásról további információt a Figyelő használata Read-Only másodlagos replikához (Read-Only útválasztás) című témakörben talál.

Előnyök

A csak olvasható kapcsolatok írásvédett másodlagos replikákhoz való irányítása a következő előnyöket nyújtja:

  • Áthelyezi a másodlagos, írásvédett munkaterheléseket az elsődleges replikából, lehetővé téve, hogy az erőforrásait a kritikus fontosságú munkaterhelésekhez őrizze meg. Ha kritikus fontosságú olvasási számítási feladatokkal rendelkezik, vagy olyan számítási feladatokkal rendelkezik, amelyek nem tolerálják a késést, akkor azt az elsődleges helyen kell futtatnia.

  • Javítja az olvasható másodlagos replikákat üzemeltető rendszerek megtérülését.

Az olvasható másodlagos fájlok emellett robusztus támogatást nyújtanak az írásvédett műveletekhez az alábbiak szerint:

  • Az olvasásra optimalizált másodlagos adatbázis automatikus ideiglenes statisztikái optimalizálják a csak olvasási lekérdezéseket a lemezalapú táblákon. A memóriaoptimalizált táblák esetében a hiányzó statisztikák automatikusan létrejönnek. Az elavult statisztikák automatikus frissítése azonban nem történik meg. Manuálisan kell frissítenie az elsődleges replika statisztikáit. További információt a jelen témakör későbbi, Read-Only Access-adatbázisok statisztikái című témakörben talál.

  • A lemezalapú táblák írásvédett számítási feladatai sorverzióval távolítják el a másodlagos adatbázisok blokkolási versengését. A másodlagos adatbázisokon futó összes lekérdezés automatikusan pillanatkép-elkülönítési tranzakciószintre van leképezve, még akkor is, ha más tranzakcióelkülönítési szintek explicit módon vannak beállítva. Emellett az összes zárolási utasítás figyelmen kívül marad. Ez megszünteti az olvasói/írói versengést.

  • A memóriaoptimalizált tartós táblák írásvédett számítási feladatai pontosan ugyanúgy férnek hozzá az adatokhoz, mint az elsődleges adatbázisban, natív tárolt eljárásokkal vagy az SQL-együttműködéssel azonos tranzakcióelkülönítési szintű korlátozásokkal (lásd az adatbázismotor elkülönítési szintjeit). Az elsődleges replikán futó riportok vagy csak olvasható lekérdezések módosítás nélkül futtathatók a másodlagos replikán. Hasonlóképpen, a másodlagos replikán futó jelentéskészítési feladatok vagy írásvédett lekérdezések módosítás nélkül futhatnak az elsődleges replikán. A lemezalapú táblákhoz hasonlóan a másodlagos adatbázisokon futó összes lekérdezés automatikusan pillanatkép-elkülönítési tranzakciószintre van leképezve, még akkor is, ha más tranzakcióelkülönítési szintek explicit módon vannak beállítva.

  • A DML-műveletek végrehajthatók a táblaváltozókon másodlagos replikán, mind lemezalapú, mind memóriaoptimalizált táblatípusok esetén.

A rendelkezésre állási csoport előfeltételei

  • Olvasható másodlagos replikák (kötelező)

    Az adatbázis-rendszergazdának egy vagy több replikát kell konfigurálnia, hogy a másodlagos szerepkörben való futtatáskor engedélyezhesse az összes kapcsolatot (csak írásvédett hozzáféréshez), vagy csak olvasási szándékú kapcsolatokat.

    Megjegyzés:

    Az adatbázis-rendszergazda konfigurálhatja bármelyik rendelkezésre állási replikát úgy, hogy kizárja az írásvédett kapcsolatokat, amikor az elsődleges szerepkörben fut.

    További információ: Tudnivalók az ügyfélkapcsolat rendelkezésre állási replikákhoz való hozzáféréséről (SQL Server).

    Figyelmeztetés

    Csak azok a replikák lesznek olvashatók, amelyek az SQL Server ugyanazon fő buildjén találhatók. További információkért tekintse meg a működés közbeni frissítés alapjait .

  • Rendelkezésre állási csoport figyelője

    Az írásvédett útválasztás támogatásához a rendelkezésre állási csoportnak rendelkeznie kell egy rendelkezésre állási csoport figyelőjével. Az csak olvasható ügyfélnek a figyelőhöz kell irányítania a kapcsolati kéréseit, az ügyfél kapcsolati sztringjének pedig "csak olvashatóként" kell megadnia az alkalmazás szándékát. Vagyis olvasási szándékú kapcsolatkéréseknek kell lenniük.

  • Csak olvasható útválasztás

    Az írásvédett útválasztás azt jelenti, hogy az SQL Server képes a bejövő olvasási szándékú kapcsolatkéréseket egy rendelkezésre állási csoport figyelőjének átirányítani egy elérhető olvasható másodlagos replikára. Az írásvédett útválasztás előfeltételei a következők:

    • Az írásvédett útválasztás támogatásához egy olvasható másodlagos replikának írásvédett útválasztási URL-címre van szüksége. Ez az URL-cím csak akkor lép érvénybe, ha a helyi replika a másodlagos szerepkör alatt fut. Az írásvédett útválasztási URL-címet szükség szerint egyenként, replikánként kell megadni. Minden egyes írásvédett útválasztási URL-címet az olvasási szándékú kapcsolatkérések adott olvasható másodlagos replikához történő irányításhoz használják. Általában minden olvasható másodlagos replikához írásvédett útválasztási URL-cím tartozik.

    • Az egyes rendelkezésre állási replikák, amelyek az írásvédett útválasztást támogatják, amikor elsődleges replikaként szolgálnak, írásvédett útválasztási listát igényelnek. Egy adott írhatatlan útválasztási lista csak akkor lép érvénybe, ha a helyi replika elsődleges szerepben fut. Ezt a listát szükség szerint replika alapján kell megadni. Általában minden csak olvasható útválasztási lista minden csak olvasható útválasztási URL-címet tartalmaz, a helyi replika URL-címét pedig a lista végén.

      Megjegyzés:

      Az olvasási szándékú kapcsolatkérések a replikák közötti terheléselosztással kiegyensúlyozottak lehetnek. További információ: Terheléselosztás konfigurálása írásvédett replikák között.

    További információért, lásd: Read-Only útvonaltervezés konfigurálása egy rendelkezésre állási csoporthoz (SQL Server)

Megjegyzés:

A rendelkezésre állási csoport figyelőiről és a csak olvasható útválasztásról további információt a Rendelkezésre állási csoport figyelők, ügyfélkapcsolatok és alkalmazás-feladatátvitel (SQL Server) című témakörben talál.

Korlátozások és korlátozások

Egyes műveletek nem támogatottak teljes mértékben az alábbiak szerint:

  • Amint egy olvasható replika engedélyezve van az olvasáshoz, megkezdheti a másodlagos adatbázisokkal való kapcsolatok elfogadását. Ha azonban aktív tranzakciók léteznek egy elsődleges adatbázisban, a sorverziók nem lesznek teljes mértékben elérhetők a megfelelő másodlagos adatbázisban. A másodlagos replika konfigurálásakor az elsődleges replikán meglévő aktív tranzakcióknak véglegesíteni vagy vissza kell állítaniuk azokat. A folyamat befejezéséig a másodlagos adatbázis tranzakcióelkülönítési szintje hiányos, és a lekérdezések ideiglenesen le lesznek tiltva.

    Figyelmeztetés

    A hosszú tranzakciók futtatása hatással van a tárolt verziószámozott sorok számára, mind a lemezalapú, mind a memóriaoptimalizált táblák esetében.

  • A memóriaoptimalizált táblákkal rendelkező másodlagos adatbázisokban, bár a sorverziók mindig memóriaoptimalizált táblákhoz jönnek létre, a lekérdezések mindaddig le lesznek tiltva, amíg az elsődleges replikában lévő összes aktív tranzakció be nem fejeződik, amikor a másodlagos replika olvasásra lett engedélyezve. Ez biztosítja, hogy a lemezalapú és a memóriaoptimalizált táblák egyszerre legyenek elérhetők a jelentéskészítési számítási feladat és az írásvédett lekérdezések számára.

  • A változáskövetés és a változásadat-rögzítés nem támogatott az olvasható másodlagos replikához tartozó másodlagos adatbázisokban:

    • A változáskövetés kifejezetten le van tiltva a másodlagos adatbázisokban.

    • Az adatrögzítés módosítása nem engedélyezhető csak másodlagos replikaadatbázison. A módosítási adatrögzítés engedélyezhető az elsődleges replika-adatbázisban, és a módosítások a CDC-táblákból olvashatók a másodlagos replikaadatbázis függvényeivel.

  • Mivel az olvasási műveletek pillanatkép-elkülönítési tranzakciószintre vannak leképezve, az elsődleges replika szellemrekordjainak törlését egy vagy több másodlagos replikán végzett tranzakciók blokkolhatják. A ghost record cleanup feladat automatikusan törli a lemezalapú táblák szellemrekordjait az elsődleges replikán, ha már nincs rájuk szükség másodlagos replika számára. Ez hasonló ahhoz, amit akkor tesz, amikor tranzakció(ka)t futtat az elsődleges replikán. Szélsőséges esetben a másodlagos adatbázison meg kell szakítania egy hosszú ideig futó olvasási lekérdezést, amely akadályozza a szellem-tisztítás végrehajtását. Vegye figyelembe, hogy a szellemtisztaság blokkolható, ha a másodlagos replika le van választva, vagy ha az adatáthelyezés fel van függesztve a másodlagos adatbázisban. A szellemrekordok fizikai helyet használnak egy adatfájlban, ez a hely újrafelhasználásával kapcsolatos problémákat okozhat. További információért tekintse meg a szellemek törlését . Ez az állapot a napló csonkolását is megakadályozza, ezért ha ez az állapot továbbra is fennáll, javasoljuk, hogy távolítsa el ezt a másodlagos adatbázist a rendelkezésre állási csoportból. A memóriaoptimalizált táblák esetében nem jelentkezik probléma a fantomrekordok törlésével, mivel a sorverziók a memóriában maradnak, és függetlenek az elsődleges replika sorverzióitól.

  • A lemezalapú táblákat tartalmazó fájlok DBCC SHRINKFILE művelete meghiúsulhat az elsődleges replikán, ha a fájl olyan szellemrekordokat tartalmaz, amelyekre még szükség van egy másodlagos replikán.

  • Az SQL Server 2014 -től (12.x) kezdődően az olvasható másodlagos replikák akkor is online állapotban maradhatnak, ha az elsődleges replika offline állapotban van felhasználói művelet vagy hiba miatt, például egy felhasználói parancs vagy hiba miatt felfüggesztették a szinkronizálást, vagy a replika a WSFC offline állapotának köszönhetően feloldja az állapotot. Azonban a csak olvasható útválasztás ebben a helyzetben nem működik, mert a rendelkezésre állási csoport figyelője is offline van. Az ügyfeleknek közvetlenül kell csatlakozniuk az írásvédett számítási feladatok írásvédett másodlagos replikáihoz.

Megjegyzés:

Ha lekérdezi a sys.dm_db_index_physical_stats dinamikus felügyeleti nézetet egy olvasható másodlagos replikát futtató kiszolgálópéldányon, reDO blokkolási problémát tapasztalhat. Ennek az az oka, hogy ez a dinamikus felügyeleti nézet egy IS-zárolást szerez be a megadott felhasználói táblára vagy nézetre, amely blokkolhatja az adott felhasználói tábla vagy nézet X-zárolásához tartozó REDO-szál kéréseit.

Teljesítménnyel kapcsolatos szempontok

Ez a szakasz az olvasható másodlagos adatbázisok teljesítményével kapcsolatos számos szempontot tárgyal

Ebben a szakaszban:

Adatkésés

A másodlagos replikák írásvédett hozzáférésének megvalósítása akkor hasznos, ha az írásvédett számítási feladatok képesek némi adatkésést elviselni. Olyan esetekben, amikor az adatkésés elfogadhatatlan, érdemes lehet írásvédett számítási feladatokat futtatni az elsődleges replikán.

Az elsődleges replika naplórekordokat küld az elsődleges adatbázis változásairól a másodlagos replikáknak. Minden másodlagos adatbázisban egy dedikált ismétlési szál alkalmazza a naplórekordokat. Olvasási hozzáférésű másodlagos adatbázisban egy adott adatváltozás csak akkor jelenik meg a lekérdezési eredményekben, ha a módosítást tartalmazó naplórekordot alkalmazták a másodlagos adatbázisra, és a tranzakciót az elsődleges adatbázisban véglegesítették.

Ez azt jelenti, hogy az elsődleges és a másodlagos replikák között van némi késés, általában csak másodpercek kérdése. Szokatlan esetekben azonban, például ha a hálózati problémák csökkentik az átviteli sebességet, a késés jelentős lehet. A késleltetés nő, amikor I/O-szűk keresztmetszetek jelentkeznek, és amikor az adatmozgás fel van függesztve. A felfüggesztett adatáthelyezés figyeléséhez használhatja az Always On irányítópultot vagy a sys.dm_hadr_database_replica_states dinamikus felügyeleti nézetet.

Adatkésés memóriaoptimalizált táblákkal rendelkező adatbázisokon

Az SQL Server 2014-ben (12.x) az aktív másodpéldányok adatkésésével kapcsolatban speciális szempontokat is figyelembe vettek – lásd: SQL Server 2014 (12.x) Active Secondaries: Readable Secondary Replicas. Az SQL Server 2016 (13.x) indításakor nincs különös tekintettel a memóriaoptimalizált táblák adatkésésére. A memóriaoptimalizált táblák várható adatkésése összehasonlítható a lemezalapú táblák késésével.

Read-Only Munkaterhelés hatása

Ha másodlagos replikát konfigurál írásvédett hozzáférésre, a másodlagos adatbázisok írásvédett számítási feladatai rendszererőforrásokat használnak fel, például a processzort és az I/O-t (lemezalapú táblákhoz) az ismétlési szálakból, különösen akkor, ha a lemezalapú táblák írásvédett számítási feladatai magas I/O-igényesek. A memóriaoptimalizált táblák elérésekor nincs I/O-hatás, mert az összes sor a memóriában található.

Emellett a másodlagos replikák írásvédett számítási feladatai blokkolhatják a naplórekordokon keresztül alkalmazott adatdefiníciós nyelv (DDL) módosításait.

  • Annak ellenére, hogy az olvasási műveletek nem fogadnak el megosztott zárolásokat a sorverziók miatt, ezek a műveletek sémastabilitási (Sch-S) zárolásokat vesznek igénybe, amelyek blokkolhatják a DDL-módosításokat alkalmazó újraműveleteket. A DDL-műveletek magukban foglalják az ALTER/DROP táblákat és nézeteket, de nem a tárolt eljárások DROP vagy ALTER műveletét. Ha például egy lemezes vagy memória optimalizált táblát töröl az elsődlegesből. Amikor a REDO-szál feldolgozza a naplórekordot a tábla elvetéséhez, SCH_M zárolást kell szereznie a táblán, és egy futó, a táblához hozzáférő lekérdezés blokkolhatja. Ez ugyanaz a viselkedés az elsődleges replikán, azzal a különbséggel, hogy a tábla törlése egy felhasználói munkamenet részeként történik, és nem a REDO szál részeként.

  • További blokkolási Memory-Optimized táblák is találhatók. A natív tárolt eljárás törlése blokkolhatja a REDO szálat, ha a másodlagos replikán a natív tárolt eljárás egyidejűleg fut. Ez ugyanaz a viselkedés az elsődleges replikán, azzal a különbségtel, hogy a tárolt eljárás elvetése egy felhasználói munkamenet részeként történik, és nem a REDO szál.

Vegye figyelembe a lekérdezések készítésének ajánlott eljárásait, és gyakorolja ezeket az ajánlott eljárásokat a másodlagos adatbázisokban. Ütemezze például a hosszú ideig futó lekérdezéseket, például az adatok összesítését alacsony tevékenység idején.

Megjegyzés:

Ha egy másodlagos replikán lévő lekérdezések blokkolják a redo szálat, az XEvent sqlserver.lock_redo_blocked generálódik.

Indexelés

Az olvasható másodlagos replikák írásvédett számítási feladatainak optimalizálásához érdemes lehet indexeket létrehozni a másodlagos adatbázisok tábláiban. Mivel nem végezhet sémát vagy adatmódosításokat a másodlagos adatbázisokon, hozzon létre indexeket az elsődleges adatbázisokban, és engedélyezze a módosítások átvitelét a másodlagos adatbázisba az ismétlési folyamaton keresztül.

Ha egy másodlagos replikán szeretné monitorozni az indexhasználati tevékenységet, kérdezze le a sys.dm_db_index_usage_stats dinamikus felügyeleti nézet user_seeks, user_scans és user_lookups oszlopait.

Az Read-Only Access-adatbázisok statisztikái

A táblák és indexelt nézetek oszlopainak statisztikái a lekérdezéstervek optimalizálására szolgálnak. Rendelkezésre állási csoportok esetén az elsődleges adatbázisokon létrehozott és karbantartott statisztikák automatikusan megmaradnak a másodlagos adatbázisokon a tranzakciónapló-rekordok alkalmazásának részeként. A másodlagos adatbázisok írásvédett számítási feladatainak azonban más statisztikákra lehet szükségük, mint az elsődleges adatbázisokban létrehozottak. Mivel azonban a másodlagos adatbázisok írásvédett hozzáférésre vannak korlátozva, a másodlagos adatbázisokon nem hozhatók létre statisztikák.

A probléma megoldásához a másodlagos replika ideiglenes statisztikákat hoz létre és tart fenn a tempdb másodlagos adatbázisaihoz. A _readonly_database_statistic utótag hozzá van fűzve az ideiglenes statisztikák nevéhez, hogy megkülönböztesse őket az elsődleges adatbázisból megmaradó állandó statisztikáktól.

Csak az SQL Server hozhat létre és frissíthet ideiglenes statisztikákat. Az ideiglenes statisztikákat azonban törölheti, és a tulajdonságokat az állandó statisztikákhoz használt eszközökkel figyelheti:

  • Ideiglenes statisztikák törlése a DROP STATISTICS Transact-SQL utasítással.

  • Statisztikák monitorozása a sys.stats és sys.stats_columns katalógusnézetek használatával. sys_stats tartalmaz egy is_temporary oszlopot, amely jelzi, hogy mely statisztikák állandóak és melyek ideiglenesek.

Az elsődleges vagy másodlagos replikán a memóriaoptimalizált táblák automatikus statisztikáinak frissítése nem támogatott. Figyelnie kell a másodlagos replika lekérdezési teljesítményét és terveit, és szükség esetén manuálisan frissítenie kell az elsődleges replika statisztikáit. A hiányzó statisztikák azonban automatikusan létrejönnek az elsődleges és a másodlagos replikán is.

Az SQL Server statisztikáiról további információt a Statisztika című témakörben talál.

Ebben a szakaszban:

Elöregedett állandó statisztikák másodlagos adatbázisokban

Az SQL Server észleli, ha egy másodlagos adatbázis állandó statisztikái elavultak. Az állandó statisztikákon azonban csak az elsődleges adatbázis módosításain keresztül lehet módosításokat végrehajtani. A lekérdezésoptimalizáláshoz az SQL Server ideiglenes statisztikákat hoz létre a másodlagos adatbázis lemezalapú tábláihoz, és ezeket a statisztikákat használja az elavult állandó statisztikák helyett.

Amikor az elsődleges adatbázis állandó statisztikái frissülnek, azok automatikusan megmaradnak a másodlagos adatbázisban. Ezután az SQL Server a frissített állandó statisztikákat használja, amelyek aktuálisabbak az ideiglenes statisztikáknál.

Ha a rendelkezésre állási csoport meghiúsul, a rendszer az összes másodlagos replikán törli az ideiglenes statisztikákat.

Korlátozások és korlátozások

  • Mivel az ideiglenes statisztikákat a tempdb tárolja, az SQL Server szolgáltatás újraindítása miatt az összes ideiglenes statisztika eltűnik.

  • A _readonly_database_statistic utótag az SQL Server által létrehozott statisztikák számára van fenntartva. Ezt az utótagot nem használhatja elsődleges adatbázis statisztikáinak létrehozásakor. További információ: Statisztika.

Memóriaoptimalizált táblák elérése másodlagos replikán

A másodlagos replikán a memóriaoptimalizált táblákkal használható tranzakcióelkülönítési szintek megegyeznek az elsődleges replikával. A javaslat az, hogy a munkamenetszintű elkülönítési szintet a READ COMMITTED értékre állítsa, és az adatbázisszintű beállítást pedig a MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT BE állítsa. Például:

ALTER DATABASE CURRENT SET MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT=ON  
GO  
SET TRANSACTION ISOLATION LEVEL READ COMMITTED  
GO  
SELECT SUM(UnitPrice*OrderQty)   
FROM Sales.SalesOrderDetail_inmem  
GO

Kapacitástervezési szempontok

  • Lemezalapú táblák esetén az olvasható másodlagos replikák két okból igényelhetnek helyet a tempdb-ben :

    • A pillanatkép-elkülönítési szint a sorverziókat a tempdb fájlba másolja.

    • A másodlagos adatbázisok ideiglenes statisztikáit a tempdb hozza létre és tartja karban. Az ideiglenes statisztikák a tempdb méretének enyhe növekedését okozhatják. További információkért tekintse meg a Read-Only Access-adatbázisok statisztikáit a szakasz későbbi részében.

  • Ha egy vagy több másodlagos replika olvasási hozzáférését konfigurálja, az elsődleges adatbázisok 14 bájtnyi többletterhelést adnak hozzá a törölt, módosított vagy beszúrt adatsorokhoz, hogy a meghajtóalapú táblák másodlagos adatbázisainak sorverzióira mutató mutatókat tároljanak. Ez a 14 bájtos többletterhelés a másodlagos adatbázisokba kerül. Mivel a 14 bájtos többletterhelés hozzáadódik az adatsorokhoz, oldaleloszlások is előfordulhatnak.

    A sorverzió adatait nem az elsődleges adatbázisok generálják. Ehelyett a másodlagos adatbázisok generálják a sorverziókat. A sorverziós verziószámozás azonban növeli az elsődleges és a másodlagos adatbázisok adattárolását.

    A sorverzió adatainak hozzáadása az elsődleges adatbázis pillanatkép-elkülönítésétől vagy az írásvédett pillanatkép-elkülönítési (RCSI) szint beállításától függ. Az alábbi táblázat egy olvasható másodlagos adatbázis verziószámozásának viselkedését ismerteti a lemezalapú táblák különböző beállításai között.

    Olvasható másodlagos másolat? A pillanatkép-izolálás vagy az RCSI izolálási szint engedélyezve van? Elsődleges adatbázis Másodlagos adatbázis
    Nem Nem Nincs sorverzió vagy 14 bájtos többletterhelés Nincs sorverzió vagy 14 bájtos többletterhelés
    Nem Igen Sorverziók és 14 bájtos többletterhelés Nincsenek sorverziók, de 14 bájtos többletterhelés
    Igen Nem Nincsenek sorverziók, de 14 bájtos többletterhelés Sorverziók és 14 bájtos többletterhelés
    Igen Igen Sorverziók és 14 bájtos többletterhelés Sorverziók és 14 bájtos többletterhelés

Kapcsolódó tevékenységek

Kapcsolódó tartalom

Lásd még:

Az "Always On" rendelkezésre állási csoportok (SQL Server) áttekintése
Az ügyfélkapcsolat rendelkezésre állási replikákhoz való hozzáféréséről (SQL Server)
Rendelkezésre állási csoport figyelők, Ügyfélkapcsolatok és Alkalmazás-feladatátvitel (SQL Server)
Statisztika

  • Last updated on