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

Şunlar için geçerlidir:Linux üzerinde SQL Server

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 yalnızca kullanılabilirlik için değil, farklı amaçlarla 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. Veritabanı günlüklerinde yakalanmayan veya veritabanında yapılandırılmayan her şey, her ikincil kopya 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 şemada, 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, AG'ler otomatik veya manuel yük devretme sağlayabilir. Eşzamanlı veri aktarımı yapılandırılmışsa ve birincil ile ikincil çoğaltmadaki veritabanı eşitlenmiş durumdaysa 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ğaltmanın yeni bir birincil çoğaltma yapılması için yük devretme işlemi, otomatik veya manuel olarak yapılandırılabilir ve genellikle saniyeler içinde ö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 çözümü ve Linux tabanlı küme çözümü farklılıktan ziyade benzerdir. 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 dahil olmak üzere hem AG hem de FCI yapılandırmaları için Pacemaker'ı desteklemek amacıyla Microsoft, WSFC'deki kaynak DLL'lere benzeyen fakat 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 üç küme türü vardır, bunlar sys.availability_groupscluster_type sütunlarında ve cluster_type_desc sütununda depolanı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. Temel alınan WSFC kullanan Windows Server tabanlı AG'ler için varsayılan küme türü WSFC'dir ve bunu ayarlamanız gerekmez. 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, AG'nin Yok'tan Dış veya WSFC'ye ya da tersi yönde geçirilemeyeceğ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, senkronize edilmesi gereken ikincil çoğaltmaların sayısını ifade eder ve bu, veri kaybı, Erişilebilirlik Grubu (AG) kullanılabilirliği ve yük devretmenin etkilerinde bulunan bir unsurdur.
WSFC'ler ve None küme türü için varsayılan değer 0'dir ve bunu 1 veya 2 olarak manuel 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. Senkron üç replika için varsayılan değer 1'dir.

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

Veri korumasını artırmak için, 0 değerinin daha yüksek olması, gerekli ikincil kopya sayısı mevcut olmadığında, koşul çözülene kadar birincilin kullanılamaz olmasına neden olur. REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT ayrıca, doğru sayıda ikincil çoğaltmalar doğru durumda değilse otomatik yük devretme gerçekleşmeyeceğinden, yük devretme davranışını etkiler. Linux'ta değeri 0, otomatik yük devretmeye izin vermez. Bu nedenle Linux'ta zaman uyumlu çalışmayı ve otomatik yük devretmeyi birlikte kullanırken, otomatik yük devretmeyi gerçekleştirmek için değerin 0'dan daha yüksek olması 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'ler), ö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 FCI'ler için bir miktar paylaşılan depolama alanı gerekir. Bir düğüm, herhangi bir zamanda FCI kaynaklarını çalıştırabilir ve onlara sahip olabilir. Aşağıdaki diyagramda, kümenin ilk düğümü FCI'nin sahibidir. Ayrıca, kendisiyle ilişkilendirilmiş paylaşılan depolama kaynaklarına da sahiptir ve bu, depolamaya giden kesintisiz ç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ı.

FCI'da sıfır veri kaybı vardır, ancak verilerin yalnızca bir kopyasına sahip olan ortak depolama, bir arıza kaynağıdır. Veritabanlarının yedekli kopyalarına sahip olmak için FCI'leri AG veya günlük gönderimi gibi başka bir kullanılabilirlik yöntemiyle birleştirin. 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ı, bir veri noktasından hatanın meydana geldiği veya elle yük devretmenin gerçekleştiği zamana 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 bir AG'nin yük devri işleminden 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önderimi, işlem günlüğü yedeklemelerini yedekleme, kopyalama ve uygulama işlemini otomatikleştirmek için SQL Server Agent işlerini kullanır.

Log Shipping diyagramı.

Günlük gönderimini kullanmanın en büyük avantajı, işlem günlüklerinin uygulanmasını geciktirebildiğiniz için insan hatasına neden olmasıdır. Örneğin, biri bir UPDATE'ı bir WHERE maddesi olmadan yaparsa, bekleme sistemi bu değişikliği almamış olabilir, bu yüzden birincil sistemi onarırken ona 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 EÇ'de olduğu gibi, işlem günlüğüne yansımayan tüm nesneleri el ile eşitlemeniz gerekir. Her bir veritabanı için günlük gönderimini yapılandırmanız gerekirken, tek bir AG birden fazla veritabanı içerebilir.

AG veya FCI'den farklı olarak, günlük gönderiminde rol değişikliği için herhangi bir soyutlama yoktur ve bu durumun uygulamalar tarafından işlenebilmesi gerekir. DNS diğer adı (CNAME) gibi teknikler uygulanabilir, ancak değişiklikten sonra DNS'nin yenilenme süresi gibi bazı avantajlar ve dezavantajlar bulunmaktadı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.