joomla templates Data Warehouse Türkiye

Oracle zaman içerisinde yeni sürümlerini piyasaya sürdükçe bizlerde zamanı geldikçe kullandığımız oracle versiyonlarımızı bir üst sürüme upgrade etmek durumunda kalıyoruz. Oracle son 3 versiyonuna destek verdiğinden dolayı metalink üzerinden destek alıyorsanız kullandığınız versiyonunuz mutlaka 9i veya sonrası olmak zorunda, ki çok yakın bir tarihde 9i’ ninde desupported olacağını tahmin etmek zor olmasa gerek.

Bugün bu upgrade işlemi ile ilgili olarak öncesinde ve sonrasında yapılması gerekenleri anlatmaya çalışacağım.

Aşağıdaki örnekde 10gR1 – 10gR2 den 11gR2 ye upgrade işlemini kapsamaktadır.

İlk olarak upgrade edeceğimiz database’ in compatible seviyesini kontrol ediyoruz. Tüm upgrade’ ler için izlenmesi gereken bir yol vardır. Kimi sistemleri tek seferde istediğiniz versiyona upgrade edemiyor olabilirsiniz. Örneğin kullandığınız versiyon 9.2.0.3 ise bunu önce 9.2.0.8’ e sonrasında 11gR2 ye upgrade edebilirsiniz. Dolayısıyla bu kısım önemli ;

SELECT name, value FROM v$parameter

WHERE name = 'compatible';

NAME VALUE

compatible 10.1.0.5.0

Upgrade aşamaları ile ilgili hangi versiyondan hangisine geçebileceğinizi aşağıdaki tablolardan öğrenebilirsiniz.

Source Database                 Target Database 

9.2.0.8 or higher          è            11.2.x

10.1.0.5 or higher      è            11.2.x

10.2.0.2 or higher      è            11.2.x

11.1.0.6 or higher       è            11.2.x

Source Database                       Upgrade Path for             Target Database 

Target Database 

7.3.3 (or lower)               è      7.3.4 -> 9.2.0.8         è          11.2.x

8.0.5 (or lower)               è            8.0.6 -> 9.2.0.8         è     11.2.x

8.1.7 (or lower)                è     8.1.7.4 -> 10.2.0.4     è     11.2.x

9.0.1.3 (or lower)            è            9.0.1.4 -> 10.2.0.4     è   11.2.x

9.2.0.7(or lower)             è     9.2.0.8                      è   11.2.x

Öncelikle 11gR2 softwareinin farklı bir path’ e kuruyoruz. (sadece software, instance create etmiyoruz)

Kurulumu oracle userı yapıyoruz.

Upgrade yapacağımız database’ de read-only tablespace olup olmadığı kontrol edilir. Eğer olanlar var ise bunları upgrade işlemi bittikden sonra bir kereliğine read-write yapıp sonrasında tekrar read-only moda çekilebilir. Aynı şekilde offline olanlar var ise bir kereliğine online yapılıp datafile headerlarının güncellenmesi sağlanır. Sonra tekrar eski haline çekilebilir.

select * from dba_tablespaces where status <> 'ONLINE';

Oracle’a ait tüm nesnelerin VALID durumda olmaları gerekir. Bunun için aşağıdaki scriptlerden faydalanılabilir;

select substr(comp_name,1,40) comp_name, schema, status, substr(version,1,10) version from

dba_registry order by comp_name;

select substr(object_name,1,40) object_name,substr(owner,1,15) owner,object_type from

dba_objects where status='INVALID' order by owner,object_type;

select owner,object_type,count(*) from dba_objects where status='INVALID' group by
owner,object_type order by owner,object_type ;

Eğer invalid durumda nesne çıkar ise $ORACLE_HOME/rdbms/admin adresindeki utlrp.sql dosyası hiç invalid nesne kalmayıncaya kadar tekrar tekrar çalıştırılır. B işlemler upgrade yapılacak olan oracle versiyonunun home path’ inden yapılır.

$ sqlplus / as sysdba
SQL> @utlrp.sql 

SYS ve SYSTEM şemalarında aynı isimli nesne olup olmadığı kontrol edilir. Bunun için aşağıdaki sorgu çalıştırılır.

select object_name, object_type from dba_objects where object_name||object_type in  

(select object_name||object_type from dba_objects where owner = 'SYS') and owner = 'SYSTEM'; 

Sonuç olarak sadece aşağıdaki nesneler çıkmalıdır. Bunların dışından nesne çıkarsa Metalink1030426.6’a bakılır.

OBJECT_NAME                         OBJECT_TYPE
------------------------------                   -------------------
AQ$_SCHEDULES                       TABLE
AQ$_SCHEDULES_PRIMARY     INDEX
DBMS_REPCAT_AUTH               PACKAGE
DBMS_REPCAT_AUTH               PACKAGE BODY 

Upgrade öncesi kontrol aracı (Pre-Upgrade Information Tool) çalıştırılır. Bunun için sırasıyla ;

1. ORACLE_HOME(yeni)/rdbms/admin adresindeki utlu112i.sql ve utltzuv2.sql dosyaları geçici bir alana kopyalanır.

2. Geçici dizine girilir.

3. SQL*Plus(eski) ile veritabanına SYSDBA ayrıcalıklarıyla bağlanılır.

4. Spool açılır. SQL> SPOOL upgrade_info.log

5. Araç çalıştırılır. SQL> @utlu112i.sql

6. Bitince spool kapatılır. SQL> SPOOL OFF

7. upgrade_info.log kontrol edilip tüm WARNING’ler kontrol edilir.

WARNING: --> Database contains schemas with objects dependent on network packages.

Upgrade öncesi kontrol aracında (Pre-Upgrade Information Tool) yukarıdaki uyarı çıkmış ise kontrol edilir.

Veritabanında XML DB özelliğinin olup olmadığı aşağıdaki SQL ile kontrol edilir.

select comp_name "Component" from dba_registry;

XMLDB özelliği var ise, (bu component kullanılıyor ise) aşağıdaki SQL ile de hangi kullanıcıların bağımlılığı var diye kontrol edilir;

SELECT * FROM DBA_DEPENDENCIES

WHERE referenced_name IN ('UTL_TCP','UTL_SMTP','UTL_MAIL','UTL_HTTP','UTL_

INADDR') AND owner NOT IN ('SYS','PUBLIC','ORDPLUGINS');

Sorgudan çıkan kullanıcılar upgrade sonrası network access control list’lere (ACLs) gerekli yetkileri vermek üzere bir kenara not alınır. Zira bu kullanıcılar upgrade sonrası çalıştırılacak bir prosedürde kullanılacaktır. Yukarıdaki script web servisi kullanan kullanıcıları tespit ediyor, sonrasında uygulama sahibinden kullanılan tüm webservicelerin adresleri ve portları alınmalıdır. Upgrade sonrasında bu userlara network ACL yetkisi verilecektir.

Mevcut veritabanının tutarlılığı metalink Note 556610.1’dan indirilen  dbupgdiag.sql scripti çalıştırılarak kontrol edilir.

Metalink üyeliği olmayıpda test etmek isteyen arkadaşlar için scripti isterlerse gönderebilirim.

( Bu e-Posta adresi istek dışı postalardan korunmaktadır, görüntülüyebilmek için JavaScript etkinleştirilmelidir ) adresinden iletişime geçebilir varsa diğer sorularınızı da iletebilirsiniz.

Çalıştırmak için;

$ sqlplus / as sysdba
SQL> @dbupgdiag.sql

Eğer bu script invalid nesne döndürürse, (eski)$ORACLE_HOME/rdbms/admin adresindeki utlrp.sql dosyası hiç invalid nesne kalmayıncaya kadar tekrar tekrar çalıştırılır.

$ sqlplus / as sysdba
SQL> @utlrp.sql 

Sonra kontrol etmek için dbupgdiag.sql scripti tekrar çalıştırılır.

$ sqlplus / as sysdba
SQL> @ dbupgdiag.sql

Upgrade sonrasında CONNECT rolü sadece CREATE SESSION sistem yetkisi içerecek şekilde güncellenecektir. Eski versiyonlarda CONNECT rolünde başka yetkiler de vardı. Mevcut veritabanında CONNECT rolüne hangi yetkiler verilmiş tespit etmek için;

SELECT GRANTEE,PRIVILEGE FROM DBA_SYS_PRIVS WHERE GRANTEE ='CONNECT'; 

CREATE SESSION’dan başka yetki çıkarsa, CONNECT rolü atanmış kullanıcılardan upgrade sonrası bu yetkilerin gideceği hatırlanmalıdır. Dolayısıyla aşağıdaki script çalıştırılarak CONECT rolü hangi kullanıcılara atanmış tespit edilir. Gerekli önlemler alınarak upgrade sonrası hangi kullanıcıya hangi yetki atanacak tespit edilir. 

Aşağıdaki script ile CONNECT rolü CREATE SESSION sistem yetkisi haricinde hangi yetkilerde var ise onlara tekrar atamak için otomatik Grant scripti üretir. Bu scripti upgrade bittikden sonra çalıştıracağız.

select 'GRANT ' || a.privilege || ' TO ' || b.grantee ||';' from

(SELECT PRIVILEGE FROM DBA_SYS_PRIVS WHERE GRANTEE ='CONNECT') a,

(SELECT grantee FROM dba_role_privs WHERE granted_role = 'CONNECT' and grantee NOT IN (

'SYS', 'OUTLN', 'SYSTEM', 'CTXSYS', 'DBSNMP', 'LOGSTDBY_ADMINISTRATOR', 'ORDSYS',

'ORDPLUGINS', 'OEM_MONITOR', 'WKSYS', 'WKPROXY', 'WK_TEST', 'WKUSER', 'MDSYS', 'LBACSYS', 'DMSYS', 'WMSYS', 'EXFSYS', 'SYSMAN', 'MDDATA',

'SI_INFORMTN_SCHEMA', 'XDB', 'ODM')) b where a.privilege<> 'CREATE SESSION' ;

9.2 veya 10.1 sürümünden 11.2’ye geçerken database link’lerin şifreleri encrypt edilir. Yani upgrade sonrasında SYS.LINK$ tablosundan şifreleri göremeyiz. Herhangi bir sorundan dolayı veritabanını downgrade yapacak olursak bunun için şifreleri encrypt edilmiş dblink’leri drop etmemiz, işlemden sonra yeniden create etmemiz gerekir. lTabi bunun için de tüm bu işlemlerden önce dblink’lerin create scriptlerinin yedeğini almış olmamız gerekir. Bunun için aşağıdaki scripti kullanabilirsiniz ;

SELECT 'CREATE '||DECODE(U.NAME,'PUBLIC','public ')||'DATABASE LINK '||CHR(10)

||DECODE(U.NAME,'PUBLIC',Null, 'SYS','',U.NAME||'.')|| L.NAME||chr(10)

||'CONNECT TO ' || L.USERID || ' IDENTIFIED BY "'||L.PASSWORD||'" USING

'''||L.HOST||''''

||chr(10)||';' TEXT

FROM SYS.LINK$ L, SYS.USER$ U

WHERE L.OWNER# = U.USER#;

Time zone değeride kontrol etmemiz gereken diğer önemli bir konu.

11GR2’de TIME ZONE dosyasının versiyonu 11’dir. Mevcut veritabanının TIME ZONE dosya versiyonunu aşağıdaki script ile öğrenebiliriz.

select * from v$timezone_file; 

Zaten Upgrade öncesi kontrol aracı (Pre-Upgrade Information Tool) aşağıdaki uyarıyı vermiş ise mevcut veritabanının TIME ZONE dosyasının eski olduğunu öğrenmiş oluruz.

Example :
WARNING: -->Database is using a timezone file older than version 11.
.... After the release migration, it is suggested that DBMS_DST package
.... be used to upgrade the 11.1.0.6.0 database timezone version
.... to the latest version which comes with the new release. 

Eski TIME ZONE dosyasını upgrade sonrasında güncelleriz. Upgrade işlemi bittikden sonra bununla ilgili yapılacaklardan o kısımda hahsedeceğim. 

Mevcut veritabanının National Characterset’i (NLS_NCHAR_CHARACTERSET) aşağıdaki SQL ile kontrol edilir.

select value from NLS_DATABASE_PARAMETERS where parameter = 'NLS_NCHAR_CHARACTERSET';

UTF8 veya AL16UTF16 değilse, Note 276914.1’a bakılır. Burdaki adımlar takip edilir.

Upgrade öncesinde data dictionary tablo istatistiklerinin alınması tavsiye edilir. Zira bu sayede upgrade süresi kısaltacaktır. Çünkü upgrade sırasında istatistiği olmayan data dictionary tablolarının istatistiği alınır.

Upgrade öncesi kontrol aracı (Pre-Upgrade Information Tool) logunda hangi tabloların istatistiğinin eksik olduğu çıkar. Aşağıdaki script ile tüm data dictionary tablolarının istatistiği alınır. Tabi bu işlemin upgrade öncesinde yapılması son derece faydalı olur.

$ sqlplus /as sysdba
SQL> EXEC DBMS_STATS.GATHER_DICTIONARY_STATS; 

Oracle Database Vault varsa upgrade öncesinde kapatılması gerekir. Upgrade sonrasında tekrar açılır.

Spesifik bir konu olduğu için bu kısma girmeden kullanacaklar için metalink linklerini yazıyorum sadece.

Note 453903.1 - Enabling and Disabling Oracle Database Vault in UNIX
Note 453902.1 - Enabling and Disabling Oracle Database Vault in WINDOWS

Kontrol etmemiz gereken bir diğer adımımız Data Dictionary’de corruption olup olmadığıdır. Aşağıdaki scripti sysdba yetkili bir userla çalıştırmamız yeterli olacaktır.

Set verify off
Set space 0
Set line 120
Set heading off
Set feedback off
Set pages 1000
Spool analyze.sql

SELECT 'Analyze cluster "'||cluster_name||'" validate structure cascade;'
FROM dba_clusters
WHERE owner='SYS'
UNION
SELECT 'Analyze table "'||table_name||'" validate structure cascade;'
FROM dba_tables
WHERE owner='SYS'
AND partitioned='NO'
AND (iot_type='IOT' OR iot_type is NULL)
UNION
SELECT 'Analyze table "'||table_name||'" validate structure cascade into invalid_rows;'
FROM dba_tables
WHERE owner='SYS'
AND partitioned='YES';

spool off 

Bu işlemin ardından analyze.sql isimli bir dosya oluşur. Aşağıdaki işlemde bu dosya kullanılır.

(Hala upgrade işlemine başlamadığımız için upgrade scriptlerde geçen $ORACLE_HOME ibaresi eski oracle hpme dizinini kastetmektedir.)

$ sqlplus "/ as sysdba"
SQL> @$ORACLE_HOME/rdbms/admin/utlvalid.sql
SQL> @analyze.sql 

İkinci komutun çıktısı dinamik olarak takip edilmelidir. Zira herhangi bir log dosyası oluşturmaz. (dilerseniz bunuda bir txt file’ e yazdırabilirsiniz)

Tamamlanması gereken Materialized View refresh’lerin olup olmadığı aşağıdaki SQL ile kontrol edilip bitmeleri beklenir.

SELECT DISTINCT(TRUNC(last_refresh)) FROM dba_snapshot_refresh_times;

Log miner database’ in kurulumu ile birlikte gelen ve bir package yardımıyla create edilen bir opsiyon olarak düşünebiliriz. Yapabilirlikleri aslında kimi zaman herhangi bir geri dönüş operasyonuna kalkışmadan hızlı bir şekilde yapılmış olan bir hatayı düzeltebilmemize olanak sağlar. 

Log miner database seviyesinde yapılan bir takım işlemlerin geri alınabilmesi için izlenilen bir yöntemdir. Kullanımı ile ilgili olarak genelde  yanlışlıkla yapıldığı düşünülen bir DML işlemini geri almak için kullanılabilir diyebiliriz.

Log Miner’ ın kurulumu ve konfigure edilmesi ;

Log Miner’ ın çalışması için  SUPPLEMENTAL_LOG_DATA_MIN değerinin database’ de açık olması gerekmektedir. Aşağıdaki gibi kontrol edebilirsiniz ;

SQL> select SUPPLEMENTAL_LOG_DATA_MIN from v$database;

SUPPLEMENTAL_LOG_DATA_MIN

-------------------------------------

NO

Sonucun NO dönmesi durumunda aşağıdaki şekilde Alter edebiliriz ;

SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
Database altered.

Sonrasında log_miner’ ın ihtiyaç duyduğu nesnelerin create edilmesi için aşağıdaki dizindeki sql dosyası çalıştırılır.

SQL>@$ORACLE_HOME/rdbms/admin/dbmslm.sql

Paket yaratıldı.

Erişim Yetkisi verme başarılı.

Aşağıdaki yetkinin ilgili kullanıcıya

GRANT EXECUTE_CATALOG_ROLE TO kamil;

Grant complete.

Package kolay erişim için public synonym tanımlanabilir. (schema name’ i kullanılarak da erişilebilir.)

CREATE PUBLIC SYNONYM DBMS_LOGMNR FOR SYS.DBMS_LOGMNR;

Synonym created. 

Log_miner’ ın redologları okuması için log_miner’ a tanıtılması, eklenmesi gerekmektedir. Bunun için önce loglarımıza bakalım ;

SQL> SELECT distinct member LOGFILENAME FROM V$LOGFILE;

LOGFILENAME

C:\ORACLE\10GR2\ORADATA\TEST\REDO02.LOG

C:\ORACLE\10GR2\ORADATA\TEST\REDO01.LOG

C:\ORACLE\10GR2\ORADATA\TEST\REDO03.LOG

Log_miner package’ ina okuması için dahil etmek için;

BEGIN DBMS_LOGMNR.ADD_LOGFILE

('C:\ORACLE\10GR2\ORADATA\TEST\REDO01.LOG'); 

DBMS_LOGMNR.ADD_LOGFILE 

('C:\ORACLE\10GR2\ORADATA\TEST\REDO02.LOG'); 

DBMS_LOGMNR.ADD_LOGFILE 

('C:\ORACLE\10GR2\ORADATA\TEST\REDO03.LOG'); 

END;

/

PL/SQL procedure successfully completed. 

Bakacağı son archive’ ı görmek için ;

SELECT NAME FROM V$ARCHIVED_LOG
WHERE FIRST_TIME = (SELECT MAX(FIRST_TIME) FROM V$ARCHIVED_LOG);

NAME

C:\ORACLE\10GR2\FLASH_RECOVERY_AREA\TEST\ARCHIVELOG\2011_02_08\O1_MF_1_11_6O2RV9M1_.ARC

C:\ORACLE\10GR2\FLASH_RECOVERY_AREA\TEST\ARCHIVELOG\2011_02_08\O1_MF_1_12_6O2RVHG5_.ARC

Log_Miner kurulumu tamamlanmış oldu, şimdi start ediyoruz ;

BEGIN
DBMS_LOGMNR.START_LOGMNR
(options => 
dbms_logmnr.dict_from_online_catalog);
END;
/ 

PL/SQL procedure successfully completed. 

Sonuçları Select etmek içinse  v$logmnr_contents view’ ini kullanabiliriz.

SELECT   username,

TO_CHAR (timestamp, 'mm/dd/yy hh24:mi:ss') timestamp,

seg_type_name,

seg_name,

table_space,

session# SID,

serial#,

operation,

sql_redo,

sql_undo,

session_info

FROM   v$logmnr_contents

Şimdi bir test yapalım, user_test adında bir userımız var, bu userla önce bir tablo create edelim, sonrasında içerisinde data insert edelim. En son olarak da yaptığımız bu işlemin yanlış olduğunu varsayıp nasıl düzeltebileceğimize bakalım.

create table log_miner_test as select * from dba_tables where rownum < 2 ; 

Table created. 

insert into log_miner_test select * from log_miner_test ; 

1 row created. 

commit 

Commit complete. 

v$logmnr_contents  tablosundan select ediyoruz.

SELECT   username, 

TO_CHAR (timestamp, 'mm/dd/yy hh24:mi:ss') timestamp, 

seg_type_name, 

seg_name, 

table_space, 

session# SID, 

serial#, 

operation, 

sql_redo, 

sql_undo, 

session_info 

FROM   v$logmnr_contents 

where seg_name = 'LOG_MINER_TEST' 

and username = 'USER_TEST' 

Selectin çıktısı olarak sql_redo, sql_undo ve session_info kısımlarını ayrı olarak ekliyorum ; 

USERNAME	TIMESTAMP	SEG_NAME	TABLE_SPACE	SID	SERIAL#	OPERATION
USER_TEST	02.08.2011 17:59	LOG_MINER_TEST		128	49	DDL
USER_TEST	02.08.2011 18:00	LOG_MINER_TEST	TEST_TBS	128	49	INSERT

Sql_redo;

insert into "USER_TEST"."LOG_MINER_TEST"("OWNER","TABLE_NAME","TABLESPACE_NAME","CLUSTER_NAME","IOT_NAME","STATUS","PCT_FREE","PCT_USED","INI_TRANS","MAX_TRANS","INITIAL_EXTENT","NEXT_EXTENT","MIN_EXTENTS","MAX_EXTENTS","PCT_INCREASE","FREELISTS","FREELIST_GROUPS","LOGGING","BACKED_UP","NUM_ROWS","BLOCKS","EMPTY_BLOCKS","AVG_SPACE","CHAIN_CNT","AVG_ROW_LEN","AVG_SPACE_FREELIST_BLOCKS","NUM_FREELIST_BLOCKS","DEGREE","INSTANCES","CACHE","TABLE_LOCK","SAMPLE_SIZE","LAST_ANALYZED","PARTITIONED","IOT_TYPE","TEMPORARY","SECONDARY","NESTED","BUFFER_POOL","ROW_MOVEMENT","GLOBAL_STATS","USER_STATS","DURATION","SKIP_CORRUPT","MONITORING","CLUSTER_OWNER","DEPENDENCIES","COMPRESSION","DROPPED") values ('SYS','CON$','SYSTEM',NULL,NULL,'VALID','10','40','1','255','65536',NULL,'1','2147483645',NULL,'1','1','YES','N','2786','12','0','0','0','20','0','0','         1','         1','    N','ENABLED','2786',TO_DATE('30/08/2005', 'DD/MM/RRRR'),'NO',NULL,'N','N','NO','DEFAULT','DISABLED','YES','NO',NULL,'DISABLED','YES',NULL,'DISABLED','DISABLED','NO');

sql_undo;

delete from "USER_TEST"."LOG_MINER_TEST" where "OWNER" = 'SYS' and "TABLE_NAME" = 'CON$' and "TABLESPACE_NAME" = 'SYSTEM' and "CLUSTER_NAME" IS NULL and "IOT_NAME" IS NULL and "STATUS" = 'VALID' and "PCT_FREE" = '10' and "PCT_USED" = '40' and "INI_TRANS" = '1' and "MAX_TRANS" = '255' and "INITIAL_EXTENT" = '65536' and "NEXT_EXTENT" IS NULL and "MIN_EXTENTS" = '1' and "MAX_EXTENTS" = '2147483645' and "PCT_INCREASE" IS NULL and "FREELISTS" = '1' and "FREELIST_GROUPS" = '1' and "LOGGING" = 'YES' and "BACKED_UP" = 'N' and "NUM_ROWS" = '2786' and "BLOCKS" = '12' and "EMPTY_BLOCKS" = '0' and "AVG_SPACE" = '0' and "CHAIN_CNT" = '0' and "AVG_ROW_LEN" = '20' and "AVG_SPACE_FREELIST_BLOCKS" = '0' and "NUM_FREELIST_BLOCKS" = '0' and "DEGREE" = '         1' and "INSTANCES" = '         1' and "CACHE" = '    N' and "TABLE_LOCK" = 'ENABLED' and "SAMPLE_SIZE" = '2786' and "LAST_ANALYZED" = TO_DATE('30/08/2005', 'DD/MM/RRRR') and "PARTITIONED" = 'NO' and "IOT_TYPE" IS NULL and "TEMPORARY" = 'N' and "SECONDARY" = 'N' and "NESTED" = 'NO' and "BUFFER_POOL" = 'DEFAULT' and "ROW_MOVEMENT" = 'DISABLED' and "GLOBAL_STATS" = 'YES' and "USER_STATS" = 'NO' and "DURATION" IS NULL and "SKIP_CORRUPT" = 'DISABLED' and "MONITORING" = 'YES' and "CLUSTER_OWNER" IS NULL and "DEPENDENCIES" = 'DISABLED' and "COMPRESSION" = 'DISABLED' and "DROPPED" = 'NO' and ROWID = 'AAAMmXAAHAAAAKNAAA';

session_info;

login_username=USER_TEST client_info= OS_username=WINDB\Administrator Machine_name=CB\WINDB OS_terminal=WINDB OS_process_id=4720:488 OS_program_name=toad.exe

görüldüğü üzere yapmış olduğumuz insert işlemine karşılık sorunu düzeltmek adına delete scriptini verdi, delete işlemi yapmış olsaydık insert scriptini verecekti.

Son olarak log miner’ ın çalışma şeklinden biraz bahsetmek gerekirse, ana mantığı redologları okumaktan geçiyor sonrasında ise çıkan archive’ lar üzerinden okumaya devam ediyor. Dolayısıyla geçmişe dönük ne kadar archive’ ınız var ise o kadar geriye gidebilirsiniz demektir.

Tablo ve indexler üzerinde DDL işlemlerinin nasıl yapılacapı konsunda zaman zaman yazılar yazıyoruz. Örneğin tablo ve indexlerin farklı bir tablespace taşınması ile ilgili 

(http://kamilturkyilmaz.blogspot.com/2010/10/tablo-ve-indexlerin-tasnmas_25.html) bir yazı yazmıştım. Burada ise logsegment ve logindexleri anlatmaya çalışacağım.  

Aslında burada bahsedilmesi gereken en önemli konu lobs ların taşınması olduğunu düşünüyorum. Dolayısıyla naşıl taşıyabiliriz sorusuna cevap ararken diğer yapılacak işlemlerinde sırasıyla üzerinden geçmeyi planlıyorum.  

Öncelikle üzerinde çalışabileceğimiz lob alan içeren bir tablo create edelim. 

CREATE TABLE deneme_lob ( 

ad VARCHAR2(30), 

soyad VARCHAR2(30), 

resim1 BLOB, 

resim2 BFILE, 

resim3 clob); 

Table created 

Create edilen her lob alanı için otomatik olarak bir logsegmenti ile lobindexi create edilir. Create etmiş olduğumuz tabloya ilişkin lob alanları sorguladığımızda da bunları görebiliyor oluruz. 

SELECT  segment_name , 

segment_type , 

tablespace_name tbs_name 

FROM user_segments 

WHERE segment_name like 'SYS_LOB%' 

OR segment_name like 'SYS_IL%' 

SEGMENT_NAME                                           SEGMENT_TYPE    TBS_NAME 

SYS_IL0000051350C00005$$                       LOBINDEX               TEST1 

SYS_LOB0000051350C00005$$                   LOBSEGMENT       TEST1 

SYS_IL0000051350C00003$$                        LOBINDEX               TEST1 

SYS_LOB0000051350C00003$$                   LOBSEGMENT       TEST1 

Bu örneğimizde create edilen tablomuz test1 tablespace2 inde yer alıyor. Şimdi tablo üzerinde oynamadan son durumda hangi nesnenin nerde saklandığını tekrar kontrol edelim ; 

SELECT  owner, segment_name seg_name, 

segment_type seg_type, 

tablespace_name tbs_name 

FROM dba_segments  

WHERE owner = 'KAMIL' 

OWNER        SEG_NAME                                                SEG_TYPE              TBS_NAME 

KAMIL            DENEME_LOB                                          TABLE                       TEST1 

KAMIL            SYS_IL0000051350C00005$$                LOBINDEX               TEST1 

KAMIL            SYS_LOB0000051350C00005$$           LOBSEGMENT        TEST1

KAMIL            SYS_IL0000051350C00003$$                LOBINDEX               TEST1

KAMIL            SYS_LOB0000051350C00003$$           LOBSEGMENT        TEST1

Tüm nesnelerimiz TEST1 tablesspace’ inde.

Tablomuza yeni bir lob alan ekleyelim;

alter table deneme_lob

add (resim4 blob)

ekledik, şimdi bir tane alan ekleyelim ancak bu farklı bir tablespace’ de store ediliyor olsun ;

alter table deneme_lob

add (resim5 blob)

lob (resim5) store as resim5_seg

(tablespace test2)

Kontrol ediyorum ;

SELECT   owner,

segment_name seg_name,

segment_type seg_type,

tablespace_name tbs_name

FROM   dba_segments

WHERE   owner = 'KAMIL'

OWNER        SEG_NAME                                                     SEG_TYPE              TBS_NAME

KAMIL            DENEME_LOB                                                TABLE                       TEST1

KAMIL            SYS_IL0000051350C00005$$                     LOBINDEX               TEST1

KAMIL            SYS_LOB0000051350C00005$$                LOBSEGMENT        TEST1

KAMIL            SYS_IL0000051350C00003$$                     LOBINDEX               TEST1

KAMIL            SYS_LOB0000051350C00003$$                LOBSEGMENT        TEST1

KAMIL            SYS_IL0000051350C00006$$                     LOBINDEX               TEST1

KAMIL            SYS_LOB0000051350C00006$$                LOBSEGMENT        TEST1

KAMIL            SYS_IL0000051350C00007$$                     LOBINDEX               TEST2

KAMIL            RESIM5_SEG                                                  LOBSEGMENT        TEST2

Tamam yeni alanımız istediğimiz gibi test2 tablespace’ inde store edilecek şekilde create edilmiş oldu.

Şimdi test1 tablespace' inde yer resim1 alanına ait lob segmentlerini test3 tablespace' ine taşıyalım.

ALTER TABLE deneme_lob

MOVE LOB(resim1) STORE AS (TABLESPACE test3)

Table altered.

SELECT   owner,

segment_name seg_name,

segment_type seg_type,

tablespace_name tbs_name

FROM   dba_segments

WHERE   owner = 'KAMIL'

OWNER        SEG_NAME                                                   SEG_TYPE  TBS_NAME

KAMIL            DENEME_LOB                                             TABLE                       TEST1

KAMIL            SYS_IL0000051350C00005$$                        LOBINDEX                  TEST1

KAMIL            SYS_LOB0000051350C00005$$                    LOBSEGMENT           TEST1

KAMIL            SYS_IL0000051350C00003$$                        LOBINDEX                  TEST3

KAMIL            SYS_LOB0000051350C00003$$                    LOBSEGMENT           TEST3

KAMIL            SYS_IL0000051350C00006$$                        LOBINDEX                  TEST1

KAMIL            SYS_LOB0000051350C00006$$                    LOBSEGMENT           TEST1

KAMIL            SYS_IL0000051350C00007$$                        LOBINDEX                  TEST2

KAMIL            RESIM5_SEG                                              LOBSEGMENT           TEST2

Evet, resim alanına ait tüm lob segmentler test3 tablespace’ ine taşınmış oldu. Yukarıdaki örneklerde tablo’ nun tablespace’ ine dokunmadan sadece lob alanlarının tablespace’ lerini değiştirmiştik. Şimdi resim4 alanı ile beraber tablonun tablespace’ inide değiştirellim ;

ALTER TABLE deneme_lob

MOVE TABLESPACE test4 LOB (resim4) STORE AS (TABLESPACE test4)

Kontrol edelim ;

SELECT   owner,

segment_name seg_name,

segment_type seg_type,

tablespace_name tbs_name

FROM   dba_segments

WHERE   owner = 'KAMIL'

OWNER        SEG_NAME                                                SEG_TYPE              TBS_NAME

KAMIL            DENEME_LOB                                          TABLE                       TEST4

KAMIL            SYS_IL0000051350C00005$$                      LOBINDEX                 TEST1

KAMIL            SYS_LOB0000051350C00005$$                  LOBSEGMENT          TEST1

KAMIL            SYS_IL0000051350C00003$$                      LOBINDEX                 TEST3

KAMIL            SYS_LOB0000051350C00003$$                  LOBSEGMENT          TEST3

KAMIL            SYS_IL0000051350C00006$$                      LOBINDEX                 TEST4

KAMIL            SYS_LOB0000051350C00006$$                  LOBSEGMENT          TEST4

KAMIL            SYS_IL0000051350C00007$$                      LOBINDEX                 TEST2

KAMIL            RESIM5_SEG                                            LOBSEGMENT          TEST2

Resim4 alanı ile birlikte tablonun tablespace’ inide değiştirmiş olduk.

Lobindexlerin nasıl rebuild edilebileceğinden bahsedelim, bilindik rebuild index komutu ile lobindexleri rebuild etmek istediğimizde aşağıdaki gibi hata alırız. Lobindexleri rebuild etmek istiyorsak (bulundukları tablespace’ e)  move komutu

taşımak suretiyle rebuild etmiş oluruz.

Alter index SYS_IL0000051350C00005$$ rebuild tablespace test1

Error at line 1

ORA-02327: LOB veri türündeki ifade için dizin yaratılamaz

Özellikle Rman ile bir database’ in backupını başka bir ortama kurduğumuzda database’ in dbid ve db_name değerleri asıl ortamda ne ise burda da aynı olur. Dolayısıyla bu şekilde yeni bir database create ettikden sonra elimizdeki bu yeni ortamın bu değerlerini değiştirmek isteyebiliriz. (özelliklede rman catalog database’ i kullanarak database’ lerimizin backupını alıyorsak, dbid bizim için son derece önemli olacaktır)


Şimdi değişikliğe başlamadan önce dbid ve db_name’ in şu anki değerlerine bakalım (bu değerleri sonradan işlem yapılırken de görebiliriz) ;

SQL> select dbid, name from v$database;
DBID                NAME
----------         ----------
4271840000     KTEST

Öncelikle aşağıdaki dizinde init ve spfile dosyasının olduğundan emin olun. İlgili dizin ;

Linux ortam üzerinde çalışıyorsanız ;

cd $ORACLE_HOME/dbs

Windows üzerinde çalışıyorsanız;

cd $ORACLE_HOME/database

Sonra database’ imizi immediate ile kapatıyoruz.

C:\Documents and Settings\oracle>sqlplus "/as sysdba"
SQL*Plus: Release 11.2.0.1.0 Production on Wed Feb 2 22:39:01 2011
Copyright (c) 1982, 2010, Oracle. All rights reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - Production
With the Partitioning, Oracle Label Security, OLAP, Data Mining and Oracle Database Vault options
SQL> shutdown immediate
Database closed.
Database dismounted.
ORACLE instance shut down.

SQL> startup mount
ORACLE instance started.
Total System Global Area 627732480 bytes
Fixed Size 1376408 bytes
Variable Size 184553320 bytes
Database Buffers 436207616 bytes
Redo Buffers 5595136 bytes
Database mounted.
SQL>

Mount ile database’i start ettikden sonra, komut satırından aşağıdaki komutu çalıştırıyoruz. Bu konuttaki “nid” bizim dbid ve db_name’ i değiştirmemizi sağlayacak olan komutumuz, target kısmı database’ in şu anki sys userı ve onun şifresi @ kısmı ise database’ imizin db_name’ini, dbname = parametresi ise database’ in yeni name’ mini ifade etmektedir.

nid

C:\Documents and Settings\oracle>nid DBNAME=KAMIL
DBNEWID: Release 11.2.0.1.0 - Production on Wed Feb 2 22:40:29 2011
Copyright (c) 1982, 2009, Oracle and/or its affiliates. All rights reserved.
Connected to database KTEST (DBID=4271840000)
Connected to server version 11.2.0
Control Files in database:
C:\ORACLE11GR2\ORADATA\KTEST\CONTROL01.CTL
C:\ORACLE11GR2\FLASH_RECOVERY_AREA\KTEST\CONTROL02.CTL
Change database ID and database name KTEST to KAMIL? (Y/[N]) => Y
Proceeding with operation
Changing database ID from 4271840000 to 3000141920
Changing database name from KTEST to KAMIL
Control File C:\ORACLE11GR2\ORADATA\KTEST\CONTROL01.CTL - modified
Control File C:\ORACLE11GR2\FLASH_RECOVERY_AREA\KTEST\CONTROL02.CTL - modified
Datafile C:\ORACLE11GR2\ORADATA\KTEST\SYSTEM01.DB - dbid changed, wrote newname
Datafile C:\ORACLE11GR2\ORADATA\KTEST\SYSAUX01.DB - dbid changed, wrote newname
Datafile C:\ORACLE11GR2\ORADATA\KTEST\UNDOTBS01.DB - dbid changed, wrote new name
Datafile C:\ORACLE11GR2\ORADATA\KTEST\USERS01.DB - dbid changed, wrote new name
Datafile C:\ORACLE11GR2\ORADATA\KTEST\TEMP01.DB - dbid changed, wrote new name
Control File C:\ORACLE11GR2\ORADATA\KTEST\CONTROL01.CTL - dbid changed, wrote new me
Control File C:\ORACLE11GR2\FLASH_RECOVERY_AREA\KTEST\CONTROL02.CTL - dbid changed, wrote new name
Instance shut down
Database name changed to KAMIL.
Modify parameter file and generate a new password file before restarting.
Database ID for database KAMIL changed to 3000141920.
All previous backups and archived redo logs for this database are unusable.
Database is not aware of previous backups and archived logs in Recovery Area.
Database has been shutdown, open database with RESETLOGS option.
Succesfully changed database name and ID.
DBNEWID - Completed succesfully.

Yukarıdaki mesajları başarıyla almış olmamız gerekiyor.
Bundan sonraki kısımda ;

Database’ i nomunt modda açıyoruz.

SQL> startup mount
ORACLE instance started.
Total System Global Area 627732480 bytes
Fixed Size 1376408 bytes
Variable Size 184553320 bytes
Database Buffers 436207616 bytes
Redo Buffers 5595136 bytes

Yapılan bu değişikliği aşağıdaki Alter ile de system üzerinden spfile’ e yazdırıyoruz.

SQL> ALTER SYSTEM SET DB_NAME=KAMIL SCOPE=SPFILE;
System altered.

Şimdi immediate ile tekrar kapatıyoruz ;

SQL> shutdown immediate
ORA-01507: database not mounted
ORACLE instance shut down.

Aslında bundan sonraki kısım klasik database operayonları gibi düşünebiliriz. Database’in name’ I değiştiğinden dolayı ona uygun bir password file create etmemiz gerekiyor. Ek olarak spfile dosyamızın adını da yeni SID’ imizi içerek şekilde rename edeceğiz.

orapwd file=C:\oracle11gR2\product\pwdKAMIL.ora password=oracle entries=5

Ben bu çalışmamı windows bir sunucu üzerinde yaptığımdan dolayı ..\database\ dizinindeki spfileKTEST.ora dosyasının adını spfileKAMIL.ora olacak şekilde rename ediyorum.

Yine windowslar için unutulmaması gereken bir nokta database ilk create ederken windows servisleride create ettiğinden dolayı (oracle servisleri SID bazında create edilmekte) bu servisleri de değiştirmemiz gerekiyor. Yani eski SID’ li servis tanımı silinip yerine yeni SID’ li servis tanımını eklememiz gerekiyor.

Eski tanımı silmek için ;

C:\Documents and Settings\oracle>oradim -delete -sid KTEST
Instance deleted.

Yenisini eklemek içinse;

C:\Documents and Settings\oracle>oradim -new -sid KAMIL -intpwd oracle –startmode a -pfile C:\oracle11gR2\product\spfileKAMIL.ora
Instance created.

Yapılan bu değişiklikden listener’ ında etkilenmesi için stop / start yapıyoruz.

C:\Documents and Settings\oracle>lsnrctl stop
LSNRCTL for 32-bit Windows: Version 11.2.0.1.0 - Production on 02-FEB-2011 23:29:07
Copyright (c) 1991, 2010, Oracle. All rights reserved.
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=dataguart)(PORT=1521)))
The command completed successfully

C:\Documents and Settings\oracle>lsnrctl start
LSNRCTL for 32-bit Windows: Version 11.2.0.1.0 - Production on 02-FEB-2011 23:29:12
Copyright (c) 1991, 2010, Oracle. All rights reserved.
Starting tnslsnr: please wait...
TNSLSNR for 32-bit Windows: Version 11.2.0.1.0 - Production
System parameter file is c:\oracle11gR2\product\network\admin\listener.ora
Log messages written to c:\oracle11gr2\diag\tnslsnr\dataguart\listener\alert\log.xml
Listening on: (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=dataguart)(PORT=1521)))
Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=dataguart)(PORT=1521)))
STATUS of the LISTENER
------------------------
Alias LISTENER
Version TNSLSNR for 32-bit Windows: Version 11.2.0.1.0 - Produ
ction
Start Date 02-FEB-2011 23:29:16
Uptime 0 days 0 hr. 0 min. 5 sec
Trace Level off
Security ON: Local OS Authentication
SNMP OFF
Listener Parameter File c:\oracle11gR2\product\network\admin\listener.ora
Listener Log File c:\oracle11gr2\diag\tnslsnr\dataguart\listener\alert\log.xml
Listening Endpoints Summary...
(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=dataguart)(PORT=1521)))
Services Summary...
Service "CLRExtProc" has 1 instance(s).
Instance "CLRExtProc", status UNKNOWN, has 1 handler(s) for this service...
The command completed successfully
C:\Documents and Settings\oracle>

Buraya kadar herşey yolunda, artık yeni spfile’ imiz ile database’ imizi açabiliriz. Ancak database’ i startup ile açmayacağız. Database’ in dbid ve name’ I değiştiğinden dolayı, bu database’ den alınmış olan backuplar artık kullanılamaz duruma gelmiştir çünkü artık dbid ve name’ ler farklı, dolayısıyla database’ in hayata sıfırdan yeni bir başlangıç yapması için open RESETLOGS ile açmamız gerekiyor (başka türlü açılamaz) ;

SQL> startup mount
ORACLE instance started.
Total System Global Area 627732480 bytes
Fixed Size 1376408 bytes
Variable Size 184553320 bytes
Database Buffers 436207616 bytes
Redo Buffers 5595136 bytes
Database mounted.
SQL> alter database open resetlogs ;
Database altered.

Şimdi yeni dbid ve name değerlerimizi kontrol edelim.

SQL> select dbid, name from v$database;
DBID                NAME
----------          ---------
3000141920     KAMIL

Database’ in sadece DBID’ sini veya DB_NAME’ ini de değiştirebilirsiniz, şöyleki ;

Sadece DBID değiştirmek isterseniz ;

nid çalıştırmanız yeterli olacaktır. Bu komut sadece dbid’ yi değiştirecektir ve name aynı kalacaktır. Burada db_name’ dokunmadığımız için spfile veya pasword file üzerinde vir değişiklik yapmamıza gerek yok, sadece open RESETLOGS ile açmamız yeterli olacaktır.

Sadece DB_NAME’ i değiştirmek istersenizde

nid SETNAME=YES komutunu çalıştırmamız yeterli olacaktır. BU komutta dbid’ ye dokunmadan sadece name’ I değiştirecektir. Diğer adımlar yukarıdakiler ile aynı.

Bu işleme aslında çok sık olmasa da rman’ le create ettiğimiz yeni database’ imizi başka bir projede PROD olarak kullanmamız gerektiğinde veya kullanılan bir database farklı bir projede kullanılacaksa ona uygun bir name verilmek istendiğinde kullanılabilirsiniz.

Bundan önceki yazımda AWR’ ın kullanımı ile giriş yaparak, AWR aracılığı ile snaphotları nasıl create, drop ederizden bahsettik. Şimdi alınan bu snaphotlara ait raporları nasıl compare ederiz buna bakacağız. Özetle şunu yapmaya çalışıyoruz aslında database’ de yaşanan bir performans probleminin ne boyutta olduğuna veya aynı dönemi kapsayan başka bir aralığa göre problemin neden kaynaklandığını, yoğunluk olarak hangi alanlarda artış olduğunu görebilmek ve içinde bulunduğumuz durumu daha iyi yorumlayabilmek için karşılaştırma yapabiliriz. 

Şöyle bir problem olduğunu varsayalım. Her gün saat 09:00 ile 11:00 arasında database’ imizin performansı stabil iken, gün içerisinde bu saatler aralığında performansın ciddi bir şekilde düştüğünü varsayalım. Buradaki sorunu tespit içinde dün ile bugün aynı saatler aralığını gösteren AWR raporlarını compare etmeye çalışalım. (bu işlemi konsol üzerinden grafik ekranda çok rahatlıkla yapabilirsiniz ancak biz ortada bir problem var iken konsolun çalışmama riskini gözönünde bulundurarak komut satırından yapmaya çalışacağız) 

Bu işlemler için dba yetkisi gerektiğini tekrar hatırlatalım. 

Komut satırından scriptimizin yer aldığı awrddrpt.sql dosyasını çalıştırıyoruz.

@$ORACLE_HOME/rdbms/admin/awrddrpt.sql 

Sonrasında yapılan işlemlerle ilgili loglarıda ekliyorum ; 

SQL> @$ORACLE_HOME/rdbms/admin/awrddrpt.sql 

Current Instance 

~~~~~~~~~~~~~~~~ 

DB Id DB Id DB Name Inst Num Inst Num Instance

----------- ----------- ------------ -------- -------- ------------ 

2656835042 2656835042 TEST                 1 1 TEST

Specify the Report Type 

~~~~~~~~~~~~~~~~~~~~~~~ 

Would you like an HTML report, or a plain text report? 

Enter 'html' for an HTML report, or 'text' for plain text 

Defaults to 'html' 

Enter value for report_type: text 

Type Specified: text

Instances in this Workload Repository schema 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 

DB Id Inst Num DB Name Instance Host

------------ -------- ------------ ------------ ------------ 

* 2656835042 1 TEST          TEST          tester

Database Id and Instance Number for the First Pair of Snapshots 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 

Using 2656835042 for Database Id for the first pair of snapshots 

Using 1 for Instance Number for the first pair of snapshots

Specify the number of days of snapshots to choose from 

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 

Entering the number of days (n) will result in the most recent 

(n) days of snapshots being listed. Pressing without

specifying a number lists all completed snapshots. 

Enter value for num_days: 2 

Listing the last 2 days of Completed Snapshots 

Snap

Instance DB Name Snap Id Snap Started Level

------------ ------------ --------- ------------------ ----- 

TEST TEST     6480 22 Feb 2011 00:00      1

                       6481 22 Feb 2011 01:00      1

                       6482 22 Feb 2011 02:00      1

                       6483 22 Feb 2011 03:00      1

                       6484 22 Feb 2011 04:00      1

                       6485 22 Feb 2011 05:00      1

                       6486 22 Feb 2011 06:00      1

                       6487 22 Feb 2011 07:00      1

                       6488 22 Feb 2011 08:00      1

                       6489 22 Feb 2011 09:00      1

                       6490 22 Feb 2011 10:00      1

                       6491 22 Feb 2011 11:00      1

                       6492 22 Feb 2011 12:00      1

                       6493 22 Feb 2011 12:48      1

                       6494 22 Feb 2011 12:48      2

                       6496 22 Feb 2011 14:00      1

                       6497 22 Feb 2011 15:00      1

                       6498 22 Feb 2011 16:00      1

                       6499 22 Feb 2011 17:00      1

                       6500 22 Feb 2011 18:00      1

                       6501 22 Feb 2011 19:00      1

                       6502 22 Feb 2011 20:00      1

                       6503 22 Feb 2011 21:00      1

                       6504 22 Feb 2011 22:00      1

                       6505 22 Feb 2011 23:00      1

                       6506 23 Feb 2011 00:00      1

                       6507 23 Feb 2011 01:00      1

                       6508 23 Feb 2011 02:00      1

                       6509 23 Feb 2011 03:00      1

                       6510 23 Feb 2011 04:00      1

                       6511 23 Feb 2011 05:00      1

                       6512 23 Feb 2011 06:00      1

                       6513 23 Feb 2011 07:00      1

                       6514 23 Feb 2011 08:00      1

                       6515 23 Feb 2011 09:00      1

                       6516 23 Feb 2011 10:00      1

                       6517 23 Feb 2011 11:00      1

                       6518 23 Feb 2011 12:00      1

                       6519 23 Feb 2011 13:00      1

                       6520 23 Feb 2011 14:00      1

                       6521 23 Feb 2011 15:00      1

                      6522 23 Feb 2011 16:00      1

Specify the First Pair of Begin and End Snapshot Ids

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Enter value for begin_snap: 6489

First Begin Snapshot Id specified: 6489

Enter value for end_snap: 6491

First End Snapshot Id specified: 6491

Instances in this Workload Repository schema

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

DB Id Inst Num DB Name Instance Host

------------ -------- ------------ ------------ ------------

* 2656835042 1 TEST          TEST          tester

Database Id and Instance Number for the Second Pair of Snapshots

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Using 2656835042 for Database Id for the second pair of snapshots

Using 1 for Instance Number for the second pair of snapshots

Specify the number of days of snapshots to choose from

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Entering the number of days (n) will result in the most recent

(n) days of snapshots being listed. Pressing without

specifying a number lists all completed snapshots.

Enter value for num_days2: 2

Listing the last 2 days of Completed Snapshots

                               Snap

Instance DB Name Snap Id Snap Started Level

------------ ------------ --------- ------------------ -----

TEST TEST    6480 22 Feb 2011 00:00      1

                     6481 22 Feb 2011 01:00      1

                     6482 22 Feb 2011 02:00      1

                     6483 22 Feb 2011 03:00      1

                     6484 22 Feb 2011 04:00      1

                     6485 22 Feb 2011 05:00      1

                     6486 22 Feb 2011 06:00      1

                     6487 22 Feb 2011 07:00      1

                     6488 22 Feb 2011 08:00      1

                     6489 22 Feb 2011 09:00      1

                     6490 22 Feb 2011 10:00      1

                     6491 22 Feb 2011 11:00      1

                     6492 22 Feb 2011 12:00      1

                     6493 22 Feb 2011 12:48      1

                     6494 22 Feb 2011 12:48      2

                     6496 22 Feb 2011 14:00      1

                     6497 22 Feb 2011 15:00      1

                     6498 22 Feb 2011 16:00      1

                     6499 22 Feb 2011 17:00      1

                     6500 22 Feb 2011 18:00      1

                     6501 22 Feb 2011 19:00      1

                     6502 22 Feb 2011 20:00      1

                     6503 22 Feb 2011 21:00      1

                     6504 22 Feb 2011 22:00      1

                     6505 22 Feb 2011 23:00      1

                     6506 23 Feb 2011 00:00      1

                     6507 23 Feb 2011 01:00      1

                     6508 23 Feb 2011 02:00      1

                     6509 23 Feb 2011 03:00      1

                     6510 23 Feb 2011 04:00      1

                     6511 23 Feb 2011 05:00      1

                     6512 23 Feb 2011 06:00      1

                     6513 23 Feb 2011 07:00      1

                     6514 23 Feb 2011 08:00      1

                     6515 23 Feb 2011 09:00      1

                     6516 23 Feb 2011 10:00      1

Bugün database' in performansı ile ilgili belli aralıklarla alınmakta olan snapshotların, bizler için ne ifade ettiğinden, nasıl alınabileceğinden, çalışma şeklinden ve nasıl configure edileceğinden bahsetmek istiyorum.

Automatic Workload Repository (AWR), problemi tespit etmek ve self-tuning yapabilmek amacıyla istatistik toplar. Toplanan bu istastikler ise hem memoryde hem de veritabanında saklanır.

AWR istatistikleri neleri içerir, nelerden oluşur ;

*     * Erişim ve kullanım istatistiklerini belirlemek için Object İstatistikleri,

*     * Session bazında, zaman modelli istatistikleri (ki alınan bu istatistikleri V$SYS_TIME_MODEL ve V$SESS_TIME_MODEL viewlerinden görebiliriz.)

*     * Bazı system ve session istatistiklerini, (bu istatistikleride V$SYSSTAT and V$SESSTAT viewlerinden izleyebiliriz)

*     * System üzerinde çalışma süresi ve CPU kullanımında top olan sql statmentları ile ilgili istatistikleri,

*     * ASH istastikleri, son sesessionlara ait işlemler ile ilgili istastikleri

İçerir.

Database istatistikleri AWR aracılığıyla toplanır ve defaultunda enable olarak gelir ve bu opsiyon Statistics_level inital parametsiyle kontrol edilir. Awr’ ın çalışabilmesi için  statistic_level parametresi mutlaka TYPICAL veya ALL  olarak set edilmelidir. Defaultunda Typical olarak geldiği içinde AWR’ ın defaultu enable’ dır.  Bu değer BASIC olarak set edildiğinde artık database’ in istatistikleri toplanmayacağı anlamına gelmektedir. (AWR disable olacağından) Bu parametrenin BASIC olması performans açısından da (tabloların zaman içerisinde structure’ ları, size’ ları, indexleri değişeceğinden, çalışan sql’ lere ait execution planları da zamanla yanlış ve yavaş çalışmaya başlayacağından) olumsuz sonuçlar doğuracaktır. Dolayısıyla bu önerilen bir durum değildir. AWR,  database’ in istatistiklerini belirli periyodlarda otomatik olarak alır, eğer statistics_level parametresi BASIC ise yani AWR disable ise, manuel olarak DBMS_WORKLOAD_REPOSITORY package’ ı kullanılarak AWR istatistikleri alabilirsiniz. Ancak system istatistiklerinin büyük bir kısmı (segment istatistikleri ve memory advisor bilgileri gibi) disable olacağından  anlık olarak alınmaya çalışılan istatistikler tam olmayabilir.

Ne olduğundan bahsettik, şimdi biraz da Automatic Workload Repository ile ilgili kavramlar üzerinde duralım biraz, sonrasında yönetimi ile devam edeceğiz ;

*     * Snapshots ;

Snapshots, ADDM tarafından performans karşılaştırmaları yapmak için kullanılan, belirli bir zaman aralığına ait verilerin history bilgisini turarlar. Oracle’ ın kurulumu ile birlikte default olarak her saat başında otomatik olarak çalışır ve saat başında alınan bu snapshot’ larıda 8 gün boyunca saklar.  Saat başında otomatik olarak alınmasının yanında, istenildiği anda manuel olarak da snapshot alınabilir. AWR tarafından alınan snapshotlar, Automic Database Diagnostic Monitor (AADDM) tarafında da otomatik olarak incelenmektedir.

AWR raporları, iki dönem arasındaki performansı karşılaştırarak, performans kaybına yol açan sql statementlarının tespit edilmesine yardımcı olur. Oracle 10g ile birlikte tanışmış olduğumuz AWR ve ADDM, kullanıcılardan performans ile ilgili şikayetlerin arttığı zamanlarda sorunun tespiti açısından ciddi rol oynamaktadırlar.

*     * Baselines ;

Baseline, belli bir zaman aralığındaki performans ile ilgili dataları içerir.

*     * Adaptive Thresholds

Adaptive thresholds’ lar performans ile ilgili sorunları tespit ve monitor etmeye yardımcı olur. Bunu, tanımlayacağınız thresholdlar da otomatik olarak warning/critical alert seviyeleri bazında yapabiliriz.

   Atomatic Workload Repository Yönetimi 

*      * Snapshot Yönetimi

Oracle database kurulumu ile birlikte default olarak her saat başı otomatik olarak snaphot’ ların alınmaktadır. Alınan bu snapshotların saklanmasıda default olarak 8 gün dür. İhtiyaç halinde DBMS_WORKLOAD_REPOSITORY package’ı ile manuel olarak snapshot create, drop veya edit edebiliriz. Bu package kullanabilmek için user’ ın DBA yetkisine sahip olmalıdır. Manuel olarak snapshot create – drop edilmesi işlemi özellikle enterprise manager konsolu kullanamadığımız durumlarda (ki kimiz zaman sistemde yaşanan problemlerden dolayı zaman zaman konsolu kullanamayabiliyoruz) ciddi önemli olduğu durumlarla karşılaşabiliriz. Dolayısıyla sadece bu işlem için değil, database seviyesinde yapacağımız tüm işlemlerin sql komutları ile nasıl yapıldıklarını bilmemiz zaman zaman hayati önem taşıyabiliyor.

Manuel olarak bahsettiğimiz bu işlemleri şimdi sırası ile nasıl yapabileceğimize bakalım;

(aşağıda belirtilen işlemlerin aynısı konsol üzerinden de yapılabilir ben burada sadece konsolu kullanmadan nasıl yapabileceğimiz üzerinde duracağım)

Manuel Snapshot create etmeye çalışalım; 

BEGIN

DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT ();

END;

/

PL/SQL procedure successfully completed

Yukarıdaki scriptte snapshot kısmında sonraki “()” alanı doldurmadan direk çalıştırdık. Buraya TYPICAL  veya ALL da yazabilirdik. Null  olarak gönderdiğimizde statistic_level parametreniz ne olarak set etmişseniz onu dikkate alıyor.

Şimdi almış olduğum son snapshot’ ı drop etmek isteyelim ; 

BEGIN

DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE (low_snap_id => 6495,

high_snap_id => 6495, dbid => 2656835042);

END;

/

PL/SQL procedure successfully completed

Bu şekilde sadece seçmiş olduğunuz snapshotı drop edebileceğiniz gibi bir aralık içerisindeki tüm snapshotlarıda drop edebilirsiniz.

Snapshot ayarlarını modify etmeye çalışalım ; 

BEGIN

DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS( retention => 43200,

interval => 30, topnsql => 100, dbid => 3310949047);

END;

/

PL/SQL procedure successfully completed

Yapılan bu değişikliği şöyle tanımlayabiliriz; retention parametresi ile alınan snapshotların saklanma süresi 43200 dakikaya yani 30 güne, interval 30 ile snapshot alınma sıklığı 30 dak’ ya, topnsql 100 ile snapshotlara dikkate alınanacak top sql sayısı 100’ e set edilmektedir. Dbid parametresi ise üzerinde işlem yapmakta olduğunuz database’ in dbis’ sini ifade etmektedir. (select dbid from v$database ile bulunabilir)

Snapshot ayarları ile ilgili yapmış olduğunuz bu değişiliklerin history’ si neDBA_HIST_WR_CONTROL view’ ini select ederek görebilirsiniz.

select * from  sys.DBA_HIST_WR_CONTROL

DBID                SNAP_INTERVAL                      RETENTION                             TOPNSQL

2040370613    +00 01:00:00.000000              +07 00:00:00.000000               DEFAULT

AWR ile tüm testleri 11gR2 ortamında yaptığımdan dolayı farklı versiyonlarda bu selectin sonuçu farklı çıkacaktır. (örneğin 10gR2 de topnsql alanı olmayacaktır)

*     * Baseline Yönetimi

Baseline’ lar sistemin optimum olarak çalıştığı bir dönemde create edilip problem oluştuğu dönemde nelerin problem teşkil ettiğini yani iki dönem arasındaki farkı ne olarak görebilmek için alınır. (veya yoğun dönemlerde oluşturulup başka bir aralık ile karşılaştırmamıza olanak sağlar) Baseline’ da iki şekilde create edebiliriz. Konsol üzerinden ve DBMS_WORKLOAD_REPOSITORY package’ ını kullanarak. Package ile nasıl create, drop veya modify baseline yapabiliriz bunlara bakalım kısaca;

  create etmek için ; 

öncelikle hangi aralığa ait snapshotları kullanarak baseline create edeceğiz buna kara veriyoruz. Aşağıdaki sql’ den mevcut snapshotlara bakabiliriz;

select * from DBA_HIST_SNAPSHOT ;

sonra ;

BEGIN

DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE (start_snap_id => 6517,

end_snap_id => 6518, baseline_name => 'deneme baseline',

dbid => 2656835042, expiration => 30);

END;

PL/SQL procedure successfully completed

Artık oluşturmuş olduğumuz yeni baseline’ nıda ;

select * from DBA_HIST_BASELINE  

view’ inde görebiliyoruz. 

Create scriptinde expiration parametresini null gönderirseniz asla expire olmayacak demiş olursunuz.bizim bu örneğimizde 30 olarak set etmiş olduk.

Drop etmek için ;  

Aynı mantıkda, hangi baseline’ i drop etmek istediğimize DBA_HIST_BASELINEtablosundan bakıp karar veriyoruz. (tabi eğer bilmiyorsak) 

Sonra; 

BEGIN

DBMS_WORKLOAD_REPOSITORY.DROP_BASELINE (baseline_name => 'deneme baseline',

cascade => FALSE, dbid => 2656835042);

END;

PL/SQL procedure successfully completed

Ile drop edebiliriz. 

Daha önce alınmış olan bir baseline’ nın adını rename etmek için ; 

BEGIN

DBMS_WORKLOAD_REPOSITORY.RENAME_BASELINE (

old_baseline_name => 'deneme baseline',

new_baseline_name => 'dene baseline',

dbid => 2656835042);

END;

PL/SQL procedure successfully completed

Ile yapabiliriz. 

İşinize yarayacağını düşündüğüm bazı Automatic Workload Repository ile ilgili wievler ; 

V$ACTIVE_SESSION_HISTORY = Database’ deki active sessionlara ait bilgilerin turulduğu view,

DBA_HIST_ACTIVE_SESS_HISTORY = memorydeki en son system aktivitelerine ait bilgileri içerir,

DBA_HIST_BASELINE = database’ deki baseline’ leri listeler,

DBA_HIST_BASELINE_DETAILS = baseline’ lar hakkında detaylı bilgileri içerir,

DBA_HIST_BASELINE_TEMPLATE = system tarafından generate edilen baseline template’ leri hakkında bilgiler içerir,

DBA_HIST_DATABASE_INSTANCE = database environment’ ları hakkında bilgileri içeir,

DBA_HIST_SNAPSHOT = database’deki snapshotlar hakkında bilgileri içerir,

DBA_HIST_WR_CONTROL = AWR’ ın kontrol ayarları ile ilgili bilgileri içerir.

AWR raporu create etmek için ; 

Yine konsolu kullanmadan awr raporu create etmek için aşağıdaki adımları izleyebiliriz. Tabi bunları yapan kullanıcının dba yetkisine sahip olması gerektiğini de unutmayalım.

Sql komut satırıdan aşağıdaki sql dosyasını çağırıyoruz;

@$ORACLE_HOME/rdbms/admin/awrrpt.sql

[ admin]$ sqlplus "/as sysdba"

SQL*Plus: Release 11.2.0.1.0 Production on Wed Feb 23 14:43:32 2011

Copyright (c) 1982, 2009, Oracle.  All rights reserved.

Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL>

SQL>

SQL> @$ORACLE_HOME/rdbms/admin/awrrpt.sql;

Current Instance

~~~~~~~~~~~~~~~~

DB Id            DB Name         Inst Num          Instance

-----------          ------------         --------             ------------

2656835042   TEST                 1                     TEST

Specify the Report Type

~~~~~~~~~~~~~~~~~~~~~~~

Would you like an HTML report, or a plain text report?

Enter 'html' for an HTML report, or 'text' for plain text

Defaults to 'html'

Enter value for report_type: html

Type Specified:  html

Instances in this Workload Repository schema

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

DB Id            Inst Num DB Name      Instance     Host

------------         -------- ------------ ------------ ------------

* 2656835042        1   TEST          TEST          tester1

Using 2656835042 for database Id

Using          1 for instance number

Specify the number of days of snapshots to choose from

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Entering the number of days (n) will result in the most recent

(n) days of snapshots being listed.  Pressing without

specifying a number lists all completed snapshots.

Enter value for num_days: 1

Listing the last day's Completed Snapshots

Snap

Instance     DB Name        Snap Id    Snap Started    Level

------------ ------------ --------- ------------------ -----

TEST     TEST      6506 23 Feb 2011 00:00      1

                           6507 23 Feb 2011 01:00      1

                           6508 23 Feb 2011 02:00      1

                           6509 23 Feb 2011 03:00      1

                           6510 23 Feb 2011 04:00      1

                           6511 23 Feb 2011 05:00      1

                           6512 23 Feb 2011 06:00      1

                           6513 23 Feb 2011 07:00      1

                           6514 23 Feb 2011 08:00      1

                           6515 23 Feb 2011 09:00      1

                           6516 23 Feb 2011 10:00      1

                           6517 23 Feb 2011 11:00      1

                           6518 23 Feb 2011 12:00      1

                           6519 23 Feb 2011 13:00      1

                           6520 23 Feb 2011 14:00      1

Specify the Begin and End Snapshot Ids

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Enter value for begin_snap: 6519

Begin Snapshot Id specified: 6519

Enter value for end_snap: 6520

End   Snapshot Id specified: 6520

Specify the Report Name

~~~~~~~~~~~~~~~~~~~~~~~

The default report file name is awrrpt_1_6519_6520.html.  To use this name,

press to continue, otherwise enter an alternative.

Enter value for report_name: deneme_awr

Using the report name deneme_awr

…

…

…

…

…

Report written to deneme_awr

SQL>

awrrpt.sql’ i komut satırından başlatııkdan sonra sırası ile istenilen bilgileri giriyoruz. Bu bilgileri sırasıyla açıklayalım ;

Enter value for report_type: html

(rapor çıktısının formatını belirliyoruz, text veya html giriyoruz)

Enter value for num_days: 1

(snapshot id’ si seçmek için kaç günlük snapshotları görmek istediğimizi söylüyoruz)

Enter value for begin_snap: 6519

Enter value for end_snap: 6520

(alacağımız raporun hangi snapshotları dikkate alması gerektiğini söylüyoruz)

Enter value for report_name: deneme_awr

(raporun ismini set ediyoruz. Hangi dizinde çalıştırdıysanız o dizin altına belirlediğiniz isimle dosyayı create ediyor)

 

RAC kullanıyorsanız çalıştıracağınız file’ in ismi  awrgrpt.sql olacaktır. (@$ORACLE_HOME/rdbms/admin/awrgrpt.sql)

 

Spesifik bir instance için AWR raporu create etmek için çalıştırılması gereken file awrrpti.sql olacaktır.  

(@$ORACLE_HOME/rdbms/admin/awrrpti.sql)

Bu awrrpti.sql çalıştırıldığından yukarıdakinden farklı olarak sizden hangi instance için almanız gerekiyor ise o instance ait dbis bilgisini girmenizi isteyecektir.

 

Instances in this Workload Repository schema

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

DB Id    Inst Num DB Name      Instance     Host

----------- -------- ------------ ------------ ------------

3309173529        1 MAIN         main         examp1690

3309173529        1 TINT251      tint251      samp251

Rac kullanıpda, spesifik bir instance için AWR raporu create etmek için çalıştırılması gereken file awrgrpti.sql olacaktır.  

(@$ORACLE_HOME/rdbms/admin/awrgrpti.sql)

 

Burada da istenilen bilgiler yukarıdaki örnekdeki gibi girilmesi gerekmektedir.  

Şimdi işi biraz daha detaylandırıp snapshot içerisinde bizim için problemli olduğunu düşündüğümüz sadece bir sql için awr raporu almaya çalışalım. Bunun için kendi test ortamımda şöyle bir case oluşturdum. 06y3gf61vurz7 id’ li bir sql’ im var ve sabah 08 – 09 arasında sistemde kaynaklanan yoğunluğun bu sql’ den kaynaklandığını düşünelim ve araştıralım ;

Yaptığım işleme ait log ;

[]$ sqlplus "/as sysdba"

SQL*Plus: Release 11.2.0.1.0 Production on Wed Feb 23 15:20:14 2011

Copyright (c) 1982, 2009, Oracle.  All rights reserved.

Connected to:

Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production

With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> @$ORACLE_HOME/rdbms/admin/awrsqrpt.sql

Current Instance

~~~~~~~~~~~~~~~~

DB Id    DB Name      Inst Num Instance

----------- ------------ -------- ------------

2656835042 TEST                 1 TEST

Specify the Report Type

~~~~~~~~~~~~~~~~~~~~~~~

Would you like an HTML report, or a plain text report?

Enter 'html' for an HTML report, or 'text' for plain text

Defaults to 'html'

Enter value for report_type: text

Type Specified:  text

Instances in this Workload Repository schema

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

DB Id     Inst Num DB Name      Instance     Host

------------ -------- ------------ ------------ ------------

* 2656835042  &nbs

Database’ in olmazsa olmaz koşullarından biri en 2 gruplu bir redolog grubunuzun olmasıdır. Redolog’ lar sistemin son ana döndürülmesinde kritik bir önem taşıdığından dolayı groupların memberlanması son derece önemlidir. Redologların nasıl memberlanacağı ile ilgili http://kamilturkyilmaz.blogspot.com/2010/11/redolog-group-tanmlama-degisiklik-yapma.html 

gerekli bilgiyi daha önceki yazımda detaylı olarak anlatmıştım. Redologlarınız member’ lı değilse ve herhangi birini kaybetdiyseniz  veritabanını kurtarmak için aşağıdaki işlemleri yapmamız gerekir. Ancak burada unutumaması gereken nokta; commit edilmemiş tüm transactionların geri getirilemeyeceği yani veri kaybı yaşanacağıdır.  

Benzer bir case’ i oluşturabilmek için database’ imizi shutdown immediate ile kapatıyoruz.

SQL> shutdown immediate;

Veritabanı kapatıldı.

Veritabanı kullanıma kapatıldı.

ORACLE anı kapatıldı.

SQL>

Redologlardan birini, yer aldığı dizinden siliyorum; Şimdi bu haliyle database’ i açmayı deniyorum (hatayı görebilmek için) ;

SQL> startup

ORACLE anı başlatıldı.

Total System Global Area  612368384 bytes

Fixed Size                  1250428 bytes

Variable Size             222301060 bytes

Database Buffers          381681664 bytes

Redo Buffers                7135232 bytes

Veritabanı kullanıma açıldı.

ORA-00313: 1 günlük grubunun (thread 1) üyeleri açılamadı

ORA-00312: çevrimiçi günlük 1, thread 1:

'C:\ORACLE\10GR2\ORADATA\TEST\REDO01.LOG'

Database redologlardan redo01.log dosyasını bulamadığı için açamadı. Ve mount modda kaldı. (hatırlayınız; database’ e startup komutu verildiğinde son aşaması datafile’ leri ve redologları açtığı nokta idi, bu aşamayı geçemediğinden dolayı mount modda kalıyor.)  Kontrol etmek için ;

SQL> select open_mode from v$database;

OPEN_MODE

----------

MOUNTED

Bu durumdan kurtulmak için şimdi komut satırından database’ i recover ediyoruz. Bu işlem ile kayıp olan redolog dosyası otomatikl olarak daha önce olduğu lokasyona aynı isimle system tarafından otomatik olarak create ediliyor. Bu işlemi “recover database until cancel” komutu ile yapmamızın nedeni gelebildiğimiz kadar son noktaya gelmeye çalıştığımızdan dolayıdır.

SQL> recover database until cancel;

Ortam kurtama tamamlandı.

Bu işlemi başarıyla gerçekleştirdikden sonra yine unutlmaması gereken bir nokta incomplete recovery işlemlerinden sonra mutlaka database’ i open resetlogs komutu ile açabilmemizdir. Zaten open ile açmayı denediğinizde aşağıdaki hatayı alırsınız.

SQL> alter database open ;

alter database open

*

1 satırında HATA:

ORA-01589: veritabanı açma için RESETLOGS veya NORESETLOGS seçeneği  kullanılmalı

Rsetlogs ile açıyoruz.

SQL> alter database open resetlogs;

Veritabanı değiştirildi.

Bu şekilde database’ imizi kurtarmış olduk.  Bu işlemi yapabilmek için database’ in archive modda olmasına gerek yoktur.  Çünkü bu problemi düzeltmek için archive loglara ihtiyaç bulunmamaktadır.

Bu tarz disaster durumlarında veri kaybı çoğu zaman kabul edilebilir bir nokta olmakdan çıkıyor, dolayısıyla yazımın başında belirtmiş olduğum gibi önlemlerimizi zamanında ve doğru bir şekilde alıyor olmamız gerekiyor.