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 mimariler müşteri dağıtımlarına göre 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
Tanımlı RPO ve RTO Gereksinimleri

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:

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.

Not

Microsoft tarafından sağlanan çalışma süresi SLA'sından çok daha yüksek bir çalışma süresi hedefiniz olabilir.

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.

Uzak mesafe veri çoğaltması için Far Sync'i kullanmanız önerilir. Far Sync bir Oracle Active Data Guard Özelliğidir.

Not

Far Sync'i etkinleştirirseniz bir Active Data Guard lisansı gerekir. Lisanslamanın etkilerini tartışmak için Oracle temsilcinize başvurun.

Oracle Far Sync, Far Sync Örneği olarak bilinen bir ara sunucu sunarak birincil veritabanı ile ikincil veritabanı arasındaki uzak mesafeyi giderir. Bu sunucu, birincil veritabanından yineleme verilerini alır ve bekleme veritabanına iletir. Böylece Far Sync örneği, iletişim süresini azaltmak için birincile daha yakın bir yere yerleştirilir. Ardından Far Sync sunucusu yineleme verilerini zaman uyumsuz olarak ikincil veritabanına aktarır.

Not

Oracle Standard Sürümü veritabanlarını kullandığınızda, DBVisit Bekleme Veya Tessell gibi yüksek kullanılabilirlik ve olağanüstü durum kurtarma ayarlamanızı 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 mesafe ve uygulamanın gecikmeye olan toleransına bağlı olarak, eşzamanlı veya eşzamansız çoğaltma yapabilirsiniz.

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

Data Guard, Hızlı Başlatma Yük Devretme (FSFO) kullanılarak dağıtılabilir. Hızlı Başlatma-Yük Devretme, Data Guard Aracı Yapılandırması içinde sağlanan bir özelliktir. Bu özellik, hata durumunda otomatik olarak yük devretme gerçekleştirmenizi sağlar. Müşterilerin kullandığı varsayılan süre 30 saniyedir, ancak gereksinimlerinize göre ayarlanabilir. OperationTimeout olarak adlandırılan bu, dağıtımınız sırasında tanımladığınız Data Guard özelliklerinin bir parçasıdır.

Data Guard bu özellik ile nasıl çalışır?

Veri Koruma görevi, birincil ve ikincil Veritabanının sistem durumunu ve durumunu sürekli izlemektir. Hızlı Başlangıç-Yük Devretmeyi (FSFO) etkinleştirdiğinizde, gözlemci işlemi tetikler ve belirli bir zamanda yüksek kullanılabilirlik sağlamak için düzenli aralıklarla sistem durumunu inceler.

Şimdi birincil Veritabanı kullanılamaz duruma gelirse, gözlemci ve Data Guard Aracısı bu kesintiyi algılar. Böylece, 30 saniyelik OperationTimeout parametresi, Aracı'nın başka bir işlem yapmadan önce birincil veritabanından yanıt beklemesi gereken zamanı belirtir.

Bu da, eğer birincil sunucu bu 30 saniyelik süre içinde yanıt vermezse, Gözlemci birincil sunucunun erişilemez olduğunu varsayar ve yük devretme sürecini başlatır.

Broker hemen bekleyen veritabanını birincil duruma yükseltir, rolleri değiştirir ve uygulamanın bekleme durumundan hızla devam etmesini sağlar.

Bu süre boyunca Aracı, işlemlerin yedekteki sistemde güncel olmasını da sağlar. Yapılandırdığınız En Yüksek Kullanılabilirlik veya En Yüksek Koruma modunda, zaman uyumlu çoğaltma minimum düzeyde veya sıfır veri kaybı sağlar. 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. Ayrıca, arıza durumunda ikincil veritabanına geçişi başlatmak üzere iki farklı kullanılabilirlik bölgesinde iki FSFO gözlemcisi ayarlanmıştır. Yük devretme gerçekleştikten ve önceki birincil veritabanınız yeniden kullanılabilir duruma geldikten sonra yeniden etkinleştirilebilir. Data Guard Aracısı bu işlemi kolaylaştırır.

Sonuç olarak, birincil veritabanı planlanmış veya planlanmamış bir kesinti nedeniyle kullanılamıyorsa, Data Guard bekleme veritabanınıza devreder veya geçiş yapar.

Bu özellik, gözlemciyi ayrı bir sanal makinede ayarlayarak ek dayanıklılık sağlayabilir. Böylece gözlemciyi basit bir VM'ye dağıtırsınız. Bu yaklaşım yüksek kullanılabilirlik ve dayanıklılık 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. Bir gözlemci ve ikincil veritabanı kesinti yaşarsa, ek erişilebilirlik sağlar. Data Guard Aracısı ve avantajları hakkında daha fazla bilgi için bkz . Oracle Data Guard Aracı Kavramları.

Aşağıdaki diyagramda, 5 dakikadan kısa kurtarma süresiyle Far Sync olmadan oracle Data Guard yüklemesi gösterilmektedir.

Oracle Data Guard Mimarisini gösteren diyagram.

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. Ayrıca, arıza durumunda ikincil veritabanına geçişi başlatmak üzere iki farklı kullanılabilirlik bölgesinde iki FSFO gözlemcisi ayarlanmıştır.

Not

Simetrik bir Data Guard dağıtımı planlarken, üç kullanılabilirlik alanında bir gözlemciye daha ihtiyacınız olacağını lütfen unutmayın.

Ayrıca, veritabanı katmanına genel bir bakış sağlamak için Oracle Enterprise Manager'ı dağıtmanızı kesinlikle öneririz. Azure İzleyici'nin aşağıdaki ölçümlerle dağıtılması önerilir: Diskleri izleyin:

İşletim Sistemi Disk IOPS Kullanım Yüzdesi
Veri Diski Üzerinden Tüketilen IOPS Yüzdesi
Veri Diski Okuma Bayt/Saniye
Veri Diski Yazma Baytları/Saniye
Disk Kuyruğu Derinliği
Lun başına % cinsinden Disk Bant Genişliği

Yukarıdakilere ek olarak VM içgörülerini de etkinleştirmenizi kesinlikle öneririz.

Sanal Makine, AWR değerlendirmenize göre seçilir. Daha fazla bilgi için lütfen Oracle Kapasite Planlaması'nı gözden geçirin. Lisanslama maliyetlerinden tasarruf etmek ve performansı en üst düzeye çıkarmak için kısıtlanmış çekirdek vCPU'lardan yararlanmanızı kesinlikle öneririz.

Disk türü seçimi, AWR değerlendirmenizin çıkışına bağlıdır.

Yukarıda belirtildiği gibi Far Sync, uzun mesafeleri aşan bölgeler arasında çoğaltma yaptığınız senaryolarda ağırlıklı olarak kullanılan bir özelliktir. Bu senaryoya göre Oracle Active Data Guard Far Sync, Oracle Veritabanları için sıfır veri kaybı koruması özelliği sağlar. Oracle Far Sync örneğinin ayrı bir VM'ye yüklenmesi gerekir.

Premium SSD v2, işletim sistemine başvuran dosyalar için desteklenmez. Daha fazla bilgi için lütfen Premium SSD v2'yi dağıtma adresini ziyaret edin.

Yedekleme hedefi olarak Azure Premium Dosyalar kullanılır. Bu çözüm en yüksek performanslı çözümdür. Yedekleme hedefi olarak Azure Blob Depolama de kullanabilirsiniz. Her zaman size en uygun seçeneği test edin. Lütfen Oracle Veritabanı Yedekleme Stratejileri'ne de bakın.

Oracle Data Guard Far Sync

Yukarıda belirtildiği gibi Far Sync, uzun mesafeleri aşan bölgeler arasında çoğaltma yaptığınız senaryolarda ağırlıklı olarak kullanılan bir özelliktir. Bu senaryoya göre Oracle Far Sync, Oracle Veritabanları için sıfır veri kaybı koruması özelliği sağlar. Oracle Far Sync örneğinin ayrı bir VM'ye yüklenmesi gerekir.

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, birincil sunucudan eşzamanlı bir şekilde yeniden yapıyı alır ve ardından gecikmesiz olarak tüm yedek veritabanlarına eşzamansız bir şekilde 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, Active 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, yüksek kullanılabilirlik ve olağanüstü durum kurtarma elde etmek için Oracle Active Data Guard FSFO ve Far Sync kullanan bir mimaridir:

Not

Simetrik bir Far Sync dağıtımı planlarken, ikinci bölgede bir Far Sync örneğine daha ihtiyacınız olacağını lütfen unutmayın.

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, uygulama düzeyinde farkındalık gerektiren çoklu-ana veya etkin-etkin bir yapılandırma ayarlamanıza olanak tanır. Aşağıdaki diyagram, Azure'da Oracle GoldenGate aktif-aktif 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 hiper iş parçacıklı ve kısıtlanmış çekirdekli vCPU'lara sahip bellek için optimize edilmiş bir sanal makine kullanılarak yapılandırılmıştır. Mimari, performans ve kullanılabilirlik için birden çok premium veya ultra disk (yönetilen disk) kullanır.

Not

Benzer bir mimari, kullanılabilirlik alanlarının henüz mevcut olmadığı bölgelerde kullanılabilirlik kümeleri kullanılarak ayarlanabilir.

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 süreçler, kullanılabilirlik bölgesi düzeyinde bir kesinti söz konusu olduğunda veritabanınızın yüksek kullanılabilirliğini garanti altına almak için iki yönlü çoğaltmayı kurmanıza olanak tanır.

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ığı verileri diğer erişilebilirlik bölgesindeki Ç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 ağında ayarlanabilir ve veritabanı katmanı kendi alt ağına ayrılabilir. Mümkün olduğunda, uygulama sunucularınız arasındaki trafiği yük dengelemek için Azure Application Gateway'i 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 bağlılığı 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, kesinti süresine tahammülü olmayan yüksek işlem hacimli 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, bir SDB'deki tüm yinelenen tabloların ana kopyasını da içerir.

Parça kataloğu, değişiklikleri tüm parçalardaki yinelenen tablolara otomatik olarak çoğaltmak için maddileştirilmiş görünümleri kullanır. Parça kataloğu veritabanı, hem birden fazla parça içeren sorguları hem de parçalama anahtarı belirtmeyen sorguları işlemek için kullanılan bir sorgu düzenleyicisi olarak da görev yapar.

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. Shard Yöneticileri, Oracle Sharding bağlamında konumlandırılan Global 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.

Başlangıçta veritabanına bağlanırken, shard yöneticisi yönlendirme bilgilerini ayarlar ve sonraki istekler için bilgileri önbelleğe alır, bu da sonraki isteklerin shard yöneticisini atlamasını sağlar. 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 şardlar arasındaki bölge bağımlılığı ve çoğaltma gecikmesi toleransını 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 olduğunda, Oracle Sharing birincil veritabanı bağlantılarını bekleme konumuna aktarır.

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, ya parçalı kataloğu merkezi koordinatör olarak kullanarak ya da her parçada Veri Pompası çalıştırarak 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 referans 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ıdı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, shard alanında birden çok parça arasında tutarlı karma kullanılarak daha fazla bölümlenir.

Her bir parça alanı birden çok parça grubu barındırır. 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 bekleme gruplarıdır. 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 Uygulama Ağ Geçidi ve parça yöneticisi, istek ve yanıt gecikmelerini izler ve talepleri buna göre yönlendirir.

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 Uygulama Gateway ayrıca kalıcı oturumları 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, parça bazında bölge içi yüksek kullanılabilirlik sağlamak amacıyla Oracle GoldenGate ile birlikte kullanılan 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 yazabilir. 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 uygulamanın kısıtlamaları ve daha fazla bilgi için Parçalı Veritabanı ile Oracle GoldenGate Kullanma başlığına bakın.

Ö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 Uygulama Ağ Geçidi ve parça yöneticisi, istek ve yanıt gecikmelerini izler ve talepleri buna göre 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 bölgesindeki sunuculara hiçbir zaman aynı anda düzeltme eki uygulanmaz. 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.

Sanal makine işletim sistemi düzeltme eki uygulaması Azure Otomasyonu Güncelleştirme Yönetimi kullanılarak 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ıtlı çekirdekli 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. veritabanı iç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.
Oracle Data Guard'a giriş
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.

Geri Bildirim

Bu sayfayı yararlı buldunuz mu?

Last updated on 2024-12-07