İş sürekliliği ve veritabanı kurtarma - SQL Server

Şunlar için geçerlidir: SQL Server 2016 (13.x) ve sonraki sürümleri

Bu makale, Windows ve Linux üzerinde SQL Server'da yüksek kullanılabilirlik ve olağanüstü durum kurtarma için iş sürekliliği çözümlerine genel bir bakış sağlar.

SQL Server'ı dağıtan herkesin, iş ve son kullanıcıların ihtiyaç duyduğu tüm görev açısından kritik SQL Server örneklerinin ve veritabanlarının, kullanılabilirlik normal iş saatlerinde veya 24 saat boyunca kullanılabilir olduğundan emin olması gerekir. Amaç, işi en az kesintiyle veya hiç kesinti olmadan çalışır durumda tutmaktır. Bu kavram iş sürekliliği olarak da bilinir.

SQL Server 2017 (14.x) ve sonraki sürümleri kullanılabilirlik için özellikler ve geliştirmeler kullanıma sunulmuştur. En büyük ekleme, Linux dağıtımlarında SQL Server desteğidir. SQL Server'daki yeni özelliklerin tam listesi için aşağıdaki makalelere bakın:

Sürüm	İşletim sistemi
SQL Server 2025 (17.x) sürümündeki yenilikler	Windows \| Linux
SQL Server 2022 (16.x) sürümündeki yenilikler	Windows \| Linux
SQL Server 2019 (15.x) sürümündeki yenilikler	Windows \| Linux
SQL Server 2017 (14.x) sürümündeki yenilikler	Windows \| Linux

Bu makalede, SQL Server 2017 (14.x) ve sonraki sürümlerdeki kullanılabilirlik senaryolarının yanı sıra yeni ve gelişmiş kullanılabilirlik özelliklerine odaklanılır. Senaryolar, hem Windows Server hem de Linux'ta SQL Server dağıtımlarına yayılabilen karma olanları ve bir veritabanının okunabilir kopya sayısını artırabilenleri içerir.

Bu makale SQL Server dışındaki kullanılabilirlik seçeneklerini (sanallaştırma gibi) kapsamasa da, burada açıklanan her şey ister genel bulutta ister şirket içi hiper yönetici sunucusu tarafından barındırılan bir konuk sanal makine içindeki SQL Server yüklemeleri için geçerlidir.

Kullanılabilirlik özelliklerini kullanan SQL Server senaryoları

Always On kullanılabilirlik gruplarını, yük devretme kümesi örneklerini ve günlük gönderimlerini sadece kullanılabilirlik için değil, farklı amaçlarla da kullanabilirsiniz. Kullanılabilirlik özelliklerini kullanmanın dört ana yolu vardır:

Yüksek ulaşılabilirlik
Felaket kurtarma
Geçişler ve yükseltmeler
Bir veya daha fazla veritabanının okunabilir kopyalarını ölçeklendirme

Aşağıdaki bölümlerde her senaryo için ilgili özellikler açıklanmaktadır. Kapsanmayan bir özellik SQL Server çoğaltmasıdır. SQL Server çoğaltması Always On şemsiyesi altında resmi olarak kullanılabilirlik özelliği olarak belirlenmiyor olsa da, genellikle belirli senaryolarda verileri yedekli hale getirmek için kullanılır. SQL Server için Linux üzerinde birleştirme çoğaltması desteklenmez. Daha fazla bilgi için bkz. Linux'ta SQL Server çoğaltması.

Önemli

SQL Server kullanılabilirlik özellikleri sağlam, iyi test edilmiş bir yedekleme ve geri yükleme stratejisine sahip olma gereksinimini değiştirmez. Yedekleme ve geri yükleme stratejisi, kullanılabilirlik çözümlerinin en temel yapı taşıdır.

Yüksek ulaşılabilirlik

Buluttaki bir veri merkezinde veya tek bir bölgede yerel bir sorun oluştuğunda SQL Server örneklerinin veya veritabanlarının kullanılabilir olduğundan emin olmak önemlidir. Bu bölümde SQL Server kullanılabilirlik özelliklerinin nasıl yardımcı olabileceği açıklanmaktadır. Açıklanan özelliklerin tümü hem Windows Server'da hem de Linux'ta kullanılabilir.

Kullanılabilirlik grupları

Kullanılabilirlik grupları (AG' ler), bir veritabanının her işlemini başka bir örneğe veya özel durumdaki bir veritabanının kopyasını içeren çoğaltmaya göndererek veritabanı düzeyinde koruma sağlar. Standart veya Kurumsal sürümlerde AG dağıtabilirsiniz. AG'ye katılan örnekler tek başına veya yük devretme kümesi örnekleri olabilir (SONRAKI bölümde açıklanan FC'ler). İşlemler gerçekleşirken bir replika gönderildiğinden, daha düşük kurtarma noktası ve kurtarma süresi hedefleri gereksinimi olan durumlarda AG gruplarının kullanılması önerilir. Çoğaltmalar arasındaki veri taşıma senkron veya asenkron olabilir; Enterprise sürümünde, birincil dahil en fazla üç çoğaltmanın senkron olmasına imkan tanınır. Ag, birincil çoğaltmada bulunan veritabanının bir tam okuma/yazma kopyasına sahipken, tüm ikincil çoğaltmalar doğrudan son kullanıcılardan veya uygulamalardan işlem alamaz.

Uyarı

Always On, SQL Server'daki kullanılabilirlik özellikleri için kullanılan bir terimdir ve hem AG'leri hem de FC'leri kapsar. Always On, AG özelliğinin adı değildir.

SQL Server 2022(16.x) öncesinde, AG'ler yalnızca veritabanı düzeyinde koruma sağlar, örnek düzeyinde koruma sağlamaz. İşlem günlüğünde yakalanmayan veya veritabanında yapılandırılmayan her şey, her bir ikincil çoğaltma için manuel olarak senkronize edilmelidir. El ile eşitlenmesi gereken nesnelere örnek olarak örnek düzeyinde oturum açma işlemleri, bağlı sunucular ve SQL Server Aracısı işleri verilebilir.

SQL Server 2022 (16.x) ve sonraki sürümlerinde kullanıcılar, oturum açma bilgileri, izinler ve SQL Server Aracısı işleri gibi meta veri nesnelerini örnek düzeyine ek olarak AG düzeyinde yönetebilirsiniz. Daha fazla bilgi için bkz. Kapsanan kullanılabilirlik grubu nedir?

Ag ayrıca, uygulamaların ve son kullanıcıların birincil çoğaltmayı hangi SQL Server örneğinin barındırdığını bilmeye gerek kalmadan bağlanmasına olanak tanıyan dinleyici adlı başka bir bileşene de sahiptir. Her AG'nin kendi dinleyicisi vardır. Dinleyicinin uygulamaları Windows Server ve Linux'ta biraz farklı olsa da, ikisi de aynı işlevselliği ve kullanılabilirliği sağlar. Aşağıdaki diyagramda, Windows Server Yük Devretme Kümesi (WSFC) kullanan Windows Server tabanlı bir AG gösterilmektedir. Linux veya Windows Server'da olsun, kullanılabilirlik için işletim sistemi katmanında temel alınan bir küme gereklidir. Örnek, altyapı kümesi olarak WSFC ile iki sunucu veya düğüm içeren basit bir yapılandırmayı gösterir.

Basit bir kullanılabilirlik grubunun diyagramı.

Standart ve Enterprise sürümleri, çoğaltmalar söz konusu olduğunda farklı maksimum değerlere sahiptir. Standart sürümde "temel kullanılabilirlik grubu" olarak bilinen bir AG, AG'de yalnızca tek bir veritabanı bulunan iki replikayı (birincil ve ikincil) destekler. Enterprise edition, birden çok veritabanının tek bir AG'de yapılandırılmasına izin vermekle kalmaz, aynı zamanda en fazla dokuz toplam çoğaltmaya (bir birincil, sekiz ikincil) sahip olabilir. Enterprise edition ayrıca okunabilir ikincil çoğaltmalar, ikincil çoğaltmadan yedekleme yapma ve daha fazlası gibi diğer isteğe bağlı avantajları da sağlar.

Uyarı

SQL Server 2012'de (11.x) kullanım dışı bırakılan veritabanı yansıtma, SQL Server'ın Linux sürümünde kullanılamaz ve eklenmez. Veritabanı yansıtmayı kullanmaya devam eden müşteriler, veritabanı yansıtmasının yerini alan AG'lere geçmeyi planlamalıdır.

Kullanılabilirlik söz konusu olduğunda, Kullanılabilirlik Grupları otomatik veya manuel yük devretme sağlayabilir. Eşzamanlı veri taşıma yapılandırılırsa ve birincil ve ikincil çoğaltmadaki veritabanı senkronize edilmiş haldeyse otomatik yük devretme gerçekleşebilir. Dinleyici kullanıldığı ve uygulama desteklenen bir .NET Framework sürümünü (Service Pack 1 veya 4.6.2 ve sonraki sürümleri içeren 3.5) kullandığı sürece, dinleyici kullanılırsa yük devretmenin son kullanıcılar üzerinde en az düzeyden hiçbir etkisi olmayacak şekilde işlenmesi gerekir. İkincil bir çoğaltmaya yük devredilmesiyle yeni birincil çoğaltmanın otomatik veya manuel olarak yapılandırılması sağlanabilir ve genellikle saniye cinsinden ölçülür.

Aşağıdaki listede, Windows Server'da Linux yerine AG'lerle ilgili bazı farklar vurgulanır:

Temel kümenin Linux ve Windows Server'da çalışma şekli nedeniyle, tüm AG yük devretmeleri (el ile veya otomatik) Linux üzerindeki küme üzerinden yapılır. Windows Server tabanlı AG dağıtımlarında el ile yük devretme işlemleri SQL Server aracılığıyla yapılmalıdır. Otomatik yük devretme işlemleri hem Windows Server hem de Linux'ta temel alınan küme tarafından işlenir.

Linux üzerinde SQL Server için, temel kümelemenin çalışma şekli nedeniyle en az üç çoğaltmaya sahip bir AG yapılandırmanız gerekir.
Linux'ta, her dinleyici tarafından kullanılan ortak ad, Windows Server'daki gibi kümede değil DNS'de tanımlanır.

SQL Server 2017 (14.x), AG'ler için aşağıdaki özellikleri ve geliştirmeleri kullanıma sunar:

Küme türleri
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT
Windows Server tabanlı yapılandırmalar için gelişmiş Microsoft Dağıtımcı İşlem Düzenleyicisi (DTC) desteği
Salt okunur veritabanları için ek ölçek genişletme senaryoları (bu makalenin ilerleyen bölümlerinde açıklanmaktadır)

Kullanılabilirlik grubu küme türleri

Windows Server'da kümelemenin yerleşik kullanılabilirlik biçimi, Yük Devretme Kümelemesi adlı bir özellik aracılığıyla etkinleştirilir. AG veya FCI ile kullanılacak bir WSFC oluşturmanıza olanak tanır. SQL Server, AG'ler ve FC'ler için tümleştirme sağlayan küme kullanan kaynak DLL'lerini gönderir.

Linux üzerinde SQL Server birden çok kümeleme teknolojisini destekler. Microsoft, SQL Server bileşenlerini desteklerken, iş ortaklarımız da ilgili kümeleme teknolojisini destekler. Örneğin, Pacemaker ile birlikte Linux üzerinde SQL Server, küme çözümü olarak HPE Serviceguard ve DH2i DxEnterprise'i destekler.

Windows tabanlı bir yük devretme kümesi ve Linux kümesi çözümü, birbirine benzer özellikler taşır. Her ikisi de tek tek sunucuları alıp kullanılabilirlik sağlamak için bir yapılandırmada birleştirmek için bir yol sağlar ve kaynaklar, kısıtlamalar (farklı uygulansa bile), yük devretme vb. kavramlara sahiptir.

Örneğin, otomatik yük devretme gibi işlemler ve daha fazlasını içeren hem AG hem de FCI yapılandırmaları için Pacemaker'ı desteklemek amacıyla Microsoft, Pacemaker için WSFC'deki kaynak DLL'lere benzeyen ancak tam olarak aynı olmayan mssql-server-ha paketini sağlar. WSFC ile Pacemaker arasındaki farklardan biri, Pacemaker'da bir WSFC'deki dinleyicinin adını (veya FCI'nın adını) soyutlamada yardımcı olan bir ağ adı kaynağı olmamasıdır. Linux'ta ad çözümlemesi için DNS kullanın.

Küme yığınındaki fark nedeniyle SQL Server 2017 (14.x) ve sonraki sürümlerdeki AG'lerin WSFC tarafından yerel olarak işlenen bazı meta verileri işlemesi gerekir. Örneğin, bir kullanılabilirlik grubu için, cluster_type ve cluster_type_desc sütunlarında sys.availability_groups depolanan üç küme türü vardır.

WSFC
Dış
Hiç kimse

Yüksek kullanılabilirlik gerektiren tüm AG'ler, SQL Server 2017 (14.x) ve sonraki sürümlerde WSFC veya Linux kümeleme aracısı anlamına gelen temel bir küme kullanmalıdır. Temelini WSFC'nin oluşturduğu Windows Server tabanlı Erişilebilirlik Grupları (AG'ler) için varsayılan küme türü WSFC'dir ve bunu ayarlamanıza gerek yoktur. Linux tabanlı AG'ler için AG'yi oluştururken küme türünü Dış olarak ayarlamanız gerekir. Linux'ta dış küme çözümüyle tümleştirme AG oluşturulduktan sonra yapılandırılırken, WSFC'de oluşturma zamanında yapılır.

"None küme türü, hem Windows Server hem de Linux AG'leri ile kullanılabilir." Küme türünü Yok olarak ayarlamak, AG'nin temel alınan bir küme gerektirmediği anlamına gelir. Bu, SQL Server 2017 'nin (14.x) küme olmayan AG'leri destekleyen ilk SQL Server sürümü olduğu anlamına gelir, ancak bu yapılandırmanın yüksek kullanılabilirlik çözümü olarak desteklenmediği anlamına gelir.

Önemli

SQL Server 2017 (14.x) ve sonraki sürümlerinde, ag oluşturulduktan sonra küme türünü değiştiremezsiniz. Bu kısıtlama, bir AG'nin Yok'tan Dış veya WSFC'ye ve bunun tersi yönde değiştirilemeyeceği anlamına gelir.

Veritabanının yalnızca salt okunur ek kopyalarını eklemek istiyorsanız veya AG'nin geçiş ve yükseltmeler için sağladığını istiyorsanız ancak temel alınan bir kümenin karmaşıklığıyla ve hatta çoğaltmayla ilgilenmek istemiyorsanız, küme türü Yok olan bir AG ayarlamayı düşünün. Daha fazla bilgi için Geçişler ve yükseltmeler ve okuma ölçeği bölümlerine bakın.

Aşağıdaki ekran görüntüsünde, SQL Server Management Studio'daki (SSMS) farklı küme türleri için destek gösterilmektedir. 17.1 veya sonraki bir sürümü çalıştırıyor olmanız gerekir. Aşağıdaki ekran görüntüsü 17.2 sürümünden alınmıştı:

Taahhüt İçin Gerekli Senkronize İkincil Sistemler

SQL Server 2016 (13.x), Enterprise sürümünde zaman uyumlu çoğaltma sayısı için desteği ikiden üçe artırdı. Ancak, bir ikincil çoğaltma eşitlenmişse ancak diğer çoğaltma sorun yaşıyorsa, birincil çoğaltmaya hatalı davranan çoğaltmayı beklemesini veya devam etmesini sağlamasını bildirme davranışını denetlemenin bir yolu yoktur. Bu senaryoda, ikincil çoğaltma eşitlenmiş durumda olmasa bile birincil çoğaltma yine de yazma trafiği alabilir ve bu da ikincil çoğaltmada veri kaybına neden olur.

SQL Server 2017 (14.x) ve sonraki sürümlerinde ile zaman uyumlu çoğaltmalar REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMITolduğunda ne olacağının davranışını denetleyebilirsiniz. Bu seçenek aşağıdaki gibi çalışır:

Üç olası değer vardır: 0, 1ve 2.
Değer, eşitlenmesi gereken ikincil çoğaltmaların sayısıdır ve bu, veri kaybı, Kullanılabilirlik Grubu (AG) kullanılabilirliği ve yük devretme işlemi için etkileri vardır.
WSC'ler ve küme türü Yok için varsayılan değer 0 ve bunu el ile 1 veya 2 olarak ayarlayabilirsiniz.
Dış küme türü için, küme mekanizması bu değeri varsayılan olarak ayarlar ve el ile geçersiz kılabilirsiniz. Zaman uyumlu üç çoğaltma için varsayılan değerdir 1.

Linux'ta REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT değerini kümedeki AG kaynağında yapılandırırsınız. Windows'ta, Transact-SQL aracılığıyla ayarlarsınız.

Daha yüksek 0 bir değer, daha fazla veri koruması sağlar, çünkü gerekli ikincil çoğaltma sayısı mevcut değilse, bu koşul çözülene kadar birincil devreye girmez. REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT ayrıca, uygun sayıda ikincil replik doğru durumda değilse otomatik yük devretme gerçekleşemeyeceğinden yük devretme davranışını da etkiler. Linux'ta değer 0 otomatik yük devretmeye izin vermez, bu nedenle Linux'ta zaman uyumlu ve otomatik yük devretme kullanırken otomatik yük devretmeyi sağlamak için değeri 0'den daha yüksek bir değer ayarlamanız gerekir. 0 Windows Server'da, SQL Server 2016 (13.x) ve önceki sürümlerdeki davranıştır.

Gelişmiş Microsoft Dağıtılmış İşlem Düzenleyicisi desteği

SQL Server 2016(13.x) öncesinde, SQL Server'da, kapakların altında DTC kullanan dağıtılmış işlemler gerektiren uygulamalar için kullanılabilirlik elde etmenin tek yolu, FCI'leri dağıtmaktı. Dağıtılmış bir işlem iki yoldan biriyle yapılabilir:

Aynı SQL Server örneğindeki birden fazla veritabanına yayılan bir işlem.
Birden fazla SQL Server örneğine yayılan veya SQL Server olmayan bir veri kaynağı içeren bir işlem.

SQL Server 2016 (13.x), ikinci senaryoyu ele alan AG'lerle DTC için kısmi destek kullanıma sunulmuştur. SQL Server 2017 (14.x), DTC ile her iki senaryoyu da destekleyerek hikayeyi tamamlar.

SQL Server 2017 (14.x) ve sonraki sürümlerinde, oluşturulduktan sonra AG'ye DTC desteği ekleyebilirsiniz. SQL Server 2016'da (13.x), YALNıZCA AG'yi oluştururken DTC desteğini etkinleştirebilirsiniz.

Yedekleme kümesi örnekleri

Yük devretme kümesi örnekleri (FCI), örnek olarak bilinen SQL Server yüklemesinin tamamı için kullanılabilirlik sağlar. FCI'lerde, temel alınan sunucu bir sorunla karşılaşırsa, örneğin içindeki her şey veritabanları, SQL Server Aracısı işleri, bağlı sunucular ve daha fazlası dahil olmak üzere başka bir sunucuya taşınır. Ağ tanımlı olsa bile tüm FC'ler için paylaşılan depolama alanı gerekir. Bir düğüm, herhangi bir zamanda FCI'nin kaynaklarını çalıştırabilir ve sahip olabilir. Aşağıdaki diyagramda, kümenin ilk düğümü FCI'nin sahibidir. Ayrıca, kendisiyle ilişkilendirilmiş olan paylaşımlı depolama kaynaklarına da sahiptir ve bu ilişki, depolamaya giden düz çizgi ile belirtilir.

Yük devretme kümesi örneğinin diyagramı.

Yük devretme işleminden sonra, aşağıdaki diyagramda gösterildiği gibi sahiplik değişir:

Yük devretme sonrası yük devretme kümesi örneğinin diyagramı.

Bir FCI'da sıfır veri kaybı vardır; ancak, verilerin yalnızca bir kopyası olduğundan, temel alınan paylaşılan depolama için tek bir hata noktası oluşur. Veritabanlarının yedekli kopyalarını sağlamak için, FCI'leri AG veya log gönderimi gibi başka bir yüksek kullanılabilirlik yöntemiyle entegre edin. Diğer yöntem FCI'dan fiziksel olarak ayrı depolama kullanmalıdır. FCI başka bir düğüme yük devrettiğinde, bir düğümde durur ve başka bir düğümde başlar. Bu işlem, bir sunucuyu açıp kapatmaya benzer.

FCI normal kurtarma işleminden geçer. İleriye alınması gereken tüm işlemleri ileriye doğru alır ve tamamlanmamış işlemleri geri alır. Bu nedenle, veritabanı, veri noktasından hata veya manuel yük devretme zamanına kadar tutarlı olduğu için veri kaybı olmaz. Veritabanları yalnızca kurtarma tamamlandıktan sonra kullanılabilir. Kurtarma süresi birçok faktöre bağlıdır ve genellikle AG'nin yük devretmesinden daha uzundur. Sonuç olarak, bir AG'nin yükünü devreddiğinizde, veritabanını kullanılabilir hale getirmek için sql Server Agent işini etkinleştirme gibi ek görevler gerekebilir.

Uyarı

Hızlandırılmış veritabanı kurtarma (ADR) kurtarma süresini azaltabilir. Daha fazla bilgi için bkz . Hızlandırılmış veritabanı kurtarma.

AG'ler gibi, FCI'ler de temel alınan kümenin hangi düğümünün onu barındırdığına dair bir soyutlama sağlar. FCI her zaman aynı adı korur. Uygulamalar ve son kullanıcılar düğümlere hiçbir zaman bağlanmaz. Bunun yerine, FCI'ya atanan benzersiz adı kullanırlar. FCI, bir AG'ye birincil veya ikincil kopyayı barındıran örneklerden biri olarak katılabilir.

Aşağıdaki listede, Windows Server ve Linux'taki FCI'lerle ilgili bazı farklar vurgulanır:

Windows Server'da FCI, yükleme işleminin bir parçasıdır. SQL Server'ı yükledikten sonra Linux üzerinde bir FCI yapılandırabilirsiniz.
Linux, konak başına tek bir SQL Server yüklemesini desteklediğinden tüm FCI'ler varsayılan bir örnektir. Windows Server, WSFC başına en fazla 25 FCI'yi destekler.
Linux'ta FCI'ler tarafından kullanılan ortak ad DNS'de tanımlanır ve FCI için oluşturulan kaynakla aynı olmalıdır.

Log gönderimi

Kurtarma noktası ve kurtarma süresi hedefleri daha esnekse veya veritabanları son derece görev açısından kritik değilse, günlük gönderimi SQL Server'da kanıtlanmış bir diğer kullanılabilirlik özelliğidir. SQL Server'ın yerel yedeklemelerine bağlı olarak, günlük gönderimi işlemi otomatik olarak işlem günlüğü yedekleri oluşturur, bunları sıcak bekleme olarak bilinen bir veya daha fazla örneğe kopyalar ve işlem günlüğü yedeklemelerini otomatik olarak bu beklemeye uygular. Günlük gönderme, işlem günlüğü yedeklerini yedekleme, kopyalama ve uygulama süreçlerini otomatikleştirmek için SQL Server Agent işleri kullanarak gerçekleştirir.

Log Shipping diyagramı.

İşlem günlüklerinin uygulanmasını geciktirebilme imkânı sunduğu için, günlük gönderimini kullanmanın en büyük avantajı insan hatalarını önleyebilmesidir. Örneğin, birisi bir UPDATEWHERE yan tümce olmadan verirse, yedekte değişiklik olmayabilir, böylece birincil sistemi onarırken yedeğe geçiş yapabilirsiniz. Günlük gönderimini yapılandırmak kolay olsa da, birincilden rol değişikliği olarak bilinen sıcak bekleme moduna geçmek her zaman el ile gerçekleştirilir. Transact-SQL aracılığıyla bir rol değişikliği başlatırsınız ve AG gibi işlem günlüğünde yakalanmayan tüm nesneleri el ile eşitlemeniz gerekir. Veritabanı başına günlük gönderimi yapılandırmanız gerekirken, tek bir AG birden çok veritabanı içerebilir.

AG veya FCI'den farklı olarak, günlük gönderiminde rol değişikliklerini işlemek için bir soyutlama yoktur, bu nedenle uygulamaların bunu yönetebilmesi gerekir. DNS diğer adı (CNAME) gibi teknikler kullanılabilir, ancak DNS anahtar değişikliğinden sonra yenilenme süresi gibi faktörlerin avantajları ve dezavantajları vardır.

Felaket kurtarma

Birincil kullanılabilirlik konumunuz deprem veya sel gibi yıkıcı bir olayla karşılaştığında, işletmenin sistemlerinin başka bir yerde çevrimiçi olmasını sağlamak için hazırlıklı olması gerekir. Bu bölümde SQL Server kullanılabilirlik özelliklerinin iş sürekliliği konusunda nasıl yardımcı olabileceği anlatılabilir.