Utilizzo del mirroring del database
[!NOTA]
Questa funzionalità verrà rimossa a partire da una delle prossime versioni di Microsoft SQL Server. Evitare di utilizzare questa funzionalità in un nuovo progetto di sviluppo e prevedere interventi di modifica nelle applicazioni in cui è attualmente implementata. In alternativa, utilizzare Gruppi di disponibilità AlwaysOn.
Il mirroring del database, introdotto in SQL Server 2005, è una soluzione per aumentare la disponibilità del database e la ridondanza dei dati. SQL Server Native Client fornisce supporto implicito per il mirroring del database, pertanto, una volta eseguita la configurazione per il database, lo sviluppatore non deve scrivere codice né intraprendere altre azioni.
Il mirroring del database, implementato per singoli database, mantiene una copia di un database di produzione di 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 viene denominato database principale e la copia di standby viene denominata database mirror. Il database principale e il database mirror devono trovarsi in istanze separate di SQL Server (istanze server) e, se possibile, dovrebbero risiedere in computer separati.
L'istanza del server di produzione, denominato server principale, comunica con l'istanza del server di standby, denominato 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 può utilizzare come database il database principale mediante un processo denominato 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 ulteriori 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 Connessione di 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. Se non si esegue questa operazione, SQL Server Native Client non proverà ad eseguire il failover nel database partner.
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 mediante attributi di connessione e delle stringhe 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 ulteriori informazioni, vedere Utilizzo delle parole chiave delle stringhe di connessione con SQL Server Native Client.
La cache di failover viene gestita finché è caricato il provider, ovvero fino a quando non viene chiamato CoUninitialize o finché nell'applicazione è presente 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 Proprietà di inizializzazione e di autorizzazione.
Driver ODBC di SQL Server Native Client
Il provider ODBC di SQL Server Native Client supporta il mirroring del database mediante attributi di connessione e delle stringhe di connessione. Nello specifico, l'attributo SQL_COPT_SS_FAILOVER_PARTNER è stato aggiunto per l'utilizzo con le funzioni SQLSetConnectAttr e SQLGetConnectAttr, mentre la parola chiave Failover_Partner è stata aggiunta come nuovo attributo di 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.
Vedere anche
Concetti
Connessione di client a una sessione di mirroring del database (SQL Server)
Mirroring del database (SQL Server)