SQL Server equivalente alla funzionalità di Oracle RAC? [chiuso]

11

Chiuso. Questa domanda è fuori tema . Al momento non accetta risposte.

Vuoi migliorare questa domanda? Aggiorna la domanda in modo che sia in argomento per Exchange Stack di amministratori di database.

Chiuso 5 anni fa .

Ho fatto un po 'di Google e non sono riuscito a trovare una risposta a questa domanda più recente di qualche anno fa, quindi ho pensato di fare una domanda. La funzionalità RAC di Oracle offre il bilanciamento del carico sia per le transazioni di lettura e scrittura, sia per la scalabilità e l'alta disponibilità senza tempi di inattività (almeno, come ho capito, stiamo per implementare i nostri primi database che utilizzano RAC, quindi noi vedrò come va).

Esiste un set di funzionalità di SQL Server (o un componente di terze parti che è possibile installare in cima) che offre funzionalità equivalenti? Abbiamo sempre usato il clustering di Windows, in cui un evento di failover provoca circa 20-30 secondi di downtime di SQL, sempre tollerabili, ma non ideali. Ora, con AlwaysOn in SQL 2012, SQL Server lo riduce a circa 15 secondi e aggiunge il concetto di database secondari di sola lettura, ma richiedono comunque che le transazioni di scrittura siano bloccate attraverso un singolo punto di connessione (molto migliorato, poiché molte transazioni sono basta leggere, ma ancora non si esegue il bilanciamento del carico) e, nel caso di un errore del nodo o della necessità di patch, ci sono ancora tempi di inattività.

Suppongo che sia solo più curiosità: penso che questa sia l'unica area in cui SQL Server è indietro rispetto a Oracle (almeno tra le funzionalità che ho visto personalmente usato). Volevo vedere se ci sono opzioni là fuori per colmare questa lacuna e possibilmente migliorare la nostra distribuzione di SQL Server mentre aspettiamo che venga aggiunta la funzionalità equivalente di Microsoft, forse in SQL 2014/2015?

— SqlRyan
fonte

1

Non sono sicuro che SQL Server sia davvero così indietro rispetto a Oracle. Bene, sì, ha una funzionalità che SQL Server non ha, ma assicurati di rivisitare questo thread dopo averlo eseguito per alcuni mesi e facci sapere se è tutto rose o no. :-) Neanche io ne ho esperienza, ma i colleghi che non hanno sempre avuto cose belle da dire al riguardo.

— Aaron Bertrand

2

Spero anche che non ti aspetti alcuna speculazione accurata sulle funzionalità nelle versioni future di SQL Server. Chi sa se ci sono o meno tali caratteristiche nella fase di pianificazione non può dirti; anche quelli che non possono dirtelo. :-)

— Aaron Bertrand

1

@AaronBertrand: Abbastanza giusto, non mi aspetto davvero alcuna speculazione sulle funzionalità, poiché mi rendo conto che non sarebbe affatto preciso. Mentre AlwaysOn è un miglioramento (in alcuni casi), ho avuto maggiori speranze che replicasse più da vicino la funzionalità di RAC e colmasse tale divario. A mio avviso, MSSQL fa molte cose meglio di Oracle, ma questa è un'area in cui Oracle detiene il testimone, secondo me.

— SqlRyan,

1

@rwmnau di nuovo, ti suggerisco di esprimere la tua brillante lode al RAC fino a quando non lo avrai implementato e lo avrai usato per alcuni mesi. :-) Potresti avere ragione; potrebbe essere tutto ciò che promette e funziona perfettamente per te. Ma potresti essere sorpreso dal luccicante scintillio sulla scatola. :-)

— Aaron Bertrand

2

@AaronBertrand: Ah, punto preso. Ho sentito una serie di critiche, come quella che è troppo sensibile alla latenza della rete ed è veloce per sfrattare i nodi e così via, quindi terrò sicuramente un giudizio totale fino a quando non lo avremo implementato e l'ho usato in prima persona . SQL Server, sebbene abbia una serie di opzioni HA, non sembra muoversi nello spazio "front-end scrivibile multiplo". Forse sto per scoprire il motivo per cui :)

— SqlRyan il

8

No, nulla in SQL Server può darti la stessa cosa pronta all'uso .

Attualmente, l'unica tecnologia di SQL Server che consente scritture simultanee su più nodi è la replica peer-to-peer . Si noti che non ho detto "scala di scrittura", perché funziona in modo tale che l'intero sistema abbia la capacità di scrittura di un solo nodo. Il paragrafo introduttivo di quella pagina è redatto attentamente per includere il termine "ridimensionamento" senza dire "scrivere ridimensionamento". Sì per parlare di marketing.

Da quello che ho letto , Oracle RAC è lo stesso in questo senso. Funzionalmente, l'unica cosa che manca a SQL Server in questa configurazione è una soluzione di bilanciamento del carico, che è sia un vantaggio (è possibile implementarlo nel modo desiderato) sia uno svantaggio (non è nella confezione o supportato da Microsoft) quando confronto con prodotti concorrenti.

Al contrario, Oracle RAC non ti dà la stessa cosa di SQL Server , fuori dalla scatola sia. Ad esempio, si consiglia di implementare RAC con nodi entro 100 km l'uno dall'altro a causa della latenza della rete in tempo reale, mentre la replica peer-to-peer non ha tale limitazione. (Non sto dicendo che una soluzione sia migliore dell'altra: sto solo sottolineando che sono diverse. L'azienda dovrebbe scegliere una soluzione che si adatti meglio alle sue esigenze specifiche.)

— Jon Seigel
fonte

1

Il motivo principale della cosa dei 100 km è perché Oracle rimane compatibile ACID su tutti i nodi: devono comunicare tra loro tramite un'interconnessione ad alta velocità e la velocità della luce diventa un problema. SQL Server in una configurazione simile propaga le modifiche e puoi ottenere conflitti a livello di riga se due nodi aggiornano la stessa riga in un determinato periodo di tempo - non ACID - non un singolo database. Un insieme di istanze RAC è un singolo database, questa è la distinzione.

— Philᵀᴹ

@Phil: Sì, quello era il mio punto: sono diversi.

— Jon Seigel,

6

Sono un DBA che supporta sia SQL 2000-2012, Oracle 11g e Oracle 11g RAC.

IMO, Gruppi di disponibilità Always On in SQL 2012 si avvicina molto alla disponibilità e alla scalabilità di RAC a costi molto inferiori sia in dollari che in complessità. È possibile ridimensionare le letture eseguendo una query sui mirror, ma si desidera indirizzare tutti i DML al server primario (i mirror di SQL Server non possono essere aggiornati). Se il server SQL primario si arresta in modo anomalo, il failover su uno dei mirror è quasi istantaneo. RAC subisce una pausa simile se un nodo si arresta in modo anomalo quando le transazioni senza commit sul nodo non riuscito vengono ripristinate dal nodo sopravvissuto.

Il più grande vantaggio (IMHO) di SQL 2012 AAAG su RAC è che si tratta di un'architettura a nulla condiviso. RAC condivide l'archiviazione. In caso contrario, l'intero cluster è inattivo. Questo è un enorme SPOF in RAC che tutti sembrano dimenticare. Se si desidera proteggersi da ciò, è necessario impostare un server di standby. Se vuoi che sia RAC, il costo viene ulteriormente aggravato.

— Mandrino
fonte

1

Un buon punto sullo SPOF di RAC.

— Stanley Johns

5

La risposta diretta alla tua domanda è no, SQL Server non ha funzionalità equivalenti. Esistono aspetti di SQL Server che offrono il tipo di tolleranza agli errori desiderata (anche fino a SQL Server 2005 quando si utilizza il mirroring del DB e un'applicazione compatibile con il mirroring ), ma non esiste un 1: 1 con Oracle RAC.

— Eric Higgins
fonte

1

Un migliore confronto di AlwaysOn sarebbe la funzionalità Data Guard di Oracle. Clustering attivo-passivo. (sì, puoi leggere dalla modalità standby, ma è di sola lettura, quindi è attivo solo un nodo ")

Oracle RAC è un animale completamente diverso e clustering attivo-attivo. Non ho visto alcuna mossa se Microsoft vorrà mai implementarlo.

— Tagar
fonte

-2

SQL Server 2012/2014 con AlwaysOn aggiunge molte funzionalità che ti avvicinano a Oracle RAC e in alcuni casi migliorano. (Ricorda che con RAC, devi utilizzare Oracle app server, weblogic e JDBC, oltre a funzionare in un singolo data center e l'app può connettersi a un solo cluster RAC: l'archiviazione condivisa significa che RAC non funziona nel cloud) .

Con AlwaysOn ottieni secondari di sola lettura (4 in 12, 8 in 14) e supporto per il failover automatico. Alcune cose sono comunque difficili - AlwaysOn non supporta il bilanciamento del carico - a meno che tu non scriva uno script, disegna sempre il primo server nell'elenco. Il failover influisce anche sull'app: non è trasparente, quindi potrebbe essere necessario riavviare le app.

Divulgazione completa - Lavoro per un'azienda che produce software che aumenta AlwaysOn. Il nostro software front-end del software di bilanciamento del carico del database SQL Server: esegue la lettura / scrittura suddivisa per conto dell'app, esegue il bilanciamento del carico basato sul tempo di risposta che abbraccia i data center e accoda le scritture / transazioni in entrata durante il failover in modo che le app non vedano errori . Scopri come Microsoft, Dell, Quicken Loans e altre aziende utilizzano il software ScaleArc per migliorare AlwaysOn di SQL Server e ottenere funzionalità simili a RAC senza modifiche alle app.

— Michelle
fonte