SQL Server setara dengan fungsionalitas Oracle RAC? [Tutup]

11

Saya melakukan beberapa Googling dan tidak dapat menemukan jawaban untuk pertanyaan ini lebih baru daripada beberapa tahun yang lalu, jadi saya pikir saya akan bertanya. Fitur RAC Oracle menawarkan load-balancing untuk transaksi baca dan tulis, serta skala dan ketersediaan tinggi tanpa downtime (setidaknya, seperti yang saya mengerti - kami akan menggunakan basis data pertama kami yang menggunakan RAC, jadi kami akan lihat bagaimana kelanjutannya).

Apakah ada set fitur SQL Server (atau komponen pihak ketiga yang dapat Anda instal di atas) yang memberikan fungsionalitas yang setara? Kami selalu menggunakan pengelompokan Windows, di mana acara failover menyebabkan sekitar 20-30 detik downtime SQL - selalu dapat ditoleransi, tetapi tidak ideal. Sekarang, dengan AlwaysOn di SQL 2012, SQL Server mengecilkan itu menjadi sekitar 15 detik dan menambahkan konsep database read-only-secondary, tetapi mereka masih mengharuskan transaksi tulis tersendat melalui titik koneksi tunggal (lebih ditingkatkan, karena banyak transaksi baru saja membaca, tetapi masih belum benar-benar memuat balancing), dan dalam kasus kegagalan simpul atau kebutuhan untuk menambal, masih ada downtime.

Saya kira itu hanya lebih penasaran - Saya merasa seperti ini adalah satu-satunya area yang SQL Server tertinggal dari Oracle (setidaknya di antara fitur yang saya pribadi lihat digunakan). Saya ingin melihat apakah ada opsi di luar sana untuk menutup celah itu dan mungkin meningkatkan penyebaran SQL Server kami sendiri sementara kami menunggu fitur setara Microsoft ditambahkan - mungkin dalam SQL 2014/2015?

sql-server feature-comparison high-availability rac oracle-rac SqlRyan
sumber
1
Saya tidak yakin SQL Server benar-benar jatuh jauh di belakang Oracle. Yah, ya ia memiliki fitur yang tidak dimiliki SQL Server, tetapi pastikan untuk mengunjungi kembali utas ini setelah Anda menjalankannya selama beberapa bulan dan beri tahu kami apakah semuanya mawar atau tidak. :-) Saya juga tidak punya pengalaman dengan itu tetapi kolega yang tidak selalu memiliki hal-hal baik untuk dikatakan tentang hal itu.
Aaron Bertrand
2
Saya juga berharap Anda tidak mengharapkan spekulasi yang akurat tentang fitur dalam versi SQL Server yang akan datang. Mereka yang tahu apakah ada fitur seperti itu dalam tahap perencanaan tidak dapat memberi tahu Anda; mereka yang tidak bisa memberitahumu juga. :-)
Aaron Bertrand
1
@ AaronBertrand: Cukup adil, saya tidak terlalu mengharapkan spekulasi fitur, karena saya menyadari itu tidak akurat sama sekali. Sementara AlwaysOn merupakan peningkatan (dalam beberapa kasus), saya memiliki harapan yang lebih tinggi bahwa itu akan lebih dekat meniru fungsi RAC dan menutup celah itu. MSSQL melakukan beberapa hal lebih baik daripada Oracle, menurut saya, tetapi ini adalah salah satu area di mana Oracle memegang tongkat komando, menurut saya.
SqlRyan
1
@ rwmnau lagi, saya sarankan Anda memegang pujian bersinar Anda dari RAC sampai Anda telah menerapkannya dan telah menggunakannya selama beberapa bulan. :-) Kamu mungkin benar; mungkin itu semua yang dijanjikan dan bekerja dengan sempurna untuk Anda. Tapi Anda mungkin diperdaya oleh kilau mengkilap di kotak. :-)
Aaron Bertrand
2
@ AaronBertrand: Ha, poin diambil. Saya telah mendengar sejumlah kritik, seperti itu terlalu sensitif tentang latensi jaringan dan cepat untuk mengusir node dan semacamnya, jadi saya pasti memegang penilaian total sampai setelah kami meluncurkannya dan saya telah menggunakannya secara langsung . SQL Server, meskipun memiliki sejumlah opsi HA, tampaknya tidak bergerak ke ruang "beberapa ujung depan yang dapat ditulis". Mungkin saya akan menemukan alasan mengapa :)
SqlRyan

Jawaban:

8

Tidak, tidak ada dalam SQL Server yang dapat memberi Anda hal yang sama di luar kotak .

Saat ini, satu-satunya teknologi SQL Server yang memungkinkan penulisan simultan di banyak node adalah replikasi Peer-to-Peer . Perhatikan bahwa saya tidak mengatakan "write scale-out," karena ia berfungsi sedemikian rupa sehingga seluruh sistem hanya memiliki kapasitas menulis satu simpul saja. Paragraf pengantar dari halaman tersebut ditulis dengan hati-hati untuk memasukkan istilah "skala-out" tanpa mengatakan "skala-tulis". Yay untuk berbicara pemasaran.

Dari apa yang saya baca , Oracle RAC adalah sama dalam hal itu. Secara fungsional, satu-satunya hal yang hilang dari SQL Server dalam konfigurasi ini adalah solusi load-balancing, yang merupakan keuntungan (Anda dapat mengimplementasikannya dengan cara apa pun yang Anda inginkan) dan kerugian (tidak ada di dalam kotak atau didukung oleh Microsoft) saat membandingkan dengan produk pesaing.

Sebaliknya, Oracle RAC tidak memberikan hal yang sama seperti SQL Server di luar kotak baik. Sebagai contoh, RAC direkomendasikan untuk diimplementasikan dengan node dalam jarak 100 km satu sama lain karena latensi jaringan waktu nyata, sedangkan replikasi Peer-to-Peer tidak memiliki batasan seperti itu. (Saya tidak mengatakan satu solusi lebih baik dari solusi yang lain: Saya hanya menunjukkan bahwa mereka berbeda. Bisnis harus memilih solusi yang paling sesuai dengan kebutuhan spesifik mereka.)

Jon Seigel
sumber
1
Alasan utama untuk jarak 100 km adalah karena Oracle tetap mematuhi ACID di seluruh node - mereka perlu berkomunikasi satu sama lain melalui interkoneksi kecepatan tinggi & kecepatan cahaya menjadi masalah. SQL Server dalam konfigurasi yang serupa menyebarkan perubahan & Anda bisa mendapatkan konflik level baris jika dua node memperbarui baris yang sama dalam periode waktu tertentu - bukan ACID - bukan database tunggal. Seperangkat instance RAC adalah database tunggal, itulah perbedaannya.
Philᵀᴹ
@ Phil: Ya, itu maksud saya - mereka berbeda.
Jon Seigel
6

Saya seorang DBA yang mendukung SQL 2000-2012, Oracle 11g, dan Oracle 11g RAC.

IMO, Grup Ketersediaan Selalu Aktif di SQL 2012 datang sangat dekat dengan ketersediaan dan skalabilitas RAC dengan biaya yang jauh lebih sedikit dalam dolar dan kompleksitas. Anda dapat mengurangi pembacaan dengan kueri terhadap mirror, tetapi Anda ingin mengarahkan semua DML ke server utama (Mirror SQL Server tidak dapat diperbarui). Jika SQL Server utama crash, failover ke salah satu mirror hampir instan. RAC mengalami jeda yang sama jika sebuah simpul macet karena transaksi yang tidak terikat pada simpul yang gagal diputar kembali oleh simpul yang masih hidup.

Keuntungan terbesar (IMHO) dari SQL 2012 AAAG atas RAC adalah bahwa itu adalah arsitektur shared-nothing. RAC membagikan penyimpanan. Jika itu gagal, seluruh kluster turun. Itu adalah SPOF besar dalam RAC yang tampaknya dilupakan oleh semua orang. Jika Anda ingin melindungi diri dari hal itu, Anda harus menyiapkan server siaga. Jika Anda ingin itu menjadi RAC, biaya semakin diperparah.

Membuang
sumber
1
Poin bagus di SPOF of RAC.
StanleyJohns
5

Jawaban langsung untuk pertanyaan Anda adalah tidak, SQL Server tidak memiliki fungsi yang setara. Ada beberapa aspek dari SQL Server yang memberikan Anda toleransi kegagalan yang Anda inginkan (bahkan sejauh SQL Server 2005 saat menggunakan DB mirroring dan aplikasi mirror-aware), tetapi tidak ada 1: 1 dengan Oracle RAC.

Eric Higgins
sumber
1

Perbandingan yang lebih baik dari AlwaysOn adalah fitur Penjaga Data Oracle. Pengelompokan aktif-pasif. (ya, Anda dapat membaca dari standby, tetapi hanya baca, jadi masih hanya satu simpul yang aktif ")

Oracle RAC adalah hewan yang sama sekali berbeda, dan pengelompokan aktif-aktif. Saya tidak melihat langkah apa pun jika Microsoft ingin menerapkannya.

Tagar
sumber
-2

SQL Server 2012/2014 dengan AlwaysOn menambahkan banyak kemampuan yang membuat Anda dekat dengan Oracle RAC - dan dalam beberapa kasus meningkatkannya. (Ingatlah bahwa dengan RAC, Anda harus menggunakan server aplikasi Oracle, weblogic, dan JDBC - plus yang beroperasi di pusat data tunggal dan aplikasi dapat terhubung ke hanya satu cluster RAC - penyimpanan bersama berarti RAC tidak berfungsi di cloud) .

Dengan AlwaysOn Anda mendapatkan sekunder hanya-baca (4 dalam 12, 8 dalam 14) dan dukungan failover otomatis. Namun ada beberapa hal yang menantang - AlwaysOn tidak mendukung load balancing - kecuali Anda menulis skrip, itu akan selalu menarik server pertama dalam daftar. Failover juga memengaruhi aplikasi - tidak transparan sehingga aplikasi mungkin harus dimulai ulang.

Pengungkapan penuh - Saya bekerja untuk perusahaan yang membuat perangkat lunak yang menambah AlwaysOn. Bagian depan perangkat lunak penyeimbang beban basis data kami berakhir dengan SQL Server - ia melakukan split baca / tulis atas nama aplikasi, melakukan penyeimbangan beban berdasarkan waktu respons yang mencakup pusat data, dan antrian penulisan / transaksi selama failover sehingga aplikasi tidak melihat kesalahan . Lihat bagaimana Microsoft, Dell, Quicken Loans, dan perusahaan lain menggunakan perangkat lunak ScaleArc untuk menambah SQL Server AlwaysOn dan mendapatkan kemampuan seperti RAC tanpa perubahan aplikasi.

Michelle
sumber