messaggi di Service Broker non essere inviata se bersaglio riavviata

Question

Ad alto livello, ecco cosa sta accadendo:

1. Abbiamo due sistemi R2 SP1 di SQL Server 2008 (Standard Edition su Windows NT 6.1 (Build 7601: Servizio Pack 1)) Stanno canticchiando bene, comunicando bidirezionalmente senza errori o problemi.
2. Riavvia il sistema n. 2, prevedendo che tutti i messaggi di Service Broker inviati ad esso mentre non è disponibile si accodano sul sistema n. 1, finché non viene ripristinato il sistema n.
3. Il sistema n. 2 viene ripristinato e tutto inizia normalmente senza errori.
4. I messaggi accodati sul sistema # 1 per il sistema n. 2 rimangono accodati; non vengono mai inviati. Inoltre, i nuovi messaggi su quella conversazione si accodano e non vengono mai inviati.
5. I messaggi inviati a nuove conversazioni vengono trasmessi bene.

dettagli sui messaggi che non vengono mai inviati:

A. Mentre il sistema # 2 non è attivo, il transmission_status per i messaggi nella coda mostrano vari errori che indicano che non può comunicare con il sistema # 2, come previsto.

B. Poco dopo l'avvio del sistema n. 2, lo stato di transmissions_status per tali messaggi diventa vuoto. Lo stato vuoto non cambia mai dopo questo punto.

C. La conversazione in cui i messaggi si accumulano si trova nello stato CONVERSING/CO. Nessuna colonna nella vista di sistema indica che qualcosa è diverso dalle altre code che funzionano correttamente. (Se trovassi i flag impostati in modo diverso, saprei terminare la conversazione sbagliata, ma il sistema non offre indizi, a parte la sempre crescente profondità della coda.)

D. I messaggi non vengono mai ricevuti sul sistema # 2, nel senso che la mia stored procedure di attivazione non viene mai chiamata per questi messaggi.

E. In Profiler (con tutti i tipi di traccia Broker accesi), una buona conversazione mostra queste cose in fase di ingresso:

Broker:Conversation CONVERSING 1 - SEND Message  Initiator          
Broker:Message Classify 2 - Remote Initiator 
[SQL Batch complete; SQL that caused the SEND to occur] 
Broker:Remote Message Acknowledgement 1 - Message with Acknowledgement Sent Initiator 
Broker:Message Classify  1 - Local Initiator 
Broker:Conversation CONVERSING 6 - Received Sequenced Message Target 
Broker:Remote Message Acknowledgement 3 - Message with Acknowledgement Received  Initiator 
Broker:Activation  Microsoft SQL Server Service Broker Activation 1 - Start 

Un messaggio inviato che è destinata a ottenere spettacoli bloccati solo il primo due di quegli eventi:

Broker:Conversation CONVERSING 1 - SEND Message Initiator 
Broker:Message Classify 2 - Remote Initiator 

Per quanto posso dire, questo è tanto più lontano si ottengono quei messaggi. Non c'è alcuna indicazione che SQL Server tenta di trasmetterli mai più. Il sistema # 1 pensa che la conversazione sia ancora buona, ma System # 2 l'ha completamente dimenticata. Il sistema # 1 non sembra mai capirlo. Se successivamente riavviamo il sistema # 1, tutto torna alla normalità con tutti i messaggi che scorrono come previsto.

Ho considerato che questi messaggi sono stati effettivamente inviati, ma che il riconoscimento non sta ritornando al sistema # 1. Ma non vedo alcuna prova di code di conferme di backup.

Abbiamo controllato per numerose problematiche tipiche su entrambi i lati:

Broker è attivato su entrambi i lati. 2. Tutte le code sono accese, con tutte le cose appropriate abilitate (accodata, ricezione). Le code non sono avvelenate. 3. Non esistono problemi di permessi di cui siamo a conoscenza. 4. Non usiamo il fuoco e dimentichiamo. 5. Stiamo riutilizzando le conversazioni, come diverse persone raccomandano di fare. (In effetti, il problema è il riutilizzo della conversazione!) 6. Stiamo intercettando eccezioni SQL, utilizzando le transazioni come indicato, ecc. 7. ssbdiagnose non restituisce errori.

Quando viene riavviato un host di SQL Server, ci aspettiamo che tutti i messaggi in coda vengano inviati, ma non lo sono. Che cosa sta succedendo qui??

Answer 1

Capisco che questo è un thread piuttosto vecchio, ma ho combattuto esattamente la stessa situazione prima, e nel mio caso la configurazione di rete era il colpevole.

Per qualche motivo, l'iniziatore ha inviato i suoi messaggi da un indirizzo IP, ma un altro IP è stato aperto per accettare le risposte in entrata (e questo secondo IP è stato specificato nel percorso della destinazione).

L'ho rilevato per caso, davvero. Quando ho provato a finire la conversazione sul lato di destinazione ma non e 'chiusa, ma il messaggio EndDialog apparso in sys.transmission_queue con lo stato:

Connection attempt failed with error: '10060(A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.)'.

Non ho idea del perché il riavvio di destinazione ha innescato il crollo, ma quando gli ingegneri di rete hanno risolto il problema e ho cambiato la rotta dell'obiettivo, tutto è volato verso le loro destinazioni come si supponeva dall'inizio.