OLE DB-drivrutin för SQL Server för stöd för hög tillgänglighet, katastrofåterställning

Gäller för:SQL ServerAzure SQL DatabaseAzure SQL Managed InstanceAzure Synapse AnalyticsAnalysplattformssystem (PDW)SQL-databas i Microsoft Fabric

Ladda ned OLE DB-drivrutins

Den här artikeln diskuterar OLE DB-drivrutin för SQL Server-stöd för Always On-tillgänglighetsgrupper. För mer information om Always On-tillgänglighetsgrupper, se Tillgänglighetsgrupplyssnare, Klientanslutning och applikationsfailover (SQL Server),Skapande och konfiguration av tillgänglighetsgrupper (SQL Server),Failover-klustring och Always On-tillgänglighetsgrupper (SQL Server) samt Aktiva sekundäraries: läsbara sekundära repliker (Always On tillgänglighetsgrupper).

Du kan ange tillgänglighetsgruppens lyssnare för en given tillgänglighetsgrupp i anslutningssträngen. Om en OLE DB-drivrutin för SQL Server-applikation är ansluten till en databas i en tillgänglighetsgrupp som failover, bryts den ursprungliga anslutningen och applikationen måste öppna en ny anslutning för att fortsätta arbetet efter failovern.

Om du inte ansluter till en tillgänglighetsgrupplyssnare, och om flera IP-adresser är kopplade till ett värdnamn, kommer OLE DB-drivrutinen för SQL Server att iterera sekventiellt genom alla IP-adresser kopplade till DNS-posten. Detta kan ta tid om den första IP-adressen som returneras av DNS-servern inte är bunden till något nätverkskort (NIC). När man ansluter till en tillgänglighetsgruppslyssnare försöker OLE DB-drivrutinen för SQL Server etablera anslutningar till alla IP-adresser parallellt, och om ett anslutningsförsök lyckas kommer drivrutinen att kassera alla väntande anslutningsförsök.

Anmärkning

Att öka anslutningstidsgränsen och implementera logik för återuppkoppling ökar sannolikheten att en applikation ansluter till en tillgänglighetsgrupp. Eftersom en anslutning kan misslyckas på grund av en tillgänglighetsgrupp-failover, bör du implementera logik för återuppkoppling av anslutningen, där du försöker om en misslyckad anslutning tills den ansluter igen.

Anslutning med MultiSubnetFailover

Ange alltid MultiSubnetFailover=Yes när målet är Azure SQL Database, Azure SQL Managed Instance, SQL database i Microsoft Fabric, en Always On tillgänglighetsgrupplyssnare eller en SQL Server failover-klusterinstans.

När servernamnet i din reťazec pripojenia upplöses till mer än en IP-adress, säger MultiSubnetFailover=Yes åt OLE DB Driver for SQL Server att öppna anslutningar till alla dessa adresser samtidigt och använda den första som svarar. Utan den försöker föraren adresserna en i taget. En adress som inte svarar stannar tills operativsystemets TCP-anslutningstidsavbrott löper ut, vilket kan förbruka anslutningstiden innan drivrutinen når en adress som svarar. Efter en failover kan adressen som drivrutinen först försöker vara en som inte längre tjänar databasen, så en anslutning som skulle lyckas mot en annan adress misslyckas med en timeout istället.

MultiSubnetFailover=Ja ändrar hur snabbt klienten hittar repliken som betjänar databasen. Det förändrar inte hur lång tid servern tar att failovera.

MultiSubnetFailover=Ja, är säkert på enskilda IP-mål. När DNS löses till en enda adress gör drivrutinen ett enda anslutningsförsök, så inställningen kostar ingenting när den inte behövs.

För mer information om anslutningssträngsnyckelord, se Användning av anslutningssträngsnyckelord med OLE DB-drivrutin för SQL Server.

Använd följande riktlinjer för att ansluta till en server i en tillgänglighetsgrupp eller Failover Cluster Instance:

  • Sätt MultiSubnetFailover-anslutningsegenskapen till Ja.

  • För att ansluta till en tillgänglighetsgrupp, ange tillgänglighetsgruppens lyssnare för tillgänglighetsgruppen som servern i din anslutningssträng.

  • Du kan inte använda MultiSubnetFailover över ett annat protokoll än TCP.

  • Anslutning till en SQL Server-instans konfigurerad med mer än 64 IP-adresser orsakar anslutningsfel.

  • Du kan inte använda MultiSubnetFailover med databasspegling. Drivrutinen ger ett felmeddelande när servern rapporterar att databasen är speglad. Databasspegling är föråldrad i alla stödda versioner av SQL Server. Använd AlwaysOn-tillgänglighetsgrupper i stället.

  • Typen av autentisering, SQL Server-autentisering, Kerberos-autentisering eller Windows-autentisering, påverkar inte beteendet hos en applikation som använder MultiSubnetFailover-anslutningsegenskapen.

  • Du kan öka värdet på Connect Timeout för att hantera failover-tid och minska försök till återanslutning i applikationer. Standardvärdet är 15 sekunder. Samma inställning heter Timeout när du ställer in den genom IDBInitialize::Initialize, och den mappas till egenskapen DBPROP_INIT_TIMEOUT . För Azure SQL Database serverless med auto-paus aktiverad, använd en Connect Timeout på minst 60 sekunder. En automatiskt pausad databas återupptas vid första anslutningsförsöket, och det försöket kan misslyckas med fel 40613 medan databasen återupptas, så applikationen måste försöka igen. Mer information finns i Automatisk paus och automatisk återupptagning.

  • Distribuerade transaktioner stöds inte.

Om skrivskyddad routning inte gäller misslyckas anslutningen till en sekundär replikplats i en tillgänglighetsgrupp i följande situationer:

  1. Om den sekundära replikplatsen inte är konfigurerad för att acceptera anslutningar.
  2. Om en applikation använder ApplicationIntent=ReadWrite och den sekundära replikplatsen är konfigurerad för skrivskyddad åtkomst.

En anslutning misslyckas om en primär replika är konfigurerad att avvisa skrivskyddade arbetsbelastningar och reťazec pripojenia innehåller ApplicationIntent=ReadOnly.

Uppgradering från databasspegling

Ett anslutningsfel uppstår om reťazec pripojenia innehåller både MultiSubnetFailover och Failover_Partner nyckelord. Ett fel uppstår också om du använder MultiSubnetFailover och SQL Server returnerar ett failover-partnersvar som indikerar att det är en del av ett databasspeglingspar.

Om du uppgraderar en OLE DB Driver for SQL Server-applikation som för närvarande använder databas-spegling till ett multi-subnet-scenario, ta bort egenskapen Failover_Partner connection och ersätt den med MultiSubnetFailover inställd på Ja. Byt ut servernamnet i reťazec pripojenia med en tillgänglighetsgrupplyssnare. Om en reťazec pripojenia använder Failover_Partner och MultiSubnetFailover=Ja, genererar drivrutinen ett fel. Om en reťazec pripojenia använder Failover_Partner och MultiSubnetFailover=No (eller ApplicationIntent=ReadWrite), använder applikationen databasspegling.

Drivrutinen ger ett felmeddelande om du använder databasspegelning på primärkopian i tillgänglighetsgruppen, och om du använder MultiSubnetFailover=Yes i reťazec pripojenia som ansluter till en primär replik istället för till en tillgänglighetsgrupplyssnare.

Sätt MultiSubnetFailover programmatiskt

De ekvivalenta anslutningsegenskaperna är:

  • SSPROP_INIT_MULTISUBNETFAILOVER
  • DBPROP_INIT_PROVIDERSTRING

En OLE DB Driver for SQL Server-applikation kan använda en av följande metoder för att ställa in MultiSubnetFailover-alternativet:

  • IDBInitialize::Initialize
    Använder den tidigare konfigurerade uppsättningen egenskaper för att initiera datakällan och skapa datakällobjektet. Ange MultiSubnetFailover som en leverantörsegenskap eller som en del av den utökade egenskapssträngen.
  • IDataInitialize::GetDataSource
    Tar en inmatnings-reťazec pripojenia som kan innehålla nyckelordet MultiSubnetFailover.
  • IDBProperties::SetProperties
    För att sätta MultiSubnetFailover-egenskapsvärdet, anropa IDBProperties::SetProperties som skickar in SSPROP_INIT_MULTISUBNETFAILOVER-egenskapen med värdet VARIANT_TRUE eller VARIANT_FALSE, eller DBPROP_INIT_PROVIDERSTRING-egenskapen med värdet som innehåller MultiSubnetFailover=Yes eller MultiSubnetFailover=No.

Example

DBPROP rgPropMultisubnet;

rgPropMultisubnet.dwPropertyID = SSPROP_INIT_MULTISUBNETFAILOVER;
rgPropMultisubnet.dwOptions = DBPROPOPTIONS_REQUIRED;
rgPropMultisubnet.dwStatus = DBPROPSTATUS_OK;
rgPropMultisubnet.colid = DB_NULLID;
V_VT(&(rgPropMultisubnet.vValue)) = VT_BOOL;
V_BOOL(&(rgPropMultisubnet.vValue)) = VARIANT_TRUE;

DBPROPSET PropSet;

PropSet.rgProperties = &rgPropMultisubnet;
PropSet.cProperties = 1;
PropSet.guidPropertySet = DBPROPSET_SQLSERVERDBINIT;
IDBProperties* pIDBProperties = NULL;
hr = pIDBInitialize->QueryInterface(IID_IDBProperties, (void **)&pIDBProperties);
pIDBProperties->SetProperties(1, &PropSet);

Specificera applikationens avsikt

Du kan ange nyckelordet ApplicationIntent i din anslutningssträng. De tilldelbara värdena är ReadWrite (standardvärdena) eller ReadOnly.

När du sätter ApplicationIntent=ReadOnly, begär klienten en läsarbetsbelastning vid anslutning. Servern upprätthåller avsikten vid anslutningstidpunkten och under en USE databassats.

Nyckelordet ApplicationIntent fungerar inte med äldre skrivskyddade databaser.

Mål för ReadOnly

När en anslutning väljer ReadOnly, tilldelas anslutningen någon av följande speciella konfigurationer som kan finnas för databasen:

  • Alltid på. En databas kan tillåta eller avvisa läsarbetsbelastningar på den avsedda tillgänglighetsgruppens databas. Detta val styrs genom att använda ALLOW_CONNECTIONS klausulen i PRIMARY_ROLE och SECONDARY_ROLE Transact-SQL-satserna.

  • Geo-replication

  • Lässkalbarhet

Om inga av dessa specialmål finns tillgängliga läses den vanliga databasen från.

Nyckelordet ApplicationIntent möjliggör skrivskyddad routing.

Skrivskyddad routing

Skrivskyddad routning är en funktion som kan säkerställa tillgången till en skrivskyddad kopia av en databas. För att aktivera skrivskyddad routing gäller alla följande:

  • Du måste koppla upp dig till en lyssnare i Always On-tillgänglighetsgruppen.

  • Nyckelordet för ApplicationIntent anslutningssträngen måste sättas till ReadOnly.

  • Databasadministratören måste konfigurera tillgänglighetsgruppen för att möjliggöra skrivskyddad routing.

Flera anslutningar som båda använder skrivskyddad routing kanske inte alla ansluter till samma skrivskyddade replik. Förändringar i databassynkronisering eller ändringar i serverns routningskonfiguration kan resultera i klientanslutningar till olika skrivskyddade repliker.

Du kan säkerställa att alla skrivskyddade förfrågningar ansluter till samma skrivskyddade replika genom att inte skicka en tillgänglighetsgrupplyssnare till anslutningssträngens Server nyckelord. Ange istället namnet på den skrivskyddade instansen.

Read-only-routing kan ta längre tid än att ansluta till primären. Detta beror på att read-only-routing först kopplas till primären och sedan letar efter den bästa tillgängliga läsbara sekundären. På grund av dessa flera steg bör du öka din login timeout till minst 30 sekunder.

ApplicationIntent

OLE DB Driver for SQL Server stöder nyckelordet ApplicationIntent reťazec pripojenia. För mer information om anslutningssträngsnyckelord, se Användning av anslutningssträngsnyckelord med OLE DB-drivrutin för SQL Server.

Sätt ApplicationIntent programmatiskt

De ekvivalenta anslutningsegenskaperna är:

  • SSPROP_INIT_APPLICATIONINTENT
  • DBPROP_INIT_PROVIDERSTRING

En OLE DB Driver for SQL Server-applikation kan använda en av följande metoder för att specificera applikationens avsikt:

  • IDBInitialize::Initialize
    Använder den tidigare konfigurerade uppsättningen egenskaper för att initiera datakällan och skapa datakällobjektet. Ange applikationsavsikt som en leverantörsegenskap eller som en del av den utökade egenskapssträngen.
  • IDataInitialize::GetDataSource
    Tar en input reťazec pripojenia som kan innehålla nyckelordet Application Intent.
  • IDBProperties::SetProperties
    För att sätta egenskapsvärdet ApplicationIntent , anropa IDBProperties::SetProperties som skickar in egenskapen SSPROP_INIT_APPLICATIONINTENT med värdet ReadWrite eller ReadOnly, eller egenskapen DBPROP_INIT_PROVIDERSTRING med värdet innehållande ApplicationIntent=ReadOnly eller ApplicationIntent=ReadWrite.

Du kan ange applikationsavsikt i fältet Application Intent Properties på fliken Alla i dialogrutan Data Link Properties .

När du etablerar implicita anslutningar använder den implicita anslutningen applikationsintention-inställningen för föräldraanslutningen. På samma sätt ärver flera sessioner skapade från samma datakälla datakällans applikationsintention-inställning.

Relaterat innehåll

  • Last updated on