Mimari Bileşenler

Oracle Database, iş yüklerinin sistem kaynakları üzerindeki rekabetini yönetmek için hiyerarşik ve plan tabanlı bir mimari sunar. Bu mimarinin temelinde, Consumer Group (Tüketici Grubu), Resource Plan (Kaynak Planı), Resource Plan Directive (Kaynak Plan Yönergesi) ve Resource Manager Scheduler (Kaynak Yöneticisi Zamanlayıcısı) gibi bileşenler bulunur. Her bileşen, kaynak tahsisinin farklı bir soyutlama katmanını temsil eder ve birbirleriyle katı bir hiyerarşi içinde etkileşime girer.

Tüketici grupları, kaynak tüketim profilleri ve öncelikleri benzer olan kullanıcı oturumlarının mantıksal kümeleridir. Bir oturum, bir tüketici grubuna atanarak, o gruba tanımlanmış olan kaynak limitleri ve önceliklerine tabi olur. Örneğin, OLTP_USERS, BATCH_JOBS, REPORTING_USERS gibi gruplar oluşturulabilir. Gruplar, otomatik veya manuel olarak atanabilir.

Bileşen Açıklama İlişki
Resource Plan Bir veya daha fazla tüketici grubuna kaynak tahsisini tanımlayan ana şemadır. Bir Plan, birden fazla Yönerge içerir. Her Yönerge bir Grup için kuralları belirler.
Plan Directive Belirli bir tüketici grubunun bir kaynak planı altında nasıl kaynak alacağını detaylandıran kuraldır.
Consumer Group Benzer kaynak ihtiyaçlarına sahip kullanıcı oturumlarının kümesi. Birden fazla Plan'a dahil edilebilir, ancak aktif bir Plan içinde olmalıdır.
Scheduler CPU tahsisini zaman dilimleri (time slices) bazında yöneten çekirdek altyapı bileşenidir. Plan Yönergelerini işletim sistemi seviyesine yakın bir seviyede uygular.

Bu bileşenlerin etkileşimi, veritabanının çok katmanlı hizmet kalitesi (QoS) sağlamasını mümkün kılar. Kaynak Yöneticisi, işletim sistemi seviyesindeki kaynak yönetimi araçlarından farklı olarak, Oracle SGA ve PGA bellek havuzları, paralel sorgu sunucuları ve I/O talepleri gibi veritabanına özgü kaynakları anlar ve kontrol eder. Bu bağlamda, veritabanı içi kaynak izolasyonu sağlamanın en etkili yoludur.

Mimari, active session pool, queueing ve automatic consumer group switching gibi mekanizmalarla desteklenir. CPU kullanımı için paylaşım yüzdeleri (CPU_Pn) veya mutlak kullanım sınırları (UTILIZATION_LIMIT) gibi çeşitli metodolojilerle çalışarak, yöneticiye yüksek seviyede esneklik sunar. Kilit nokta, bu bileşenlerin birlikte çalışarak, tek bir veritabanı örneğinde farklı iş yükü sınıflarının birbirlerinin performansını kritik şekilde etkilemesini önlemesidir.

Plan Yapısı

Bir Oracle Resource Manager planının yapısı, bir ağaç (tree) veya hiyerarşik model olarak kavramsallaştırılabilir. Bu hiyerarşinin en üst seviyesinde, planın kendisi yer alır. Plan, çok seviyeli (multi-level) bir yapıda olabilir; bu sayede kaynakların tahsisi sadece birinci seviye gruplar arasında değil, alt gruplar arasında da bölünebilir. Örneğin, DAY_PLAN adlı bir ana plan, OLTP ve REPORTS adlı iki alt plan veya tüketici grubunu içerebilir.

Her seviyedeki kaynak dağılımı, bir üst seviyeden kendisine ayrılmış pay üzerinden hesaplanır. Bu, kritik öneme sahip bir esneklik sağlar: Üst seviyede belirlenen genel bir pay, alt seviyelerde daha da detaylandırılabilir. Örneğin, CPU kaynağının %70'i OLTP grubuna, %30'u REPORTS grubuna ayrılmış olabilir. Daha sonra, REPORTS grubunun kendi içindeki %30'luk pay, ACCOUNTING_REPORTS ve SALES_REPORTS gibi alt gruplara %50-%50 gibi oranlarla dağıtılabilir.

Kaynak Tahsisi ve Dağıtım Mekanizması

Kaynakların tüketici grupları arasında fiili dağıtımı, dinamik ve geri bildirim tabanlı bir algoritma ile gerçekleşir. En önemli ve sık yönetilen kaynak CPU'dur. CPU tahsisi, CPU metodolojisi olarak adlandırılan ve belirli bir plan için seçilen modele göre yapılır. EMPHASIS yöntemi, çok seviyeli hiyerarşiler için paylaşım yüzdeleri (CPU_P1, CPU_P2, … CPU_P8) kullanırken, RATIO yöntemi daha basit, tek seviyeli planlarda basit ağırlıklandırma oranları ile çalışır.

CPU dışında, Resource Manager paralel sorgu derecelendirme (PARALLEL_DEGREE_LIMIT_P1), yürütme süresi tahmini (MAX_EST_EXEC_TIME) ve aktif oturum havuzu (ACTIVE_SESS_POOL_P1) gibi kavramları da kontrol edebilir. Aktif oturum havuzu mekanizmsı, belirli bir tüketici grubunun aynı anda çalıştırabileceği maksimum aktif oturum sayısını sınırlayarak, sistemin kilit kaynaklarını (CPU, I/O) aşırı yüklenmeye karşı korur. Havuz limiti aşıldığında, yeni oturumlar QUEUEING_P1 parametresinde belirtilen süre kadar bekletilir.

  • CPU Kontrolü: Paylaşım yüzdeleri (EMPHASIS) veya oranlar (RATIO) ile hiyerarşik dağıtım. Kritik grup tanımlanabilir.
  • Paralellik Sınırı: Gruba ait bir sorgunun kullanabileceği maksimum paralel sunucu sayısı (PARALLEL_DEGREE_LIMIT_P1).
  • Oturum Havuzu: Eşzamanlı aktif oturum sınırı (ACTIVE_SESS_POOL_P1). Aşılırsa kuyruğa alma.
  • Yürütme Sınırı: Bir işlemin maksimum çalışma süresi (MAX_EST_EXEC_TIME). Aşılırsa iptal edilir veya başka gruba geçirilir.
  • I/O Kontrolü: G/Ç istekleri için oran sınırlama (MAX_IOPS ve MBPS_PER_SESSION gibi parametrelerle).

Mekanizmanın en güçlü özelliklerinden biri, otomatik tüketici grubu geçişidir. Bir oturum, belirli bir koşul (örneğin, belirlenen CPU kullanım süresini aşmak) sağlandığında, daha düşük öncelikli bir gruba dinamik olarak taşınabilir. Bu, uzun süren batch işlerinin, anlık OLTP işlemlerinin performansını düşürmesini engellemek için kritik bir araçtır. Geçiş, SWITCH_GROUP ve SWITCH_TIME yönergeleri ile kontrol edilir.

Kaynak Türü Kontrol Parametresi Etkisi ve Kullanım Senaryosu
CPU CPU_P1...P8, UTILIZATION_LIMIT CPU yarışmasını yönetmek, kritik hizmetlere garantili kapasite ayırmak.
Paralellik PARALLEL_DEGREE_LIMIT_P1 Büyük raporlama sorgularının tüm paralel sunucuları tüketmesini önlemek.
Aktif Oturumlar ACTIVE_SESS_POOL_P1 Sistemi aşırı yükleyebilecek eşzamanlı bağlantı patlamalarını sınırlamak.
Yürütme Süresi MAX_EST_EXEC_TIME, SWITCH_TIME Kontrolsüz uzayan sorguları otomatik olarak sonlandırmak veya düşük önceliğe almak.
G/Ç (I/O) MAX_IOPS, MBPS_PER_SESSION Bir oturum veya grubun disk alt sistemini aşırı kullanmasını engellemek, I/O yarışmasını yönetmek.

Kullanım Senaryoları ve İş Avantajları

Oracle Resource Manager'ın uygulama alanı, basit performans iyileştirmelerinin ötesine geçerek iş sürekliliği ve hizmet seviyesi anlaşmalarının (SLA) operasyonel garantisi sağlamaya kadar uzanır. En yaygın senaryo, çok kiracılı veritabanı mimarilerinde (Multitenant) kaynak yalıtımı sağlamaktır. Bir CDB içindeki farklı PDB'ler, tüketici grupları gibi davranabilir veya her PDB'ye özgü planlar oluşturularak, bir kiracının kaynak açgözlü iş yükünün diğer tüm kiracıların performansını etkilemesi engellenir.

Bir diğer kritik senaryo, karma iş yükü ortamlarının konsolidasyonudur. Aynı fiziksel sunucu ve veritabanı örneği üzerinde çalışan OLTP sistemleri, raporlama uygulamaları ve ETL batch işleri, Resource Manager olmadan sürekli bir kaynak çatışması içindedir. Manager, öncelikli OLTP işlemlerine garantili CPU payı (%80 gibi) ayırırken, raporlama işlerine kalan payı (%20) ve batch işlerine de sadece boştaki kaynakları (BELOW_PERCENT yönergesi ile) kullanma imkanı tanıyabilir.

Bu teknik düzenlemelerin sağladığı iş avantajları doğrudan finansal etki yaratır. Donanım konsolidasyonu sayesinde sunucu sayısı ve lisans maliyetleri azalır. Performansın öngörülebilir olması, operasyonel riski düşürür ve planlama yapmayı kolaylaştırır. Ayrıca, önemli müşteri işlemlerine veya yönetici sorgularına yönelik kritik grup (CRITICAL_GROUP) tanımlanarak, sistem yoğunluğu ne olursa olsun bu işlemlerin gecikmesiz tamamlanması garanti edilebilir.

Performans mühendisliği açısından bakıldığında, Resource Manager proaktif bir yönetim aracıdır. Reaktif yaklaşımlar (örneğin, sorun olunca sorguyu öldürmek), iş süreçlerini kesintiye uğratır. Manager ise, kaynak çekişmesini kaynağı tüketen işlemi başlatmadan önce tanımlanan politikalarla önler. Bu, daha stabil bir sistem, daha az acil müdahale ihtiyacı ve sonuç olarak daha düşük toplam sahip olma maliyeti (TCO) anlamına gelir. Özellikle bulut ortamlarında, hizmet kalitesinin sözleşmeli seviyelerde tutulması için vazgeçilmez bir bileşendir.

Uygulama geliştirme ve test ortamlarında da değerli bir rol oynar. Geliştiricilerin yazdığı verimsiz bir sorgu, test ortamının tüm kaynaklarını tüketip diğer test süreçlerini bloke edebilir. Resource Manager ile her geliştirici grubuna veya test senaryosuna ayrı bir kaynak sınırı konularak, bir testin diğerlerini olumsuz etkilemesi engellenir ve test süreçlerinin paralelliği ve güvenilirliği artırılır.

Performans İzleme ve Sorun Giderme

Resource Manager'ın etkinliğini değerlendirmek ve olası tıkanıklık noktalarını tespit etmek, dinamik performans görünümleri (Dynamic Performance Views - V$ views) ve Kaynak Yöneticisi istatistikleri üzerinden yapılır. V$RSRC_CONSUMER_GROUP görünümü, her bir tüketici grubunun gerçek zamanlı CPU kullanımı, kuyrukta bekleyen oturum sayısı, kuyrukta geçirilen ortalama süre ve grup içinde gerçekleşen geçiş istatistikleri gibi kritik metrikleri sunar.

Bu görünümlerin analizi, politika tasarımındaki hataları ortaya çıkarabilir. Örneğin, belirli bir grup için sürekli yüksek bir CUMULATIVE_QUEUEING_TIME değeri, ACTIVE_SESS_POOL_P1 limitinin çok düşük ayarlandığını veya CPU payının yetersiz kaldığını gösterir. Benzer şekilde, V$RSRC_SESSION_INFO görünümü, bireysel oturum seviyesinde tüketici grubu atamalarını, geçiş geçmişini ve kaynak kullanımını izlemeye olanak tanıyarak sorunlu bir oturumun davranışının detaylı analizini mümkün kılar.

Sorun giderme sürecinin bir diğer ayağı, plan aktivasyonu ve geçişlerinin doğrulanmasıdır. V$RSRC_PLAN görünümü, hangi kaynak planının aktif olduğunu gösterir. Planlar, zamanlamaya bağlı olarak (Oracle Scheduler aracılığıyla) veya manuel olarak değiştirilebilir. Yaygın bir hata, beklenen planın aktif olmaması veya hiyerarşidki alt planların yanlış yapılandırılmasıdır. Ayrıca, UTL_RM paketi ve DBMS_RESOURCE_MANAGER paketinin VALIDATE_PENDING_AREA, SUBMIT_PENDING_AREA prosedürleri, plan doğrulama ve aktive etme süreçlerinde hata ayıklama için hayati öneme sahiptir. 

-- Tüketici gruplarının mevcut performans istatistiklerini sorgulamak:
SELECT name,
       active_sessions,
       queue_length,
       consumed_cpu_time,
       cpu_waits,
       cpu_wait_time
FROM   v$rsrc_consumer_group;

-- Belirli bir oturumun kaynak yöneticisi bilgilerini izlemek:
SELECT sid,
       serial#,
       consumer_group,
       current_queue_duration,
       cpu_wait_time
FROM   v$session s,
       v$rsrc_session_info rsi
WHERE  s.sid = rsi.sid
AND    s.username = 'APP_USER';

İleri seviye izleme için, AWR (Automatic Workload Repository) raporları ve ASH (Active Session History) verileri de Resource Manager metriklerini içerir. AWR raporunun "Resource Manager Stats" bölümü, planlar ve tüketici grupları bazında tarihsel eğilim analizi yapmayı sağlar. ASH verileri ise, geçmişteki bir performans sorunu anında hangi grupların kaynak için yarıştığını ve hangi oturumların kuyrukta beklediğini gösteren detaylı kök neden analizi imkanı sunar. Bu veriler, politika revizyonları için kanıta dayalı bir zemin oluşturur.

İleri Seviye Konfigürasyon ve En İyi Uygulamalar

Temel yapılandırmayı aşan, karmaşık ve yüksek kullanılabilirlik gerektiren ortamlarda, bir dizi ileri seviye teknik ve en iyi uygulama devreye girer. Bunların başında, Oracle RAC (Real Application Clusters) ortamlarında Resource Manager'ın merkezi yönetimi gelir. RAC'ta, planlar küme genelinde (cluster-wide) veya örnek bazında (instance-specific) olarak uygulanabilir. Küme geneli planlar, tüm örneklerde tutarlı bir kaynak yönetimi politikası sağlar ve DBMS_RESOURCE_MANAGER paketinin CREATE_CLUSTER_PLAN ve ilgili yordamları ile yönetilir.

Bir diğer kritik konu, Exadata gibi özel donanım platformlarında I/O kaynak yönetimidir. Exadata'da, Resource Manager sadece geleneksel I/O parametreleri (MAX_IOPS, MBPS) ile değil, aynı zamanda IORM (I/O Resource Manager) ile entegre çalışarak, hücresel diskler ve flash önbellek üzerinde de ayrıntılı kontrol sağlar. Bu entegrasyon, depolama seviyesinde de performans yalıtımı ve öngörülebilirlik sağlayarak, uçtan uca bir QoS zinciri oluşturur.

  • Basitten Başlayın ve Yineleyin: Önce en kritik iki veya üç grup için basit bir plan oluşturun. Performansı izleyin ve politikaları kademeli olarak geliştirin.
  • SWITCH_GROUP ve SWITCH_TIME'ı Stratejik Kullanın: Kaynak açgözlü oturumları düşük öncelikli bir "PENALTY_BOX" grubuna otomatik geçirin. Bu, sistem istikrarını korumanın etkili bir yoludur.
  • UTILIZATION_LIMIT ile Mutlak Sınırlar Belirleyin: Özellikle PDB'ler veya batch işleri için, CPU kullanımını mutlak bir üst limitle (örn. %40) sınırlayın.
  • MULTILEVEL_PLAN Yanlış Anlaşılmasın: Çok seviyeli planlar esneklik sağlar, ancak tasarımı karmaşıktır. Her seviyedeki yüzdelerin toplamının doğru olduğundan emin olun.
  • ORACLE_MAINTENANCE Grubunu Yapılandırın: Otomatik görevler (AWR, istatistik toplama) için ayrılmış bu grubun kaynaklarını, kritik uygulama iş yükünü etkilemeyecek şekilde ayarlayın.
  • Plan Değişikliklerini Zamanlayın: Günün saatine veya iş yüküne göre farklı planları otomatik olarak etkinleştirmek için DBMS_SCHEDULER ile birlikte kullanın.

Performans garantisi verilen kritik uygulamalar için MAX_UTILIZATION_LIMIT parametresi, tüketici grubunun aldığı CPU payını boş kaynak olsa bile aşmasını engelleyen sert bir üst sınırdır. Bu, diğer grupların kaynaklarını asla gasp etmeyecek şekilde tasarlanmş bir "iyi vatandaş" grubu yaratmak için kullanışlıdır. Aksine, MIN_UTILIZATION_LIMIT ile alt sınır garantisi verilerek, bir grubun her koşulda belirli bir minimum kaynağı alması sağlanabilir.

Güvenlik ve yönetişim açısından, tüketici gruplarına kullanıcı ve rol atama işlemleri DBMS_RESOURCE_MANAGER_PRIVS paketi ile dikkatlice yönetilmelidir. SWITCH_CONSUMER_GROUP_FOR_USER gibi yüksek ayrıcalıklı prosedürlerin yetkileri, yalnızca gerekli DBA'lar ile sınırlandırılmalıdır. Tüm yapılandırma değişiklikleri, test ortamında kapsamlı bir şekilde validasyondan geçirilmeli ve değişiklik yönetimi prosedürlerine tabi tutulmalıdır. Bu disiplinli yaklaşım, Oracle Resource Manager'ın sunduğu güçlü kontrollerden maksimum faydayı sağlarken, beklenmeyen yan etki riskini minimize eder.