Azure NetApp Files'da oracle veritabanı performansı birden çok birim

Yüksek performanslı Exadata sınıf veritabanlarının buluta geçirilmesi, Microsoft müşterileri için giderek daha zorunlu hale geliyor. Tedarik zinciri yazılım paketleri genellikle tek bir işlem düğümü tarafından yönetilen karma okuma ve yazma iş yüküyle depolama G/Ç'sine yönelik yoğun talepler nedeniyle çıtayı yüksek ayarlar. Azure NetApp Files ile birlikte Azure altyapısı, bu yüksek talep gerektiren iş yükünün gereksinimlerini karşılar. Bu makalede, bir müşteri için bu talebin nasıl karşılandığı ve Azure'ın kritik Oracle iş yüklerinizin taleplerini nasıl karşılayabildiğine ilişkin bir örnek sunulur.

Kurumsal ölçekli Oracle performansı

Performansın üst sınırlarını keşfederken, sonuçları yanlış şekilde çarpıtabilecek kısıtlamaları tanımak ve azaltmak önemlidir. Örneğin, amaç bir depolama sisteminin performans özelliklerini kanıtlamaksa, depolama performansı sınırlarına ulaşılmadan önce CPU'nun azaltıcı bir faktör haline gelmemesi için istemcinin ideal olarak yapılandırılması gerekir. Bu amaçla, bu VM yalnızca 100 Gb/sn ağ arabirimiyle değil, eşit derecede büyük (100 Gb/sn) çıkış sınırıyla birlikte geldiğinden test, E104ids_v5 örnek türüyle başladı.

Test iki aşamada gerçekleşti:

1. İlk aşama, Kevin Closson'un şimdi endüstri standardı olan SLOB2 (Silly Little Oracle Benchmark) aracını kullanarak teste odaklandı - sürüm 2.5.4. Amaç, bir sanal makineden (VM) birden çok Azure NetApp Files birimine mümkün olduğunca çok Oracle G/Ç'yi yönlendirmek ve ardından doğrusal ölçeklendirmeyi göstermek için daha fazla veritabanı kullanarak ölçeği genişletmektir.
2. Ölçeklendirme sınırlarını test ettikten sonra, testimiz gerçek bir Tedarik Zinciri uygulama iş yükü ve gerçek dünya verileri kullanılarak test aşamasına yönelik daha düşük maliyetli ancak neredeyse en uygun E96ds_v5 özetlendi.

SLOB2 ölçeği artırma performansı

Aşağıdaki grafikler, sekiz depolama uç noktasına sahip sekiz Azure NetApp Files birimine karşı tek bir Oracle 19c veritabanı çalıştıran tek bir E104ids_v5 Azure VM'sinin performans profilini yakalar. Birimler üç ASM disk grubuna yayılır: veriler, günlük ve arşiv. Veri disk grubuna beş birim, günlük disk grubuna iki birim ve arşiv disk grubuna bir birim ayrıldı. Bu makale boyunca yakalanan tüm sonuçlar üretim Azure bölgeleri ve etkin üretim Azure hizmetleri kullanılarak toplandı.

Birden çok depolama uç noktasında birden çok Azure NetApp Files birimi kullanarak Azure sanal makinelerinde Oracle dağıtmak için Oracle için uygulama birimi grubunu kullanın.

Tek konaklı mimari

Aşağıdaki diyagramda testin tamamlandığı mimari gösterilmiştir; Birden çok Azure NetApp Files birimine ve uç noktasına yayılmış Oracle veritabanını not edin.

Tek konaklı depolama GÇ

Aşağıdaki diyagramda veritabanı arabellek isabet oranı yaklaşık %8 olan rastgele seçilen %100 iş yükü gösterilmektedir. SLOB2, saniye başına yaklaşık 850.000 G/Ç isteği yönlendirirken bir yandan da alt milisaniye db dosyasının sıralı okuma olayı gecikme süresini koruyabildi. Yaklaşık 6.800 MiB/sn depolama aktarım hızına sahip 8K veritabanı blok boyutu ile.

Tek konak aktarım hızı

Aşağıdaki diyagramda, tam tablo taramaları veya RMAN etkinlikleri gibi bant genişliği yoğunluklu sıralı GÇ iş yükleri için Azure NetApp Files'ın E104ids_v5 VM'nin tüm bant genişliği özelliklerini sunabileceği gösterilmektedir.

SLOB2 ölçeği genişletme performansı

Aşağıdaki grafikler, her biri tek bir Oracle 19c veritabanı çalıştıran üç E104ids_v5 Azure VM'sinin ve her birinin kendi Azure NetApp Files birimleri kümesine ve performansı ölçeklendirme bölümünde açıklandığı gibi aynı ASM disk grubu düzenine sahip olan performans profilini yakalar. Grafiklerde, Azure NetApp Files ile çok birimli/çok uç noktalı performans, tutarlılık ve öngörülebilirlik ile kolayca ölçeklendirilebilir.

Çok konaklı mimari

Aşağıdaki diyagramda testin tamamlandığı mimari gösterilmiştir; Birden çok Azure NetApp Files birimine ve uç noktasına yayılmış üç Oracle veritabanını not edin. Uç noktalar Oracle VM 1'de gösterildiği gibi tek bir konağa bağlanabilir veya Oracle VM2 ve Oracle VM 3 ile gösterildiği gibi konaklar arasında paylaşılabilir.

Çok konaklı depolama GÇ

Aşağıdaki diyagramda veritabanı arabellek isabet oranı yaklaşık %8 olan rastgele seçilen %100 iş yükü gösterilmektedir. SLOB2, her üç konakta da saniyede yaklaşık 850.000 G/Ç isteği kullanabildi. SLOB2, her konağın sıralı okuma olayı gecikme süresini sürdürmeye devam ederken saniyede yaklaşık 2.500.000 G/Ç isteğine paralel olarak yürütürken bunu gerçekleştirebildi. 8K veritabanı blok boyutuyla bu, üç konak arasında yaklaşık 20.000 MiB/sn'ye eşittir.

Çok konaklı aktarım hızı

Aşağıdaki diyagramda sıralı iş yükleri için Azure NetApp Files'ın ölçeği genişletilirken bile E104ids_v5 VM'nin tam bant genişliği özelliklerini sunabileceği gösterilmektedir. SLOB2, paralel çalışırken üç konak arasında toplam 30.000 MiB/sn'den fazla G/Ç kullanabildi.

Gerçek dünya performansı

SLOB2 ile ölçeklendirme sınırları test edildikten sonra, azure netapp dosyalarında Oracle'a karşı gerçek sözcük tedarik zinciri uygulama paketiyle testler yapıldı ve mükemmel sonuçlar elde edildi. Oracle Otomatik İş Yükü Deposu (AWR) raporundan alınan aşağıdaki veriler, belirli bir kritik işin nasıl gerçekleştirdiğini gösteren vurgulanmış bir görünümdür.

Bu veritabanında geri dönüş etkinleştirildiğinden ve veritabanı bloğu boyutu 16k olduğundan uygulama iş yüküne ek olarak önemli miktarda ek GÇ vardır. AWR raporunun GÇ profili bölümünde, okumalara kıyasla yoğun yazma oranı olduğu açıkça görülüyor.

SLOB2 testinden 2,2 ms daha yüksek gecikme süresi gösteren veritabanı dosyası sıralı okuma bekleme olayına rağmen, bu müşteri Exadata'daki RAC veritabanından Azure'daki tek örnekli veritabanına gelen iş yürütme süresinde on beş dakikalık bir azalma gördü.

Azure kaynak kısıtlamaları

Tüm sistemler sonunda kaynak kısıtlamalarına (geleneksel olarak boğulma noktaları olarak bilinir) isabet eder. Özellikle tedarik zinciri uygulama paketleri gibi yüksek talep gerektiren veritabanı iş yükleri yoğun kaynak kullanımlı varlıklardır. Bu kaynak kısıtlamalarını bulmak ve bunların üzerinde çalışmak, başarılı dağıtımlar için çok önemlidir. Bu bölüm, yalnızca böyle bir ortamda karşılaşmayı bekleyebileceğiniz çeşitli kısıtlamaları ve bunları nasıl çalıştırabileceğinizi aydınlatmaktadır. Her alt bölüm için hem en iyi yöntemleri hem de bunların arkasındaki mantığı öğrenmeyi bekleyebilirsiniz.

Sanal makineler

Bu bölümde, en iyi performans için VM'lerin seçilmesinde dikkate alınması gereken ölçütler ve test için yapılan seçimlerin ardındaki gerekçe ayrıntılı olarak açıklanmıştır. Azure NetApp Files bir Ağa Bağlı Depolama (NAS) hizmetidir, bu nedenle uygun ağ bant genişliği boyutlandırması en iyi performans için kritik öneme sahiptir.

Yonga Kümeleri

İlgilenen ilk konu yonga kümesi seçimidir. Seçtiğiniz VM SKU'slarının tutarlılık nedeniyle tek bir yonga kümesinde oluşturulduğuna emin olun. E_v5 VM'lerin Intel çeşidi üçüncü Nesil Intel Xeon Platinum 8370C (Ice Lake) yapılandırmasında çalışır. Bu ailedeki tüm VM'ler tek bir 100 Gb/sn ağ arabirimi ile donatılmış olarak gelir. Buna karşılık, örnek olarak bahsedilen E_v3 serisi, çeşitli fiziksel ağ bant genişliklerine sahip dört ayrı yonga kümesi üzerine kurulmuştur. E_v3 ailesinde kullanılan dört yonga kümesi (Broadwell, Skylake, Cascade Lake, Haswell) makinenin performans özelliklerini etkileyen farklı işlemci hızlarına sahiptir.

Yonga kümesi seçeneklerine dikkatle dikkat ederek Azure İşlem belgelerini okuyun. Ayrıca Azure NetApp Files için en iyi Azure VM SKU'ları yöntemlerine de bakın. En iyi tutarlılık için tek yonga kümesine sahip bir VM seçmek tercih edilir.

Kullanılabilir ağ genişliği

VM ağ arabiriminin kullanılabilir bant genişliği ile aynı bant genişliğine uygulanan tarifeli bant genişliği arasındaki farkı anlamak önemlidir. Azure İşlem belgeleri ağ bant genişliği sınırlarını ifade ettiğinde, bu sınırlar yalnızca çıkışa (yazma) uygulanır. Giriş (okuma) trafiği tarifeli değildir ve bu nedenle yalnızca ağ arabirimi kartının (NIC) fiziksel bant genişliğiyle sınırlıdır. Çoğu VM'nin ağ bant genişliği, makineye uygulanan çıkış sınırını aşıyor.

Azure NetApp Files birimleri ağa bağlı olduğundan çıkış sınırı özellikle yazma işlemlerine uygulanıyor olarak anlaşılabilirken giriş okuma ve okuma benzeri iş yükleri olarak tanımlanır. Çoğu makinenin çıkış sınırı NIC'nin ağ bant genişliğinden büyük olsa da, bu makalede testte kullanılan E104_v5 için aynı şey söylenemez. E104_v5 çıkış sınırı da 100 Gb/sn olarak ayarlanmış 100 Gb/sn NIC'ye sahiptir. Karşılaştırmak gerekirse, 100 Gb/sn NIC'sine sahip E96_v5 giriş 100 Gb/sn'de kaldırılmış şekilde 35 Gb/sn çıkış sınırına sahiptir. VM'lerin boyutu azaldıkça çıkış sınırları azalır, ancak giriş mantıksal olarak uygulanan sınırlar tarafından değiştirilmez.

Çıkış sınırları VM genelindedir ve tüm ağ tabanlı iş yüklerine uygulanır. Oracle Data Guard kullanılırken, tüm yazma işlemleri arşiv günlüklerine iki katına alınır ve çıkış sınırıyla ilgili dikkat edilmesi gerekenler dikkate alınmalıdır. Bu durum, çok hedefli arşiv günlüğü ve kullanılıyorsa RMAN için de geçerlidir. VM'leri seçerken, Azure ağ arabirimi yapılandırmalarını belgelemediğinden NIC'nin yapılandırmasını kullanıma sunan gibi ethtoolkomut satırı araçları hakkında bilgi sahibi olun.

Ağ eşzamanlılığı

Azure VM'leri ve Azure NetApp Files birimleri belirli miktarda bant genişliğiyle donatılmış olarak gelir. Daha önce gösterildiği gibi, vm yeterli CPU giriş alanına sahip olduğu sürece, bir iş yükü teoride, ağ kartının ve uygulanan çıkış sınırının sınırları içinde yer alan, kullanıma sunulan bant genişliğini tüketebilir. Ancak uygulamada, elde edilebilen aktarım hızı miktarı, ağ akışlarının ve ağ uç noktalarının sayısı olan ağdaki iş yükünün eşzamanlılığından kaynaklanır.

Daha iyi anlamak için VM ağ bant genişliği belgesinin ağ akışı sınırları bölümünü okuyun. Çözüm: İstemciyi depolamaya bağlayan ağ akışları ne kadar fazla ise olası performans da o kadar zengin olur.

Oracle iki ayrı NFS istemcisini destekler: Çekirdek NFS ve Doğrudan NFS (dNFS). Çekirdek NFS, geç saatlere kadar iki uç nokta (işlem – depolama) arasında tek bir ağ akışını desteklemektedir. İkisinin daha yüksek performanslısı olan Direct NFS, değişken sayıda ağ akışını destekler. Testler uç nokta başına yüzlerce benzersiz bağlantı göstermiştir ve yük talebi olarak artar veya azalır. İki uç nokta arasındaki ağ akışlarının ölçeklenmesi nedeniyle, Çekirdek NFS yerine Doğrudan NFS çok tercih edilir ve bu nedenle önerilen yapılandırmadır. Azure NetApp Files ürün grubu, Oracle iş yükleriyle Çekirdek NFS kullanılmasını önermez. Daha fazla bilgi için Bkz. Azure NetApp Files'ı Oracle Veritabanı ile kullanmanın avantajları.

Yürütme eşzamanlılığı

Tutarlılık için tek bir yonga kümesi olan Doğrudan NFS'yi kullanmak ve ağ bant genişliği kısıtlamalarını anlamak sizi yalnızca şu ana kadar götürür. Sonunda, uygulama performansı destekler. SLOB2 kullanan kavram kanıtı ve gerçek müşteri verilerine karşı gerçek dünya tedarik zinciri uygulama paketi kullanan kavram kanıtı, yalnızca uygulamalar yüksek eşzamanlılık derecelerinde çalıştığından önemli miktarda aktarım hızı sağlayabildi; şema başına önemli sayıda iş parçacığı kullanan, ikincisi birden çok uygulama sunucusundaki birden çok bağlantıyı kullanan iş parçacığı. Kısacası eşzamanlılık iş yükünü, düşük eşzamanlılığı(düşük aktarım hızı, yüksek eşzamanlılık)altyapı aynı desteği sağlamak için uygun olduğu sürece yüksek aktarım hızını destekler.

Hızlandırılmış ağ

Hızlandırılmış ağ, bir VM'ye tek köklü G/Ç sanallaştırmasını (SR-IOV) etkinleştirerek VM'nin ağ performansını büyük ölçüde geliştirir. Bu yüksek performanslı yol, veri yolunda konağı atladığından, desteklenen sanal makine türlerinde üzerindeki en zorlu ağ iş yükleri için gecikme süresini ve CPU kullanımını azaltır. Terraform veya komut satırı gibi yapılandırma yönetimi yardımcı programları aracılığıyla VM'leri dağıtırken hızlandırılmış ağın varsayılan olarak etkinleştirilmediğini unutmayın. En iyi performans için hızlandırılmış ağı etkinleştirin. Hızlandırılmış ağın ağ arabirimi temelinde bir ağ arabiriminde etkinleştirildiğini veya devre dışı bırakıldığını unutmayın. Hızlandırılmış ağ özelliği, dinamik olarak etkinleştirilebilen veya devre dışı bırakılan bir özelliktir.

Bir NIC için hızlandırılmış ağ oluşturmak için yetkili bir yaklaşım Linux terminali üzerinden etkinleştirilir. Bir NIC için hızlandırılmış ağ etkinleştirildiyse, ilk NIC ile ilişkili ikinci bir sanal NIC vardır. Bu ikinci NIC, sistem tarafından bayrağı etkin olarak SLAVE yapılandırılır. Bayrağıyla birlikte SLAVE NIC yoksa, bu arabirim için hızlandırılmış ağ etkinleştirilmez.

Birden çok NIC'nin yapılandırıldığı senaryoda, NFS birimini bağlamak için kullanılan NIC ile hangi SLAVE arabirimin ilişkilendirileceğini belirlemeniz gerekir. SANAL makineye ağ arabirimi kartları eklemenin performans üzerinde hiçbir etkisi yoktur.

Yapılandırılan ağ arabirimi ile ilişkili sanal arabirimi arasındaki eşlemeyi tanımlamak için aşağıdaki işlemi kullanın. Bu işlem, Hızlandırılmış ağın Linux makinenizdeki belirli bir NIC için etkinleştirildiğini doğrular ve NIC'nin ulaşabileceği fiziksel giriş hızını görüntüler.

1. Komutunu yürüt:ip a
2. Doğrulamakta /sys/class/net/ olduğunuz NIC kimliğinin dizinini (eth0 örnekte) ve grep daha düşük sözcüğü için listeleyin:

   ls /sys/class/net/eth0 | grep lower lower_eth1
   

3. ethtool Önceki adımda daha düşük cihaz olarak tanımlanan ethernet cihazına karşı komutunu yürütür.

Azure VM: Ağ ve disk bant genişliği sınırları karşılaştırması

Azure VM performans sınırları belgelerini okurken uzmanlık düzeyi gereklidir. Aşağıdakilere dikkat edin:

• Geçici depolama aktarım hızı ve IOPS numaraları, doğrudan VM'ye bağlı kısa ömürlü yerleşik depolamanın performans özelliklerine başvurur.
• Kazınmamış disk aktarım hızı ve G/Ç numaraları özellikle Azure Disk'e (Premium, Premium v2 ve Ultra) başvurur ve Azure NetApp Files gibi ağa bağlı depolama alanı üzerinde hiçbir şey taşımaz.
• VM'ye ek NIC'lerin eklenmesi, VM'nin performans sınırlarını veya performans özelliklerini etkilemez (belgelenmiş ve doğru olarak test edilmiştir).
• Ağ bant genişliği üst sınırı, VM ağ bant genişliğine uygulanan çıkış sınırlarını (Azure NetApp Files söz konusu olduğunda yazma) ifade eder. Giriş sınırı (yani Azure NetApp Files söz konusu olduğunda okuma) uygulanmaz. Yeterli CPU, yeterli ağ eşzamanlılığı ve yeterince zengin uç noktalar göz önüne alındığında, vm giriş trafiğini teorik olarak NIC sınırlarına yönlendirebilir. Kullanılabilir ağ bant genişliği bölümünde belirtildiği gibi, NIC'nin bant genişliğini görmek için gibi ethtool araçları kullanın.

Başvuru için örnek grafik gösterilir:

Azure NetApp Files

Azure birinci taraf depolama hizmeti Azure NetApp Files, daha önce sunulan zorlu Oracle iş yüklerini destekleyebilecek yüksek oranda kullanılabilir, tam olarak yönetilen bir depolama çözümü sağlar.

Oracle veritabanındaki ölçeği artırma depolama performansının sınırları iyi anlaşıldığı için, bu makale kasıtlı olarak genişleme depolama performansına odaklanır. Depolama performansının ölçeğinin genişletilmesi, bu birimlerin birden çok depolama uç noktası üzerinden dağıtıldığı birçok Azure NetApp Files birimine tek bir Oracle örneği erişimi verilmesi anlamına gelir.

Bir veritabanı iş yükünü birden çok birim arasında bu şekilde ölçeklendirerek, veritabanının performansı hem birim hem de uç nokta üst sınırlarından çıkarılır. Depolama artık performans sınırlamaları eklemediğinden, VM mimarisi (CPU, NIC ve VM çıkış sınırları) ile devam etmek için boğma noktası haline gelir. VM bölümünde belirtildiği gibi, E104ids_v5 ve E96ds_v5 örneklerin seçilmesi göz önünde bulundurularak yapılmıştır.

Veritabanının tek bir büyük kapasite hacmine yerleştirilmesi veya birden çok küçük birime yayılması fark etmez, toplam finansal maliyet aynıdır. G/Ç'yi tek bir birim ve uç noktanın aksine birden çok birime ve uç noktaya dağıtmanın avantajı, bant genişliği sınırlarının ortadan kalkmasıdır; tamamen ödediğiniz miktarı kullanabilirsiniz.

Veritabanı

Oracle'ın veritabanı sürümü 19c, Oracle'ın geçerli uzun vadeli sürüm sürümüdür ve bu makalede ele alınan tüm test sonuçlarını üretmek için kullanılan sürümdür.

En iyi performans için, tüm veritabanı birimleri Doğrudan NFS kullanılarak bağlanmıştır; performans kısıtlamaları nedeniyle Çekirdek NFS'ye karşı önerilir. İki istemci arasında performans karşılaştırması için Bkz. Azure NetApp Files tek birimlerinde Oracle veritabanı performansı. Azure NetApp Files kullanarak Microsoft Azure'da Oracle Veritabanları raporunda açıklanan en iyi yöntemler gibi tüm ilgili dNFS düzeltme eklerinin (Oracle Destek Kimliği 1495104) uygulandığını unutmayın.

Oracle ve Azure NetApp Files hem NFSv3 hem de NFSv4.1'i desteklese de, NFSv3 daha olgun bir protokol olduğundan genellikle en kararlılığa sahip olarak görüntülenir ve kesintiye karşı son derece hassas ortamlar için daha güvenilir bir seçenektir. Bu makalede açıklanan testin tümü NFSv3 üzerinden tamamlandı.

NFS birimleri için Otomatik Depolama Yönetimi (ASM) desteklenir. ASM'nin hem mantıksal birim yönetiminin (LVM) hem de dosya sisteminin yerini aldığı blok tabanlı depolama ile ilişkili olsa da, ASM çok birimli NFS senaryolarında değerli bir rol oynar ve önemli bir değerlendirmeye değerdir. ASM'nin bu tür avantajlarından biri, yeni eklenen NFS birimleri ve uç noktaları arasında dinamik çevrimiçi ekleme ve yeniden dengeleme, yönetimi basitleştirerek hem performansın hem de kapasitenin istediğiniz zaman genişletilmesine olanak tanır. ASM kendi içinde ve kendi başına veritabanının performansını artırmasa da, kullanımı sık erişimli dosyaları önler ve dosya dağıtımını el ile sürdürme gereksinimini ortadan kaldırır. Bu, kolayca görülmesi gereken bir avantajdır.

Bu makalede ele alınan tüm test sonuçlarını üretmek için dNFS üzerinden ASM yapılandırması kullanılmıştır. Aşağıdaki diyagramda, Azure NetApp Files birimlerindeki ASM dosya düzeni ve ASM disk gruplarına dosya ayırma gösterilmektedir.

Bazı mimari konuların üstesinden gelinebilecek depolama anlık görüntüleri söz konusu olduğunda Azure NetApp Files NFS'ye bağlı birimler üzerinde ASM kullanımıyla ilgili bazı sınırlamalar vardır. Bu konuları ayrıntılı olarak gözden geçirmek için Azure NetApp Files uzmanınıza veya bulut çözümleri mimarınıza başvurun.

Sentetik test araçları ve tonlamalar

Bu bölümde, belirli test mimarisi, ayarlanabilirler ve yapılandırma ayrıntıları açıklanmaktadır. Önceki bölüm, yapılandırma kararlarının neden alındığına odaklanmış olsa da, bu bölüm özellikle yapılandırma kararlarının "ne" bölümüne odaklanır.

Otomatik dağıtım

• Veritabanı VM'leri GitHub'da bulunan bash betikleri kullanılarak dağıtılır.
• Birden çok Azure NetApp Files biriminin ve uç noktasının düzeni ve ayırması el ile tamamlanır. Yardım için Azure NetApp Files Uzmanınızla veya Bulut Çözümü Mimarınızla birlikte çalışmanız gerekir.
• Her makinede kılavuz yüklemesi, ASM yapılandırması, veritabanı oluşturma ve yapılandırma ve SLOB2 ortamı tutarlılık için Ansible kullanılarak yapılandırılır.
• Birden çok konak arasında paralel SLOB2 test yürütmeleri de tutarlılık ve eşzamanlı yürütme için Ansible kullanılarak tamamlanır.

VM yapılandırması

Sistem yapılandırması

Sürüm 19c için tüm Oracle gerekli sistem yapılandırma ayarları Oracle belgelerine göre uygulandı.

Linux sistem dosyasına aşağıdaki parametreler eklendi /etc/sysctl.conf :

• sunrpc.max_tcp_slot_table_entries: 128
• sunrpc.tcp_slot_table_entries = 128

Azure NetApp Files

Tüm Azure NetApp Files birimleri aşağıdaki NFS bağlama seçenekleriyle bağlanmıştır.

nfs rw,hard,rsize=262144,wsize=262144,sec=sys,vers=3,tcp

Veritabanı parametreleri

SLOB2 yapılandırması

Test için tüm iş yükü oluşturma işlemi SLOB2 aracı sürüm 2.5.4 kullanılarak tamamlandı.

Listelenen slob yapılandırma dosyası ayarlarıyla birlikte SLOB2 veri kümesini 7 TiB'ye koyan on dört SLOB2 şeması standart bir Oracle tablespace'e yüklendi ve üzerinde yürütüldü. Aşağıdaki ayarlar SLOB2 için rastgele okuma yürütmesini yansıtır. Sıralı test sırasında yapılandırma parametresi SCAN_PCT=0 olarak SCAN_PCT=100 değiştirildi.

• UPDATE_PCT=0
• SCAN_PCT=0
• RUN_TIME=600
• SCALE=450G
• SCAN_TABLE_SZ=50G
• WORK_UNIT=32
• REDO_STRESS=LITE
• THREADS_PER_SCHEMA=1
• DATABASE_STATISTICS_TYPE=awr

Rastgele okuma testi için dokuz SLOB2 yürütmesi gerçekleştirildi. Her test yinelemesi birden başlayarak iş parçacığı sayısı altı artırıldı.

Sıralı test için yedi SLOB2 yürütmesi gerçekleştirildi. her test yinelemesi birden başlayarak iş parçacığı sayısı iki artırıldı. Ağ bant genişliği üst sınırına ulaşılması nedeniyle iş parçacığı sayısı altıda eşlendi.

AWR ölçümleri

Tüm performans ölçümleri Oracle Otomatik İş Yükü Deposu (AWR) aracılığıyla bildirilmiştir. Sonuçlarda gösterilen ölçümler şunlardır:

• Aktarım hızı: AWR Yük Profili bölümünden ortalama okuma aktarım hızının ve yazma aktarım hızının toplamı
• AWR Yük Profili bölümünden ortalama okuma GÇ istekleri
• AWR Ön Plan Bekleme Olayları bölümünden veritabanı dosyası sıralı okuma bekleme olayı ortalama bekleme süresi

Amaca yönelik, tasarlanmış sistemlerden buluta geçiş

Oracle Exadata, Oracle iş yüklerini çalıştırmaya yönelik en iyi duruma getirilmiş çözüm olarak kabul edilen donanım ve yazılımların birleşimi olan, tasarlanmış bir sistemdir. Bulut, teknik dünyanın genel şemasında önemli avantajlara sahip olsa da, bu özel sistemler Oracle'ın kendi iş yükleri etrafında oluşturduğu iyileştirmeleri okuyan ve görüntüleyenler için inanılmaz derecede çekici görünebilir.

Oracle'ı Exadata üzerinde çalıştırma konusunda Exadata'nın seçilmesinin bazı yaygın nedenleri vardır:

• Exadata özelliklerine doğal olarak uyan 1-2 yüksek GÇ iş yükü ve bu iş yükleri exadata tarafından tasarlanmış önemli özellikler gerektirdiğinden, bunlarla birlikte çalışan veritabanlarının geri kalanı Exadata'da bir araya getirilmiştir.
• RAC'nin ölçeklendirilmesini gerektiren karmaşık veya zor OLTP iş yükleri, Oracle iyileştirmesi hakkında derin bilgi sahibi olmadan özel donanımla mimari oluşturması zordur veya teknik borç iyileştirilemeyebilir.
• Çeşitli iş yükleriyle mevcut Exadata'nın kullanım dışı bırakılması: Bu durum önceki geçişler, önceki bir Exadata'daki kullanım ömrü sonu veya bir Exadata'yı şirket içinde çalışma/test etme isteğinden kaynaklanmıştır.

Bir Exadata sisteminden yapılan tüm geçişlerin iş yükleri açısından anlaşılması ve geçişin ne kadar basit veya karmaşık olabileceği önemlidir. İkincil bir gereksinim, Exadata satın alma nedenini durum açısından anlamaktır. Exadata ve RAC becerileri daha yüksek talep görüyor ve teknik paydaşlar tarafından satın alınması önerisini yönlendirmiş olabilir.

Bu iş yükü fırsatlarını değerlendirmek için kullanılabilecek çeşitli araçlar vardır:

• Otomatik İş Yükü Deposu (AWR):
  • Tüm Exadata veritabanları, AWR raporlarını ve bağlı performans ile tanılama özelliklerini kullanma lisansına sahiptir.
  • Her zaman açık ve geçmiş iş yükü bilgilerini görüntülemek ve kullanımı değerlendirmek için kullanılabilecek verileri toplar. En yüksek değerler sistemdeki yüksek kullanımı değerlendirebilir,
  • Daha büyük bir pencere AWR raporları, genel iş yükünü değerlendirerek özellik kullanımı ve iş yükünün Exadata olmayanlara etkili bir şekilde nasıl geçirilmesine ilişkin değerli içgörüler sağlar. Buna karşılık en yüksek AWR raporları performans iyileştirme ve sorun giderme için en iyisidir.
• Exadata için Genel (RAC-Aware) AWR raporu, belirli Exadata özellik kullanımına inen ve veritabanı ve hücre düğümüne göre değerli içgörü bilgileri flash önbelleği, flash günlüğü, GÇ ve diğer özellik kullanımı sağlayan Exadata'ya özgü bir bölüm de içerir.

Exadata'dan ayırma

Buluta geçiş için Oracle Exadata iş yüklerini tanımlarken aşağıdaki soruları ve veri noktalarını göz önünde bulundurun:

• İş yükü, donanım avantajları dışında birden çok Exadata özelliği mi kullanıyor?
  • Akıllı taramalar
  • Depolama dizinleri
  • Flash önbellek
  • Hızlı günlüğe kaydetme
  • Karma sütunlu sıkıştırma
• Exadata yük boşaltmasını kullanan iş yükü verimli bir şekilde mi yükleniyor? İlk zaman ön plan olaylarında, iş yükünün oranı (VERITABANı süresinin %10'undan fazlası) nedir:
  • Hücre akıllı tablo taraması (en uygun)
  • Hücre çok bloklu fiziksel okuma (daha az en uygun)
  • Tek bloklu hücre fiziksel okuma (en düşük en uygun)
• Karma Sütunlu Sıkıştırma (HCC/EHCC): Sıkıştırılmış ve sıkıştırılmamış oranlar nedir:
  • Veritabanı, verilerin sıkıştırılması ve sıkıştırılması için veritabanı zamanının %10'undan fazla mı harcıyor?
  • Sorgularda sıkıştırmayı kullanarak koşullarda performans artışlarını inceleyin: Elde edilen değer, sıkıştırma ile kaydedilen tutara kıyasla buna değer mi?
• Hücre fiziksel GÇ: Aşağıdakilerden sağlanan tasarrufları inceleyin:
  • CPU dengelemek için VERITABANı düğümüne yönlendirilen tutar.
  • akıllı tarama tarafından döndürülen bayt sayısını belirleme. Bu değerler, Exadata dışına geçirildikten sonra tek bloklu fiziksel okuma hücresinin yüzdesi için GÇ'de çıkarılabilir.
• Önbellekten mantıksal okuma sayısını not edin. İş yükü için bir bulut IaaS çözümünde flash önbelleğin gerekli olup olmadığını belirleyin.
• Fiziksel okuma ve yazma toplam baytlarını önbellekte gerçekleştirilen toplam miktarla karşılaştırın. Fiziksel okuma gereksinimlerini ortadan kaldırmak için bellek yükseltilebilir mi (bazılarında Exadata için boşaltmayı zorlamak için SGA'nın küçültülmesi yaygındır)?
• Sistem İstatistikleri'nde hangi nesnelerin hangi istatistiklerden etkilendiğini belirleyin. SQL'i ayarlama, daha fazla dizin oluşturma, bölümleme veya diğer fiziksel ayarlamalar iş yükünü önemli ölçüde iyileştirir.
• Alt çizgi (_) veya kullanım dışı parametreler için Başlatma Parametrelerini inceleyin. Bu parametreler, performans üzerinde neden olabilecek veritabanı düzeyi etkisi nedeniyle gerekçelendirilmelidir.

Exadata sunucu yapılandırması

Oracle sürüm 12.2 ve üzeri sürümlerde, AWR genel raporuna Exadata'ya özgü bir ekleme eklenecektir. Bu rapor, Exadata'dan geçişe olağanüstü değer sağlayan bölümlere sahiptir.

• Exadata sürümü ve sistem ayrıntıları

• Hücre düğümü uyarıları ayrıntısı

• Exadata doğrusal olmayan diskler

• Tüm Exadata işletim sistemi istatistikleri için aykırı veriler

  • Sarı/Pembe: Endişe konusu. Exadata en iyi şekilde çalışmıyor.

  • Kırmızı: Exadata performansı önemli ölçüde etkilenir.

  • Exadata işletim sistemi CPU istatistiği: en üst hücreler

    • Bu istatistikler hücrelerdeki işletim sistemi tarafından toplanır ve bu veritabanı veya örneklerle sınırlı değildir
    • A v ve koyu sarı arka plan, düşük aralığın altında aykırı değer olduğunu gösterir
    • A ^ ve açık sarı arka plan, yüksek aralığın üzerinde aykırı değer olduğunu gösterir
    • CPU yüzdesine göre en üstteki hücreler görüntülenir ve CPU yüzdesinin azalan sırasına göredir
    • Ortalama: %39,34 CPU, %28,57 kullanıcı, %10,77 sys

    

• Tek hücreli fiziksel blok okumaları

• Flash önbellek kullanımı

• Geçici GÇ

• Sütunlu önbellek verimliliği

GÇ aktarım hızına göre en iyi veritabanı

Boyutlandırma değerlendirmeleri yapılasa da, büyük iş yükleri için bu değerlerde yerleşik olarak bulunan ortalamalar ve simülasyon tepeleri hakkında bazı sorular vardır. AWR raporunun sonunda bulunan bu bölüm, Exadata'daki ilk 10 veritabanının hem ortalama flash hem de disk kullanımını gösterdiğinden son derece değerlidir. Çoğu kişi veritabanlarını bulutta en yüksek performans için boyutlandırmak istediğini düşünse de, bu durum çoğu dağıtım için anlamlı değildir (%95'in üzerinde ortalama aralıktadır; sanal tepe değerinin hesaplanmasıyla ortalama aralık %98'den büyük olur. Oracle'ın en yüksek talep iş yükleri için bile gerekenleri ödemek önemlidir ve GÇ Aktarım Hızına Göre En İyi Veritabanlarını incelemek, veritabanı için kaynak gereksinimlerini anlamak için aydınlatıcı olabilir.

Exadata'da AWR kullanarak Oracle'ı doğru boyutlandırma

Şirket içi sistemler için kapasite planlaması yaparken, donanımda önemli ek yüklerin olması doğaldır. Aşırı sağlanan donanımın veri büyümesi, kod değişiklikleri veya yükseltmeler nedeniyle iş yükü eklemeleri ne olursa olsun oracle iş yüküne birkaç yıl hizmet vermesi gerekir.

Bulutun avantajlarından biri, vm konağındaki kaynakları ölçeklendirmektir ve talepler arttıkça depolama gerçekleştirilebilir. Bu, işlemci kullanımına bağlı (Oracle ile ilgili) bulut maliyetlerini ve lisanslama maliyetlerinin korunmasına yardımcı olur.

Doğru boyutlandırma, donanımı geleneksel lift-and shift geçişinden kaldırmayı ve Oracle'ın Otomatik İş Yükü Deposu (AWR) tarafından sağlanan iş yükü bilgilerini kullanarak iş yükünü müşterinin tercih ettiği bulutta desteklemek üzere özel olarak tasarlanmış işlem ve depolamaya taşımayı içerir. Doğru boyutlandırma işlemi, bundan sonra mimarinin altyapı teknik borcunu, şirket içi sistemin çoğaltılması durumunda ortaya çıkabilecek mimari yedekliliğini ortadan kaldırmasını ve mümkün olduğunda bulut hizmetlerini uygulamasını sağlar.

Microsoft Oracle konu uzmanları Oracle veritabanlarının %80'inden fazlasının fazla sağlandığını ve buluta geçişten önce Oracle veritabanı iş yükünü doğru boyutlandırmaya zaman ayırdıkları takdirde aynı maliyetten veya tasarruftan yararlandığını tahmin ettiler. Bu değerlendirme, ekipteki veritabanı uzmanlarının geçmişte kapasite planlamasını nasıl gerçekleştirebileceklerine ilişkin fikirlerini değiştirmelerini gerektirir, ancak paydaşın buluta yaptığı yatırıma ve işletmenin bulut stratejisine değer.

Sonraki adımlar

• Performans veya Ölçeklenebilirlikten Ödün Vermeden Azure'da En Zorlu Oracle İş Yüklerinizi Çalıştırma
• Azure NetApp Files kullanarak çözüm mimarileri - Oracle
• Azure'da Oracle veritabanı tasarlama ve uygulama
• Oracle İş Yüklerini Azure IaaS VM'lerine Boyutlandırmak için Tahmin Aracı
• Azure'da Oracle Veritabanı Enterprise Sürümü için başvuru mimarileri
• SAP HANA için Azure NetApp Files uygulama birimleri gruplarını anlama