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

Questo argomento illustra SQL Server Native Client supporto (aggiunto in SQL Server 2012) per i gruppi di disponibilità di Always On. Per altre informazioni sui gruppi di disponibilità Always On, vedere Listener del gruppo di disponibilità, connettività client e failover dell'applicazione (SQL Server),creazione e configurazione dei gruppi di disponibilità (SQL Server),clustering di failover e gruppi di disponibilità AlwaysOn (SQL Server) eSecondarie 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à che esegue il failover, la connessione originale viene interrotta e l'applicazione deve aprire una nuova connessione per continuare a funzionare dopo il failover.

Se non si esegue la connessione a un listener del gruppo di disponibilità e se più indirizzi IP sono associati a un nome host, SQL Server Native Client eseguirà l'iterazione sequenziale di 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. Quando ci si connette a un listener del gruppo di disponibilità, SQL Server Native Client tenta di stabilire connessioni a tutti gli indirizzi IP in parallelo e se un tentativo di connessione ha esito positivo, il driver eliminerà eventuali tentativi 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à, permette di abilitare l'istanza del cluster di failover in SQL Server 2012, nonché di ridurre in modo significativo la durata del failover per le topologie AlwaysOn singole e su più subnet. Durante un failover su più subnet, verranno tentate connessioni in parallelo da parte del client. Durante un failover della subnet, SQL Server Native Client riprova la connessione TCP in modo aggressivo.

La MultiSubnetFailover proprietà di connessione indica che l'applicazione viene distribuita in un gruppo di disponibilità o un'istanza del cluster di failover e che SQL Server Native Client tenterà di connettersi al database nell'istanza di SQL Server primaria tentando di connettersi a tutti gli indirizzi IP. Quando MultiSubnetFailover=Yes viene specificato per una connessione, il client tenta di eseguire tentativi di connessione TCP più velocemente rispetto agli intervalli di ritrasmissione TCP predefiniti del sistema operativo. In tal modo si abilita la riconnessione a seguito di failover di un gruppo di disponibilità AlwaysOn o un'istanza del cluster di failover AlwaysOn ed è applicabile a istanze del cluster di failover o a gruppi di disponibilità su una singola subnet o su più subnet.

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 specificazione di MultiSubnetFailover=Yes durante la connessione a un oggetto diverso da un listener del gruppo di disponibilità o dell'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:

• Utilizzare la proprietà di connessione MultiSubnetFailover in caso di connessione a una subnet singola 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 che usa la proprietà di connessione MultiSubnetFailover non è influenzato dal tipo di autenticazione, ovvero autenticazione di SQL Server, autenticazione Kerberos o 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 in un'applicazione viene utilizzato ApplicationIntent=ReadWrite (già illustrato in precedenza) e il percorso di replica secondaria è configurato per l'accesso in sola lettura.

Una connessione non verrà eseguita correttamente se una replica primaria è configurata per rifiutare i carichi di lavoro in sola lettura e nella stringa di connessione è contenuto 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à anche un errore se MultiSubnetFailover viene usato e il SQL Server restituisce una risposta del partner di failover che indica che fa parte di una coppia di mirroring del database.

Se si aggiorna un'applicazione SQL Server Native Client che attualmente usa il mirroring del database in uno scenario multi-subnet, è necessario rimuovere la proprietà di connessione e sostituirla con MultiSubnetFailover impostata su Yes e sostituire il Failover_Partner nome del server nella stringa di connessione con un listener del gruppo di disponibilità. Se in una stringa di connessione vengono utilizzati Failover_Partner e MultiSubnetFailover=Yes, verrà generato un errore dal driver. Se, tuttavia, in una stringa di connessione vengono utilizzati Failover_Partner e MultiSubnetFailover=No (o ApplicationIntent=ReadWrite), nell'applicazione verrà utilizzato il mirroring del database.

Tramite il driver verrà restituito un errore se il mirroring del database viene utilizzato nel database primario nel gruppo di disponibilità e se MultiSubnetFailover=Yes viene utilizzato nella stringa di connessione a un database primario anziché a un listener del gruppo di disponibilità.

Specificazione della finalità dell'applicazione

Se ApplicationIntent=ReadOnly, nel client viene richiesto un carico di lavoro di lettura quando si esegue la connessione a un database abilitato per AlwaysOn. Tramite il server, la finalità verrà applicata al momento della connessione e durante un'istruzione di database USE, ma solo a un database abilitato per Always On.

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

Un database può consentire o impedire carichi di lavoro di lettura nel database AlwaysOn di destinazione. Questa operazione viene eseguita con la clausola ALLOW_CONNECTIONS delle istruzioni Transact-SQL PRIMARY_ROLE e SECONDARY_ROLE.

La parola chiave ApplicationIntent è utilizzata per abilitare 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:

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

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

3. Il gruppo di disponibilità deve essere configurato dall'amministratore del database per abilitare il routing di sola lettura.

È possibile che non tutte le connessioni in cui viene utilizzato il routing di sola lettura vengano stabilite 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. Per assicurare la connessione di tutte le richieste di sola lettura alla stessa replica di sola lettura, non fornire un listener del gruppo di disponibilità alla parola chiave della stringa di connessione Server. Specificare invece il nome dell'istanza di sola lettura.

Il routing di sola lettura potrebbe impiegare più tempo a connettersi rispetto alla replica primaria poiché innanzitutto viene eseguita la connessione del routing di sola lettura alla replica primaria e, successivamente, viene cercata la replica secondaria migliore dal punto di vista della lettura. Per questo motivo è necessario aumentare il timeout di accesso.

ODBC

Due parole chiave della stringa di connessione ODBC sono state aggiunte per supportare i gruppi di disponibilità Always On in SQL Server Native Client:

• ApplicationIntent

• MultiSubnetFailover

Per altre informazioni sulle parole chiave delle stringhe di connessione ODBC in SQL Server Native Client, vedere Uso delle parole chiave stringa 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.

Le funzionalità delle parole chiave e MultiSubnetFailover verranno esposte nell'amministratore dell'origine ApplicationIntent dati ODBC per INS che usano il driver SQL Server Native Client, a partire da SQL Server 2012.

Un'applicazione ODBC SQL Server Native Client può usare una delle tre funzioni per rendere la connessione:

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 alcuna indicazione se il server è un server autonomo o un server primario o secondario in un cluster WSFC (Windows Server Failover Clustering) che contiene due o più istanze SQL Server abilitate per i gruppi di disponibilità di Always On. Se si esegue la connessione a un server e viene restituito un errore, è possibile che sia stata stabilita la connessione a un server e 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 SQL Server abilitate per Always On gruppi di disponibilità, SQLBrowseConnect ignora la MultiSubnetFailover parola chiave stringa di connessione.
SQLConnect	SQLConnect supporta sia ApplicationIntent sia MultiSubnetFailover tramite un nome di origine dati (DSN) o proprietà di connessione.
SQLDriverConnect	SQLDriverConnect supporta ApplicationIntent e MultiSubnetFailover tramite parole chiave della stringa di connessione, proprietà di connessione o DSN.

OLE DB

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

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

Una parola chiave della stringa di connessione OLE DB aggiunta per supportare i gruppi di disponibilità Always On in SQL Server Native Client:

• Application Intent

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

Le proprietà di connessione equivalenti sono:

• SSPROP_INIT_APPLICATIONINTENT

• DBPROP_INIT_PROVIDERSTRING

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

IDBInitialize::Initialize
IDBInitialize::Initialize prevede l'utilizzo 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" oppure 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