Oracle’ın parallel execution yetenekleri ve performans

Editor's Notes

• #5: Büyük seri görevlerin, eş zamanlı çalıştırılabilecek küçük görev parçalarına bölünmesi ve bu küçük görev parçalarının çalıştırılarak sonuçlarının toplanarak nihai sonuca ulaşılması.
• #6: Parallel Execution improves processing for: + Large table scans, joins or partitioned index scans +Creations of large indexes +Creation of large tables +bulk inserts, updates,merges and deletes
• #7: 1- İşleyeceğimiz task seri olarak dakikalar, saatler veya günlerce sürüyorsa paralel execute etmek için bu task seçilebilir. Taskın büyüklüğü önemli bir nokta. Aksi takdirde saniyeler mertebesinde çalışan bir taskı paralel çalıştırırsak, paralel sonuçların koordinasyon maliyeti seri çalışmasından daha fazla olacak ve daha kötü bir performans elde edilecek. OLAP sistemlerdeki tasklar paralel çalıştırmak için daha uygun. OLTP sistemlerde paralel erişen user sayısı çok fazla ve görevlerin karakteristikleri kısa ve response time odaklı bu yüzden paralel çalıştırmaya uygun sistemler değiller, paralel çalştırma opsyonu bu sistemlerde felakete yol açabilir. 2- Donanım karakteristiği --- Sysmetric Multipreocessor, Clusters, massively parallel systems --- Sufficent I/O bandwith: I/O kanallarım yeterli olmalı çünkü çekeceğim data birden fazla diske dağılmış olabilir, bu sebepten ötürü eş zamanlı birden fazla okuma isteği gerçekleşecektir bundan dolayı bilgisayarla disk arasında data taşınmasını sağlayacak sayıda I/O kanallarımın olması gerekiyor. --- CPU underutilized or intermittently(aralıklı) used (typically usage less than %30) --- Sufficient memory to support additional memory intensive process, such as sorts, hashing and I/O buffers. 3- Sistemde yeterli available kaynak olmalıki, paralel operasyonlarımız kendisi için yeterli kaynağı alsın ve paralel çalışabilsin.
• #9: Parallik 3 Seviyede + Statement Level + Object Level + Instance Level ---------------------------------------------------------------------------------------------------- In Oracle, the degree of parallelism consists of two components, the number of instances to use and the number of slave processes to use on each instance. In Oracle's SQL syntax, the keywords INSTANCES and DEGREE are always used to specify values for these two components as follows: INSTANCES: Specifies the number of instances to use DEGREE: Specifies the number of slave processes to use on each instance INSTANCES applies only to the Oracle Parallel Server configuration. Unless you are using OPS, the value of INSTANCES should be set to 1; any other value is meaningless.  Level of parallel execution The degree of parallelism used for a SQL statement can be specified at three different levels: Statement level  Using hints or the PARALLEL clause Object level Found in the definition of the table, index, or other object Instance level  Using default values for the instance Oracle determines the degree of parallelism to use for a SQL statement by checking each item in this list in the order shown. Oracle first checks for a degree of parallelism specification at the statement level. If it can't find one, it then checks the table or index definition. If the table or index definition does not explicitly specify values for DEGREE and INSTANCES, Oracle uses the default values established for the instance. ------------------------------- Datanın fiziksel olarak dağılmış olması paralellikten için daha optimal bir durum oluşturabilir. Aşağıdaki yolları izleyerek datayı fiziksel olarak dağıtabilirz. Using Raid Using ASM Using partitioning Using multiple data files in a sşngle tablespace
• #10: alter table big_table parallel; vs alter table big_table parallel 8; select sid,qcsid,server#,degree from v$px_session order by server# desc  kaç parallel açtığını görmek için -- alter table big_table noparallel; -- Seri -- Elapsed: 00:01:17.89 -- alter table big_table parallel 4; -- 4 Parallelde -- Elapsed: 00:00:04.10 -- alter table big_table parallel 8; -- 8 Parallelde -- Elapsed: 00:00:02.30 -- alter table big_table parallel 16; -- 8 Parallelde -- Elapsed: 00:00:03.30 -- alter table big_table parallel; -- 32 Parallelde -- Elapsed: 00:00:12.27
• #11:  Parallel dml’in çalışabilmesi için operasyon yapılacak tablonun paralel yaratılması yeterli değildir. Bunun yanında Alter session enable parallel dml; cümlesininde çalıtırılması gerekir.  Büyük boyutlu DML işlemlerini yeterli CPU ve I/O bandwith i varsa performans anlamında çalışma süresini oldukça düşürür.  Makinedeki tüm kaynakları tüketmeye çalışır bu yüzden OLTP sistemlerde tercih edilmezler. OLTP userlarına paralel dml yeteneği verilmemelidir.  OLAP sistemlerde paralel erişen user sayısı OLTP ye göre daha az olduğundan kaynakların tamamı utilize edilmek istenenebilir. Bu sistemlerde kullanmak mantıklıdır. DWH lerde oldukça kullanışlı bir yapıdır.  Paralel sorgulama 100 user’ın yarattığı iş yükünü sistemde yaratır bu yüzden OLTP sistemlerde böyle bir kullanım söz konusu olmaz. İşler bitmemeye başlar. Her bir paralel execution server ayrı bir transaction yaratır ve kendilerine özel undo segmentleri vardır. Tüm transaction coordinator session’ı ile commitlenirler. ----------------------KISITLAR----------------------------------------------------------- Trigger olan tablolarda PDML operasyonları yapamayız. Trigger büyük bir overhead update işlemlerinde ama PDML ise hızlı çalışmak isteyen bir yapı bu yüzden trigger olan bir tabloda PDML çalışmaz. Self Referential Integrity olan bir tabloda PDML yine yapılamaz. Bunun nedeni datanın ayrı olan her parçası ayrı transanactionlarda ve ayrı sessionlarda değiştirilir bu yüzden deadlock veya herhangi bir locking issues a sebebiyet verilebilir bu yüzden SRI bulunan bir tabloda PDML yapılamaz. PDML işlemi sonunda commit veya rollback yapılana kadar o tabloya erişilemez. ORA-12838: cannot read/modify an object after modifying it in parallel. Advanced replication trigger based olduğu için PDML işlemini bu tarz durumlarda kullanamayız. Bir tabloda deffered constraints varsa bu tablo PDML li destekemez. Eğer bir tabloda partition varsa bitmap index veya LOB kolon içeren tablolarda PDML çalıştırılabilir. Ancak bu case de parallelik sayısı partition sayısı ile sınırlıdır. Aynı partition a birden fazla session açıp parttion bazında parallelik yapamaz. Her partition’a bir execution servers atar. Distirbuted transactionlar da PDML’i desteklemez. Clustered tablolar PDML’i desteklemez. Yukarıdaki kısıtlar ihlal edildiği takdirde 2 olay olabilir. 1- DML seri çalışabilir. 2- Hata alınır. ORA-12838 gibi. -----------------------------------------------------------------------------------------------------------------------------------------------------------------------
• #12: İlk 4 komut individual table veya index partition lar içinde çalışabilir. Bu sayede bir tabloya ait individual bir partition ı paralel bir şekilde taşıyabiliriz (MOVE). Paralel DDL Oracle’ın en iyi ölçülebilir fayda sağlayan özelliklerinden biridir. Paralel sorgu ile kullanarak (as select) uzun süren operasyonları kısa sürede yapabiliriz. Paralel DDL sürdürlebilirlik ve yönetim noktasında etkisi doğrudan bizleredir yani DBA lere ve Developerlaradır. CREATE INDEX: Multiple parallel execution servers can scan the table, sort the data, and write the sorted segments out to the index structure. • CREATE TABLE AS SELECT: The query that executes the SELECT may be executed using parallel query, and the table load itself may be done in parallel. • ALTER INDEX REBULD: The index structure may be rebuilt in parallel. • ALTER TABLE MOVE: A table may be moved in parallel. • ALTER TABLE SPLIT|COALESCE PARTITION: The individual table partitions may be split or coalesced in parallel. • ALTER INDEX SPLIT PARTITION: An index partition may be split in parallel. --------------------------------- (Her bir paralel execution server kendine ayrın bir extent allocate eder ve burada çalışır.) Create table as select’de extent lerle alakalı bir case var, extentlerde ölü yerler oluşması gibi. 1010 MB bir dosya yüklediğimiz durumda 100 MB extentler kullandığımızı varsayalım ve 10 paralelde bu işi yapmış olalım. Bu durumda her bir paralel session ın 101 MB yükkediğini varsayalım. Her session ilk 100 MB için bir extenti tam doldurdu ve elinde kalan 1 mb için yeni bir extent allocate etmek durumunda kaldı. Bu durumda ilk bakışta 11 extentin yeteceği beklenirken 1 mb için her execution server’ın yeni extentler alması toplamdaki extent sayısını 20 ye çıkarttı. 990 MB lık kullanılmayan ölü bir alan allocate edilmiş olundu. Bu alanlar daha sonra doldurulacaktır ancak şuan elimizde 990 mb ölü bir alan mevcut. Bu durumu engelleme adına Extent Trimming mevzusu meydana çıkıyor. Oracle her paralel execution serverının aldığı son extentini ölü yerler oluşmaması adına execution servera yetecek şekilde trim etme olayına giriyor. Trim İşleminin gerçekleşebilmesi Table Space yönetimi ile doğrudan alakalı. Dictionary Managed Tablespaces Auto Allocated TableSpace(AUTOALLOCATE) vs Uniform Allocated TableSpace(UNIFORM_SIZE)
• #13: AUTOALLOCATE vs UNIFORM_SIZE Table Space
• #14: PDML bu case’de aşırı kaynak tüketmekten başka çokta fayda sağlamayacak Select * from some table ı parallelştirsek performasımızda yine kademeli bir artış görmemiz çok zor. Complex processimizden sonra DML’imizi paralelleştirmek yine performansımızı iyileştirmicek çünkü döngü içinde tek bir satırla ilgili bir işlem yapıyoruz o yüzden etkilenmicez. Burada yapacağımız update veya insert i array processing yaparak değiştirmek bir kademe iyileştirme sağlayabilir ama bu 2 – 3 -4 kat gibi iyileşmeler olmayabilir. Bu tarz durumda işliyeceğim veri seti her geçen gün büyüdüğünü varsayalım, bu durumda çalışma zamanı git gide yavaşlayacak? Performansı 2 3 4 kat gibi seviyelere çıkarmam gerekiyor Ne yapıcam? 1- Parallel Pipelined Function 2- Do it yourself parallelism – dbms_parallel_execute
• #15: Execution of a table function can be parallelized, and returned rows can be streamed directly to the next process without intermediate staging. Rows from a collection returned by a table function can also be pipelined—that is, iteratively returned as they are produced instead of in a batch after all processing of the table function's input is completed. Streaming, pipelining, and parallel execution of table functions can improve performance: By enabling multithreaded, concurrent execution of table functions By eliminating intermediate staging between processes By improving query response time: With non-pipelined table functions, the entire collection returned by a table function must be constructed and returned to the server before the query can return a single result row. Pipelining enables rows to be returned iteratively, as they are produced. This also reduces the memory that a table function requires, as the object cache does not need to materialize the entire collection. By iteratively providing result rows from the collection returned by a table function as the rows are produced instead of waiting until the entire collection is staged in tables or memory and then returning the entire collection Figure 13-1 shows a typical data-processing scenario in which data goes through several (in this case, three) transformations, implemented by table functions, before finally being loaded into a database. In this scenario, the table functions are not parallelized, and the entire result collection must be staged after each transformation.
• #16: (Yukarıdaki örnek fonksyon, Parallel Pipelined Table Function Parallel Table Function olmasını sağlan özellik Parallel_Enable cümlesi ve içeri bir adet cursor alması) ) Pipe Row deyimi PL/SQL Routinelerimizin geriye tablo döndürmesini sağlayan bir yapı. Böylelikle fonksoynumuza doğrudan select yazma hakkında sahip olabiliyoruz. Input bir refcursor olmalı. PARALLEL_ENABLE cümlesini vermek durumundayız. Gelen Cursor’ı partitionlamak zorundayız. Partitionlamayı by any diyerek geçebiliriz. Bu durumda Oracle var olan datayı açtığı paralel prosesler arasında rastgele paylaştırır. Ancak burada hash veya range partitioning de kullanabiliriz vereceğimiz specifik bir kolon üzerinden. Ancak compiler’ın cursor içinde hangi kolonların olduğunu bilmesi için strongly typed ref cursor tanımlamak zorundayız. Örnek: Strongly Typed Cursor TYPE t_ref_cursor IS REF CURSOR RETURN cursor_variable_test%ROWTYPE;  c_cursor  t_ref_cursor;
• #17: Sistemde job create etme yetkisi olmalıdır. Paketin sahip olduğu tüm metodlar commit işlemi gerçekleştirir. Oracle’da DML operasyonlarını otomatize eden bir yapı.
• #19: Sorgularımızı paralel işleyen paralel execution server ların sayısı degree of parallelism olarak bilinir. Açılacak paralel execution birden çok CPU lu sistemler için tasarlanmış yapılardır. Oracle da parallel işleme mimarisi kendimizin belirleyebileceği gibi, oracle’a güvenip paralellik seviyesinin ayarlanmasını onun kontrolüne bırakabiliriz. Fixed DoP  ALTER TABLES sales PARALLEL 8; ALTER TABLE customers PARALLEL 4; Oracle’da biri 4 diğer 8 olarak paralellik seviyesi ayarlanmış tablolara erişim ikisi içinde en büyük paralellik seviyesine göre ayarlanır. Bu durumda eş zamanlı 2 tabloyada erişim var ise 16 proses tahsis edilir ve 8 er 8 er paylaşılır. (Kaynak Oracle® Database VLDB and Partitioning Guide) Default DoP nasıl hesaplanır------ Alter table x parallel; default dop, kontrol oracle’a bırakılmış durumda. For a single instance, DOP = PARALLEL_THREADS_PER_CPU x CPU_COUNT For an Oracle RAC configuration, DOP = PARALLEL_THREADS_PER_CPU x CPU_COUNT x INSTANCE_COUNT Default DoP ne kadar çok kaynak kullanırsa o kadar hızlı biteceğini sandığından sistemdeki tüm available kaynakları tüketmeye çalışır bu sebepten ötürü çok user ın bağlandığı bir sistemde default paralellik önerilen bir şey değildir. Bu yüzden Oracle Resoruce Manager ile paralel sorguların kaynak tüketimine sınır getirilebilir. PARALLEL_DEGREE_POLICY parametresi AUTO-LIMITED-MANUAL şeklinde ayarlanabilir. ---------------------- Optimizer ilk etapta sorgunun ihtiyacı olan tüm scan operasyonlarını değerlendirerek bir parallelik seviyesi belirliyor sorgu için. Daha sonraki adımda sistemde tanımlı olan Parallel_degree_limit parametresine bakarak kendi bulduğu parallelik seviyesi ile sistemde limitlendirilmiş değeri kontrol edip kendi bulduğu seviyenin sistemi boğum boğmayacağına bakıyor eğer bu bulduğu değer tanımlı parametreden küçük bunu alıyor değilse paralel limit parametresinde tanımlanmış değeri alıyor. (Parallel Degreee Limitin default değeri PARALLEL_THREADS_PER_CPU x CPU_COUNT x INSTANCE_COUNT dur.). Thresholuld Zamnıda parallel_min_time_threshould değerine göre karşılaştırılır. Bu değer ilk olarak default 10 sn olarak gelir. Eğer bu değeri AUTO olarak set edersek sistem parallel_min_time_threshould değerini hesaplar. --------------------------------------------------------------- PARALLEL_DEGREE_POLICY Manual – Limited ve Auto olabilir. Default olarak manual gelir, manual durumdayeken automatic degree of parallelism, statement queuing, and in-memory parallel execution özellikleri kapalıdır. Limited seçeneğinde auto DoP açık gelir ama statement queue ve in memory parallel execution kapalıdır. Auto automatic degree of parallelism, statement queuing, and in-memory parallel execution seçenkelerinin hepsi açılır. PARALLEL_DEGREE_LIMIT CPU(Default) The maximum degree of parallelism is limited by the number of CPUs in the system. The formula used to calculate the limit is PARALLEL_THREADS_PER_CPU * CPU_COUNT * the number of instances available (by default, all the opened instances on the cluster but can be constrained using PARALLEL_INSTANCE_GROUP or service specification). This is the default. IO The maximum degree of parallelism the optimizer can use is limited by the I/O capacity of the system. The value is calculated by dividing the total system throughput by the maximum I/O bandwidth per process. You must run the DBMS_RESOURCE_MANAGER.CALIBRATE_IO procedure on the system in order to use the IO setting. This procedure will calculate the total system throughput and the maximum I/O bandwidth per process. integer A numeric value for this parameter specifies the maximum degree of parallelism the optimizer can choose for a SQL statement when automatic degree of parallelism is active. Automatic degree of parallelism is only enabled if PARALLEL_DEGREE_POLICY is set to AUTO or LIMITED. PARALLEL_MIN_TIME_THRESHOLD AUTO: Default olarak 30 sn geliyor. INTEGER: El ilede verilebiliyor. PARALLEL_MIN_TIME_THRESHOLD specifies the minimum execution time a statement should have before the statement is considered for automatic degree of parallelism. By default, this is set to 30 seconds. Automatic degree of parallelism is only enabled if PARALLEL_DEGREE_POLICY is set to AUTO or LIMITED.
• #21: Bu mekanizmanın aktif olabilmesi için paralel_degree_policy parametresinin AUTO olması gerekmektedir. Eğer işimizin kuyruğa girmesini istemiyorsak NO_STMT_QUEUING hinti yazılır. Sistemimzin açabileceği available proses sayısı default olarak DoP*4 kadardır. Benim PC için 16. Bu bilgi PARALLEL_SERVERS_TARGET parametresinde tutulur. Eğer sistemimde 64 tane maximum active server bulunabiliyorsa ve bunların 60 tanesi şuan kullanılıyorsa yeni gelen 16 lık bir istek için yeteri kadar server olmadığı için bu gelen yeni istek kuyruğa yollanacaktır. Birde sistemde PARALLEL_MAX_SERVERS parametresi var bu parametre PARALLEL_SERVERS_TARGET parametresinden daha büyük, bunun nedeni paralel çalışacak işlerin seri çalışacak işlerin kaynağından yememsi durumu, eğer bu 2 parametrebirbirine eşit olsaydı tüm kaynaklar paralel işlemler tarafından alınabilirdi böylelikle seri çalışacak işlere kaynak kalmazdı. Queue da ne kadar iş beklerse beklesin seri işler hiç bir zaman bekletilmez ve hemen çalıştırılır.