Azure Sanal Makineler'da Oracle veritabanı mimarileri

Şunlar için geçerlidir: ✔️ Linux VM'leri

Bu makale, Azure'da yüksek oranda kullanılabilir bir Oracle veritabanı dağıtma hakkında bilgi içerir. Ayrıca bu kılavuzda olağanüstü durum kurtarma konuları ele alınıyor. Bu makalede açıklanan mimariler, müşteri dağıtımları temel alınarak oluşturulmuştur. Bu kılavuz yalnızca Oracle Veritabanı Enterprise Sürümü için geçerlidir.

Oracle veritabanınızın performansını en üst düzeye çıkarma hakkında daha fazla bilgi edinmek istiyorsanız bkz . Azure'da Oracle veritabanı tasarlama ve uygulama.

Önkoşullar

• Kullanılabilirlik alanları gibi Azure'ın farklı kavramlarını anlama
• Oracle Database Enterprise Sürümü 12c veya üzeri
• Bu makaledeki çözümleri kullanırken lisanslamanın etkilerinin farkında olma

Oracle veritabanları için yüksek kullanılabilirlik

Bulutta yüksek kullanılabilirlik elde etmek, her kuruluşun planlama ve tasarımının önemli bir parçasıdır. Azure, kullanılabilirlik alanlarının kullanılamadığı bölgelerde kullanılacak kullanılabilirlik alanları ve kullanılabilirlik kümeleri sunar. Bulut için tasarlama hakkında daha fazla bilgi için bkz. Azure Sanal Makineler için kullanılabilirlik seçenekleri.

Oracle, bulutta yerel araçlara ve tekliflere ek olarak Azure'da ayarlanabilen yüksek kullanılabilirlik çözümleri sunar:

• Oracle Data Guard
• FSFO ile Data Guard
• Parçalama
• GoldenGate

Bu kılavuz, bu çözümlerin her biri için başvuru mimarilerini kapsar.

Bulut için uygulama geçirirken veya oluştururken, yeniden deneme deseni ve devre kesici deseni gibi bulutta yerel desenler kullanmanızı öneririz. Uygulamanızı daha dayanıklı hale getirmenize yardımcı olabilecek diğer desenler için bkz . Bulut Tasarım Desenleri kılavuzu.

Bulutta Oracle RAC

Oracle Real Application Cluster (RAC), oracle tarafından müşterilerin tek bir veritabanı depolama alanına erişen birçok örneğe sahip olarak yüksek aktarım hızı elde etmelerine yardımcı olan bir çözümdür. Bu desen, paylaşılan tüm mimaridir. Oracle RAC şirket içinde yüksek kullanılabilirlik için kullanılabilse de, yalnızca Oracle RAC bulutta yüksek kullanılabilirlik için kullanılamaz. Oracle RAC yalnızca örnek düzeyindeki hatalara karşı koruma sağlar, raf düzeyinde veya veri merkezi düzeyindeki hatalara karşı koruma sağlamaz. Bu nedenle Oracle, yüksek kullanılabilirlik için tek örnek veya RAC gibi veritabanınızla Oracle Data Guard'ın kullanılmasını önerir.

Müşteriler genellikle görev açısından kritik uygulamaları çalıştırmak için yüksek bir SLA gerektirir. Oracle şu anda Azure'da Oracle RAC'i onaylamaz veya desteklemez. Ancak Azure, örnek düzeyindeki hatalara karşı korunmaya yardımcı olmak için kullanılabilirlik alanları ve planlı bakım pencereleri gibi özellikler sunar. Bu tekliflere ek olarak, yüksek performans ve dayanıklılık için Oracle Data Guard, Oracle GoldenGate ve Oracle Sharding'i kullanabilirsiniz. Bu teknolojiler veritabanlarınızı raf düzeyinde, veri merkezi düzeyinde ve jeo-politik hatalardan korumaya yardımcı olabilir.

Oracle Databases'i Oracle Data Guard veya GoldenGate ile birden çok kullanılabilirlik alanında çalıştırdığınızda %99,99 çalışma süresi SLA'sını alabilirsiniz. Kullanılabilirlik alanlarının henüz mevcut olmadığı Azure bölgelerinde kullanılabilirlik kümelerini kullanabilir ve %99,95 çalışma süresi SLA'sı elde edebilirsiniz.

Oracle veritabanları için olağanüstü durum kurtarma

Görev açısından kritik uygulamalarınızı bulutta barındırırken, yüksek kullanılabilirlik ve olağanüstü durum kurtarma için tasarım yapmak önemlidir.

Oracle Database Enterprise Sürümü için Oracle Data Guard olağanüstü durum kurtarma için kullanışlı bir özelliktir. Eşleştirilmiş bir Azure bölgesinde hazır bekleyen veritabanı örneği ayarlayabilir ve olağanüstü durum kurtarma için Data Guard yük devretmesini ayarlayabilirsiniz. Sıfır veri kaybı için, Active Data Guard'a ek olarak bir Oracle Data Guard Far Sync örneği dağıtmanızı öneririz.

Uygulamanız gecikme süresine izin verirse Data Guard Far Sync örneğini Oracle birincil veritabanınızdan farklı bir kullanılabilirlik alanında ayarlamayı göz önünde bulundurun. Yapılandırmayı kapsamlı bir şekilde test edin. Yineleme dosyalarınızın Uzak Eşitleme örneğine zaman uyumlu aktarımını ayarlamak için Maksimum Kullanılabilirlik modunu kullanın. Bu dosyalar daha sonra bekleme veritabanına zaman uyumsuz olarak aktarılır.

Uygulamanız, Far Sync örneğini Maksimum Kullanılabilirlik modunda (zaman uyumlu) başka bir kullanılabilirlik alanında ayarlarken performans kaybına izin vermeyebilir. Aksi takdirde, birincil veritabanınızla aynı kullanılabilirlik alanında bir Far Sync örneği ayarlayabilirsiniz. Daha fazla kullanılabilirlik için, birincil veritabanınıza yakın ve rol geçişleri varsa bekleme veritabanınıza yakın en az bir örnek ayarlamayı göz önünde bulundurun.

Oracle Standard Sürümü veritabanlarını kullandığınızda, DBVisit Bekleme Gibi yüksek kullanılabilirlik ve olağanüstü durum kurtarma ayarlamanıza olanak sağlayan ISV çözümleri vardır.

Başvuru mimarileri

Oracle Data Guard

Oracle Data Guard, kurumsal veriler için yüksek kullanılabilirlik, veri koruma ve olağanüstü durum kurtarma sağlar. Data Guard, bekleyen veritabanlarını birincil veritabanının işlem açısından tutarlı kopyaları olarak tutar. Birincil ve ikincil veritabanları arasındaki uzaklık ile gecikme süresi için uygulama dayanıklılığına bağlı olarak, zaman uyumlu veya zaman uyumsuz çoğaltma ayarlayabilirsiniz. Birincil veritabanı planlanmış veya planlanmamış bir kesinti nedeniyle kullanılamıyorsa, Data Guard beklemedeki veritabanlarını birincil role geçirerek kapalı kalma süresini en aza indirir.

Oracle Data Guard'ı kullanırken ikincil veritabanınızı salt okunur amaçlarla da açabilirsiniz. Bu yapılandırma Active Data Guard olarak adlandırılır. Oracle Database 12c, Data Guard Far Sync Instance adlı bir özellik kullanıma sunulmuştur. Bu örnek, performansta ödün vermek zorunda kalmadan Oracle veritabanınızın sıfır veri kaybı yapılandırmasını ayarlamanıza olanak tanır.

Hızlı Başlangıç Yük Devretme ile Oracle Data Guard

Hızlı Başlangıç Yük Devretmesi (FSFO) ile Oracle Data Guard, aracıyı ayrı bir makinede ayarlayarak daha fazla dayanıklılık sağlayabilir. Data Guard aracısı ve ikincil veritabanı hem gözlemciyi çalıştırır hem de birincil veritabanını kapalı kalma süresi için gözlemler. Bu yaklaşım, Data Guard gözlemci kurulumunuzda da yedeklilik sağlar.

Oracle Veritabanı sürüm 12.2 ve üzeri ile tek bir Oracle Data Guard aracı yapılandırmasıyla birden çok gözlemci yapılandırmak da mümkündür. Bu kurulum, bir gözlemci ve ikincil veritabanı kapalı kalma süresiyle karşılaşması durumunda ek kullanılabilirlik sağlar. Data Guard Aracısı hafiftir ve nispeten küçük bir sanal makinede barındırılabilir. Data Guard Aracısı ve avantajları hakkında daha fazla bilgi için bkz . Oracle Data Guard Aracı Kavramları.

Aşağıdaki diyagram, Kullanılabilirlik alanlarıyla Azure'da Oracle Data Guard'ı kullanmak için önerilen bir mimaridir. Bu mimari %99,99 oranında vm çalışma süresi SLA'sı almanıza olanak tanır.

Önceki diyagramda, istemci sistemi web'i kullanarak Oracle arka ucu ile özel bir uygulamaya erişir. Web ön ucu bir yük dengeleyicide yapılandırılır. Web ön ucu, işi işlemek için uygun uygulama sunucusuna bir çağrı yapar. Uygulama sunucusu birincil Oracle veritabanını sorgular. Oracle veritabanı, lisanslama maliyetlerinden tasarruf etmek ve performansı en üst düzeye çıkarmak için kısıtlanmış çekirdek vCPU'lara sahip hiper iş parçacıklı bellek için iyileştirilmiş bir sanal makine kullanılarak yapılandırılır. Performans ve yüksek kullanılabilirlik için birden çok premium veya ultra disk (Yönetilen Diskler) kullanılır.

Oracle veritabanları, yüksek kullanılabilirlik için birden çok kullanılabilirlik alanına yerleştirilir. Her bölge bağımsız güç, soğutma ve ağ ile donatılmış bir veya daha fazla veri merkezinden oluşur. Dayanıklılığı sağlamak için tüm etkin bölgelerde en az üç ayrı bölge ayarlanır. Bir bölge içindeki kullanılabilirlik alanlarının fiziksel olarak ayrılması, verileri veri merkezi hatalarından korur. Buna ek olarak, iki FSFO gözlemcisi, bir kesinti oluştuğunda veritabanını başlatmak ve ikincil bölgeye yük devretmek için iki kullanılabilirlik alanında ayarlanır.

Bu durumda, önceki mimaride gösterilen bölgeden farklı bir kullanılabilirlik alanında (AZ 1) başka gözlemciler veya bekleme veritabanları ayarlayabilirsiniz. Son olarak Oracle Enterprise Manager (OEM) çalışma süresi ve performans için Oracle veritabanlarını izler. OEM, çeşitli performans ve kullanım raporlarını oluşturmanıza olanak tanır.

Kullanılabilirlik alanlarının desteklenmediği bölgelerde, Oracle Veritabanınızı yüksek oranda kullanılabilir bir şekilde dağıtmak için kullanılabilirlik kümelerini kullanabilirsiniz. Kullanılabilirlik kümeleri , %99,95'lik bir VM çalışma süresi elde etmenizi sağlar. Aşağıdaki diyagram, bu kullanımın bir başvuru mimarisidir:

Oracle Data Guard Far Sync

Oracle Data Guard Far Sync, Oracle Veritabanları için sıfır veri kaybı koruması özelliği sağlar. Bu özellik, veritabanı makineniz başarısız olursa veri kaybına karşı koruma sağlar. Oracle Data Guard Far Sync'in ayrı bir VM'ye yüklenmesi gerekir. Far Sync yalnızca bir denetim dosyası, parola dosyası, spfile ve bekleme günlüklerine sahip basit bir Oracle örneğidir. Veri dosyası yok veya günlük dosyalarını yinele.

Sıfır veri kaybı koruması için birincil veritabanınızla Far Sync örneği arasında zaman uyumlu iletişim olmalıdır. Far Sync örneği, birincilden zaman uyumlu bir şekilde yinelemeyi alır ve zaman uyumsuz bir şekilde hemen tüm bekleme veritabanlarına iletir. Bu kurulum birincil veritabanındaki ek yükü de azaltır çünkü tüm bekleme veritabanları yerine yalnızca yinelemeyi Far Sync örneğine göndermesi gerekir. Uzak Eşitleme örneği başarısız olursa Data Guard, sıfıra yakın veri kaybı koruması sağlamak için otomatik olarak birincil veritabanından ikincil veritabanına zaman uyumsuz aktarım kullanır. Daha fazla dayanıklılık için müşteriler her veritabanı örneği için birincil ve ikinciller de dahil olmak üzere birden çok Far Sync örneği dağıtabilir.

Aşağıdaki diyagram, Oracle Data Guard Far Sync kullanan yüksek kullanılabilirlik mimarisidir:

Önceki mimaride, veritabanı örneği olarak farklı bir kullanılabilirlik alanına dağıtılmış bir Far Sync örneği vardır. Bu sayede kullanılabilirlik alanı hatası olduğunda sıfır veri kaybı ve otomatik yük devretme sağlanır. Uygulamanın gecikme süresine duyarlı olduğu durumlarda, veritabanınızı ve Far Sync örneğinizi veya örneklerini yakınlık yerleştirme grubundaki aynı kullanılabilirlik alanına dağıtmayı göz önünde bulundurun.

Aşağıdaki diyagram, yüksek kullanılabilirlik ve olağanüstü durum kurtarma elde etmek için Oracle Data Guard FSFO ve Far Sync kullanan bir mimaridir:

Oracle GoldenGate

GoldenGate, kuruluş genelindeki birden çok heterojen platform arasında işlem düzeyinde veri değişimini ve manipülasyonunu sağlar. İşlem bütünlüğüne ve mevcut altyapınıza en düşük ek yüke sahip taahhüt edilen işlemleri taşır. Modüler mimarisi, çeşitli topolojilerde seçili veri kayıtlarını, işlem değişikliklerini ve veri tanımı diline (DDL) yapılan değişiklikleri ayıklama ve çoğaltma esnekliği sağlar.

Oracle GoldenGate, çift yönlü çoğaltma sağlayarak veritabanınızı yüksek kullanılabilirlik için yapılandırmanıza olanak tanır. Bu yaklaşım, çok ana veya etkin-etkin bir yapılandırma ayarlamanıza olanak tanır. Aşağıdaki diyagram, Azure'da Oracle GoldenGate etkin-etkin kurulumu için önerilen bir mimaridir. Aşağıdaki mimaride Oracle veritabanı, lisanslama maliyetlerinden tasarruf etmek ve performansı en üst düzeye çıkarmak için kısıtlanmış çekirdek vCPU'lara sahip hiper iş parçacıklı bellek için iyileştirilmiş bir sanal makine kullanılarak yapılandırılır. Mimari, performans ve kullanılabilirlik için birden çok premium veya ultra disk (yönetilen disk) kullanır.

Oracle GoldenGate, verilerinizi bir Oracle veritabanı sunucusundan diğerine zaman uyumsuz olarak çoğaltmanıza yardımcı olan Extract, Pump ve Replicat gibi işlemlere sahiptir. Bu işlemler, kullanılabilirlik alanı düzeyinde kapalı kalma süresi varsa veritabanınızın yüksek kullanılabilirliğini sağlamak için çift yönlü çoğaltma ayarlamanıza olanak sağlar.

Yukarıdaki diyagramda, Ayıklama işlemi Oracle veritabanınızla aynı sunucuda çalışır. Veri Pompası ve Çoğaltma işlemleri aynı kullanılabilirlik alanındaki ayrı bir sunucuda çalışır. Çoğaltma işlemi, diğer kullanılabilirlik alanındaki veritabanından veri almak ve verileri kullanılabilirlik alanındaki Oracle veritabanına işlemek için kullanılır. Benzer şekilde, Veri Pompası işlemi Ayıklama işleminin ayıkladığınız verileri diğer kullanılabilirlik alanındaki Çoğaltma işlemine gönderir.

Yukarıdaki mimari diyagramında ayrı bir sunucuda yapılandırılan Veri Pompası ve Çoğaltma işlemleri gösteriliyor olsa da, sunucunuzun kapasitesine ve kullanımına bağlı olarak tüm Oracle GoldenGate işlemlerini aynı sunucuda ayarlayabilirsiniz. Sunucunuzun kullanım desenini anlamak için her zaman AWR raporunuz ve Azure'daki ölçümlere başvurun.

Oracle GoldenGate çift yönlü çoğaltmasını farklı kullanılabilirlik alanlarında veya farklı bölgelerde ayarlarken, farklı bileşenler arasındaki gecikme süresinin uygulamanız için kabul edilebilir olduğundan emin olmak önemlidir. Kullanılabilirlik alanları ve bölgeler arasındaki gecikme süresi farklılık gösterebilir. Gecikme süresi birden çok faktöre bağlıdır. Farklı kullanılabilirlik alanlarında veya bölgelerde uygulama katmanınızla veritabanı katmanınız arasında performans testleri ayarlamanızı öneririz. Testler, yapılandırmanın uygulama performans gereksinimlerinizi karşıladığını onaylayabilir.

Uygulama katmanı kendi alt akında ayarlanabilir ve veritabanı katmanı kendi alt ağıyla ayrılabilir. Mümkün olduğunda, uygulama sunucularınız arasındaki trafiği yük dengelemek için Azure Uygulaması Lication Gateway kullanmayı göz önünde bulundurun. Application Gateway güçlü bir web trafiği yük dengeleyicidir. Kullanıcı oturumunu aynı sunucuda tutarak veritabanındaki çakışmaları en aza indiren tanımlama bilgisi tabanlı oturum benzimi sağlar. Application Gateway'in alternatifleri Azure Load Balancer ve Azure Traffic Manager'dır.

Oracle Sharding

Parçalama, Oracle 12.2'de kullanıma sunulan bir veri katmanı desenidir. Verilerinizi yatay olarak bölümlemenize ve bağımsız veritabanları arasında ölçeklendirmenize olanak tanır. Her veritabanının ayrılmış bir sanal makinede barındırıldığı hiçbir şey paylaşmadan bir mimaridir. Bu düzen, dayanıklılık ve daha yüksek kullanılabilirliğe ek olarak yüksek okuma ve yazma aktarım hızı sağlar.

Bu düzen tek hata noktalarını ortadan kaldırır, hata yalıtımı sağlar ve kapalı kalma süresi olmadan sıralı yükseltmeleri etkinleştirir. Bir parçanın kapalı kalma süresi veya veri merkezi düzeyinde hata, diğer parçaların diğer veri merkezlerindeki performansını veya kullanılabilirliğini etkilemez.

Parçalama, kapalı kalma süresini karşılayamayacak yüksek performanslı OLTP uygulamaları için uygundur. Aynı parçalama anahtarına sahip tüm satırların her zaman aynı parçada olması garanti edilir. Bu durum performansı artırarak yüksek tutarlılık sağlar. Parçalama kullanan uygulamaların tutarlı karma, aralık, liste veya bileşik gibi iyi tanımlanmış bir veri modeline ve veri dağıtım stratejisine sahip olması gerekir. Strateji öncelikle customerId veya accountNum gibi bir parçalama anahtarı kullanarak verilere erişir. Parçalama ayrıca belirli veri kümelerini son müşterilere daha yakın bir şekilde depolamanıza olanak sağlayarak performans ve uyumluluk gereksinimlerinizi karşılamanıza yardımcı olur.

Yüksek kullanılabilirlik ve olağanüstü durum kurtarma için parçalarınızı çoğaltmanızı öneririz. Bu kurulum, Oracle Data Guard veya Oracle GoldenGate gibi Oracle teknolojileri kullanılarak yapılabilir. Çoğaltma birimi parça, parçanın parçası veya parça grubu olabilir. Bir veya daha fazla parçanın kesintisi veya yavaşlaması parçalı veritabanının kullanılabilirliğini etkilemez.

Yüksek kullanılabilirlik için, hazır bekleyen parçalar birincil parçaların yerleştirildiği aynı kullanılabilirlik alanına yerleştirilebilir. Olağanüstü durum kurtarma için hazır bekleyen parçalar başka bir bölgede bulunabilir. Ayrıca, bu bölgelerdeki trafiğe hizmet vermek için parçaları birden çok bölgeye dağıtabilirsiniz. Parçalı veritabanınızın yüksek kullanılabilirliğini ve çoğaltmasını yapılandırma hakkında daha fazla bilgi edinmek için bkz . Parça Düzeyi Yüksek Kullanılabilirlik.

Oracle Sharding öncelikle aşağıdaki bileşenlerden oluşur. Daha fazla bilgi için bkz . Oracle Sharding'e Genel Bakış:

• Parça kataloğu. Tüm Parça veritabanı yapılandırma verileri için kalıcı bir depo olan özel amaçlı Oracle veritabanı. Parça ekleme veya kaldırma, verilerin eşlenmesi ve parça veritabanındaki DLL'ler gibi tüm yapılandırma değişiklikleri parça kataloğunda başlatılır. Parça kataloğu, SDB'deki tüm yinelenen tabloların birincil kopyasını da içerir.

  Parça kataloğu, değişiklikleri tüm parçalardaki yinelenen tablolara otomatik olarak çoğaltmak için gerçekleştirilmiş görünümleri kullanır. Parça kataloğu veritabanı, parçalama anahtarı belirtmeyen çok parçalı sorguları ve sorguları işlemek için kullanılan bir sorgu düzenleyicisi olarak da çalışır.

  En iyi uygulama olarak parça kataloğu yüksek kullanılabilirliği için kullanılabilirlik alanları veya kullanılabilirlik kümeleri ile Oracle Data Guard kullanmanızı öneririz. Parça kataloğunun kullanılabilirliği, parçalanmış veritabanının kullanılabilirliğini etkilemez. Parça kataloğundaki kapalı kalma süresi yalnızca Data Guard yük devretmesinin tamamlayacağı kısa süre boyunca bakım işlemlerini ve çok parçalı sorguları etkiler. SDB, çevrimiçi işlemleri yönlendirmeye ve çalıştırmaya devam eder. Katalog kesintisi bunları etkilemez.

• Parça yöneticileri. Parçalarınızın bulunduğu her bölgede/kullanılabilirlik alanında dağıtılması gereken basit hizmetler. Parça Yöneticileri, Oracle Sharding bağlamında dağıtılan Genel Hizmet Yöneticileridir. Yüksek kullanılabilirlik için, parçalarınızın bulunduğu her kullanılabilirlik alanına en az bir parça yöneticisi dağıtmanızı öneririz.

  Veritabanına başlangıçta bağlandığınızda, parça yöneticisi yönlendirme bilgilerini ayarlar ve sonraki istekler için bilgileri önbelleğe alır ve bu da parça yöneticisini atlar. Oturum bir parçayla oluşturulduktan sonra, verilen parça kapsamında tüm SQL sorguları ve DLL'leri desteklenir ve yürütülür. Bu yönlendirme hızlıdır ve parça içi işlemler gerçekleştiren tüm OLTP iş yükleri için kullanılır. En yüksek performans ve kullanılabilirlik gerektiren tüm OLTP iş yükleri için doğrudan yönlendirme kullanmanızı öneririz. Bir parça kullanılamaz duruma geldiğinde veya parçalama topolojisinde değişiklikler olduğunda yönlendirme önbelleği otomatik olarak yenilenir.

  Oracle, yüksek performanslı ve verilere bağımlı yönlendirme için parçalı veritabanındaki verilere erişirken bağlantı havuzu kullanılmasını önerir. Oracle bağlantı havuzları, dile özgü kitaplıklar ve sürücüler Oracle Sharding'i destekler. Daha fazla bilgi için bkz . Oracle Sharding'e Genel Bakış.

• Genel hizmet. Genel hizmet, normal veritabanı hizmetine benzer. Veritabanı hizmetinin tüm özelliklerine ek olarak, genel hizmet parçalanmış veritabanları için özelliklere sahiptir. Bu özellikler, istemciler ile parça arasındaki bölge benzini ve çoğaltma gecikmesi toleransı içerir. Parçalı veritabanına veri okumak/veritabanından veri yazmak için yalnızca bir genel hizmet oluşturulması gerekir. Active Data Guard'ı kullanırken ve parçaların salt okunur çoğaltmalarını ayarlarken, salt okunur iş yükleri için başka bir genel hizmet oluşturabilirsiniz. İstemci veritabanına bağlanmak için bu genel hizmetleri kullanabilir.

• Parça veritabanları. Parça veritabanları, Oracle veritabanlarınızdır. Her veritabanı, FSFO etkinleştirilmiş bir Aracı yapılandırmasında Oracle Data Guard kullanılarak çoğaltılır. Her parçada Data Guard yük devretme ve çoğaltmayı ayarlamanız gerekmez. Bu özellik, paylaşılan veritabanı oluşturulduğunda otomatik olarak yapılandırılır ve dağıtılır. Belirli bir parça başarısız olursa, Oracle Sharing birincilden beklemeye veritabanı bağlantıları üzerinden başarısız olur.

Oracle Parçalı veritabanlarını iki arabirimle dağıtabilir ve yönetebilirsiniz: Oracle Enterprise Manager Cloud Control GUI ve GDSCTL komut satırı yardımcı programı. Bulut denetimini kullanarak kullanılabilirlik ve performans için farklı parçaları bile izleyebilirsiniz. GDSCTL DEPLOY Komutu, parçaları ve ilgili dinleyicilerini otomatik olarak oluşturur. Ayrıca, bu komut yönetici tarafından belirtilen parça düzeyi yüksek kullanılabilirlik için kullanılan çoğaltma yapılandırmasını otomatik olarak dağıtır.

Veritabanını parça etmenin farklı yolları vardır:

• Sistem tarafından yönetilen parçalama: Bölümleme kullanarak parçalar arasında otomatik olarak dağıtılır
• Kullanıcı tanımlı parçalama: Verilerin parçalara eşlemesini belirtmenize olanak tanır; bu, mevzuat veya veri yerelleştirme gereksinimleri olduğunda iyi çalışır
• Bileşik parçalama: Farklı parça alanları için sistem tarafından yönetilen ve kullanıcı tanımlı parçalamanın birleşimi
• Tablo alt bölümleri: Normal bölümlenmiş tabloya benzer

Daha fazla bilgi için bkz . Parçalama Yöntemleri.

Parçalı veritabanı, uygulamalar ve geliştiriciler için tek bir veritabanı gibi görünür. Parçalı bir veritabanına geçiş yaptığınızda, hangi tabloların çoğaltıldığını ve parçalanmış olduğunu anlamak için dikkatli bir şekilde plan yapın.

Yinelenen tablolar tüm parçalarda depolanırken, parçalı tablolar farklı parçalar arasında dağıtılır. Küçük ve boyutlu tabloları çoğaltmanızı ve olgu tablolarını dağıtmanızı/parçalamanızı öneririz. Veriler parça kataloğu merkezi koordinatör olarak veya her parçada Veri Pompası çalıştırılarak parçalı veritabanınıza yüklenebilir. Daha fazla bilgi için bkz . Verileri Parçalı Veritabanına Geçirme.

Data Guard ile Oracle Parçalama

Oracle Data Guard sistem tarafından yönetilen, kullanıcı tanımlı ve bileşik parçalama yöntemleriyle parçalama için kullanılabilir.

Aşağıdaki diyagram, her parçanın yüksek kullanılabilirliği için kullanılan Oracle Data Guard ile Oracle Sharding için bir başvuru mimarisidir. Mimari diyagramında bileşik parçalama yöntemi gösterilir. Mimari diyagramı büyük olasılıkla veri yerelliği, yük dengeleme, yüksek kullanılabilirlik ve olağanüstü durum kurtarma için farklı gereksinimlere sahip uygulamalar için farklılık gösterir. Uygulamalar parçalama için farklı bir yöntem kullanabilir. Oracle Sharding, bu gereksinimleri karşılamanıza ve bu seçenekleri sağlayarak yatay ve verimli bir şekilde ölçeklendirmenize olanak tanır. Oracle GoldenGate kullanılarak da benzer bir mimari dağıtılabilir.

Sistem tarafından yönetilen parçalama, yapılandırılması ve yönetilmesi en kolay olan parçalamadır. Kullanıcı tanımlı parçalama veya bileşik parçalama, verilerinizin ve uygulamanızın coğrafi olarak dağıtıldığı veya her parçanın çoğaltması üzerinde denetim sahibi olmanız gereken senaryolar için uygundur.

Önceki mimaride bileşik parçalama, verileri coğrafi olarak dağıtmak ve uygulama katmanlarınızın ölçeğini yatay olarak genişletmek için kullanılır. Bileşik parçalama, sistem tarafından yönetilen ve kullanıcı tanımlı parçalamanın bir bileşimidir ve bu nedenle her iki yöntemin de avantajını sağlar. Önceki senaryoda veriler ilk olarak bölgeye göre ayrılmış birden çok parça alanı arasında parçalanır. Daha sonra veriler, parça alanında birden çok parça arasında tutarlı karma kullanılarak daha fazla bölümlenmiştir.

Her parça alanı birden çok parça grubu içerir. Her parça grubunun birden çok parçası vardır ve bir çoğaltma birimidir. Her parça grubu, parça alanında yer alan tüm verileri içerir. Parça grupları A1 ve B1 birincil parça gruplarıyken, parça grupları A2 ve B2 beklemededir. Tek tek parçaların parça grubu yerine çoğaltma birimi olmasını seçebilirsiniz.

Önceki mimaride, yüksek kullanılabilirlik için her kullanılabilirlik alanına bir Global Service Manager (GSM)/parça yöneticisi dağıtılır. Veri merkezi/bölge başına en az bir GSM/parça yöneticisi dağıtmanızı öneririz. Ayrıca, uygulama sunucusunun bir örneği bir parça grubu içeren her kullanılabilirlik alanına dağıtılır. Bu kurulum, uygulamanın uygulama sunucusu ile veritabanı/parça grubu arasındaki gecikme süresini düşük tutmasına olanak tanır. Veritabanı başarısız olursa, veritabanı rolü geçişi gerçekleştiğinde bekleyen veritabanıyla aynı bölgedeki uygulama sunucusu istekleri işleyebilir. Azure Uygulaması lication Gateway ve parça yöneticisi, istek ve yanıt gecikmesi ile yönlendirme isteklerini uygun şekilde izler.

Uygulama açısından bakıldığında, istemci sistemi Azure Uygulaması Lication Gateway'e veya Azure'daki diğer yük dengeleme teknolojilerine yönelik bir istekte bulunur ve bu da isteği istemciye en yakın bölgeye yönlendirir. Azure Uygulaması lication Gateway yapışkan oturumları da desteklediğinden, aynı istemciden gelen tüm istekler aynı uygulama sunucusuna yönlendirilir. Uygulama sunucusu, veri erişim sürücülerinde bağlantı havuzu kullanır. Bu özellik JDBC, ODP.NET ve OCI gibi sürücülerde kullanılabilir. Sürücüler, isteğin bir parçası olarak belirtilen parçalama anahtarlarını tanıyabilir. JDBC istemcileri için Oracle Evrensel Bağlantı Havuzu (UCP), Apache Tomcat ve IIS gibi Oracle dışı uygulama istemcilerinin Oracle Sharding ile çalışmasını sağlayabilir. Daha fazla bilgi için bkz . Veritabanı Parçalama için UCP Paylaşılan Havuzuna Genel Bakış.

İlk istek sırasında uygulama sunucusu, isteğin yönlendirilmesi gereken parçanın yönlendirme bilgilerini almak için kendi bölgesindeki parça yöneticisine bağlanır. Geçirilen parçalama anahtarına bağlı olarak, yönetici uygulama sunucusunu ilgili parçaya yönlendirir. Uygulama sunucusu bir harita oluşturarak bu bilgileri önbelleğe alır ve sonraki istekler için parça yöneticisini atlar ve istekleri doğrudan parçaya yönlendirir.

GoldenGate ile Oracle Sharding

Aşağıdaki diyagram, her parçanın bölge içi yüksek kullanılabilirliği için Oracle GoldenGate ile Oracle Sharding için bir başvuru mimarisidir. Önceki mimarinin aksine, bu mimari yalnızca birden çok kullanılabilirlik alanına sahip tek bir Azure bölgesinde yüksek kullanılabilirliği gösterir. Oracle GoldenGate kullanarak önceki örneğe benzer şekilde çok bölgeli yüksek kullanılabilirlik parçalı veritabanı dağıtabilirsiniz.

Yukarıdaki başvuru mimarisi, verileri parçalama amacıyla sistem tarafından yönetilen parçalama yöntemini kullanır. Oracle GoldenGate çoğaltması öbek düzeyinde yapıldığından, bir parçaya çoğaltılan verilerin yarısı başka bir parçaya çoğaltılabilir. Diğer yarısı farklı bir parçaya çoğaltılabilir.

Verilerin çoğaltılması çoğaltma faktörüne bağlıdır. İki çoğaltma faktörüyle, parça grubundaki üç parçanızda her veri öbeklerinin iki kopyasına sahip olursunuz. Benzer şekilde, parça grubunuzdaki üç ve üç parçadan oluşan çoğaltma faktörüyle, her parçadaki tüm veriler parça grubundaki diğer her parçaya çoğaltılır. Parça grubundaki her parçanın farklı bir çoğaltma faktörü olabilir. Bu kurulum, bir parça grubu içinde ve birden çok parça grubunda yüksek kullanılabilirlik ve olağanüstü durum kurtarma tasarımınızı verimli bir şekilde tanımlamanıza yardımcı olur.

Önceki mimaride, parça grubu A ve parça grubu B aynı verileri içerir ancak farklı kullanılabilirlik alanlarında bulunur. Hem parça grubu A hem de parça grubu B aynı üç çoğaltma faktörüne sahipse, parçalanmış tablonuzun her satırı/öbeği iki parça grubu arasında altı kez çoğaltılır. Parça grubu A üç çoğaltma faktörüne ve B parça grubu iki çoğaltma faktörüne sahipse, her satır/öbek iki parça grubu arasında beş kez çoğaltılır.

Bu kurulum, örnek düzeyi veya kullanılabilirlik alanı düzeyi hatası oluşursa veri kaybını önler. Uygulama katmanı her parçadan okuyabilir ve her parçaya yazabilirsiniz. Oracle Sharding, çakışmaları en aza indirmek için her karma değer aralığı için bir ana öbek oluşturur. Bu özellik, belirli bir öbek için yazma isteklerinin ilgili öbeke yönlendirilmesini sağlar. Buna ek olarak, Oracle GoldenGate ortaya çıkabilecek çakışmaları işlemek için otomatik çakışma algılama ve çözüm sağlar. Oracle Sharding ile GoldenGate uygulama hakkında daha fazla bilgi ve sınırlama için bkz . Oracle GoldenGate'i Parçalı Veritabanı ile kullanma.

Önceki mimaride, yüksek kullanılabilirlik için her kullanılabilirlik alanına bir GSM/parça yöneticisi dağıtılır. Veri merkezi veya bölge başına en az bir GSM/parça yöneticisi dağıtmanızı öneririz. Uygulama sunucusunun bir örneği, bir parça grubu içeren her kullanılabilirlik alanına dağıtılır. Bu kurulum, uygulamanın uygulama sunucusu ile veritabanı/parça grubu arasındaki gecikme süresini düşük tutmasına olanak tanır. Veritabanı başarısız olursa, veritabanı rolü geçiş yaptıktan sonra bekleyen veritabanıyla aynı bölgedeki uygulama sunucusu istekleri işleyebilir. Azure Uygulaması lication Gateway ve parça yöneticisi, istek ve yanıt gecikmesi ile yönlendirme isteklerini uygun şekilde izler.

Uygulama açısından bakıldığında, istemci sistemi Azure Uygulaması Lication Gateway'e veya Azure'daki diğer yük dengeleme teknolojilerine yönelik bir istekte bulunur ve bu da isteği istemciye en yakın bölgeye yönlendirir. Azure Uygulaması lication Gateway yapışkan oturumları da desteklediğinden, aynı istemciden gelen tüm istekler aynı uygulama sunucusuna yönlendirilir. Uygulama sunucusu, veri erişim sürücülerinde bağlantı havuzu kullanır. Bu özellik JDBC, ODP.NET ve OCI gibi sürücülerde kullanılabilir. Sürücüler, isteğin bir parçası olarak belirtilen parçalama anahtarlarını tanıyabilir. JDBC istemcileri için Oracle Evrensel Bağlantı Havuzu (UCP), Apache Tomcat ve IIS gibi Oracle dışı uygulama istemcilerinin Oracle Sharding ile çalışmasını sağlayabilir.

İlk istek sırasında uygulama sunucusu, isteğin yönlendirilmesi gereken parçanın yönlendirme bilgilerini almak için kendi bölgesindeki parça yöneticisine bağlanır. Geçirilen parçalama anahtarına bağlı olarak, yönetici uygulama sunucusunu ilgili parçaya yönlendirir. Uygulama sunucusu bir harita oluşturarak bu bilgileri önbelleğe alır ve sonraki istekler için parça yöneticisini atlar ve istekleri doğrudan parçaya yönlendirir.

Düzeltme eki uygulama ve bakım

Oracle iş yüklerinizi Azure'a dağıttığınızda, Microsoft tüm konak işletim sistemi düzeyinde düzeltme eki uygulamayla ilgilenir. Microsoft, planlanan işletim sistemi düzeyindeki bakımları müşterilere önceden iletir. İki farklı kullanılabilirlik alanından iki sunucuya hiçbir zaman aynı anda düzeltme eki uygulamaz. VM bakımı ve düzeltme eki uygulama hakkında daha fazla bilgi için bkz. Azure Sanal Makineler için kullanılabilirlik seçenekleri.

Azure Otomasyonu Güncelleştirme Yönetimi kullanılarak sanal makine işletim sisteminize düzeltme eki uygulama otomatikleştirilebilir. Oracle veritabanınıza düzeltme eki uygulama ve bakımını yapmak, kapalı kalma süresini en aza indirmek için Azure Pipelines veya Azure Otomasyonu Güncelleştirme Yönetimi kullanılarak otomatikleştirilebilir ve zamanlanabilir. Sürekli teslim ve mavi/yeşil dağıtımlar hakkında daha fazla bilgi için bkz . Aşamalı pozlama teknikleri.

Mimari ve tasarımla ilgili dikkat edilmesi gerekenler

• Lisanslama maliyetlerinden tasarruf etmek ve performansı en üst düzeye çıkarmak için Oracle Veritabanı VM'niz için kısıtlanmış çekirdek vCPU'lara sahip hiper iş parçacıklı bellek için iyileştirilmiş sanal makine kullanmayı göz önünde bulundurun. Performans ve kullanılabilirlik için birden çok premium veya ultra disk (yönetilen disk) kullanın.
• Yönetilen diskleri kullandığınızda, disk/cihaz adı yeniden başlatıldığında değişebilir. Bağlamalarınızın yeniden başlatmada kalıcı olmasını sağlamak için ad yerine cihaz UUID'sini kullanmanızı öneririz. Daha fazla bilgi için bkz . Yeni dosya sistemini /etc/fstab dosyasına ekleme.
• Bölge içinde yüksek kullanılabilirlik elde etmek için kullanılabilirlik alanlarını kullanın.
• Kullanılabilir olduğunda ultra diskleri veya Oracle veritabanınız için premium diskleri kullanmayı göz önünde bulundurun.
• Oracle Data Guard kullanarak başka bir Azure bölgesinde hazır bekleyen oracle veritabanı ayarlamayı göz önünde bulundurun.
• Uygulama ve veritabanı katmanı arasındaki gecikme süresini azaltmak için yakınlık yerleştirme gruplarını kullanmayı göz önünde bulundurun.
• Azure VM'lerinde en yüksek ağ bant genişliği (genellikle) aynı SKU'da maksimum disk aktarım hızına göre daha yüksektir. Azure NetApp Files gibi yüksek performanslı, düşük gecikme süreli ağa bağlı depolamayı kullanarak aynı VM SKU'su üzerinde daha yüksek aktarım hızı elde edebilir veya daha küçük bir VM SKU'su kullanabilirsiniz. öğesini seçin.
• Yönetim, izleme ve günlüğe kaydetme için Oracle Enterprise Manager'ı ayarlayın.
• Veritabanınız için kolaylaştırılmış depolama yönetimi için Oracle Otomatik Depolama Yönetimi'ne göz önünde bulundurun.
• Kapalı kalma süresi olmadan veritabanınızda düzeltme eki uygulama ve güncelleştirmeleri yönetmek için Azure Pipelines'ı kullanın.
• Uygulamanızın daha dayanıklı olması için buluta özel desenler eklemek için uygulama kodunuzu değiştirin. Bulut Tasarım Desenleri kılavuzunda tanımlanan yeniden deneme düzeni, devre kesici deseni ve diğerleri gibi desenleri göz önünde bulundurun.

Sonraki adımlar

Senaryonuz için geçerli olan aşağıdaki Oracle başvuru makalelerini gözden geçirin.

• Oracle Data Guard'a giriş
• Oracle Data Guard Aracı Kavramları
• Oracle GoldenGate'i Etkin-Etkin Yüksek Kullanılabilirlik için Yapılandırma
• Oracle Sharding'e Genel Bakış