Manipolazione query di database che non riescono a causa di un failover del server

Question

In un ambiente con un cluster di failover di SQL Server oa specchio, come si preferisce per gestire gli errori? Sembra che ci sono due opzioni:

1. Fail l'intera richiesta client corrente, e lasciare che l'utente dei tentativi
2. intercettare l'errore nel vostro DAL, e riprovare ci

Ogni approccio ha i suoi pro e contro. La maggior parte dei negozi con cui ho lavorato do # 1, ma molti di loro, inoltre, non seguono rigidi confini transazionali, e mi sembrano essere lasciando loro aperta di guai in caso di guasto. Anche così, sto avendo problemi a parlare in # 2, che dovrebbe anche tradursi in una migliore esperienza utente (una cattura è potenzialmente lungo ritardo mentre il failover accade).

Qualunque argomenti in un modo o nell'altro sarebbe apprezzato. Se si utilizza il secondo approccio, hai un involucro standard che aiuta a semplificare l'implementazione? In entrambi i casi, come si fa a strutturare il codice per evitare problemi come quelli legati alla mancanza di idempotenza nel comando che non è riuscito?

Answer 1

Numero 2 potrebbe essere un ciclo infinito. Che se è associata alla rete, o le esigenze di PC locali riavviato, o qualsiasi altra cosa?

Il numero 1 è fastidioso per gli utenti, ovviamente.

Se si consente l'accesso solo tramite un sito web, allora non vedrai mai l'errore in ogni caso a meno che il failover avviene a metà chiamata. Per noi, questo è improbabile e che hanno fallito più volte senza rendersene conto degli utenti finali.

Nella vita reale non si può avere bella DAL pulita su un server web. Si può avere un foglio di Excel di collegamento (la maggior parte dei dati finanziari) o WinForms in cui la connessione viene mantenuta aperta, in modo da avere solo l'opzione.

failover dovrebbe richiedere solo pochi secondi in ogni caso. Se il recupero DB prende più di questo, si hanno problemi più grandi comunque. E se succede abbastanza spesso di pensare a gestire, beh ...

In sintesi, accadrà che raramente che si desidera conoscere e il numero 1 sarebbe meglio. IMHO.