Oracle

Veritabanında Denetleme (Audit)

Veritabanında standart denetleme audit_trail parametresine değer (os, db, db extended, xml, xml extended) atanması ile başlar. Eğer denetlemeyi durdurmak istersek parametre NONE yapılmalıdır. Bu parametrenin none yapılması ile beraber veritabanı kapatılıp açıldığında tüm denetleme durmuş olur.

Denetlemeler komut, yetki, obje ve network aktiviteleri bazında tanımlanır. Denetleme başlatmak için AUDIT, durdurmak için NOAUDIT komutu kullanılmalıdır.

Bir kullanıcı kendine ait tüm kullanıcılar üzerinde AUDIT başlatabilir. Başka kullanıcıların objeleri üzerinde AUDIT başlatmak için ise AUDIT ANY yetkisi olmalıdır. Sistem yetkileri üzerinde AUDIT tanımlamak için AUDIT SYSTEM yetkisi olmalıdır. NOAUDIT komutunun çalıştırılması için ise özel bir yetkiye gerek yoktur.

O7_DICTIONARY_ACCESSIBILITY parametresi FALSE ise denetim izleri yalnızca SYSDBA yekili kullanıcılar tarafında silinebilir. DELETE ANY TABLE yetkisine sahip kullanıcılar dahi silemezler.

Tüm denetim kayıtları herhangi bir transaction’ın tanımlanmasını beklemeden, denetlenecek komutun çalışma anında yazılır.

Komutların Denetlenmesi

Komut bazında denetleme yapılması, kullancıların çalıştırdığı,

  • DML(INSERT, UPDATE, DELETE, SELECT)
  • DDL(CREATE, DROP….)

gibi veritabanı komutlarının denetlenmesi işlemidir. Denetleme yaparken denetleyeceğimiz obje türünü girmemiz yeterlidir. AUDIT komutunda yazdığınız obje türüne türüne göre istenilen komutlar denetlenir. Obje türüne göre denetleyebileceğimiz komutlar aşağıdaki gibidir.

Oracle Audit System

 

 

 

 

 

 

 

Bu tür komut bazlı denetlemeyi başlatmak için AUDIT SYSTEM yetkisine sahip olunması gerekir. (dba_sys_privs viewi sorgulanarak yetki sahipleri bulunabilir) Komut bazında denetleme yeni session açıldığında aktif olur.

Örneğin tablo objesi DELETE komutunun tüm veritabanında denetlenmesi için aşağıdaki komutu çalıştırabiliriz.

audit delete table by access;

Yada sadece SYSTEM kullanıcısında çalıştırılan SELECT TABLE komutunu denetlemek istersek aşağıdaki komutu çalıştırabiliriz.

audit select table by system;

Verilen audit leri görmek için DBA_STMT_AUDIT_OPTS viewini sorgulayabiliriz.

Oracle Audit Privilege

 

 

Yukarıdaki resimdede görüldüğü gibi;

  • SYSTEM kullanıcısında çalışan tüm SELECT TABLE komutları
  • SYSTEM kullanıcısının çalıştırdığı tüm komutların
  • EXEMPT ACCESS POLICY yetkisini veren GRANT komutlarının
  • Bütün kullanıcılarda olmak üzere DELETE TABLE komutlarının denetlendiğini görmekteyiz.

(continue reading…)

4,472 total views, 4 views today


Oracle Audit – Denetim İzlerinin Yönetilmesi

Denetim izleri yapılan konfigürasyona göre veritabanında tablo olarak veya işletim sisteminde dosya olarak tutulmaktadır. Bu denetim izlerini silmek veya başka ortamlara taşımak için farklı yöntemler kullanılabilir. Fakar Oracle 11g ile beraber denetim izlerinin yönetilmesi için DBMS_AUDIT_MGMT paketi kullanılmaya başlanmıştır. Böylece değişik ortamlarda tutulan denetim izleri tek bir paket ile yönetilebilir hale gelmiştir. DBMS_AUDIT_MGMT paketi denetim izleri üzerinde taşıma silme işlemi yaparken veritabanındaki sessionları bekler duruma getirmez ve kullanıcılar çalışmalarına kesintisiz devam ederler. Bu nedenle değişik yöntemler ile denetim izlerini yönetebilmemize rağmen(Örneğin tabloda ise DELETE komutu, işletim sisteminde ise rm komutu kullanabiliriz) DBMS_AUDIT_MGMTpaketini kullanmak daha doğrudur.

Veritabanında Saklanılan Denetim İzlerinin Farklı Tablespacelere Taşınması

Veritabanında tutulan standart denetim izleri SYS.AUD$ tablosunda, ayrıntılı denetim izleride(Fine Grained Auditing-log mekanizması diyebiliriz) FGA_LOG$ tablolarında tutulur. Veritabanı ilk yaratıldığında bu tablolar varsayılan olarak SYSTEM tablespace’inde tutulur. Ama tabloların büyümesi ve denetleme politikası nedeniyle SYSTEM tablespace üzerinde baskı oluşabilir. Bu nedenle sık sık silinmesi ve sürekli ekleme yapılan tabloları ayrı bir tablespace’e taşımak isteriz.

Bu işlem DBMS_AUDIT_MGMT.set_audit_trail_location veritabanı paketi ile yapılır. Bu paket 2 tane parametre alır. Bir tanesi taşımak istediğiniz tablo türünü gösteren parametre, diğeri ise tabloların taşınacağı tablespace adıdır.

Tablo türünü gösteren parametre aşağıdaki 3 değerden birini alır.

  • DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD: Standard denetim izi (AUD$).
  • DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD: Ayrıntılı enetim izi (FGA_LOG$).
  • DBMS_AUDIT_MGMT.AUDIT_TRAIL_DB_STD : Standart ve Ayrıntılı denetim izi için.
SELECT table_name, tablespace_name
FROM dba_tables
WHERE table_name IN ('AUD$', 'FGA_LOG$')
ORDER BY table_name;
TABLE_NAME   TABLESPACE_NAME
------------------------------ ------------------------------
AUD$            SYSTEM
FGA_LOG$        SYSTEM

CREATE TABLESPACE AUDIT_TS
DATAFILE
'/u01/app/oracle/oradata/ORCL/AUDIT_TS' SIZE 104857600 AUTOEXTEND ON NEXT 10485760 MAXSIZE UNLIMITED;


BEGIN
DBMS_AUDIT_MGMT.set_audit_trail_location(
audit_trail_type = DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,
audit_trail_location_value = 'AUDIT_TS');
END;
/


SELECT table_name, tablespace_name
FROM dba_tables
WHERE table_name IN ('AUD$', 'FGA_LOG$')
ORDER BY table_name;
TABLE_NAME   TABLESPACE_NAME
------------------------------ ------------------------------
AUD$           AUDIT_TS
FGA_LOG$       SYSTEM


BEGIN
DBMS_AUDIT_MGMT.set_audit_trail_location(
audit_trail_type = DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD,
audit_trail_location_value = 'AUDIT_TS');
END;
/


SELECT table_name, tablespace_name
FROM dba_tables
WHERE table_name IN ('AUD$', 'FGA_LOG$')
ORDER BY table_name;

TABLE_NAME  TABLESPACE_NAME
------------------------------ ------------------------------
AUD$         AUDIT_TS
FGA_LOG$     AUDIT_TS

(continue reading…)

2,418 total views, 2 views today


Oracle Audit

Denetleme en genel tanımıyla, veritabanında yapılan işlemlerin belirlenmiş kurallara göre izlenmesi ve kayıt edilmesidir.

Veritabanı denetlemesi veritabanı güvenliği açısından en önemli çalışmalardan bir tanesidir. Veritabanı denetlemesi sayesinde;

  • Veritabanında bulunan bilgilerin tutarlı olduğu,yetkisiz kişilerce değiştirilmediğini kanıtlar.
  • Veritabanında yapılan şüpheli hareketler sorgulanabilir ve kimin tarafından yapıldığı bulunur.
  • Veritabanında yetkisiz işlem yapmak isteyen kullanıcılar açısından caydırıcı önlem alınmış olur.
  • Güvenlik yönetmeliklerine uyum sağlanır.
  • Veritabanı performansı ile ilgili bilgiler toplanır.

Burada önemli noktalarda bir tanesi hangi kurallara göre izleme ve kayıt yapılacağımızın belirlenmesidir. Veritabanında kısa bir süre içerisinde milyonlarca işlem olabilir. Önemli olan kayıt altına alınmaya değer işlemlerin belirlenmesidir. Kayıt altına alınması gereken işlemlerin belirlenmesi  bizim denetleme politikamıza (Auditing Policy) bağlıdır.

Diğer önemli bir nokta ise, veritabanındaki işlemlerin nasıl kayıt altına alınacağıdır. Bu kayıtlara denetim izi denmektedir.

Bunun yanında diğer bir önemli noktada denetim izlerinin değiştirilmeden saklanmasının sağlanmasıdır.

Oracle Veritabanında Mutlaka Tutulan Denetim İzleri

Oralce veritabanında denetim tamamen kapansa bile zorunlu kayıt altına alınan 3 tane işlem vardır.Bunlar;

  • Veritabanı açılışı
  • Veritabanı kapatılışı
  • SYSDBA ve SYSOPER rolüne sahip kullanıcıların veritabanına bağlanması

Veritabanında denetim izleri iki ayrı parametre ile yönetilmektedir. Bunlar audit_trail ve audit_sys_operations parametreleridir. Bu paramrelerden audit_trail parametresine NONE, audit_sys_operations parametresine boşluk atarsak veritabanında denetlemeyi durdurmuş oluruz.

Bu durumda olan bir veritabanında, yanlızca veritabanı kapama, açma ve veritabanı yöneticisi login işlemleri, denetim izi olarak audit_file_dest dizininde bulunan *.aud dosyalarına yazılır.
(continue reading…)

2,400 total views, 8 views today


PL SQL Mail Gönderme

CREATE OR REPLACE PROCEDURE MAIL_GONDER (p_to        IN VARCHAR2,
                                       p_subject   IN VARCHAR2,
                                       p_message   IN VARCHAR2)
AS
   l_mail_conn   UTL_SMTP.connection;
   p_from        VARCHAR2 (30) := 'Gonderici Bilgisi';
   p_smtp_host   VARCHAR2 (30) := 'mail server bilgisi';
   p_smtp_port   NUMBER := 25;
BEGIN
   l_mail_conn := UTL_SMTP.open_connection (p_smtp_host, p_smtp_port);
   UTL_SMTP.helo (l_mail_conn, p_smtp_host);
   UTL_SMTP.mail (l_mail_conn, p_from);
   UTL_SMTP.rcpt (l_mail_conn, p_to);

   UTL_SMTP.open_data (l_mail_conn);

   UTL_SMTP.write_data (l_mail_conn,'Date: ' || TO_CHAR (SYSDATE, 'DD-MON-YYYY HH24:MI:SS') || UTL_TCP.crlf);
   UTL_SMTP.write_data (l_mail_conn, 'To: ' || p_to || UTL_TCP.crlf);
   UTL_SMTP.write_data (l_mail_conn, 'From: ' || 'Database Report Mail' || UTL_TCP.crlf);
   UTL_SMTP.write_data (l_mail_conn,'Subject: ' || p_subject || UTL_TCP.crlf);
   UTL_SMTP.write_data (l_mail_conn,'Reply-To: ' || p_from || UTL_TCP.crlf || UTL_TCP.crlf);

   UTL_SMTP.write_data (l_mail_conn,p_message || UTL_TCP.crlf || UTL_TCP.crlf);
   
   UTL_SMTP.close_data (l_mail_conn);

   UTL_SMTP.quit (l_mail_conn);
END;
/
begin
  dbms_network_acl_admin.create_acl (
    acl         => 'utl_mail.xml',
    description => 'Allow mail to be send',
    principal   => 'Mail Gonderecek Username',
    is_grant    => TRUE,
    privilege   => 'connect'
    );
    commit;
end;


BEGIN
  DBMS_NETWORK_ACL_ADMIN.assign_acl (
  acl => 'utl_mail.xml',
  host => 'mail server', 
  lower_port => '25',
  upper_port => '25');
  COMMIT;
END;
/
Begin
MAIL_GONDER('Gonderilen mail adresi','Konu','Deneme mesajı');
End;
/

exec MAIL_GONDER('Gonderilen mail adresi','Konu','Deneme mesajı');

3,468 total views, 6 views today


Oracle Partition

Bu yazımda sizlere hemen hemen Tüm Veritabanı yönetim sistemlerinde var olan Partitioning gibi güzel bir teknolojiyi anlatacağım.

Partitioning teknolojisini genel olarak ifade edersek çok büyük tablolarımızı, indexlerimizi yada index-organized tablolarımızı ayrı ayrı segmentlerde oluşturabilmemize olanak sağlayan bir teknolojidir diyebiliriz. Yani mantıksal olarak bir bütün halinde görünen büyük tablo yada indexleri Partitionlı yapıya dönüştürdüğümüzde daha küçük farklı fiziksel bölümlere ayırabilmekteyiz.

Özellikle çok büyük veritabanı sistemlerinde(VLDB=Very Large DB) terabytelar seviyesinde datanın olması hem bu datanın bakımında hem de üzerinde gerekli işlemlerin yapılabilmesinde sıkıntılara yol açar. Bununla baş edebilmenin ilk akla gelen en etkin yolu bu büyük parçayı daha ufak parçalara ayırmaktır.Burada devreye “partitioning” kavramı girmektedir.”Partitioning” verilerin bir bütün içersinde parçalara ayrılması seklinde kabaca açıklanabilir.

Partitioning ile bir tablo ya da index kendi içinde daha küçük parçalara ayrıştırılıp kullanılabilir.İşin güzel yanı bu yapıldıgı takdirde yazılan DML sorgu vs. scriplerde herhangi bir değişiklik yapmanıza gerek yoktur. Oracle bunu kendisi halleder.(Tabi bazı durumlarda partition ismi vererekte işlem yapmak gerekebilir.) Ancak, partitionlar tanımlandıktan sonra,  DDL sorguları tabloların veya indexlerin tamamı yerine bireysel partitionlara erişebilir ve bunları işleyebilir. Bu, bölümlemenin büyük veritabanı nesnelerinin yönetilebilirliğini nasıl basitleştirebileceğidir.

Bir tablonun veya indexin her partitionı, sütun adları, veri türleri ve kısıtlamalar gibi aynı mantıksal niteliklere sahip olmalıdır, ancak her partition, sıkıştırmanın etkin veya devre dışı bırakılmısı fiziksel storage ayarları ve tablospace gibi ayrı fiziksel niteliklere sahip olabilir. Örneğin Bir tablonun en eski 10 yıllık verilerini SATA disklere yönlendirirken güncel verilerinin SAS üzerinde olacak Ģekilde konumlandırabiliriz.

Partitioning, özellikle büyük hacimli verileri yöneten uygulamalar olmak üzere birçok farklı türde uygulama için kullanışlıdır. OLTP sistemleri genellikle yönetilebilirlik ve kullanılabilirlikteki gelişmelerden yararlanırken, veri depolama sistemleri performans ve yönetilebilirlikten yararlanır.

Partitioning şu avantajları sunar:

  • Tüm tablo yerine index oluşturma ve rebuilding, partition düzeyinde yedekleme ve kurtarma gibi veri yönetimi işlemlerini sağlar. Bu, bu işlemler için önemli ölçüde azaltılmış zamanlarla sonuçlanır. (Örneğin partition metoduna bağlı olarak 5 farklı partition olan bir tabloda 2. partition ı drop edebilir, farklı bir index oluşturabilir ya da bu partition’ı tablodan bağımsız olarak truncate edebilirsiniz.)
  • Büyük parçalar ile uğraşmak yerine küçük parçalar ile uğraşıldığından özellikle sorgula işlemlerinde büyük kazanç sağlar.
  • Maintenance işlemleri için zamanlanmış downtime süresinin etkisini önemli ölçüde azaltır.
  • Paralel execution, kaynak kullanımını optimize etmek ve execution time’ı en aza indirmek için özel avantajlar sağlar. Parallel execution, sorgular ve DML ve DDL için desteklenir.

(continue reading…)

146 total views, no views today


Oracle Data Concurrency and Consistency

Tek kullanıcılı bir veritabanında, bir kullanıcı aynı verileri aynı anda değiştiren diğer kullanıcılar için endişe duymadan verileri değiştirebilir. Ancak, çok kullanıcılı bir veritabanında, aynı anda birden fazla transaction içindeki ifadeler aynı verileri güncelleyebilir. Eşzamanlı olarak gerçekleştirilen transactionlar anlamlı ve tutarlı sonuçlar üretmelidir. Aynı anda aynı tablo hatta aynı satırlar üzerinde işlem yapan çok kullanıcılı sistemler artık kaçınılmaz.Hal böyle olunca bilgilerin tutarlılığının sağlanması istenmeyen sonuçları almamak açısından çok önemlidir. Çok kullanıcılı bir veritabanı aşağıdakileri sağlamalıdır.

  • Kullanıcıların aynı anda verilere erişebileceği güvencesi (veri eşzamanlılığı – data concurrency). Kısaca pek çok kullanıcının aynı anda aynı dataya ulaşabilmesi durumu
  • Her kullanıcının, kendi işlemleri tarafından yapılan görünür değişiklikler ve diğer kullanıcıların taahhüt ettiği işlemler de dahil olmak üzere verilerin tutarlı bir görüntüsünü (veri tutarlılığı – data consistency) gördüğü güvencesi. Kısaca her bir kullanıcının kendisinin ya da bir başka kullanıcının transaction ı aynı anda calişsa bile tutarlı bir data setine sahip olabilmesi şeklinde özetlenebilir.

Transactionlar aynı anda çalıştığında tutarlı işlem davranışını tanımlamak için, veritabanı araştırmacıları serializability adı verilen transaction isolation modeli tanımladılar. Bu konu ile ilgili detaylı bilgiyi bir önceki yazımda vermiştim. Serializable bir transaction, başka hiçbir kullanıcı veritabanındaki verileri değiştirmemiş gibi görünmesini sağlayan bir ortamda çalışır.

Transactionlar arasında bu tür bir isolation derecesi genellikle arzu edilmekle birlikte, birçok uygulamayı serializable modda çalıştırmak, uygulama verimini ciddi şekilde tehlikeye atabilir. Eşzamanlı çalışan transactionların tamamen isolationı, bir transactionın başka bir transaction tarafından sorgulanan bir tabloya ekleme yapamayacağı anlamına gelebilir. Kısacası, gerçek dünyadaki düşünceler genellikle mükemmel transaction isolationı ve performans arasında bir uzlaşma gerektirir.

Oracle Database, multiversion consistency modeli ve çeşitli lock ve transaction türlerini kullanarak veri tutarlılığını(consistency) korur. Bu şekilde, veritabanı, eşzamanl ı(concurrent) olarak birden fazla kullanıcıya veri görünümü sunabilir, bu da her bir görünümün zaman içindeki bir noktayla tutarlı olmasını sağlar. Farklı veri bloğu versiyonları aynı anda mevcut olabileceğinden, işlemler bir sorgu için gereken zamanda işlenen verilerin versiyonunu okuyabilir ve zaman içindeki tek bir noktayla tutarlı olan sonuçları döndürür.

Multiversion Read Consistency

Oracle Veritabanında, multiversioning, aynı anda birden fazla veri versiyonu gerçekleştirme yeteneğidir. Oracle Database, multiversion okuma tutarlılığını korur. Oracle veritabanının sorguları aşağıdaki özelliklere sahiptir:

  • Read-consistent queries

Bir sorgu tarafından döndürülen veriler zaman içinde bir point için kesin ve tutarlıdır.

Not: Oracle Database hiçbir zaman,  kirli okumalara (dirty read) izin vermez. Dirty Read bir başkası tarafından (bir başkasının transaction’ı tarafından) henüz commit edilmemiş verinin, diğer kullanıcının transaction’ı tarafından okunmasına denir.

  • Nonblocking queries

Veritabanında da sorgulayanlar ve DML işemi yapanlar birbirlerini engellemez.

Oracle’ın garanti ettiği 2 tane uyumluluk kontrolü vardır. Bunlar, Statement level read consistency ve Transaction level read consistency dir. Bunlar, Oracle’ın her zaman bir sorgunun veri ile döneceğini ve her sorgunun veriye ulaşacağını garanti eden koşullardır.

Statement-Level Read Consistency

Oracle Database her zaman statement düzeyinde okuma tutarlılığını(read consistency) zorlar; bu, bir sorgu tarafından döndürülen verilerin zaman içinde tek bir nokta için kararlı ve tutarlı olduğunu garanti eder. Tek bir SQL ifadesinin tutarlı olduğu nokta, transaction isolation level ve sorgunun yapısına bağlıdır:

  • Read committed isolation level, bu nokta sorgunun açıldığı zamandır. Örneğin, bir SELECT ifadesi SCN 1000’de açılırsa, bu ifade SCN 1000 ile tutarlıdır.
  • Serializable veya read-only transaction, bu nokta transactionın başladığı zamandır. Örneğin, bir transaction SCN 1000’de başlarsa ve bu transactionda birden fazla SELECT ifadesi varsa, her ifade SCN 1000 ile tutarlıdır.
  • Bir Flashback Sorgu işleminde (SELECT … AS OF), SELECT ifadesi, zamandaki noktayı açıkça belirtir. Örneğin, bir tabloyu geçen perşembe saat 2: 00’de göründüğü gibi sorgulayabilirsiniz.

Yani transaction t anında bir sorgulama başlattığında bu t anına kadar olan bilgileri getirme garantisi vardır.Yani t+1 anında bir data girildiğinde bu datalar t anında başlatılan sorguda görülmezler.Peki bu değişiklikler olduğu halde nasıl tutarlı data getiriliyor.Oracle bunu rollback segment bilgisini okuyarak sağlar.

Transaction-Level Read Consistency

Oracle Database ayrıca, transaction-level read consistency olarak bilinen bir transaction daki tüm sorgulara okuma tutarlılığı sağlayabilir. Bu durumda, bir transaction daki her ifade aynı zaman diliminde veri görür; bu transactionın başladığı zamandır.

Serializable transaction tarafından yapılan sorgular, transactionın kendisinde yapılan değişiklikleri görür. Örneğin, employees güncelleyen ve ardından employees sorgulayan bir transaction güncellenen verileri görecektir. Transaction-level read consistency repeatable read isolation Leveldir ve sorguyu phantom read’a maruz bırakmaz.

Yani , transaction-level read consistency sinde statement-level read consistency sinden farklı olarak bir transaction içersinde tek bir sorgulama yerine birden fazla sorgulama için aynı garanti verilmektedir.Bu sayede bir sorgulama hiçbir zaman “dirty read” yapmayacağı gibi transaction ların yaptığı commit lerdende etkilenmez.Bu sadece SELECT için değil koşul içeren DELETE, UPDATE,sorgulama ile yapılan INSERT işlemlerinde de geçerlidir

Read Consistency and Undo Segments

Multiversion read consistency modelini yönetmek için, bir tablo aynı anda sorgulandığında ve güncellendiğinde veritabanı read consistency sağlaması için veri kümesi oluşturması gerekir. Oracle Database, verileri geri alma yoluyla(undo data aracılığıyla) okuma tutarlılığı(read consistency) sağlar. Bir kullanıcı verileri değiştirdiğinde, Oracle veritabanı, segmentleri geri almak için yazdığı undo segmentlerini oluşturur .

Undo segmentleri, uncommitted veya son zamanlarda değiştirilmiş transactionlar ile değiştirilen eski veri değerlerini içerir. Bu nedenle, aynı verinin birden fazla sürümü (verisyonu), hepsi zaman içindeki farklı noktalarda, veritabanında bulunabilir. Veritabanları, verilerin read-consistenti sağlamak ve nonblocking sorguları etkinleştirmek için farklı noktalardaki verilerin anlık görüntülerini(snaphot) kullanabilir.

Single instnace ve Oracle Real Application Cluster (Oracle RAC) ortamlarında read consistency garanti edilir. Oracle RAC, bir veritabanı instance’ından diğerine veri bloklarının read-consistent aktarmak için cache fusion olarak bilinen bir cache-to-cache bloğu aktarım mekanizması kullanır.

Aşağıdaki resimde statement-level read consistency sağlamak için  undo veri kullanan bir sorgu gösterir read committed isolation level.

Bu grafik, altında “SCN 10023″ yazan bir SELECT ifadesini gösterir. Açıklamada, her biri farklı bir SCN: 10021, 10021, 10024 (shaded blok), 10008, 10024 (shaded blok), 10011, 10021 şeklinde bir bloklar sütunu bulunur. ” Scan Path ” etiketli bir ok, SELECT ifadesinden sütun boyunca sonuna kadar gider, ancak ok, shaded blokların sağına çıkar ve sütunun sağına asılı olan bloklardan geçer: biri SCN 10006 ve diğeri ile SCN 10021 ile. Undo Segment etiketli bir daire bu iki bloğa işaret eder.

Veritabanı bir sorgu adına veri blokları alırken, veritabanı her sorgudaki verinin sorgu başladığında bloğun içeriğini yansıtmasını sağlar. Veritabanı, bloğun, sorgu işlemenin başladığı noktadaki bloğu yeniden yapılandırması için gereken değişiklikleri geri alır.

Veritabanında işlemlerin sırasını garanti altına almak için SCN adı verilen internal sıralama mekanizması kullanılmaktadır. SELECT ifadesi execute aşamasına girerken, veritabanı, sorgunun çalışmaya başladığı sırada kaydedilen SCN’yi belirler.  Yukarıdaki şekilde bu SCN 10023’tür. Sorgu yalnızca SCN 10023 ile ilgili taahhütlü verileri görür.

Yukarıdaki şekilde 10023’ten sonra SCN’lere sahip bloklar, SCN 10024’e sahip iki blokta gösterildiği gibi değiştirilmiş verileri gösterir. SELECT ifadesi, blokta yapılan değişikliklerle tutarlı bir versiyonunu gerektirir. Veritabanı, geçerli veri bloklarını yeni bir buffere kopyalar ve blokların önceki sürümlerini yeniden oluşturmak için undo verilerini uygular. Bu yeniden yapılandırılmış veri bloklarına consistent read (CR) klonları denir. Yukarıdaki şekilde, veritabanı iki CR klonu yaratır: bir blok SCN 10006’ya ve diğer blok ise SCN 10021’e uyumludur. Bu şekilde, Oracle Database dirty read’i önler. (continue reading…)

166 total views, 4 views today


  • Sertifikasyon



  • Etiketler

  • Topluluklar

                     
                     
  • Live Traffic Feed

    Feedjit Widget
  • Copyright © 1996-2010 Mustafa Bektaş Tepe. All rights reserved.
    Türkçeleştirme Blogizma | AltyapıWordPress
    Takip Et

    Her yeni yazı için posta kutunuza gönderim alın.

    Diğer takipçilere katılın: