Sisteme Connect Olan Kullanıcıları Tespit Etme

 Database’ deki kullanıcı sayısı fazla olan şirketler de bir süre sonra şöyle bir problem ortaya çıkıyor. İşe başlayan personele bir database accountu açılıyor. Sonra zaman içerisinde kimi personel ayrılıyor, kimisi yeni işe başlıyor derken ipin ucu bir noktada kaçabiliyor dolayısıyla işten ayrılmış olan personelin accountu sistemde açık olarak kalabiliyor. Buda aslında sisteminiz için bir güvenlik açığı oluşturuyor. Peki bunu nasıl giderebiliriz? Birebir çözümü olmasa da (en azından ben öyle düşünüyorum) şöyle bir tespitte bulunabiliriz. Database’ e connect olan kullanıcıları sisteme giriş yaptığı anda tespit edip, bizim istemiş olduğumuz bazı bilgileri bir tabloya yazdırıp sonrasında sistemdeki tüm kullanıcılar ile karşılaştırıp baktığımız zaman aralığında sisteme hiç giriş yapmamış olan kullanıcıları bulabiliriz. Tabi bu kullanıcıları hemen drop etmek çok akıllıca olmayabilir, burada şu yapılabilir bu kullanıcıların  accountları locklanıp en azından araştırmak için zaman kazanılabilir. Şimdi bunun için neler yapmamız gerektiğine bakalım;

Önce v$sessionın tüm kolonlarını içeren bir tablo create edip, trigger da bunu kullanacğım. Aslında bu iş için v$session tablosundaki tüm kolonlara ihtiyacımız yok, siz isterseniz insert ve create table scriptini özelliştirip nesnelerinizi kolon bazında tanımlayıp create edebilirsiniz.

– tablomuzu create edelim ;

create table erdem.logon_user as select * from v$session where 0=1
Table created.

– triggerımızı create edelim ;

create or replace trigger
   erdem.logon_user_control
AFTER LOGON ON DATABASE
BEGIN
insert into erdem.logon_user select * from  v$session ;
END;
/

Trigger created.

Şimdi tablomuzu kontrol edelim, yeni gelen sessionlara ait tüm bilgileri bizim tablomuzada insert ediyor olması gerekiyor.

select count(*)  from erdem.logon_user ;

 

COUNT(*)
——————
     1078
1 row selected

Evet tablo doluyor, problem yok.

Şimdi yaptığımız işlemleri geri alalım. Temizlik zamanı;

drop trigger    erdem.logon_user_control ;
Trigger dropped

drop table erdem.logon_user ;
Table dropped

Umarım işinize yarar zaman zaman bu tarz bilgileri kimi uygulama sahipleri isteyebiliyor.

LOGGING & NOLOGGING farklılıkları..

Ne Zaman Hangisini Kullanmalıyım? LOGGING mi? NOLOGGING mi?

LOGGING kelimesi tablo, index veya tablespace oluştururken kullandığımız anahtar kelimedir. Objeyi oluştururken LOGGING kullanırsak ilgili obje üzerindeki DML işlemleri redo log dosyasında loglanır. NOLOGGING kullanılırsa log üretimi bazı durumlarda yapılmaz. LOGGING/NOLOGGING üzerine forumlarda bir çok soru sorulmaktadır. Sorulardan bazıları şu şekilde: NOLOGGING avantajı nedir? Ne zaman NOLOGGING kullanmalıyız? Tablespace düzeyinde NOLOGGING kullanıldıysa, bu tablespace içindeki tablolarımız LOGGING olabilir mi?

Tablespace seviyesindeki LOGGING/NOLOGGING kelimesi sadece bu tablespace içinde oluşturulacak objelerin varsayılan LOGGING durumunu tablespace ‘den miras (inherit) alması içindir. Şimdi test yaparak tek tek inceleyelim.

Önce NOLOGGING kullanarak NOLOGGING_TS adında bir tablespace oluşturuyorum.

CREATE TABLESPACE NOLOGGING_TS DATAFILE

‘/data_TALIPDB/nologging_ts.dbf’ SIZE 1024M AUTOEXTEND OFF

NOLOGGING

ONLINE

PERMANENT

EXTENT MANAGEMENT LOCAL UNIFORM SIZE 10M

BLOCKSIZE 8K

SEGMENT SPACE MANAGEMENT AUTO

FLASHBACK ON;

Şimdi oluşturduğumuz NOLOGGING_TS tablespace içinde aşağıdaki gibi bir tablo oluşturalım ve tablo scriptimizde LOGGING/NOLOGGING ifadesini kullanmayalım;

CREATE TABLE erdem_deneme (

id NUMBER

)

TABLESPACE nologging_ts;

Aşağıdaki sorgu ile baktığımızda tablomuzun NOLOGGING (LOGGING=NO) olarak oluşturulduğunu görürüz.

SELECT table_name, logging

FROM dba_tables

WHERE tablespace_name = ‘NOLOGGING_TS’

TABLE_NAME LOGGING

—————————— ——-

ERDEM_DENEME NO

Şimdi de tablomuzu aşağıdaki gibi LOGGING ifadesini kullanarak, oluşturduğumuz NOLOGGING_TS tablespace içinde oluşturalım.

CREATE TABLE erdem_deneme2 (

id NUMBER

)

TABLESPACE nologging_ts

LOGGING;

Yukarıdaki sorgu ile baktığımızda tablomuzun LOGGING (LOGGING=YES) olarak oluşturulduğunu görürüz.

SELECT tablespace_name, logging

FROM dba_tables

WHERE table_name = ‘ERDEM_DENEME2′

TABLE_NAME LOGGING

—————————— ——-

ERDEM_DENEME    NO
ERDEM_DENEME2  NO
O halde tablespace seviyesinde LOGGING/NOLOGGING kelimesinin kullanılması, bu tablespace içinde oluşturulacak objelerin varsayılan loglama durumunu tablespace ‘den alması içindir.

NOLOGGING olarak oluşturulan bir tablo sonradan aşağıdaki gibi LOGGING yapılabilir. Veya tam tersi de olabilir.

ALTER TABLE  erdem_deneme LOGGING;

ALTER TABLE erdem_deneme2 NOLOGGING;

Bu durum tablespace içinde geçerlidir. NOLOGGING olarak oluşturulan bir tablespace sonradan aşağıdaki gibi LOGGING yapılabilir. Veya tam tersi de olabilir.

ALTER TABLESPACE nologging_ts LOGGING;

Bu durumda tablespace içinde önceden oluşturulan NOLOGGING objeler, NOLOGGING olarak devam edecektir. Bu tablespace içinde yeni oluşturulacak objelerin varsayılan loglama durumu LOGGING olacaktır. Yazımın başında NOLOGGING kullanılırsa log üretim işlemi bazı durumlardayapılmaz demiştim. NOLOGGING kullanılırsa bazı durumlarda log üretimi devam edebilir. Peki bu durumlar nelerdir?

Tablo Log Durumu	Insert Modu	Arşiv Modu	Redo Log üretimi
LOGGING	APPEND	ARCHIVE LOG	REDO Üretilir
NOLOGGING	APPEND	ARCHIVE LOG	REDO Üretilmez
LOGGING	No APPEND	ARCHIVE LOG	REDO Üretilir
NOLOGGING	No APPEND	ARCHIVE LOG	REDO Üretilir
LOGGING	APPEND	NO ARCHIVE LOG	REDO Üretilmez
NOLOGGING	APPEND	NO ARCHIVE LOG	REDO Üretilmez
LOGGING	No APPEND	NO ARCHIVE LOG	REDO Üretilir
NOLOGGING	No APPEND	NO ARCHIVE LOG	REDO Üretilir

SQL*Loader veri yükleme yöntemlerinden birisi olan “Direct Path Load” işlemleri NOLOGGING bir tabloda redo log üretmez. Veritabanında “force logging” yapılmışsa, yani loglamaya zorlanmışsa, her zaman (LOGGING veya NOLOGGING) redo log üretilir. Tablo LOGGING modunda olsa bile veritabanı arşiv modu NO ARCHIVE LOG ise, “Direct Path Load” işlemleriredo log üretmez. Veritabanı arşiv modu ARCHIVE LOG ise, tablomuz LOGGING modunda redo log üretir. Yine böyle bir durumda “Direct Path Load” işlemleri redo log üretir. Veritabanı arşiv modu ARCHIVE LOG olsa bile tablomuz NOLOGGING modunda redo log üretmez. Yine böyle bir durumda “Direct Path Load” işlemleri redo log üretmez.

“Direct Path Load” dediğimiz işlem, buffer cache ‘i geçerek direk disk ile işlem yapar.

Bir tabloyu NOLOGGING oluşturmak LOGGING olarak oluşturmaktan daha kısa sürer. Basit bir test yapalım. Önce “dba_tables” görüntüsünün (view) bir kopyasını oluşturmak isteyelim. Önce LOGGING olarak kopya oluşturalım ve işlem süresini görelim;

Süreleri inceledğimizde NOLOGGING işlem daha kısa sürdüğünü görüyoruz.

NOLOGGING yapılacak objeler genelde verisi hiç değişmeyen, sabit objelerdir. Versi hiç değişmeyen parametrik tablolar, doldur/boşalt tablolar örnek olarak verilebilir. Bu tip objelerin mutlaka tam (full) yedeği alınmalıdır. Aksi takdirde kurtarma (recover) işlemini gerçekleştiremezsiniz. Son olarak aklınıza şöyle bir soru gelebilir. NOLOGGING olarak açılan bir tabloda bir kaydı yanlışlıkla silersek artık rollback yapamam gibi bir durum söz konusu değildir. Tablonuz NOLOGGING olsa bile, yanlışlık sildiğiniz bir kaydı rollback ile geri getirebilirsiniz. Çünkü bu işlem UNDO dediğimiz segmentlerle alakalıdır. LOGGING/NOLOGGING tamamen redo ile alakalı bir durumdur. Bu durum ile alakalı da bir örnek yapalım. Önce NOLOGGING bir tablo oluşturalım;

CREATE TABLE erdem_deneme3 (

isim varchar2(10)

)

NOLOGGING;

Tablomuza bir kayıt girelim;

insert into erdem_deneme3 values(‘erdem’);

commit;

Kaydımızı silelim;

delete from erdem_deneme3;

rollback;

select * from erdem_deneme3;

rollback yaptığımızda tablomuz NOLOGGING olduğu halde verimizin geri geldiğini gördük. Demek ki rollback işlemi LOGGING/NOLOGGING ile alakalı değildir.