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…)

3,916 total views, 2 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,116 total views, no 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,068 total views, no 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,033 total views, 2 views today


SQL Sorgusunun Shared Pool’dan Silinmesi (Flush)

Bir tabloda sürekli olarak belirli satırları sorguluyor ya da değiştiriyorsanız, her seferinde diske gitmeniz mantıklı olmaz. Çünkü I/O maliyetli bir işlemdir. Bu yüzden bellek performans için can simididir. Sıkça okuduğunuz ya da sıkça değiştirdiğiniz şeyleri her seferinde diske yazmak ya da diskten okumak yerine bunu bellekte kotarabilirseniz, performansı arttırabilirsiniz. Bellekte çalışmak performans konusunda artış sağladığından Oracle da böyle yapar; diskte çalışmak yerine mümkün olduğunca belleği kullanır. İşte bu yüzden bir sorguyu ikinci defa çalıştırdığınızda, sonuçlar daha hızlı gelir. Çünkü sorguda kullanılan block’lar hâlâ ‘sıcaktır’ ve diske hiç gitmeden, direkt bellekten sonuç döner. Bellekte yer kalmadığında, daha sıcak (kullanım sıklığı daha fazla) olan block’lar, soğuk (kullanım sıklığı daha az) block’ların yerini alır. Oracle kapalı bir yazılım olduğundan arka plânda ne olduğunu elbette bilemiyoruz. Ama zekice yazılmış bir Least Recently Used – LRU algoritmasıyla bu işin yapıldığını tahmin edebiliriz.
İşlemlerin bellekte gerçekleştirilmesi güzel bir olay. Ama bazı durumlarda (performans problemleriyle karşı karşıya kaldığımızda ya da testlerin daha tutarlı olması gerektiğinde) Oracle’a bazı komutlarla müdahele etmemiz gerekir.

1. BUFFER CACHE

Oracle’da birçok şey sadece bellekte tamamlanıyor. Örneğin bir DML işlemi (insert, update, delete) yaptığınızda gidip veritabanı dosyalarına yazması gerekmez. Ya da bir sorgu çalıştırdığınızda, sorgu biter bitmez, veri saklayan block’ların bellekten atılması gerekmez. Block’lar sorgulara göre bellekte tutulabilir. Hatta çalıştırdığınız sorgular, diske hiç erişmeden sonuç dönüyor olabilir. Bununla ilgili bir örnek üzerinden gidelim. Önce aşağıdaki gibi tabloyu yaratıyoruz:

create table test as select * from dba_objects;

Yarattığımız tabloda toplamda 96.760 kayıt var ve tablonun bulunduğu tablespace’te her block 8K’dan oluşuyor. DBA_SEGMENTS’ten baktığımda tablonun 11.534.336 byte (11MB) kapladığını ve 1408 block’tan oluştuğunu görüyorum. Tablo istatistiklerini topladığımdaysa, 1387 block görünüyor. (Block boyutunu 1K’ya kadar indirip, PCTFREE değerini düşürebilseydik; bu ikisi arasındaki fark daha da ufak olabilirdi.)
Sırada basit bir sorgu yazmak var:

SELECT COUNT(*)FROM test WHERE OBJECT_ID >1000;

Şimdi de sorgunun ne kadar disk okuması yaptığına bakalım.

SELECT a.SQL_ID,A.DISK_READS,A.EXECUTIONS,A.BUFFER_GETS  FROM V$SQL a 
WHERE a.SQL_TEXT LIKE'%SELECT COUNT(*) FROM TEST WHERE OBJECT_ID > 1000%'
SQL_ID        DISK_READS EXECUTIONS BUFFER_GETS
------------- ---------- ---------- -----------
77mjdqdj82paz    1395          1           1450

Buradaki DISK_READS, okunan block sayısı; EXECUTIONS ifadenin kaç kere çalıştığı; BUFFER_GETS ise SQL ifadesi nedeniyle bellekten ne kadar blockokunduğunu gösteriyor. Bunları daha iyi görebilmek için aynı sorguyu defalarca çalıştırıyorum:
Sorguyu defalarca çalıştırdıktan sonra, EXECUTIONS sayısı arttığı hâlde DISK_READS artmıyor, fakat BUFFER_GETS ciddi bir artış gösteriyor. Yani SQL’in diske gitmeden sürekli bellekten sonuç döndüğünü görebiliyoruz. Bu güzel bir özellik ama eğer bir SQL’i test ediyor olsaydım, sonuçları sürekli bellekten okumak beni yanıltırdı. Bu gibi durumlar için bellekteki block’ları boşaltmak daha doğru sonuçlar elde etmemi sağlar. Burada aşağıdaki komutla manüel olarak buffer cache’in içini boşaltıyoruz.

ALTER SYSTEM FLUSH BUFFER_CACHE;

Özetle FLUSH BUFFER_CAHCE yaparsanız;
• Bellekte tutulan block’lar atılır.
• Dirty Buffers (değişime uğramış ama diske yazılmamış, bellekte tutulan block’lar) diske yazılır
• SQL Plan bozulmaz
• SQL ile ilgili istatistikler silinmez

2.SHARED POOL

İlk kez çalışan SQL ifadeleri hard parse yapılır. SQL ifadesi hash’lenerek ona özel bir kimlik (SQL_ID) verilir; ihtimaller hesaplanarak en uygun (cost’u en düşük) plan belirlenir. Bu masraflı bir iştir; CPU’ya maliyeti vardır. Bu yüzden plan tekrar tekrar hesaplanmaz. Aynı ifade söz konusu ise aynı plan üzerinden gidilir. Bu güzel bir özellik ama bazı zamanlar operasyonumuz sonrası SQL’imiz için yeni bir execution plan oluştursuz isteriz. Bu gibi durumlardan sakınmak için shared pool’u boşaltmak bir çözümdür;

ALTER SYSTEM FLUSH SHARED_POOL;

Yukarıda anlattıklarım zaten bilinen şeyler. Fakat göstermek istediğim bir durum var. Aşağıdaki sorguyu çalıştırırsanız artık sonuç boş gelecektir –ki bu beklediğimiz bir şey. Çünkü SQL ID ve buna bağlı her şey gidiyor.

SELECT a.SQL_ID,A.DISK_READS,A.EXECUTIONS,A.BUFFER_GETS  FROM V$SQL a 
WHERE a.SQL_TEXT LIKE'%SELECT COUNT(*) FROM TEST WHERE OBJECT_ID > 1000%'
SQL_ID        DISK_READS EXECUTIONS BUFFER_GETS
------------- ---------- ---------- -----------
no rows selected.

Şimdi ilk sorgumuzu tekrar çalıştırıp, disk okumalarına bakalım:

SELECT a.SQL_ID,A.DISK_READS,A.EXECUTIONS,A.BUFFER_GETS  FROM V$SQL a 
WHERE a.SQL_TEXT LIKE'%SELECT COUNT(*) FROM TEST WHERE OBJECT_ID > 1000%'
SQL_ID        DISK_READS EXECUTIONS BUFFER_GETS
------------- ---------- ---------- -----------
77mjdqdj82paz    0          1           1450

İlk defa çalıştırıldığı ve sql plan ilk defa hazırlandığı hâlde, hiç disk okuması yapılmıyor.
Özetle FLUSH SHARED_POOL yaparsanız;
• Bütün SQL planları ve bellekte tutulan SQL bilgilerini atarsınız.
• Ancak bu buffer cache’te tutulan data block’larını etkilemez. Daha önce eriştiğiniz block’lar hâlâ bellektedir. (continue reading…)

14 total views, no views today


Dosya Sistem Bakımı (tune2fs komutu)

Dosya sistemini oluşturduktan sonra sistem yöneticisi tarafından bazı bakımların yapılması gerekebilir. Bu bakım ve dosya sistemindeki bazı parametre değişiklikleri tune2fs komutu ile yapılabilmektedir.

Tune2fs komutu ext2,ext3 ve ext4 dosya sistemlerine kullanılabilmektedir. Tunefs ile yapılabilecek bazı değişiklikler:

  • Dosya sistemleri arası geçiş. Örn. Ext2’den ext3’e geçiş
  • fsck işleminin yapılması için geçmesi gereken zaman aralığı veya mount sayısını belirler (-c ve –i parametreleri)
  • Mevcut dosya sistemi hakkında bilgiler verir. (-l parametresi)

Linux tune2fs komutu

Modern dosya sistemleri hatalara karşı dayanıklılığı arttırmak için journal (günlük) tutarlar. Dosya sisteminde herhangi bir işlem yapılmadan önce günlüklere kaydedilir. Daha sonra yapılacak olan iş yerine getirilir. Dosya sisteminde herhangi bir hata meydana geldiğinde günlüklerdeki muamele girdileri konrol edilerek hata düzeltilmeye çalışılır. Günlüklü dosya sistemleri, günlüksüz olanlara göre çok daha hızlı bir dosya sistemi kurtarma işlemi gerçekleştirebilir. Örneğin ani güç kesilmesi durumunda fsck aracı dosya ve dizinleri teker teker kontrol etmek yerine günlük girdileri kontrol edilir. Böylece dosya sistemini bozulmadan önceki durumuna kolayca çevirebilir. Linux ext2 dosya sistemi günlüğe sahip değildir. Ext3 dosya sistemi ise günlük kullanır. Eğer dosya sisteminiz ext2 ise ve ext3 dosya sistemine terfi etmek istiyorsanız, bu terfi işlemini biçimlendirme (format) işlemine gerek kalmadan gerçekleştirebilirsiniz. Bunun için;

tune2fs -j /dev/hdd3

Mustafa Bektaş Tepe

İyi Çalışmalar

416 total views, no 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: