Herhangi bir sorgu için kullanılabilen paralellik derecesini (DOP) sınırlayın

Oracle Exadata'da (11gR2), nispeten kaslı bir veritabanımız var.

• cpu_count 24
• parallel_server_instances 2'dir
• parallel_threads_per_cpu 2'dir

Oracle Enterprise Manager'da (OEM) gözlem yaparak, seri olarak yürütülen sorgular nedeniyle performansın korkunç olduğunu belirledik. Bunu çözmek için tüm tablolar, somutlaştırılmış görünümler ve indeksler paralellikten faydalanmak üzere değiştirildi. Örneğin:

ALTER TABLE SOME_TABLE PARALLEL (DEGREE DEFAULT INSTANCES DEFAULT);

Sistem paralelleştirmeyi açmak için değiştirildi:

ALTER SYSTEM SET PARALLEL_DEGREE_POLICY = 'AUTO';

Bu, daha iyi performans ile sonuçlandı, ancak zaman zaman OEM'de tek bir sorgunun 96 DOP'yi (mevcut tüm kaynak) bağlayacağını gözlemledik. Bu, sonraki sorguların 1 DOP'a düşürülmesine neden oldu (paralelleştirme yok). Domuzlama sorgusu tamamlanıncaya kadar düşük performans.

Bu sorunu çözmek için herhangi bir sorgu için kullanılabilir olan DOP'yi aşağıdakilerle sınırlandırmaya çalıştık:

ALTER SYSTEM SET PARALLEL_DEGREE_LIMIT = 24;

Bunun bir etkisi yoktu. Sınırdan daha fazlasını kullanacak olan sorguları sık sık gözlemleriz (genellikle 48 veya 96, ancak gerçek kalıp yoktur).

Herhangi bir sorgunun kullanılabilir kaynağın tümünü atlamasını nasıl önleyebiliriz?

Paralel Sunucu Kümeleri: PARALLEL_DEGREE_LIMIT paralellik derecesini sınırlar, ancak sorgunuz sıralıyorsa veya gruplandırıyorsa, paralel işlemlerin sayısı iki kat daha fazla olabilir (süreçler arası paralelliğin etkinleştirilmesi için iki sunucu kümesi). Bu, 24'lü bir sınırla bile neden 48 paralel işlem göreceğinizi açıklar. Bu, DOP'u sınırlamak için kaynak yöneticisi kullanıyorsanız da olur.

Paralel ipuçları: PARALLEL_DEGREE_LIMIT yalnızca otomatik paralellik derecesini kullanan ifadeler için geçerlidir. Sabit kodlanmış bir derece veya herhangi bir nesne düzeyinde paralel ipucu kullanan herhangi bir ifade, sınırı göz ardı edecektir. Bu ipuçlarına sahipseniz, neden 96'yı neden gördüğünüzü açıklayabilir.

IO'yu Kalibre Et: Belki otomatik DOP kullanılmıyor ve bu nedenle IO kalibre edilmediğinden limit takip edilmiyor . Bu sorgu, ES'nin kalibre edilip edilmediğini size söyleyecektir:

select * from V$IO_CALIBRATION_STATUS;

Daha önce bu sorunlara neden olduğunu gördüm, ancak mevcut sistemim kalibre edilmedi ve otomatik DOP iyi çalışıyor gibi görünüyor. Açıklama planının Notlar bölümüne bakarak bunun gerçekten bir sorun olup olmadığını anlayabilirsiniz. İyi gibi bir şey görürsen - automatic DOP: Computed Degree of Parallelism is 2, ama görmek istemezsen automatic DOP: skipped because of IO calibrate statistics are missing.

PARALLEL_MAX_SERVERS'ı artırın: Paralel sunucuların tükenmesi konusunda endişelenmek yerine PARALLEL_MAX_SERVERS'ı önemli ölçüde artırmanızı öneririm. Bellek ayarlarınıza bağlı olarak en azından varsayılan değere , PARALLEL_THREADS_PER_CPU x CPU_COUNT x eşzamanlı_paralel_kullanıcı x 5, 240 ile 960 arasında geri dönmeye çalışmalısınız .

Bu yüksek rakamlar birçok DBA'ya saçma geliyor, ancak aslında aşağıdaki nedenlerden dolayı çok mantıklı geliyorlar:

• Oracle paralel sunucuları çoğu insanın sandığından daha hafiftir. (Ve neredeyse hiç kimse bunu test etmez, sadece büyük bir DOP'un soruna neden olduğu bir durum bulur ve yüksek DOP'un her zaman kötü olduğunu varsayarlar.)
• Bir GUI aracında yalnızca ilk 50 satırı alan ancak düzinelerce paralel sunucu kullanan bir adhoc sorgusu çalıştırmak yaygındır. PARALLEL_MAX_SERVERS çok düşük olmadığı sürece bu sorgular önemli miktarda kaynak tüketmez. Sonra insanlar çirkin durumlara yol açabilecek mükemmel makul sorgular yürüttüler.
• Tek bir sorgu için çok büyük bir DOP her zaman kötü değildir. Herkes DOP'yi artırmaya devam ederseniz, ek yükün çok yükseleceğini ve performansın önemli ölçüde düşeceğini varsayar. Ancak birçok sistemde, gülünç derecede yüksek bir DOP'nin bile, kesinlikle azalan geri dönüşler olmasına rağmen, daha iyi performansa yol açacağını ve diğer oturumlara çok haksız olabileceğini buldum. Ama sadece tahmin etme, test et; bir sorgu alın ve 1000'e kadar her türlü DOP ile çalıştırın.
• Evet, çok fazla paralellik kötü olabilir. Ancak, optimum oturum sayısından biraz daha fazlasına sahip olmak veya bir sorguyu seriye zorlamak ve temelde önemli bir işi öldürmek için sistem için daha kötü olan nedir? Rasgele sınırlar getirmeden önce sistemi izlemelisiniz.