Supporto di SQL Server Native Client per il ripristino di emergenza a disponibilità elevata

Si applica a: sìSQL Server (tutte le versioni supportate) Sìdatabase SQL di Azure SìIstanza gestita di SQL di Azure sìAzure Synapse Analytics sìParallel Data Warehouse

In questo argomento viene illustrato il supporto in SQL Server Native Client (aggiunto in SQL Server 2012 (11.x)) per Gruppi di disponibilità AlwaysOn. Per altre informazioni su Gruppi di disponibilità AlwaysOn, vedere Listener del gruppo di disponibilità, connettività client e failover dell’applicazione (SQL Server), Creazione e configurazione di gruppi di disponibilità (SQL Server), Clustering di failover e gruppi di disponibilità AlwaysOn (SQL Server) e Repliche secondarie attive: Repliche secondarie leggibili (Gruppi di disponibilità AlwaysOn).

È possibile specificare il listener di un determinato gruppo di disponibilità nella stringa di connessione. Se un'applicazione SQL Server Native Client è connessa a un database in un gruppo di disponibilità, la connessione originale viene interrotta e deve esserne aperta una nuova per l'applicazione affinché quest'ultima possa continuare a funzionare dopo il failover.

Se non si sta eseguendo la connessione a un listener del gruppo di disponibilità e se più indirizzi IP sono associati a un nome host, in SQL Server Native Client verranno scorsi in sequenza tutti gli indirizzi IP associati alla voce DNS. Questa operazione può richiedere tempi lunghi se il primo indirizzo IP restituito dal server DNS non è associato ad alcuna scheda di interfaccia di rete. In caso di connessione a un listener del gruppo di disponibilità, in SQL Server Native Client viene effettuato un tentativo di connessione a tutti gli indirizzi IP in parallelo e in caso di riuscita, tramite il driver verrà rimosso qualsiasi tentativo di connessione in sospeso.

Nota

L'aumento del timeout di connessione e l'implementazione della logica di riesecuzione per le connessioni aumentano le probabilità che un'applicazione si connetta a un gruppo di disponibilità. Inoltre, poiché potrebbe non essere possibile stabilire una connessione a causa del failover di un gruppo di disponibilità, è opportuno implementare la logica di riesecuzione delle connessioni, finché non si ottiene la riconnessione.

Connessione con MultiSubnetFailover

Specificare sempre MultiSubnetFailover=Yes in caso di connessione a un listener del gruppo di disponibilità di SQL Server 2012 o a un'istanza del cluster di failover di SQL Server 2012. MultiSubnetFailover consente un failover più veloce per tutti i gruppi di disponibilità e l'istanza del cluster di failover in SQL Server 2012 e riduce significativamente il tempo di failover per le topologie di always on a una o più subnet. Durante un failover su più subnet, verranno tentate connessioni in parallelo da parte del client. Durante un failover della subnet, in SQL Server Native Client verrà ritentata in modo insistente la connessione TCP.

La proprietà di connessione MultiSubnetFailover indica che l'applicazione viene distribuita in un gruppo di disponibilità o nell'istanza del cluster di failover e che in SQL Server Native Client verrà effettuato un tentativo di connessione al database nell'istanza di SQL Server primaria tramite la connessione a tutti gli indirizzi IP. Quando si specifica MultiSubnetFailover=Yes per una connessione, i ripetuti tentativi di connessione TCP del client vengono eseguiti più rapidamente rispetto agli intervalli di ritrasmissione TCP predefiniti del sistema operativo. Ciò consente una riconnessione più veloce dopo il failover di un gruppo di disponibilità Always On o di un'istanza del cluster di failover di Always On ed è applicabile sia ai gruppi di disponibilità a più subnet che alle istanze del cluster di failover.

Per altre informazioni sulle parole chiave della stringa di connessione, vedere Utilizzo delle parole chiave delle stringhe di connessione con SQL Server Native Client.

La specifica di MultiSubnetFailover=Yes durante la connessione a un oggetto diverso da un listener del gruppo di disponibilità o dall'istanza del cluster di failover non è supportata poiché potrebbe determinare un impatto negativo sulle prestazioni.

Utilizzare le linee guida seguenti per connettersi a un server in un gruppo di disponibilità o nell'istanza del cluster di failover:

  • Usare la proprietà di connessione MultiSubnetFailover in caso di connessione a una singola subnet o a più subnet, in modo da migliorare le prestazioni.

  • Per eseguire la connessione a un gruppo di disponibilità, specificare il listener del gruppo di disponibilità come server nella stringa di connessione.

  • La connessione a un'istanza di SQL Server configurata con più di 64 indirizzi IP determinerà un errore di connessione.

  • Il comportamento di un'applicazione in cui viene usata la proprietà di connessione MultiSubnetFailover non è influenzato dal tipo di autenticazione, cioè dall'autenticazione di SQL Server, dall'autenticazione Kerberos, o dall’autenticazione di Windows.

  • È possibile aumentare il valore di loginTimeout per adattarlo alla durata del failover e ridurre il numero di nuovi tentativi di connessione dell'applicazione.

  • Le transazioni distribuite non sono supportate.

Se il routing di sola lettura non è attivo, non è possibile stabilire una connessione a un percorso di replica secondaria in un gruppo di disponibilità nelle situazioni seguenti:

  1. Se il percorso di replica secondaria non è configurato per accettare le connessioni.

  2. Se un'applicazione usa ApplicationIntent=ReadWrite (vedere di seguito) e il percorso di replica secondaria è configurato per l'accesso in sola lettura.

Una connessione non riesce se una replica primaria è configurata per rifiutare i carichi di lavoro in sola lettura e la stringa di connessione contiene ApplicationIntent=ReadOnly.

Aggiornamento per l'utilizzo di cluster su più subnet dal mirroring del database

Si verificherà un errore di connessione se nella stringa di connessione sono presenti le parole chiave di connessione MultiSubnetFailover e Failover_Partner. Si verificherà un errore anche se viene usato MultiSubnetFailover e SQL Server restituisce una risposta del partner di failover in cui viene indicato che fa parte di una coppia del mirroring del database.

Se si aggiorna un'applicazione SQL Server Native Client che usa il mirroring del database in uno scenario su più subnet, è necessario rimuovere la proprietà di connessione Failover_Partner e sostituirla con MultiSubnetFailover impostata su Yes, nonché sostituire il nome del server nella stringa di connessione con un listener del gruppo di disponibilità. Se in una stringa di connessione vengono usati Failover_Partner e MultiSubnetFailover=Yes, il driver genererà un errore. Se tuttavia in una stringa di connessione vengono usati Failover_Partner e MultiSubnetFailover=No (o ApplicationIntent=ReadWrite), l'applicazione userà il mirroring del database.

Il driver restituirà un errore se il mirroring del database viene usato nel database primario nel gruppo di disponibilità e se MultiSubnetFailover=Yes veine usato nella stringa di connessione a un database primario anziché a un listener del gruppo di disponibilità.

Specificare la finalità dell'applicazione

È possibile specificare la parola ApplicationIntent chiave nella stringa di connessione. I valori assegnabili sono ReadWrite (impostazione predefinita) o ReadOnly .

Quando si imposta ApplicationIntent=ReadOnly , il client richiede un carico di lavoro di lettura durante la connessione. Il server applica la finalità in fase di connessione e durante USE un'istruzione del database.

La ApplicationIntent parola chiave non funziona con i database legacy di sola lettura.

Destinazioni di ReadOnly

Quando una connessione sceglie , la connessione viene assegnata a una delle configurazioni speciali seguenti che ReadOnly potrebbero esistere per il database:

  • Always On. Un database può consentire o impedire carichi di lavoro di lettura nel database Always On di destinazione. Questa scelta viene controllata usando la clausola delle istruzioni ALLOW_CONNECTIONS PRIMARY_ROLE SECONDARY_ROLE Transact-SQL e .

  • Replica geografica

  • Read scale-out (Scalabilità in lettura)

Se nessuna di queste destinazioni speciali è disponibile, viene letto il database normale.

La ApplicationIntent parola chiave abilita il routing di sola lettura.

Routing di sola lettura

Il routing di sola lettura è una funzionalità che può garantire la disponibilità di una replica di sola lettura di un database. Per abilitare il routing di sola lettura, si applicano tutte le condizioni seguenti:

  • È necessario connettersi a un listener Always On gruppo di disponibilità.

  • La parola chiave della stringa di connessione ApplicationIntent deve essere impostata su ReadOnly.

  • L'amministratore del database deve configurare il gruppo di disponibilità per abilitare il routing di sola lettura.

È possibile che più connessioni che usano il routing di sola lettura non si connettono tutte alla stessa replica di sola lettura. Le modifiche nella sincronizzazione del database o nella configurazione di routing del server possono comportare connessioni client a repliche di sola lettura diverse.

È possibile assicurarsi che tutte le richieste di sola lettura si connettono alla stessa replica di sola lettura non passando un listener del gruppo di disponibilità alla parola chiave Server della stringa di connessione. Specificare invece il nome dell'istanza di sola lettura.

Il routing di sola lettura potrebbe richiedere più tempo della connessione al database primario. Questo perché il routing di sola lettura si connette prima al database primario e quindi cerca il database secondario leggibile migliore disponibile. A causa di questi più passaggi, è necessario aumentare il login timeout ad almeno 30 secondi.

ODBC

Sono state aggiunte due parole chiave per le stringhe di connessione ODBC per supportare Gruppi di disponibilità AlwaysOn in SQL Server Native Client:

  • ApplicationIntent

  • MultiSubnetFailover

Per altre informazioni sulle parole chiave della stringa di connessione ODBC in SQL Server Native Client, vedere Utilizzo delle parole chiave delle stringhe di connessione con SQL Server Native Client.

Le proprietà di connessione equivalenti sono:

  • SQL_COPT_SS_APPLICATION_INTENT

  • SQL_COPT_SS_MULTISUBNET_FAILOVER

Per altre informazioni sulle proprietà di connessione ODBC in SQL Server Native Client, vedere SQLSetConnectAttr.

La funzionalità delle parole chiave ApplicationIntent e MultiSubnetFailover verrà esposta in Amministratore origine dati ODBC per i DSN in cui viene usato il driver di SQL Server Native Client, a partire da SQL Server 2012 (11.x).

Un'applicazione ODBC di SQL Server Native Client può utilizzare, per la connessione, una delle tre funzioni seguenti:

Funzione Descrizione
SQLBrowseConnect L'elenco di server restituiti da SQLBrowseConnect non includerà i nomi di rete virtuale. Verrà visualizzato solo un elenco di server senza indicazione del fatto che il server sia un server autonomo oppure un server primario o secondario in un cluster WSFC (Windows Server Failover Clustering) che contiene due o più istanze di SQL Server abilitate per Gruppi di disponibilità AlwaysOn. Se si esegue la connessione a un server e viene restituito un errore, è possibile che sia stata stabilita la connessione a un server e che l'impostazione ApplicationIntent non sia compatibile con la configurazione del server.

Poiché SQLBrowseConnect non riconosce i server in un cluster WSFC (Windows Server Failover Clustering) che contiene due o più istanze di SQL Server abilitate per Gruppi di disponibilità AlwaysOn, la parola chiave della stringa di connessione MultiSubnetFailover viene ignorata da SQLBrowseConnect.
SQLConnect SQLConnect supporta sia ApplicationIntent che MultiSubnetFailover tramite un nome origine dati (DSN, Data Source Name) o una proprietà di connessione.
SQLDriverConnect SQLDriverConnect supporta ApplicationIntent e MultiSubnetFailover tramite parole chiave di stringa di connessione, proprietà di connessione o DSN.

OLE DB

OLE DB in SQL Server Native Client non supporta la parola chiave MultiSubnetFailover.

OLE DB in SQL Server Native Client supporta la finalità dell'applicazione. La finalità dell'applicazione è la stessa per le applicazioni OLE DB e per quelle ODBC (vedere sopra).

Per supportare Gruppi di disponibilità AlwaysOn in SQL Server Native Client è stata aggiunta una parole chiave per la stringa di connessione OLE DB:

  • Application Intent

Per altre informazioni sulle parole chiave della stringa di connessione in SQL Server Native Client, vedere Utilizzo delle parole chiave delle stringhe di connessione con SQL Server Native Client.

Le proprietà di connessione equivalenti sono:

  • SSPROP_INIT_APPLICATIONINTENT

  • DBPROP_INIT_PROVIDERSTRING

Un'applicazione OLE DB di SQL Server Native Client può utilizzare, per specificare la finalità dell'applicazione, uno dei metodi seguenti:

IDBInitialize::Initialize
IDBInitialize::Initialize prevede l'uso del set di proprietà precedentemente configurato per inizializzare l'origine dati e creare l'oggetto origine dati. La finalità dell'applicazione viene specificata come proprietà del provider o come parte della stringa di proprietà estesa.

IDataInitialize::GetDataSource
IDataInitialize::GetDatasource accetta una stringa di connessione di input che può contenere la parola chiave Application Intent.

IDBProperties::GetProperties
IDBProperties::GetProperties consente di recuperare il valore della proprietà attualmente impostata sull'origine dati. È possibile recuperare il valore di Application Intent tramite la proprietà DBPROP_INIT_PROVIDERSTRING e la proprietà SSPROP_INIT_APPLICATIONINTENT.

IDBProperties::SetProperties
Per impostare il valore della proprietà ApplicationIntent, chiamare IDBProperties::SetProperties passando la proprietà SSPROP_INIT_APPLICATIONINTENT con un valore "ReadWrite" o "ReadOnly" o la proprietà DBPROP_INIT_PROVIDERSTRING con un valore contenente "ApplicationIntent=ReadOnly" o "ApplicationIntent=ReadWrite".

È possibile specificare la finalità dell'applicazione nel campo delle proprietà della finalità dell’applicazione della scheda Tutte nella finestra di dialogo Proprietà di Data Link.

Quando vengono stabilite connessioni implicite, per la connessione viene utilizzata l'impostazione relativa alla finalità dell'applicazione definita per la connessione padre. Analogamente, più sessioni create dalla stessa origine dati ereditano l'impostazione relativa alla finalità dell'applicazione definita per l'origine dati.

Vedere anche

Funzionalità di SQL Server Native Client
Utilizzo delle parole chiave delle stringhe di connessione con SQL Server Native Client