Condividi tramite


Uso del mirroring del database in SQL Server Native Client

Si applica a: SQL Server Database SQL di Azure Istanza gestita di SQL di Azure Azure Synapse Analytics Piattaforma di strumenti analitici (PDW)

Nota

Questa funzionalità verrà rimossa nelle versioni future di SQL Server. Evitare di usare questa funzionalità in un nuovo progetto di sviluppo e prevedere interventi di modifica nelle applicazioni in cui è attualmente implementata. Usare invece Gruppi di disponibilità Always On.

Importante

SQL Server Native Client (SNAC) non viene fornito con:

  • SQL Server 2022 (16.x) e versioni successive
  • SQL Server Management Studio 19 e versioni successive

SQL Server Native Client (SQLNCLI o SQLNCLI11) e il provider OLE DB Microsoft legacy per SQL Server (SQLOLEDB) non sono consigliati per lo sviluppo di nuove applicazioni.

Per i nuovi progetti, usare uno dei driver seguenti:

Per SQLNCLI fornito come componente del motore di database di SQL Server (versioni dal 2012 al 2019), vedere questa Eccezione relativa al ciclo di vita del supporto.

Il mirroring del database, introdotto in SQL Server 2005 (9.x), è una soluzione per aumentare la disponibilità del database e la ridondanza dei dati. SQL Server Native Client offre il supporto implicito per il mirroring del database, pertanto lo sviluppatore non deve scrivere codice o eseguire altre azioni dopo che è stato configurato per il database.

Il mirroring del database, implementato per ogni database, consente di conservare una copia di un database di produzione SQL Server in un server di standby. Tale server può essere warm standby o hot standby, a seconda della configurazione e dello stato della sessione di mirroring del database. Un server hot standby supporta il failover rapido senza perdita di transazioni di cui è stato eseguito il commit, mentre un server warm standby supporta la forzatura del servizio (con possibile perdita di dati).

Il database di produzione è denominato database principale, mentre la copia di standby viene chiamata database mirror. Il database principale e il database mirror devono trovarsi in istanze separate di SQL Server (istanze server) e, se possibile, risiedere in computer separati.

L'istanza del server di produzione, chiamata server principale, comunica con l'istanza del server di standby, chiamata server mirror. Il server principale e il server mirror si comportano come partner all'interno di una sessione di mirroring del database. Se si verifica un errore nel server principale, il server mirror è in grado di creare un database nel database principale tramite un processo chiamato failover. Partner_A e Partner_B, ad esempio, sono due server partner, con il database principale inizialmente su Partner_A come server principale e il database mirror che risiede in Partner_B come server mirror. Se Partner_A passa alla modalità offline, il database su Partner_B può eseguire il failover per diventare il database principale corrente. Quando Partner_A si unisce alla sessione di mirroring, diventa il server mirror e il database diventa il database mirror.

Le configurazioni del mirroring del database alternative offrono livelli diversi di prestazioni e sicurezza dei dati e supportano forme diverse di failover. Per altre informazioni, vedere Mirroring del database (SQL Server).

È possibile utilizzare un alias quando si specifica il nome del database mirror.

Nota

Per informazioni sui tentativi di connessione iniziali e su quelli di riconnessione a un database con mirroring, vedere Connettere client a una sessione di mirroring del database (SQL Server).

Considerazioni sulla programmazione

Quando si verifica un errore nel server di database principale, l'applicazione client riceve errori in risposta a chiamate API che indicano che la connessione al database è stata persa. In questo caso qualsiasi modifica al database di cui non sia stato eseguito il commit viene persa e viene eseguito il rollback della transazione corrente. In una situazione di questo tipo l'applicazione deve chiudere la connessione (o rilasciare l'oggetto origine dati) e stabilirla nuovamente. La connessione viene reindirizzata in maniera trasparente al database mirror che ora viene utilizzato come server principale.

Quando viene stabilita una connessione, il server principale invia l'identità del proprio partner di failover al client da utilizzare quando si verifica il failover. Nei casi in cui un'applicazione ha provato a stabilire una connessione dopo che si è verificato un errore nel server principale, il client non conosce l'identità del partner di failover. Per consentire ai client di far fronte a questo scenario, una proprietà di inizializzazione e una parola chiave della stringa di connessione associata consentono al client di specificare l'identità del partner di failover. L'attributo client viene utilizzato solo in questo scenario. Se è disponibile, il server principale non viene utilizzato. Se il server partner di failover fornito dal client non si riferisce a un server utilizzato come partner di failover, la connessione viene rifiutata dal server. Per consentire alle applicazioni di adattarsi alle modifiche di configurazione, l'identità del partner di failover effettivo può essere determinata ispezionando l'attributo dopo che è stata stabilita la connessione. È consigliabile memorizzare nella cache le informazioni sul partner per aggiornare la stringa di connessione oppure escogitare una strategia per eseguire un nuovo tentativo nel caso in cui il primo tentativo di stabilire una connessione non riesca.

Nota

È necessario specificare in modo esplicito il database che dovrà essere utilizzato da una connessione se si desidera utilizzare questa caratteristica in un DSN, una stringa di connessione oppure una proprietà o un attributo di connessione. SQL Server Native Client non tenterà di eseguire il failover nel database partner se questa operazione non viene eseguita.

Il mirroring è una caratteristica del database. Nelle applicazioni che utilizzano più database potrebbe non essere possibile sfruttare questa caratteristica.

Per i nomi di server, inoltre, non viene fatta distinzione tra maiuscole e minuscole, mentre tale distinzione viene fatta per i nomi di database. È pertanto consigliabile assicurarsi di utilizzare la stessa combinazione tra maiuscole e minuscole nei DSN e nelle stringhe di connessione.

Provider OLE DB di SQL Server Native Client

Il provider OLE DB di SQL Server Native Client supporta il mirroring del database tramite attributi di connessione e stringa di connessione. La proprietà SSPROP_INIT_FAILOVERPARTNER è stata aggiunta al set di proprietà DBPROPSET_SQLSERVERDBINIT e la parola chiave FailoverPartner è un nuovo attributo di stringa di connessione per DBPROP_INIT_PROVIDERSTRING. Per altre informazioni, vedere Uso delle parole chiave della stringa di connessione con SQL Server Native Client.

La cache di failover viene mantenuta finché il provider viene caricato, ovvero fino a quando non viene chiamato CoUninitialize o finché l'applicazione dispone di un riferimento a un oggetto gestito dal provider OLE DB di SQL Server Native Client, ad esempio un oggetto origine dati.

Per informazioni dettagliate sul supporto del provider OLE DB di SQL Server Native Client per il mirroring del database, vedere Initialization and Authorization Properties.For details about SQL Server Native Client OLE DB provider support for database mirroring, see Initialization and Authorization Properties.

Driver ODBC di SQL Server Native Client

Il driver ODBC di SQL Server Native Client supporta il mirroring del database tramite attributi di connessione e stringa di connessione. In particolare, l'attributo SQL_COPT_SS_FAILOVER_PARTNER è stato aggiunto per l'uso con le funzioni SQLSetConnectAttr e SQLGetConnectAttr e la parola chiave Failover_Partner è stata aggiunta come nuovo attributo stringa di connessione.

La cache di failover viene gestita finché nell'applicazione è allocato almeno un handle di ambiente. Viene invece persa quando l'ultimo handle di ambiente viene deallocato.

Nota

Gestione driver ODBC è stato migliorato per supportare la specifica del nome del server di failover.

Vedi anche

Funzionalità di SQL Server Native Client
Connessione di client a una sessione di mirroring del database (SQL Server)
Mirroring del database (SQL Server)