12c - New Features Arşivleri - Kamil TÜRKYILMAZ | Oracle BlogKamil TÜRKYILMAZ

28 Aralık 2016 by Kamil TURKYILMAZ

Oracle 12c – Rman ile Container/Pluggable Db’ lerin Backup’ ını Almak

Öncelikle nasıl ve hangi detayda backup alabiliyoruz, container ve pluggable database’ lerin backuplarını ayrı ayrı veya tek bir scriptte alabiliyormuyuz ona bakalım.

Konunun daha iyi anlaşılabilmesi için aşağıdaki senaryolar yardımıyla anlatmayı planlıyorum. Sık karşılaşılabilecek senaryoları eklemeye çalıştım;

• Full database backup
• Full pluggable database backup (veya tüm pluggable db’ lerin full backupını almak);
• Root database’ inin backupı
• Sadece archivelogların backupını almak için
• Bir pluggable database’ e ait olan tablespace’ in backupı ;
• Pluggable database’ e ait olan bir tablespace’ e ait datafile’ in backupını almak

Continue reading →

28 Aralık 2016 by Kamil TURKYILMAZ

Oracle 12c New Features : Partial Indexes

Oracle 12c ile birlikte partition tablolarda “indexing off” ve “indexing partial” clause ile indexleri sadece istemiş olduğumuz partitionlar üzerine create edebiliriz. Oracle 12c öncesinde partition tablolarda index create ederken local veya global olmak üzere 2 farklı şekilde index create edebiliyorduk. Artık partial index create edebilir durumdayız. İndex create ederken indexing off opsiyonu ile index create etmek demek ilgili partition üzerinde index create etmemek anlamına gelmektedir.

Sadece ilgilendiğimiz partitiona index create etmek opsiyonunu ne işimize yarar diye düşündüğümüz de ilk aklıma gelen nedeni, çok büyük tabloları partitionladığınız da sadece üzerinde çalışacağınız partitionlara index create ederek zamandan ciddi tasarruf edebilirsiniz.

Her zamanki gibi bir örnekle durumu açıklamaya çalışalım.

Bir partition tablo create edelim;

===> CREATE TABLE kamil.test_range
(id NUMBER(10),
name varchar2(10),
create_date date)
PARTITION BY RANGE(create_date)
INTERVAL( NUMTODSINTERVAL(1,’DAY’))
(PARTITION P1 VALUES LESS THAN (TO_DATE(’01-01-2000′, ‘DD-MM-YYYY’)))
Table created.
Continue reading →

26 Aralık 2016 by Kamil TURKYILMAZ

Oracle 12c – Multi threaded Model

Linux ve Unix tabanlı işletim sistemleri process based tabanlı çalışan işletim sistemleridir. Process based tabanlı işletim sistemlerinde her bir iş için işletim sistemi tarafında bir process create edilir. Şimdiye kadar da bu yapıyı oracle’ ın tüm sürümlerinde bu şekilde kullandık. Bu yapıyı kullanıyor olmanın bir takım avantajları ve dezavantajları bulıunmaktadır. Örneğin oracle tarafında processlerin sayısı artmaya başladığı zaman, (database de her bir processe karşılık gelen bir OS procesesi olacağından dolayı) prosess sayılarının çokluğundan dolayı performans problemleri ile karşılaşma ihtimalimide artmaktadır. Defaultta oracle 12c ile de aynı yapı ile geliyor. Ancak burada istersek bir parametre değişikliği ile process based tabanlı yapıdan thread based tabanlı yapıya geçebiliriz. Multithred yapı ile anlatılmak istenen her bir process aslında bir thread altında çalışıyor. Buda OS tarafında kaynakların daha verimli kullanılmasını sağlıyor.

Process based yapıda normalde oracle processlerinin nasıl izlendiğine ve kaç adet olduğuna bakalım ;

[oracle@Redhat70 admin]$ ps -ef|grep -v grep|grep ora_ ; ps -ef|grep -v grep|grep ora_ | wc -l
oracle 25240 1 0 23:26 ? 00:00:00 /u01/sq/ora_3/oracle/db/12.1.0.2/bin/tnslsnr listener_12c -inherit
oracle 25908 1 0 23:35 ? 00:00:00 ora_pmon_t1
oracle 25912 1 0 23:35 ? 00:00:00 ora_psp0_t1
oracle 25916 1 1 23:35 ? 00:00:00 ora_vktm_t1
oracle 25922 1 0 23:35 ? 00:00:00 ora_gen0_t1
oracle 25926 1 0 23:35 ? 00:00:00 ora_mman_t1
oracle 25934 1 0 23:35 ? 00:00:00 ora_diag_t1
oracle 25938 1 0 23:35 ? 00:00:00 ora_dbrm_t1
oracle 25942 1 0 23:35 ? 00:00:00 ora_vkrm_t1
oracle 25946 1 0 23:35 ? 00:00:00 ora_dia0_t1
oracle 25950 1 0 23:35 ? 00:00:00 ora_dbw0_t1
oracle 25954 1 0 23:35 ? 00:00:00 ora_dbw1_t1
Continue reading →

11 Mart 2016 by Kamil TURKYILMAZ

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.

CREATE OR REPLACE PACKAGE SYS.dbms_privilege_capture AS
 -- Capture Types
  g_database            CONSTANT NUMBER := 1;
  g_role                CONSTANT NUMBER := 2;
  g_context             CONSTANT NUMBER := 3;
  g_role_and_context    CONSTANT NUMBER := 4;
  PROCEDURE create_capture(
    name            IN  VARCHAR2,
    description     IN  VARCHAR2 DEFAULT NULL,
    type            IN  NUMBER DEFAULT G_DATABASE,
    roles           IN  role_name_list DEFAULT role_name_list(),
    condition       IN  VARCHAR2   DEFAULT NULL);
  PROCEDURE drop_capture(name  IN VARCHAR2);
  PROCEDURE enable_capture(name  IN VARCHAR2);
  PROCEDURE disable_capture(name IN VARCHAR2);
  PROCEDURE generate_result(name IN VARCHAR2);
END;
/

CREATE OR REPLACE PACKAGE SYS.dbms_privilege_capture AS

-- Capture Types

g_database CONSTANT NUMBER := 1;

g_role CONSTANT NUMBER := 2;

g_context CONSTANT NUMBER := 3;

g_role_and_context CONSTANT NUMBER := 4;

PROCEDURE create_capture(

name IN VARCHAR2,

description IN VARCHAR2 DEFAULT NULL,

type IN NUMBER DEFAULT G_DATABASE,

roles IN role_name_list DEFAULT role_name_list(),

condition IN VARCHAR2 DEFAULT NULL);

PROCEDURE drop_capture(name IN VARCHAR2);

PROCEDURE enable_capture(name IN VARCHAR2);

PROCEDURE disable_capture(name IN VARCHAR2);

PROCEDURE generate_result(name IN VARCHAR2);

END;

Continue reading →

11 Mart 2016 by Kamil TURKYILMAZ

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)

SQL> ALTER DATABASE SWITCHOVER TO CON_STBY;
ALTER DATABASE SWITCHOVER TO CON_STBY 
*
ERROR at line 1:
ORA-16474: target_db_name not found in the LOG_ARCHIVE_DEST_n parameter

SQL> ALTER DATABASE SWITCHOVER TO CON_STBY;

ALTER DATABASE SWITCHOVER TO CON_STBY

ERROR at line 1:

ORA-16474: target_db_name not found in the LOG_ARCHIVE_DEST_n parameter

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 →