Oracle

12 Mart 2016

Oracle ile Veri Hayat Döngüsü

Veri hacmi arttıkça, yönetimi de zorlaşır. Sorunları azaltmak için artan veri hacmini olabildiğince baskılamak isteriz. Birçok iş arkadaşımın benimle benzer şeyler yaşadığına eminim. Sistemin 'off' olduğu zamanı kolla, ilgili birimlerden izin al ve eski tarihli partition'ları sıkıştır! Uzun yıllar böyle çalıştık; kazanabildiğimiz her alan için mücadele ettik ve hatta script'ler geliştirip, işi otomatize etmeye çabaladık. Fakat şimdi elimizde güzel bir alternatif var: Oracle Otomatik Veri Optimizasyonu...

Otomatik veri optimizasyonu (Advanced Data Optimization - ADO), 12c ile birlikte yeni gelen bir özellik. Advanced Compression Opsiyonu içinde yer alıyor. Belirleyeceğiniz politikalara göre, tablo veya partition'lı bir tabloyu sıkıştırıyor. Örneğin son 1 aydır işlem görmeyen tabloyu sıkıştır veya 6 aydır erişilmeyen partition'ları sütun bazlı (HCC) bir algoritmayla sıkıştır diyebiliyoruz. Yapı oldukça esnek. Koşul olarak gün, ay ve yıl verip; karşılaştırma koşullarını belirliyoruz. Erişim olmaması (NO ACCESS), nesne üzerinde değişiklik olmaması (NO MODIFICATION) veya nesnenin oluşturulma tarihine (CREATION) göre esnek tanımlar yapma şansımız var. Verdiğiniz koşullara göre nesnelerin takibi veritabanı tarafından otomatik yapılıyor.

Otomatik veri optimizasyonu (ADO), konvansiyonel sistemlerde de kullanabileceğiniz bir özellik. Fakat ADO'yu sütun bazlı sıkıştırma ile entegre edecekseniz, Exadata veya Oracle tabanlı bir storage (örn. ZFS) sahibi olmanız gerekiyor. Burada bir es verip, bir bilgi daha vereyim. Testleri sadece Basic ve Advanced Compression ile sınırlamak istemedim. Ama elimde hazır bir Exadata yoktu. Sanal bir ZFS imajıyla, elimdeki makineyi bağlayıp, testleri yapmaya karar verdim. 12c'de ZFS'in bağlanması için SNMP ile ilgili ek ayar gerekiyormuş. Bunu da ayarladım fakat bu sefer de başka bir sorun çıktı. Problemi anlamaya çalışırken, çözümün zaten gözümün önünde olduğunu farkettim. Oracle Cloud, sütun bazlı sıkıştırma desteğiyle geliyor. Lokal makine eziyetini bırakıp, çalışmayı bulut üzerinde sürdürdüm. Aklınızda olsun; Oracle Cloud'dan veritabanı hizmeti aldığınız zaman, ADO'yu mutlaka HCC ile entegre edin. Muazzam yer kazanımı sağlayabilirsiniz.

Cloud ortamında kullanmayacağım bir veritabanı vardı. Onu kaldırıp, eski mimariyle (non-container) bir başka veritabanı oluşturdum. (Unutmayın ADO, 12.1.0.2 sürümünde sadece non-container mimariyle çalışıyor.)

dbca -silent -deleteDatabase -sourceDB ORCL -sysDBAUserName sys -sysDBAPassword welcome1

dbca -createDatabase -silent \
 -gdbName NONCDB \
 -sid NONCDB \
 -sysPassword welcome1 \
 -systemPassword welcome1 \
 -emConfiguration LOCAL \
 -dbsnmpPassword DBsnmp123 \
 -storageType FS \
 -datafileDestination '/u02/app/oracle/oradata/' \
 -nodelist 'TESTDB' \
 -redoLogFileSize 100 \
 -databaseType MULTIPURPOSE \
 -responseFile NO_VALUE \
 -asmsnmpPassword welcome1 \
 -characterSet AL32UTF8 \
 -nationalCharacterSet AL16UTF16 \
 -templateName /u01/app/oracle/product/12.1.0/dbhome_1/assistants/dbca/templates/General_Purpose.dbc

Cloud ortamındaki veritabanları için TDE (Transparent Data Encryption) kullanımı isteniyor. $ORACLE_HOME/network/admin/sqlnet.ora dosyasındaki ENCRYPTION_WALLET_LOCATION adresine bakarak, buna uygun klasör oluşturuyorum. Ardından "welcome1" parolasıyla, bu lokasyonda wallet yaratıyorum.

$ mkdir -p /u01/app/oracle/admin/ORCL/tde_wallet
SQL> ALTER SYSTEM SET ENCRYPTION KEY AUTHENTICATED BY "welcome1";
SQL> shutdown immediate
SQL> startup mount
SQL> alter system set encryption wallet open identified by "welcome1";
SQL> alter database open;

ILM için HEAT_MAP parametresini açıyoruz.

-- HEAT MAP OZELLIGINI ACIYORUZ
SQL> ALTER SYSTEM SET HEAT_MAP = ON;

Farklı kullanım özelliklerini göstermek için dört adet tablespace hazırlayacağız. Özellikle TBS_03 isimli olana dikkat çekmek isterim. Tablespace seviyesinde verdiğimiz ILM tanımı sayesinde, üzerinde oluşturulacak tablolar, ILM tanımlarını 'inherit' edecektir.

-- FARKLI KULLANIM OZELLIKLERINI GOSTERMEK ICIN DORT (4) ADET TABLESPACE HAZIRLIYORUZ
-- TBS_02'YI UZUN DONEMLI, ARSIV AMACLI KULLANACAGIZ.
-- O NEDENLE READ ONLY HALE GETIRIYORUZ
CREATE TABLESPACE TBS_01 DATAFILE '/u02/app/oracle/oradata/NONCDB/tbs_01.dbf' 
	SIZE 5M AUTOEXTEND ON NEXT 1M MAXSIZE 10G;

CREATE TABLESPACE TBS_02 DATAFILE '/u02/app/oracle/oradata/NONCDB/tbs_02.dbf' 
	SIZE 5M AUTOEXTEND ON NEXT 1M MAXSIZE 10G;

ALTER TABLESPACE TBS_02 READ ONLY;

-- TABLESPACE OLUSTURULURKEN ILM POLITIKASI BELIRLENEBILIR
CREATE TABLESPACE TBS_03 DATAFILE '/u02/app/oracle/oradata/NONCDB/tbs_03.dbf' 
	SIZE 5M AUTOEXTEND ON NEXT 1M MAXSIZE 10G
	DEFAULT ILM ADD POLICY 
  	COMPRESS FOR QUERY HIGH SEGMENT
  	AFTER 5 DAY OF NO ACCESS;

-- TABLESPACE OLUSTURDUKTAN SONRA, ILM POLICY EKLENMESI DE MUMKUNDUR
CREATE TABLESPACE TBS_04 DATAFILE '/u02/app/oracle/oradata/NONCDB/tbs_04.dbf' 
	SIZE 5M AUTOEXTEND ON NEXT 1M MAXSIZE 10G;

ALTER TABLESPACE TBS_04 DEFAULT
  ILM ADD POLICY 
  COMPRESS FOR QUERY HIGH SEGMENT
  AFTER 5 DAY OF NO ACCESS;

-- DATAFILE KONTROLU YAPILIR
[oracle@testvm ~]$ ls -lh /u02/app/oracle/oradata/NONCDB/tbs_0?.dbf
-rw-r----- 1 oracle oinstall 5,1M Mar 12 15:15 /u02/app/oracle/oradata/NONCDB/tbs_01.dbf
-rw-r----- 1 oracle oinstall 5,1M Mar 12 15:15 /u02/app/oracle/oradata/NONCDB/tbs_02.dbf
-rw-r----- 1 oracle oinstall 5,1M Mar 12 15:16 /u02/app/oracle/oradata/NONCDB/tbs_03.dbf
-rw-r----- 1 oracle oinstall 5,1M Mar 12 15:16 /u02/app/oracle/oradata/NONCDB/tbs_04.dbf

-- DORT NUMARALI ORNEK TABLESPACE, KULLANILMAYACAGI ICIN DROP EDILIR
DROP TABLESPACE TBS_04 INCLUDING CONTENTS AND DATAFILES;

Aşağıda göreceğiniz gibi DUMMY bir kullanıcı oluşturup, ilgili tablespace'ler üzerinde hak veriyorum. Belki USERS tablespace'inde ayrıca hak vermem dikkatinizi çekmiştir. İzah edeyim. Eğer taşıma işlemleri online olsun istiyorsanız, redefinition işlemi için bir alan gerekiyor. Kendi çalışmamdan gördüğüm kadarıyla, kullanıcının default tablespace'i oluyor. (Elbetteki farklı bir tablespace, kullanıcının default alanı olarak tanımlanabilir ve bu ek adıma gerek kalmayabilirdi.)

-- DUMMY BIR KULLANICI OLUSTURUP, GEREKEN HAKLARI VERIYORUZ
CREATE USER RQUSER IDENTIFIED BY WELCOME1;
GRANT RESOURCE TO RQUSER;
ALTER USER rquser QUOTA UNLIMITED ON TBS_01;
ALTER USER rquser QUOTA UNLIMITED ON TBS_02;
ALTER USER rquser QUOTA UNLIMITED ON TBS_03;
ALTER USER rquser QUOTA UNLIMITED ON USERS;

Kullanıcıyı oluşturduktan sonra, iki adet düz tablo yaratıyoruz.

-- ORNEKLERIMIZDE KULLANMAK UZERE IKI ADET DUZ TABLO OLUSTURUYORUZ
-- BIRINDE AYRICA INDEX YARATILIYOR
CREATE TABLE RQUSER.DUMMY_TABLE_TBS01 TABLESPACE TBS_01 
  AS SELECT * FROM DBA_OBJECTS;

CREATE INDEX RQUSER.DUMMY_TABLE_TBS01_IDX01 ON RQUSER.DUMMY_TABLE_TBS01( OBJECT_ID ) 
  TABLESPACE TBS_01;

CREATE TABLE RQUSER.DUMMY_TABLE_TBS03 TABLESPACE TBS_03 AS SELECT * FROM DBA_OBJECTS;

SQL> select count(*) from RQUSER.DUMMY_TABLE_TBS01;
--   COUNT(*)
-- ----------
--      91297
SQL> select count(*) from RQUSER.DUMMY_TABLE_TBS01 WHERE OBJECT_ID=40;
--   COUNT(*)
-- ----------
--          1
SQL> select count(*) from RQUSER.DUMMY_TABLE_TBS03;
--   COUNT(*)
-- ----------
--      91299

Düz tablo dışında, örneklerimizi zenginleştirmek için bir de partition'lı tablo oluşturalım.

-- PARTITION OZELINDE TIERING'I GOSTERMEK ICIN PARTITION'LI BIR TABLO HAZIRLIYORUZ
CREATE TABLE RQUSER.DUMMY_PARTITIONED_TABLE (
  VERI   VARCHAR2(30 BYTE)	NOT NULL,
  YIL    NUMBER(4)          NOT NULL
)
TABLESPACE TBS_01
PARTITION BY RANGE (YIL) (
    PARTITION DUMMY_PARTITIONED_TABLE_PMIN VALUES LESS THAN (2011),
    PARTITION DUMMY_PARTITIONED_TABLE_P2011 VALUES LESS THAN(2012),
    PARTITION DUMMY_PARTITIONED_TABLE_P2012 VALUES LESS THAN(2013),
    PARTITION DUMMY_PARTITIONED_TABLE_P2013 VALUES LESS THAN(2014),
    PARTITION DUMMY_PARTITIONED_TABLE_PMAX VALUES LESS THAN (MAXVALUE) );

-- OLUSTURDUGUMUZ TABLOYA VERI GIRISI YAPIYORUZ
BEGIN
	FOR i IN 1..10000 LOOP
		INSERT INTO RQUSER.DUMMY_PARTITIONED_TABLE VALUES ( 'Merhaba Dunya', 2010 );
		INSERT INTO RQUSER.DUMMY_PARTITIONED_TABLE VALUES ( 'Moi maailma', 2011 );
		INSERT INTO RQUSER.DUMMY_PARTITIONED_TABLE VALUES ( 'Ola, mundo', 2012 );
		INSERT INTO RQUSER.DUMMY_PARTITIONED_TABLE VALUES ( 'Hello World', 2013 );
		INSERT INTO RQUSER.DUMMY_PARTITIONED_TABLE VALUES ( 'Hallo Welt', 2014 );
		INSERT INTO RQUSER.DUMMY_PARTITIONED_TABLE VALUES ( 'Hallo wereld', 2015 );
	END LOOP;
	COMMIT;
END;
/

SELECT YIL, COUNT(*) AS TOPLAM 
FROM RQUSER.DUMMY_PARTITIONED_TABLE
GROUP BY ROLLUP(YIL)
ORDER BY YIL;
--        YIL     TOPLAM
-- ---------- ----------
--       2010      10000
--       2011      10000
--       2012      10000
--       2013      10000
--       2014      10000
--       2015      10000
--                 60000

Aşağıda uzun bir ILM listesi göreceksiniz. Bu komutları açıklarsak;

DUMMY_TABLE_TBS01 tablosuna 9 gündür hiç erişim yoksa, Query High algoritmasıyla sıkıştırılacak. Kullandığımız 'GROUP' ifadesi, tabloya bağlı nesnelerin de (örn. index veya LOB) sıkıştırılmasını sağlıyor.
DUMMY_TABLE_TBS03 tablosu, ILM kurallarını, içinde bulunduğu tablespace'ten devralacak. TBS_03'ü oluştururken, 5 gün erişim olmazsa, Query High algoritmasını kullanmasını söylemiştik. DUMMY_TABLE_TBS03 tablosu da buna göre hareket edecek.
DUMMY_PARTITIONED_TABLE tablosu, partition'lardan oluşuyor. Burada bir dizi kural belirtiyoruz. Eğer 5 gündür partition'lar üzerinde değişim yoksa, Query Low ile sıkıştırılmasını söylüyoruz. Bir aydır değişim olmazsa, Query High; üç aydır değişim yoksa Archive Low kullanılacak. Son bir yıldır hiç değişim olmadıysa, en yoğun sıkıştırma algoritmasını, yani Archive High'ı kullanmak istediğimizi belirtiyoruz.
DUMMY_PARTITIONED_TABLE tablosu için bir kural daha belirtiyoruz. Şayet tablo içinde bulunan partition'larda, 2 yıldır değişim yoksa, READ ONLY olan TBS_02'ye taşınmasını istiyoruz.

-- ILM TANIMLARINI YAPIYORUZ
SET ECHO ON

-- DOKUZ (9) GUNDUR ERISIM GORMEYEN TABLO
-- HCC QUERY HIGH ILE SIKISTIRILIR
ALTER TABLE RQUSER.DUMMY_TABLE_TBS01
  ILM ADD POLICY
  COMPRESS FOR QUERY HIGH GROUP
  AFTER 9 DAY OF NO ACCESS;

-- BIR (1) GUNDUR DEGISIM GORMEYEN PARTITION'LAR
-- ADVANCED COMPRESSION ILE SIKISTIRILIR
ALTER TABLE RQUSER.DUMMY_PARTITIONED_TABLE 
  ILM ADD POLICY 
  ROW STORE COMPRESS ADVANCED SEGMENT
  AFTER 1 DAY OF NO MODIFICATION;

-- BES (5) GUNDUR DEGISIM GORMEYEN PARTITION'LAR
-- HCC QUERY LOW ILE SIKISTIRILIR
ALTER TABLE RQUSER.DUMMY_PARTITIONED_TABLE 
  ILM ADD POLICY 
  COMPRESS FOR QUERY LOW SEGMENT
  AFTER 5 DAYS OF NO MODIFICATION;

-- BIR (1) AYDIR DEGISIM GORMEYEN PARTITION'LAR
-- HCC QUERY HIGH ILE SIKISTIRILIR
ALTER TABLE RQUSER.DUMMY_PARTITIONED_TABLE 
  ILM ADD POLICY 
  COMPRESS FOR QUERY HIGH SEGMENT 
  AFTER 1 MONTH OF NO MODIFICATION;

-- UC (3) AYDIR DEGISIM GORMEYEN PARTITION'LAR
-- HCC ARCHIVE LOW ILE SIKISTIRILIR
ALTER TABLE RQUSER.DUMMY_PARTITIONED_TABLE 
  ILM ADD POLICY 
  COMPRESS FOR ARCHIVE LOW SEGMENT 
  AFTER 3 MONTHS OF NO MODIFICATION;

-- BIR (1) YILDIR DEGISIM GORMEYEN PARTITION'LAR
-- HCC ARCHIVE HIGH ILE SIKISTIRILIR
ALTER TABLE RQUSER.DUMMY_PARTITIONED_TABLE 
  ILM ADD POLICY 
  COMPRESS FOR ARCHIVE HIGH SEGMENT 
  AFTER 1 YEAR OF NO MODIFICATION;

-- UC (3) YILDIR DEGISIM GORMEYEN PARTITION'LAR
-- READ ONLY TABLESPACE'E TASINIR
ALTER TABLE RQUSER.DUMMY_PARTITIONED_TABLE 
  ILM ADD POLICY 
  TIER TO TBS_02 READ ONLY
  AFTER 2 YEARS OF NO MODIFICATION;

Kurallarla ilgili özet tanımlar için aşağıdaki sorguyu kullanabilirsiniz.

-- KURALLARIMIZI OZET OLARAK GORMEK ICIN ASAGIDAKI SORGUYU KULLANABILIRIZ
SET PAGESIZE 0 lines 200 WRAP OFF TRIMSPOOL ON
select * from DBA_ILMDATAMOVEMENTPOLICIES;
  POLICY_NAME    ACTION_TYPE SCOPE   COMPRESSION_LEVEL   TIER_TABLESPACE    
-------------- ----------- ------- ------------------- --------------------
P2             COMPRESSION SEGMENT QUERY HIGH                              
P4             COMPRESSION SEGMENT QUERY HIGH                              
P5             COMPRESSION SEGMENT ADVANCED                                
P6             COMPRESSION SEGMENT QUERY LOW                               
P7             COMPRESSION SEGMENT QUERY HIGH                              
P8             COMPRESSION SEGMENT ARCHIVE LOW                             
P9             COMPRESSION SEGMENT ARCHIVE HIGH                            
P10            STORAGE     SEGMENT                     TBS_02

Fakat detaylı bir tanım görmek için aşağıda yazdığım sorgu daha faydalı olur.

-- OLUSTURDUGUMUZ POLICY'LER KONTROL EDILIYOR
SET LINES 240 TRIMSPOOL ON pages 999
col POLICY_NAME HEADING POLICYNAME FORMAT A10
col OBJECT_NAME FORMAT A35
col SUBOBJECT_NAME FORMAT A30
col OBJECT_TYPE FORMAT A20
col ACTION_TYPE FORMAT A12
col SCOPE FORMAT A10
col COMPRESSION_LEVEL FORMAT A15
col TIER_TABLESPACE FORMAT A15
col TIER_STATUS FORMAT A12
col CONDITION_DAYS FORMAT A20
col INHERITED_FROM FORMAT A20
col ENABLED FORMAT A5
col DISABLED FORMAT A5
SELECT 
  I.POLICY_NAME,
  O.OBJECT_OWNER||'.'||O.OBJECT_NAME AS OBJECT_NAME,
  O.SUBOBJECT_NAME, 
  O.OBJECT_TYPE, 
  I.ACTION_TYPE,
  I.SCOPE,
  I.COMPRESSION_LEVEL,
  I.TIER_TABLESPACE,
  I.TIER_STATUS,
  I.CONDITION_DAYS,
  O.INHERITED_FROM,
  O.ENABLED,
  O.DELETED
FROM DBA_ILMDATAMOVEMENTPOLICIES I,
  DBA_ILMOBJECTS O
WHERE I.POLICY_NAME = O.POLICY_NAME AND O.OBJECT_OWNER='RQUSER'
ORDER BY I.POLICY_NAME, O.OBJECT_NAME, O.SUBOBJECT_NAME, O.OBJECT_TYPE;

Sorgu çıktısının bütün satır ve sütunlarını buraya koymam zor. Fikir vermek adına, çıktının ufak bir bölümünü paylaşıyorum:

OBJECT_NAME	SUBOBJECT_NAME	ACTION_TYPE	COMPRESSION_LEVEL	TIER_TABLESPACE	TIER_STATUS	CONDITION_DAYS	INHERITED_FROM
RQUSER.DUMMY_PARTITIONED_TABLE	DUMMY_PARTITIONED_TABLE_P2011	STORAGE		USERS2	READ ONLY	730	TABLE
RQUSER.DUMMY_PARTITIONED_TABLE	DUMMY_PARTITIONED_TABLE_P2012	STORAGE		USERS2	READ ONLY	730	TABLE
RQUSER.DUMMY_PARTITIONED_TABLE	DUMMY_PARTITIONED_TABLE_P2013	STORAGE		USERS2	READ ONLY	730	TABLE
RQUSER.DUMMY_PARTITIONED_TABLE	DUMMY_PARTITIONED_TABLE_PMAX	STORAGE		USERS2	READ ONLY	730	TABLE
RQUSER.DUMMY_PARTITIONED_TABLE	DUMMY_PARTITIONED_TABLE_PMIN	STORAGE		USERS2	READ ONLY	730	TABLE
...
RQUSER.DUMMY_PARTITIONED_TABLE	DUMMY_PARTITIONED_TABLE_PMAX	COMPRESSION	ARCHIVE LOW			90	TABLE
RQUSER.DUMMY_PARTITIONED_TABLE	DUMMY_PARTITIONED_TABLE_P2011	COMPRESSION	ARCHIVE HIGH			365	TABLE
RQUSER.DUMMY_PARTITIONED_TABLE	DUMMY_PARTITIONED_TABLE_P2012	COMPRESSION	ARCHIVE HIGH			365	TABLE
RQUSER.DUMMY_PARTITIONED_TABLE	DUMMY_PARTITIONED_TABLE_P2013	COMPRESSION	ARCHIVE HIGH			365	TABLE
RQUSER.DUMMY_PARTITIONED_TABLE	DUMMY_PARTITIONED_TABLE_PMAX	COMPRESSION	ARCHIVE HIGH			365	TABLE
RQUSER.DUMMY_PARTITIONED_TABLE	DUMMY_PARTITIONED_TABLE_PMIN	COMPRESSION	ARCHIVE HIGH			365	TABLE
RQUSER.DUMMY_PARTITIONED_TABLE		COMPRESSION	ARCHIVE HIGH			365	POLICY NOT INHERITED

ILM politikalarımızı belirledik. Çalıştığını görmek için elbetteki iki yıl beklemeyeceğimiz. Bunun yerine, bir prosedür yazıp, nesnelerin son erişim tarihlerini elle değiştireceğiz.

CREATE OR REPLACE PROCEDURE sys.set_stat (object_id      number,
                                      data_object_id number, 
                                      n_days         number,
                                      p_ts#            number,
                                      p_segment_access number)
as
begin
	insert into sys.heat_map_stat$ 
	              (obj#,
	               dataobj#,
	               track_time,
	               segment_access,
	               ts#) 
	         values 
	               (object_id, 
	                data_object_id, 
	                sysdate - n_days,
	                p_segment_access,
	                p_ts# );
	commit;
end;
/

Şimdi de DUMMY_TABLE_TBS03 tablosunu 6 gün yaşlandıralım.

-- DUMMY_TABLE_TBS03 TABLOSU 6 GUN YASLANDIRILIYOR
alter session set nls_date_format='dd-MM-yyyy hh:mi:ss';

declare
  v_obj# number;
  v_dataobj# number;
  v_ts#      number;
begin
   select object_id, data_object_id into v_obj#, v_dataobj#
   from all_objects 
   where object_name = 'DUMMY_TABLE_TBS03' 
     and owner = 'RQUSER';
   select ts# into v_ts#
   from sys.ts$ a, 
   dba_segments b
   where  a.name = b.tablespace_name
     and  b.segment_name = 'DUMMY_TABLE_TBS03'; 
commit;
   sys.set_stat
              (object_id         => v_obj#,
               data_object_id    => v_dataobj#,
               n_days            => 6,
               p_ts#             => v_ts#,
               p_segment_access  => 1);
end;
/

-- YASLANDIRMANIN GECERLILIGI ICIN ASAGIDAKI PROSEDURU CALISTIRIYORUZ
exec dbms_ilm_admin.set_heat_map_start(start_date => sysdate - 1000);

Üstteki prosedürün ne iş yaptığını gördük. Yalnız her partition için aynı PL/SQL bloğunu tekrar tekrar çalıştırsak, bir hâyli yer kaplayacak. Bunun yerine, DBA_OBJECTS üzerinden ilgili nesnelerin Object_ID ve Data_Object_ID değerlerini bulup, aşağıdaki gibi yazıyoruz.

BEGIN
   -- DUMMY_TABLE_TBS01 TABLOSUNU 10 GUN YASLANDIRIYORUZ
   sys.set_stat(object_id => 92782, data_object_id => 92782, n_days => 10, p_ts# => 6, p_segment_access => 1);
   -- DUMMY_PARTITIONED_TABLE TABLOSUNA AIT PARTITION'LARI TOPLU OLARAK YASLANDIRIYORUZ
   sys.set_stat(object_id => 92787, data_object_id => 92787, n_days => 800, p_ts# => 6, p_segment_access => 1);
   sys.set_stat(object_id => 92788, data_object_id => 92788, n_days => 400, p_ts# => 6, p_segment_access => 1);
   sys.set_stat(object_id => 92789, data_object_id => 92789, n_days => 180, p_ts# => 6, p_segment_access => 1);
   sys.set_stat(object_id => 92790, data_object_id => 92790, n_days => 30, p_ts# => 6, p_segment_access => 1);
END;
/

Gece 22.00 ile sabah 02.00 arasında, Oracle veritabanı bakım işlemleri çalışır. Normal işleyişte, ILM süreci Oracle Şimdi ILM sürecini elle tetikleyeceğiz. Fakat bunu yapmadan önce veritabanını kapatıp, açıyoruz. Yeterince beklerseniz, veritabanını kapatmadan da aynı işlemi yapabilirsiniz.

-- VERITABANI KAPATILIP, ACILIYOR
-- TDE KULLANIMDA WALLET'IN ACILMASI GEREKIYOR
STARTUP FORCE;

-- VERITABANI BASLADIKTAN SONRA ASAGIDAKI PL/SQL BLOGU CALISTIRILIYOR
-- ISLEMLER ONLINE VEYA OFFLINE TETIKLENEBILIR
declare
 v_executionid number;
begin
 dbms_ilm.execute_ILM (ILM_SCOPE     => dbms_ilm.SCOPE_DATABASE,
                      execution_mode => dbms_ilm.ilm_execution_offline,
                      task_id        => v_executionid);
end;
/

ILM sürecinin tetiklenmesiyle birlikte neler olup, bittiğini görmek için aşağıdaki üç sorguyu kullanabilirsiniz. Çalışan işler, onlara ait sonuçlar ve ILM değerlendirme kriterleri bu sorgular üzerinden görülebilir.

SELECT * FROM DBA_ILMTASKS;
SELECT * FROM DBA_ILMRESULTS;
SELECT * FROM DBA_ILMEVALUATIONDETAILS;

İş arka planda, çalışıp, tamamlanınca, nesnelerimiz aşağıdaki hâle geliyor:

-- TABLOLARIN DURUMU SORGULANIR
select table_name, compression, compress_for
from dba_tables
where table_name like 'DUMMY_TABLE_TBS0_' and owner = 'RQUSER'
order by 1;
-- TABLE_NAME               COMPRESS COMPRESS_FOR
-- ------------------------ -------- ------------
-- DUMMY_TABLE_TBS01        ENABLED  QUERY HIGH
-- DUMMY_TABLE_TBS03        ENABLED  QUERY HIGH
,
-- PARTITION'LARIN DURUMU SORGULANIR
select partition_name, compression, compress_for, tablespace_name
from dba_tab_partitions
where table_owner = 'RQUSER';
-- PARTITION_NAME                     COMPRESS COMPRESS_FOR   TABLESPACE_NAME
-- ---------------------------------- -------- -------------- ---------------
-- DUMMY_PARTITIONED_TABLE_P2011      ENABLED  ARCHIVE HIGH   TBS_02
-- DUMMY_PARTITIONED_TABLE_P2012      ENABLED  ARCHIVE HIGH   TBS_01
-- DUMMY_PARTITIONED_TABLE_P2013      ENABLED  ARCHIVE LOW    TBS_01
-- DUMMY_PARTITIONED_TABLE_PMAX       ENABLED  QUERY HIGH     TBS_01
-- DUMMY_PARTITIONED_TABLE_PMIN       DISABLED                TBS_02

Süreç, tanımladığımız politikalara göre otomatik gerçekleşti. Hatta bazı kurallar işlem sonunda kendiliğinden 'Disabled' hâle geldiler. Bizim tek yaptığımız, politikaları baştan düzgün belirlemekle sınırlıydı. Elbette zaman zaman müdahele etmek isteyebilirsiniz. Bu gibi durumlarda ILM kurallarını aşağıda göreceğiniz gibi geçici açıp-kapatabilir, değiştirebilir veya tamamen silebilirsiniz.

-- TABLO UZERINDE SADECE BELIRLI ILM KURALLARINA MUDAHELE
ALTER TABLE RQUSER.DUMMY_TABLE_TBS01 ILM DISABLE POLICY P4;
ALTER TABLE RQUSER.DUMMY_TABLE_TBS01 ILM ENABLE POLICY P4;

-- TABLO UZERINDEKI BUTUN ILM KURALLARINA MUDAHELE
ALTER TABLE RQUSER.DUMMY_TABLE_TBS01 ILM DISABLE_ALL;
ALTER TABLE RQUSER.DUMMY_TABLE_TBS01 ILM ENABLE_ALL;
ALTER TABLE RQUSER.DUMMY_TABLE_TBS01 ILM DELETE_ALL;

-- SONRADAN ILM KURALINI DEGISTIRMEK
ALTER TABLE RQUSER.DUMMY_PARTITIONED_TABLE 
  MODIFY PARTITION DUMMY_PARTITIONED_TABLE_P2013
  ILM ADD POLICY ROW STORE COMPRESS ADVANCED ROW 
  AFTER 900 DAYS OF NO MODIFICATION;

Otomatik veri optimizasyonu (ADO) ile birlikte, veritabanı yönetimi daha da kolaylaşacak. Artık veri hayat döngüsünü takip etmeyeceğiz. Bizim yerimize veritabanının kendisi bu işi halledecek. Bununla birlikte Exadata, ZFS veya Oracle Cloud üzerinde çalışıyorsanız, çok daha fazla sıkıştırma seçeneğine sahip olacaksınız. Özellikle sütun bazlı sıkıştırma (HCC) teknikleriyle, inanması güç rasyoları yakalabilirsiniz. Depolama alanını, yorulmadan etkin kullanmak isteyenlere harika bir çözüm!

Çağatay ÇEBİ