Descrizione di connessioni client di server virtuale SQL

Traduzione articoli Traduzione articoli
Identificativo articolo: 273673 - Visualizza i prodotti a cui si riferisce l?articolo.
Espandi tutto | Chiudi tutto

In questa pagina

Sommario

In questo articolo vengono illustrate alcune nozioni fondamentali sulle connessioni client di SQL Microsoft Virtual Server.

Informazioni

importante Questa sezione, metodo o l'attivitÓ sono contenute procedure viene illustrato come modificare il Registro di sistema. Tuttavia, possono causare seri problemi se si modifica il Registro di sistema in modo errato. Pertanto, assicurarsi che questa procedura con attenzione. Per maggiore protezione, Ŕ eseguire il backup del Registro di sistema prima di modificarlo. ╚ quindi possibile ripristinare il Registro di sistema se si verifica un problema. Per ulteriori informazioni su come eseguire il backup e ripristino del Registro di sistema, fare clic sul numero dell'articolo della Microsoft Knowledge Base riportato di seguito riportato:
322756Come eseguire il backup e il ripristino del Registro di sistema in Windows


Comportamento del server virtuale SQL client

Microsoft Cluster Server (MSCS) fornisce una piattaforma di e affidabile in cui Ŕ possibile creare applicazioni mission-critical di SQL Server. Non Ŕ necessario modificare la maggior parte delle applicazioni di server per utilizzarli con MSCS. Tuttavia, le applicazioni basate su transazione (ad esempio, database server, ad esempio Microsoft SQL Server) richiedono in genere ulteriori modifiche, in modo che se il server non riesce, il supporto di failover impedisce correttamente la perdita di integritÓ delle transazioni. Lo sviluppo di un'applicazione client per funzionare con MSCS Ŕ relativamente semplice. ╚ necessario progettare applicazioni con il ripristino del database e controllo degli errori in presente.

Anche senza utilizzare i cluster, un server SQL server recupera automaticamente tutti i database quando il server viene riavviato. Per garantire che un database viene recuperato in uno stato coerente di applicazione, utilizzare le transazioni di database in modo che si verifica di failover nel database correttamente e in uno stato coerente. Le transazioni che sono incomplete quando si verifica un failover devono eseguire il rollback, mentre gli effetti del commit di tutte le transazioni devono essere mantenuti.

Durante il failover, le applicazioni client perde la connessione di SQL server e riconnettano per continuare l'elaborazione. Se la connessione client al server Ŕ senza informazioni sullo stato, (ad esempio, le applicazioni che vengono sviluppate mediante Microsoft Internet Information Server [IIS] sono senza informazioni sullo stato) il client si riconnette al server e continua l'elaborazione. A meno che non il client e il server disponga di uno stato comune (ad esempio, i cursori aperti, le variabili di sessione, variabili globali Transact-SQL o dati in tempdb), failover non Ŕ trasparente per il client. In questi casi, Ŕ necessario progettare l'applicazione client per informare l'utente che la connessione Ŕ stata una perdita, reimpostare o che l'applicazione ristabilire automaticamente la connessione al server. Viene eseguito il rollback tutte le transazioni che sono stato eseguito il commit quando si verifica un failover.

La discussione come client affrontare i problemi relativi al server Ŕ standard per qualsiasi applicazione client di SQL Server, anche senza l'utilizzo di cluster e i server virtuali. L'errore controllo processo Ŕ simile per un'applicazione di database client per un cluster. Quando il cluster inizia il failover, il programma client riceve un messaggio di errore della connessione di database. I messaggi di errore rilevati variano a seconda che il programma client Ŕ tentando di eseguire in quel momento.

Se un server SQL Server non riuscito su per l'Amministrazione del cluster, Ŕ possibile che i pacchetti di reimpostazione TCP non vengono inviati. Se il processo di SQL Server viene terminato dal sistema operativo (per kill.exe), vengono inviati i pacchetti di reimpostazione.

Questo potrebbe interessa l'applicazione client se l'applicazione non viene specificato un parametro di timeout di query o di un timeout di query pari a zero (0).

Se l'applicazione non dispone di un valore di timeout query quindi aprire le connessioni verranno lasciate nello stato ESTABLISHED dopo un failover. Il fatto che le connessioni aperte non sono chiusi e che non ulteriori pacchetti TCP vengono inviati da tali connessioni indica che tali connessioni sono completamente inattive. PoichÚ il failover non ha inviato i pacchetti qualsiasi TCP reimpostare l'applicazione client, le connessioni aperte attendere i risultati della query per un periodo di tempo indefinito (presupponendo un timeout infinito query) e potenzialmente impedire la connessione non risponda (si blocchi).

Per risolvere questo problema dal punto di vista dell'applicazione dei client, Ŕ possibile modificare il timeout di query a un numero finito.

Comportamento di errore di database virtuale

Quando un server di database virtuale ha esito negativo, viene restituito un messaggio di errore non riuscita del collegamento di connessione al client in attesa. Il database sul nodo danneggiato del cluster viene arrestato e riavviato sullo stesso nodo per i parametri impostati:

Start\Programs\Administrative Tools (Common)\Cluster Administrator\Group\Failover\Properties
				
La soglia di predefinito di Failover del gruppo Ŕ 10 riavvii in un periodo di 6 ore prima un failover il nodo rimanente. Tuttavia, SQL Server riavviare soglia, in cui pu˛ essere verificata tramite le proprietÓ SQL Server la risorsa cluster di SQL Server, con una soglia predefinita di tre riavvii SQL Server in 900 secondi e che per impostazione predefinita influisce il gruppo. Se un client tenta di connettersi al server mentre un database viene recuperato, il client riceve un messaggio di errore ripristino di database in attesa e deve riprendere dopo una breve pausa.

Considerazioni relative a SQL Server 6.5 e SQL Server 7.0

SQL Server 6.5 e SQL Server 7.0 funzionano esattamente come descritto nella sezione "Comportamento errore di database virtuale" precedente.

Quando SQL Server 7.0 viene eseguito come un server virtuale SQL Server 7.0 supporta un solo indirizzo IP, ma potrebbe ascolto su porte aggiuntive come configurato dal cliente. Questo Ŕ descritto nell'argomento "Pi¨ ascolto TCP/IP Ports" nell'articolo della Microsoft Knowledge Base riportato di seguito riportato:
254321INF: Consigli di cluster SQL Server, sconsigliate e avvisi di base

Considerazioni di Microsoft SQL Server 2000

SQL Server 2000 dispone di alcune differenze di comportamento dalle versioni di SQL Server 6.5 e SQL Server 7.0.

utilizzo di porte SQL Server 2000

Per impostazione predefinita, un'istanza denominata si ascolta su una porta dinamica. La prima volta che il server viene avviato con una porta impostata su zero (0), il server richiede un numero di porta disponibile dal sistema operativo e quindi il server utilizza tale porta. Il server in questo record nel Registro di sistema e utilizza quindi la stessa porta ogni volta.

Se un server Ŕ configurato per l'ascolto su una porta dinamica e il server non riesce a ascolto sulla porta dinamica all'avvio, il server sceglie un'altra porta.

Se Ŕ configurata una porta statica durante l'installazione o dopo l'installazione utilizzando l'utilitÓ di rete del server non riesce per l'ascolto su TCP/IP, se questa porta Ŕ in uso.

I client di rilevare il numero di porta a cui connettersi nel caso di un'istanza denominata o uno con un numero di porta non predefinita.

Le informazioni di connessione viene scritto nella cache "LastConnect" in questa chiave del Registro di sistema:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\supersocketnetlib\lastConnect
Sono disponibili voci per ciascun server e il metodo che Ŕ stato utilizzato per connettersi a essi nel Registro di sistema.

Il client tenta di riutilizzare le informazioni di connessione su ciascuna connessione, a meno che non riesce e quindi re-negotiates le nuove informazioni. Questa situazione pu˛ verificarsi se il numero di porta Ŕ stata modificata perchÚ qualcuno stato modificato o se fosse una porta dinamica Ŕ stata riassegnata a causa di una porta in uso.

Connessioni interrotte

Esistono tre modi per che una connessione pu˛ essere interrotta:
  1. Il server non riesce, il processo viene terminato da interrotto (ID processo server [ spid ] kill sistema) o una violazione di accesso (AV) o qualcos'altro causa il sistema operativo o servizio necessario.
  2. Errore hardware di computer o perdite di potenza.
  3. Arresto del server.
Ogni tipo di interruzione connessione presentano comportamenti diversi visualizzati sul computer client.
  1. Nel caso in cui non Ŕ un server, il client riceve un messaggio di errore di interruzione connessione immediatamente. ╚ possibile simulare questo comportamento mediante la connessione con OSQL, l'esecuzione di una lunga query e quindi utilizzare KILL per terminare il processo di SQL Server. Il client termina con un messaggio di errore ODBC.
  2. Un errore del computer Ŕ pi¨ complesso. Il comportamento Ŕ possibile modificare leggermente seconda di come viene rilevata la perdita di connessione.

    Se il client Ŕ all'interno di lettura delle informazioni, la perdita di connessione pu˛ essere rilevata immediatamente quanto i dati si interrompe.

    Se il client Ŕ in attesa solo i risultati, il comportamento Ŕ leggermente diverso. Il comportamento dipende dal keep alive configurazione del computer client.

    Microsoft Windows 2000 keep alive viene impostato dal codice client in modo che per ogni connessione. Per impostazione predefinita, keep alive Ŕ impostato su 30 secondi. Ci˛ significa che se il socket Abilita, viene rilevato all'interno di 30 secondi e il client riceve un messaggio di errore. In Microsoft Windows NT 4.0, keep Alive Impossibile impostare in modo che per ogni connessione. Mantenere Alive deve essere impostato per l'intero computer, pertanto che interessa tutte le applicazioni sul server.

    Le chiavi del Registro di sistema in corso a cui fa sono:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters KeepAliveTime\REG_DWORD 30000

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters KeepAliveInterval\REG_DWORD 1000
  3. Quando si avvia un arresto del server, tempo per i client completare l'attesa del server. Tuttavia, se il client Ŕ ancora in esecuzione il server Elimina i thread all'interno del server. Interruzione del thread pu˛ causare diversi messaggi di errore sul client. Messaggi di errore possono includere una connessione interrotta errore; tuttavia, nella maggior parte dei casi viene visualizzato questo messaggio di errore:
    "Si Ŕ verificato un errore sconosciuto, connessione pu˛ essere terminata dal server".
    Il codice di errore nativo ODBC Ŕ impostato su zero (0) in questo caso, ma viene restituito come un messaggio di errore al client.

Riferimenti

Per ulteriori informazioni sul comportamento del client di server virtuale SQL in SQL Server 2005, visitare il seguente sito Web MSDN (informazioni in lingua inglese):
http://msdn2.microsoft.com/en-us/library/ms189585.aspx

ProprietÓ

Identificativo articolo: 273673 - Ultima modifica: martedý 4 dicembre 2007 - Revisione: 7.3
Le informazioni in questo articolo si applicano a:
  • Microsoft SQL Server 6.5 Enterprise Edition
  • Microsoft SQL Server 7.0 Enterprise Edition
  • Microsoft SQL Server 2000 Enterprise Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Standard Edition
Chiavi:á
kbmt kbhowto kbsql2005cluster kbclientserver kbinfo KB273673 KbMtit
Traduzione automatica articoli
Il presente articolo Ŕ stato tradotto tramite il software di traduzione automatica di Microsoft e non da una persona. Microsoft offre sia articoli tradotti da persone fisiche sia articoli tradotti automaticamente da un software, in modo da rendere disponibili tutti gli articoli presenti nella nostra Knowledge Base nella lingua madre dell?utente. Tuttavia, un articolo tradotto in modo automatico non Ŕ sempre perfetto. Potrebbe contenere errori di sintassi, di grammatica o di utilizzo dei vocaboli, pi¨ o meno allo stesso modo di come una persona straniera potrebbe commettere degli errori parlando una lingua che non Ŕ la sua. Microsoft non Ŕ responsabile di alcuna imprecisione, errore o danno cagionato da qualsiasi traduzione non corretta dei contenuti o dell?utilizzo degli stessi fatto dai propri clienti. Microsoft, inoltre, aggiorna frequentemente il software di traduzione automatica.
Clicca qui per visualizzare la versione originale in inglese dell?articolo: 273673
LE INFORMAZIONI CONTENUTE NELLA MICROSOFT KNOWLEDGE BASE SONO FORNITE SENZA GARANZIA DI ALCUN TIPO, IMPLICITA OD ESPLICITA, COMPRESA QUELLA RIGUARDO ALLA COMMERCIALIZZAZIONE E/O COMPATIBILITA' IN IMPIEGHI PARTICOLARI. L'UTENTE SI ASSUME L'INTERA RESPONSABILITA' PER L'UTILIZZO DI QUESTE INFORMAZIONI. IN NESSUN CASO MICROSOFT CORPORATION E I SUOI FORNITORI SI RENDONO RESPONSABILI PER DANNI DIRETTI, INDIRETTI O ACCIDENTALI CHE POSSANO PROVOCARE PERDITA DI DENARO O DI DATI, ANCHE SE MICROSOFT O I SUOI FORNITORI FOSSERO STATI AVVISATI. IL DOCUMENTO PUO' ESSERE COPIATO E DISTRIBUITO ALLE SEGUENTI CONDIZIONI: 1) IL TESTO DEVE ESSERE COPIATO INTEGRALMENTE E TUTTE LE PAGINE DEVONO ESSERE INCLUSE. 2) I PROGRAMMI SE PRESENTI, DEVONO ESSERE COPIATI SENZA MODIFICHE, 3) IL DOCUMENTO DEVE ESSERE DISTRIBUITO INTERAMENTE IN OGNI SUA PARTE. 4) IL DOCUMENTO NON PUO' ESSERE DISTRIBUITO A SCOPO DI LUCRO.

Invia suggerimenti

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com