Bu kısa yazıyla Oracle Exadata üzerinde çalışan AWR veritabanlarının analiziyle ilgili bir yanlış anlaşılmayı ortadan kaldırmak istiyorum. Neredeyse 10 yıldır sürekli olarak şu soruyla karşı karşıya kalıyorum: Exadata Yazılımının verimliliğe katkısı nedir? Veya yeni türetilmiş sözcükleri kullanırsak: Belirli bir veritabanının çalışması ne kadar “uzman”dır?
Bana göre bu doğru soru çoğu zaman AWR istatistiklerine göre yanlış cevaplanıyor. Yanıt süresini işlemcilerin (DB CPU'lar) çalışma süresi ile çeşitli sınıfların bekleme sürelerinin toplamı olarak ele alan sistem bekleme yöntemini sunar.
Exadata'nın gelişiyle birlikte, Exadata Yazılımının çalışmasına ilişkin spesifik sistem beklentileri AWR istatistiklerinde ortaya çıktı. Kural olarak, bu tür beklemelerin adları "hücre" kelimesiyle başlar (Exadata Depolama sunucusuna hücre denir), bunların en yaygın olanı "hücre akıllı tablo taraması", "hücre çoklu bloğu" gibi açıklayıcı adlarla beklemelerdir. fiziksel okuma” ve “hücre tek blok fiziksel okuma”.
Çoğu durumda, bu tür Exadata beklemelerinin toplam yanıt süresi içindeki payı küçüktür ve bu nedenle Toplam Bekleme Süresine göre İlk 10 Ön Plan Olayı bölümüne bile girmezler (bu durumda, bunları Ön Plan Beklemesinde aramanız gerekir) Etkinlikler bölümü). Büyük zorluklarla müşterilerimizden gelen, Exadata beklentilerinin Top10 bölümünde yer aldığı ve toplamda yaklaşık %5 tutarında bir günlük AWR örneği bulduk:
Etkinlikler
bekler
Toplam Bekleme Süresi (sn)
Ort Bekleme
%DB zamanı
Sınıfı Bekle
Veritabanı CPU'su
115.2K
70.4
SQL*Net dblink'ten daha fazla veri
670,196
5471.5
8.16ms
3.3
ağ
hücre tek blok fiziksel okuma
5,661,452
3827.6
676.07us
2.3
Kullanıcı G/Ç'si
ASM yeniden dengelemesini senkronize et
4,350,012
3481.3
800.30us
2.1
Diğer
hücre çoklu blok fiziksel okuma
759,885
2252
2.96ms
1.4
Kullanıcı G/Ç'si
doğrudan yol okuma
374,368
1811.3
4.84ms
1.1
Kullanıcı G/Ç'si
dblink'ten SQL*Net mesajı
7,983
1725
216.08ms
1.1
ağ
hücre akıllı masa taraması
1,007,520
1260.7
1.25ms
0.8
Kullanıcı G/Ç'si
doğrudan yol okuma sıcaklığı
520,211
808.4
1.55ms
0.5
Kullanıcı G/Ç'si
enq: TM - çekişme
652
795.8
1220.55ms
0.5
Uygulama
Bu tür AWR istatistiklerinden sıklıkla aşağıdaki sonuçlar çıkarılır:
1. Exadata büyüsünün veritabanı performansına katkısı yüksek değil - %5'i geçmiyor ve veritabanı zayıf bir şekilde "exadatize ediliyor".
2. Böyle bir veritabanı Exadata'dan klasik “sunucu + dizi” mimarisine aktarılırsa performansta pek bir değişiklik olmayacaktır. Çünkü bu dizinin Exadata depolama sisteminden üç kat daha yavaş olduğu ortaya çıksa bile (bu, modern All Flash dizileri için pek mümkün değildir), o zaman %5'i üçle çarptığımızda G/Ç bekleme payında %15'e kadar bir artış elde ederiz. - veritabanı kesinlikle bundan kurtulacak!
Bu sonuçların her ikisi de hatalıdır ve ayrıca Exadata Yazılımının ardındaki fikrin anlaşılmasını bozmaktadır. Exadata yalnızca hızlı I/O sağlamakla kalmaz, aynı zamanda klasik sunucu + dizi mimarisiyle karşılaştırıldığında temel olarak farklı çalışır. Veritabanı işlemi gerçekten "exadapted" ise, SQL mantığı depolama sistemine aktarılır. Depolama sunucuları, bir dizi özel mekanizma (öncelikle Exadata Depolama İndeksleri, ancak yalnızca bu değil) sayesinde gerekli verileri kendileri bulur ve DB'yi sunuculara gönderir. Bunu oldukça verimli bir şekilde yapıyorlar, dolayısıyla tipik Exadata beklemelerinin toplam yanıt süresi içindeki payı küçüktür.
Bu paylaşım Exadata dışında nasıl değişecek? Bu, bir bütün olarak veritabanının performansını nasıl etkileyecektir? Testler bu sorulara en iyi cevabı verecektir. Örneğin, Exadata dışında bir "hücre akıllı masa taraması" için beklemek, G/Ç'nin tüm yanıt süresini kaplayacağı ve performansın önemli ölçüde düşeceği kadar ağır bir Tam Tablo Taramasına dönüşebilir. Bu nedenle, AWR'yi analiz ederken Exadata beklentilerinin toplam yüzdesini, büyüsünün performansa katkısı olarak düşünmek ve hatta bu yüzdeyi Exadata dışındaki performansı tahmin etmek için kullanmak yanlıştır. Veritabanının çalışmasının ne kadar "kesin" olduğunu anlamak için, "Örnek Etkinlik İstatistikleri" bölümünün AWR istatistiklerini incelemeniz (kendini açıklayan adlara sahip çok sayıda istatistik vardır) ve bunları birbirleriyle karşılaştırmanız gerekir.
Exadata dışındaki bir veritabanının nasıl hissedeceğini anlamak için hedef mimarideki bir yedekten veritabanı klonu oluşturmak ve bu klonun yük altındaki performansını analiz etmek en iyisidir. Kural olarak Exadata sahipleri bu fırsata sahiptir.
Yazar: Alexey Struchenko, Jet Infosystems veritabanı departmanı başkanı
Kaynak: habr.com