Oracle 12c New Features : DBMS_PRIVILEGE_CAPTURE Package

Database’ in güvenliğinin sağlanması için belirli periyotlar arasında şirketlerin güvenlik birimleri aracılığıyla (özellikle bankalar bu konuda en hassas olan kurumlardır) database’ deki kullanıcıların yetkileri sorgulanır ve fazla olduğu düşünülen yetkilerin revoke edilmesi istenir. Ancak production sistemlerde yetki almak kimi aman çokda kolay olmamaktadır. Yetki revoke edildiğinde uygulamanın bu durumdan etkilenip etkilenmeyeceği, ilgili user tarafından bu yetkinin kullanılıp kullanılmadığı tam olarak kestirilemediği durumlar olabiliyor. Hal böyle oluncada yetkiyi revoke etmeye cesaret edilemediği durumlar yaşanmıyor değil 

Oracle 12c ile birlikte aslında bu soruna cevap bulunmuş oldu. Dbms_privilege_capture paketi ile kullanılan user hangi yetkinin kullanıldığını capture eden faydalı bir package’ dir. Privilege kullanıldığı zaman capture edildiğinden dolayı bu paket aracılığıyla toplanan yetkiler kullanılan yetkiler olarak yorumlanmalıdır.

Şimdi bu işlemi nasıl yapabileceğimiz den ve dbms_capture_privilege paketinin kullanımından bahsedelim.

DBMS_PRIVILEGE_CAPTURE paketinin spec’ ine baktığınız da 5 adet procedureden oluştuğunu görebilirsiniz.

Continue reading

ORA-16474: target_db_name not found in the LOG_ARCHIVE_DEST_n parameter

Dataguard kurulumları sonrasında switchover veya 12c ile birlikte gelen verify komutunu çalıştırdığınız da aşağıdaki gibi bir hata alırsanız bunun nedenini ve nasıl çözüleceğinden bahsediyor olacağım.

Primary database tarafında log_archive_dest2 yi “SERVICE=con_stby LgWR SYNC AFFIRM” şekilde set etmeniz durumunda da dataguard çalışır. Bunun için dataguardınızın hengi modda çalıştığının bir önemi yoktur.

Ancak bu şekilde set ettiğiniz de switchover yapmak istediğiniz de (primary database üzerinde)

Hatasını alırsınız. Bu hatayı gidermek için (aslında hatanın açıklamasında yer aldığı üzere) primary database’ de dest2 parametresine db_unique_name kısmını da eklemek gerekmektedir , aşağıdaki şekilde tekrar alter edelim ;
Continue reading

Oracle 12c New Features – Grid Infrastructure Management Repository (GIMR – MGMTDB Database)

MGMTDB database, oracle 12c ile birlikte tanışmış olduğumuz databaselerden bir tanesi, oracle 12c RAC kurulumu ile bilirkte geliyor. Oracle 12.1.0.1 versiyonunda opsiyonel olan ve aşağıdaki ekranda YES seçilmesi sonrasında otomatik olan kurulunan MGMTDB database oracle 12.1.0.2 versiyonu ile birlikte zorunlu hale gelmiş olup, 12c RAC kurulumunda artık bu ekran gelmemektedir.

gmt

Management database, CHM (Cluster Health Monitor) ve diğer verileri, istatistiki verileri depolamak için merkezi ve veritabanı olarak tanımlanabilir.

Bu yazıda anlatacağım tüm testlerimi Oracle 12.1.0.2 versiyonu ile yaptım. Dolayısıyla bir karşılaştırma veya kıyaslama yapacaklar için bilgi olarak belirtmek istedim.

Kurulum sonrasındaki durum ;
Continue reading

Oracle 12c New Features ; Tablo Bazında Recover İşlemi

Oracle 12c ile birlikte dba’ ler olarak aslında bizim en çok beklediğimiz bikaç özellikden biride tablo bazında recover işlemini yapabilmekti. Bu aslında çokda karşılaştığımız “Nasıl yani sadece bir tabloyu dönemiyormusunuz” gibi sorularada cevap olmuş oldu. Ama burda şunu da söylemeden geçemiycem umarım developerların bu özellikden çok da haberleri olmaz. Tabiki çalıştığım veya tanıdığım çok iyi yazılımcılarda var ama olmayanlarda var. Dolayısıyla her yapılan hata sonrasında bu tarz restore taleplerininde kaçınılmaz gibi gözüküyor.

Örneğimize geçmeden önce tablo bazından restore derken temelde neleri kastediyoruz ve ksıtlarımız neler kısaca bunlardan bahsedelim;

• Bir tabloyu restore edebileceğimiz gibi sadece bir partitionı da restore edebiliriz,
• Recover edilen tabloyu yeni bir isimle başka bir tabloya veya bir partitiona insert edebiliriz,
• Recover etmeye çalıştığımız tablonun exportunu alıp database’ de import etmeyebiliriz de,
• Bütün bu işlemleri yapabilmemiz için database archive modde ve read/write olarak açılmış olmalıdır,
• Recover edeceğimiz tabloya ait kullanılabilir bir RMAN backupımız olmalıdır.

Bu işlemi aynı zamanda bir point in time recover işlemi olarak da düşünebilirsiniz dolayısıyla biz point in time recover yaparken nasıl SCN, spesifik bir zaman dilimi veya sequence numarası verebiliyor isek aynı durum burda da geçerlidir. Bu 3 opsiyonu kullanarak da tablomuzu recover edebiliriz.

Tablo bazında recover işlemini yaparken yapılabilecek olası hatalardan da bahsetmek istiyorum. Böylelikle sizinde bu tarz işlemler de karşılaşma ihtimali yüksek olan bazı hataları farketme şansınız olacaktır.

İlk olarak tablo bazında recover ederken set until clause’ unu kullanmadan recover başlatırsanız ;

Continue reading

12c New Features : Pluggable Database Restore – Recover

Aslında bu yazıyıda bir anlamda new features olarak düşünebiliriz. Sonuçda container database 12c ile birlikte geldi. 12c öncesindeki versiyonlarda standalone database yapısı olduğundan her bir database için ayrı bir backup alır ve o backup’ ı kullanarakda yine o database için restore işlemlerimizi yapıyoruz. 12c ile bilirkte yapı RMAN tarafında biraz değişti. Örneğin bir container database’ iniz ve altında bir sürü pluggable database’leriniz olduğunu düşünürsek burda sadece container database’ in backupını alıp sonrasında bu backup içerisinden istenilen pluggable database’ i restore edebilirsiniz. Yani sizin bir container db altında 10 tane ppluggable db’ iniz varsa her biri için ayrıca backup almanız gerekmiyor. İsterseniz tabi ayrı ayrı da alabilirisiniz.

Container database’ in backupı alındığında burada kullanılan pluggable database’ lerden bir tanesini nasıl restore edebiliriz ona bakalım ;

Spfile ve controlfile container bazında olduğu için onları sonrasında anlatıyor oluruz. Şimdi databafile’ lerden başlayarak testimizi yapmaya çalışalım ;

Restore testi yapacağımız database’ i mount moda alıyoruz;

SQL> alter session set container=pdbt11;
Session altered.

SQL> shu immediate
Pluggable Database closed.

SQL> select name,dbid,open_mode from v$pdbs where name =’PDBT11′;
NAME DBID OPEN_MODE
—————————— ———- ———-
PDBT11 87534229 MOUNTED
Continue reading