joomla templates Data Warehouse Türkiye

Wed08242011

Last update07:32:32 PM GMT

Back Kamil TURKYILMAZ
Kamil TURKYILMAZ

Kamil TURKYILMAZ

1979  Tokat/Zile doğumluyum. Yıldız Teknik Üniversitesi 1997 – 2001 mezunuyum ancak 1998 yılından itibaren  IT sektöründe, 2000 yılından bu yanada Oracle üzerine çalışmaktayım. 2005 yılına kadar oracle database’i üzerine yazılmış olan kimi uygulamalara software support  hizmeti, son 6 yıl ise oracle veritabanı yöneticiliği olmak üzere yaklaşık 11 yıldır sektör içerisindeyim. Oracle’ ın hemen hemen tüm ürünlerinin kurulumu, konfigurasyonu, yönetimi konusundaki çalışmalarıma devam etmekteyim. Son 2 yıldır da özel bir bankada oracle dba olarak çalışmaktayım. Aynı zamanda kimi bilişim sitelerinde yazarlık yapıyorum, bunun yanısıra bu alandaki deneyim ve tecrübelerimi daha fazla kişiyle paylaşabilmek adına bir de oracle blog  yazarıyım.

Website bağlantısı: http://www.kamilturkyilmaz.com

Bu aralar yaklaşık 19 tb büyüklüğündeki bir production database’ imizi farklı bir sunucu üzerine migration yapacağımız için kullanacağımız muhtemel yöntemleri ve bu yöntemlerin artılarını ve eksiklerini test etmekle uğraşıyorum. Transportable tablespace bu yöntemlerin en başında geliyor aslında, burdaki en büyük problemlerimizden biride database içerisindeki materialized views’ lerin durumu, zira transportable tablespace bu nesneleri taşımıyor. Bununla ilgili bugün yapmış olduğum bir testi sizlerle paylaşmak istedim.

Transportable tablespace yöntemi ile ilgili olarak daha önce ayrıntılı bir yazı yazmıştım zaten dolayısıyla burda yöntem ile ilgili detaya girmeyeceğim. Burdan ulaşabilirsiniz

Testi yaptığım her iki database’ inde Endian formatları aynı olduğundan dolayı rman tarafında herhangi bir convert işlemi yapmayacağım.

SELECT a.platform_name, endian_format

FROM v$transportable_platform b, v$database a

WHERE b.platform_name = a.platform_name

PLATFORM_NAME                                             ENDIAN_FORMAT

—————————————————————  ————–

Linux x86 64-bit                                                    Little

1 row selected

Bu testi yaparken kapsamı biraz daha genişletip public synonym, dblink’ lerin de bu yöntemle taşınamadığını göstermek istedim. Şimdi ilk database’ imizde bu nobjeleri oluşturalım sonrasında taşıyıp sonucuna bakalım.

– public sysnonym’ mizi oluşturalım

create public synonym tester FOR kamil.test

Synonym created

– dblinkimizi oluşturalım

create database link test

connect to KAMIL

identified by xxxxxxx

using ‘alfa’

External database created

– materialized view’ imizi oluşturalım

CREATE MATERIALIZED VIEW kamil.session_log NOCACHE

LOGGING

NOCOMPRESS

NOPARALLEL

REFRESH COMPLETE

START WITH TO_DATE(’10-Mar-2011 15:50:37′,’dd-mon-yyyy hh24:mi:ss’)

NEXT SYSDATE + 360/1440

AS

select * from v$session

Snapshot created

– MV create ettikden sonra oluşan tabloya bir bakalım

select count(*) from kamil.session_log

COUNT(*)

———-

460

1 row selected

Buraya kadar herşey normal, devam ediyoruz,

–  bu test için oluşturmuş olduğumuz tbs_mvtest tablespace’ inin diğer tablespace’ ler ile bir ilişkisi olup olmadığını kontrol edelim.

begin

DBMS_TTS.TRANSPORT_SET_CHECK(‘TBS_MVTEST’,TRUE);

end;

PL/SQL procedure successfully completed

– sonucu select ediyoruz

SELECT * FROM TRANSPORT_SET_VIOLATIONS

0 rows selected

– hiçbir bağımlılığı yok, read only moda alıp meta datanın backupını alalım

alter tablespace TBS_MVTEST read only

Tablespace altered

– expdp için directory create ediyoruz

CREATE DIRECTORY expdp AS ‘/oradata/export/expdp’

Directory created

– exportu alacak user için gerekli yetkilendirmeyi yapalım

GRANT READ,WRITE ON DIRECTORY expdp TO system

Grant succeeded

– çok gerekli değil ama yinede kontrol amaçlı directory’ e bakalım

SELECT * FROM dba_directories where directory_name = ‘EXPDP’

OWNER     DIRECTORY_NAME  DIRECTORY_PATH

SYS           EXPDP                /oradata/export/expdp                                             1 row selected

– expdp ile transportable exportumuzu alalım.

expdp  system/oracle  DIRECTORY=expdp  TRANSPORT_TABLESPACES=TBS_MVTEST TRANSPORT_FULL_CHECK=y DUMPFILE=tbs_mvtest.dmp logfile=tbs_mvtest.log

[]$ expdp system/oracle DIRECTORY=expdp  TRANSPORT_TABLESPACES=TBS_MVTEST TRANSPORT_FULL_CHECK=y DUMPFILE=tbs_mvtest.dmp logfile=tbs_mvtest.log

Export: Release 11.2.0.1.0 – Production on Thu Mar 10 16:33:55 2011

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  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

Starting “SYSTEM”.”SYS_EXPORT_TRANSPORTABLE_01″:  “********” DIRECTORY=expdp TRANSPORT_TABLESPACES=TBS_MVTEST TRANSPORT_FULL_CHECK=y DUMPFILE=tbs_mvtest.dmp logfile=tbs_mvtest.log

Processing object type TRANSPORTABLE_EXPORT/PLUGTS_BLK

Processing object type TRANSPORTABLE_EXPORT/TABLE

Processing object type TRANSPORTABLE_EXPORT/COMMENT

Processing object type TRANSPORTABLE_EXPORT/MATERIALIZED_VIEW

Processing object type TRANSPORTABLE_EXPORT/POST_INSTANCE/PLUGTS_BLK

Master table “SYSTEM”.”SYS_EXPORT_TRANSPORTABLE_01″ successfully loaded/unloaded

******************************************************************************

Dump file set for SYSTEM.SYS_EXPORT_TRANSPORTABLE_01 is:

/oradata/export/expdp/tbs_mvtest.dmp

******************************************************************************

Datafiles required for transportable tablespace TBS_MVTEST:

/oradata/SET/TBS_MVTEST_01.dbf

Job “SYSTEM”.”SYS_EXPORT_TRANSPORTABLE_01″ successfully completed at 16:35:04

[]$ ls -lrt

Test için bu database’ imizdeki tüm dataları oluşturduk ve exportunu aldık, buradaki işimiz TBS_MVTEST tablespace’ ine ait dbf ile alınan exportun dmp file’ ini testin ikinci aşamasını yapacağımız sunucuya taşıdıkdan sonra burayla işimiz kalmıyor.

– Yeni ortamda expdp dizininioluşturalım

CREATE OR REPLACE DIRECTORY expdp AS ‘/oradata/export/expdp’ ;

– yetkilerini verelim

GRANT READ,WRITE ON DIRECTORY expdp TO system;

– dbf’ i ait olduğu dizine OS komutları ile taşıdığımızdan dolayı artık meta datayı import edebiliriz

impdp system/oracle TRANSPORT_DATAFILES=’/oradata/export/expdp/TBS_MVTEST_01.dbf’ DIRECTORY=expdp DUMPFILE=tbs_mvtest.dmp LOGFILE=imp_tbs_mvtest.log

– hata aldık, çünkü burada test nesnelerimi oluşturduğumuz KAMIL schemasını create etmeyi unuttuk.(hata aldığım noktaları özellikle belirtmek istiyorum ki aslında bu kısımların hepsinden daha önemli olduğunu düşünüyorum)

[]$ impdp system/oracle TRANSPORT_DATAFILES=’/oradata/export/expdp/TBS_MVTEST_01.dbf’ DIRECTORY=expdp DUMPFILE=tbs_mvtest.dmp LOGFILE=imp_tbs_mvtest.log

Import: Release 11.2.0.1.0 – Production on Thu Mar 10 16:49:57 2011

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  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

Master table “SYSTEM”.”SYS_IMPORT_TRANSPORTABLE_01″ successfully loaded/unloaded

Starting “SYSTEM”.”SYS_IMPORT_TRANSPORTABLE_01″:  system/******** TRANSPORT_DATAFILES=/oradata/export/expdp/TBS_MVTEST_01.dbf DIRECTORY=expdp DUMPFILE=tbs_mvtest.dmp LOGFILE=imp_tbs_mvtest.log

Processing object type TRANSPORTABLE_EXPORT/PLUGTS_BLK

ORA-39123: Data Pump transportable tablespace job aborted

ORA-29342: user KAMIL does not exist in the database

Job “SYSTEM”.”SYS_IMPORT_TRANSPORTABLE_01″ stopped due to fatal error at 16:50:02

– userı create edip importu tekrar deniyoruz

create user KAMIL identified by oracle

User created

– user ile ilgili bir yetki problemine takılmamak için dba yetkisi veriyorum

grant dba to kamil

Grant succeeded

– import ediyoruz

[]$ impdp system/oracle TRANSPORT_DATAFILES=’/oradata/export/expdp/TBS_MVTEST_01.dbf’ DIRECTORY=expdp DUMPFILE=tbs_mvtest.dmp LOGFILE=imp_tbs_mvtest.log

Import: Release 11.2.0.1.0 – Production on Thu Mar 10 16:52:03 2011

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  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

Master table “SYSTEM”.”SYS_IMPORT_TRANSPORTABLE_01″ successfully loaded/unloaded

Starting “SYSTEM”.”SYS_IMPORT_TRANSPORTABLE_01″:  system/******** TRANSPORT_DATAFILES=/oradata/export/expdp/TBS_MVTEST_01.dbf DIRECTORY=expdp DUMPFILE=tbs_mvtest.dmp LOGFILE=imp_tbs_mvtest.log

Processing object type TRANSPORTABLE_EXPORT/PLUGTS_BLK

Processing object type TRANSPORTABLE_EXPORT/TABLE

Processing object type TRANSPORTABLE_EXPORT/COMMENT

Processing object type TRANSPORTABLE_EXPORT/MATERIALIZED_VIEW

Processing object type TRANSPORTABLE_EXPORT/POST_INSTANCE/PLUGTS_BLK

Job “SYSTEM”.”SYS_IMPORT_TRANSPORTABLE_01″ successfully completed at 16:52:16

Aslında tüm işimiz bitti, şimdi kontrol edebiliriz.

select owner,segment_name, tablespace_name from dba_segments

where owner = ‘KAMIL’

OWNER               SEGMENT_NAME                           TABLESPACE_NAME

KAMIL                  SESSION_LOG                                    TBS_MVTEST

1 rows selected

Yukarıdaki script ile MV’ ye ait tablo geldi ancak hemen belirteyimki refresh statüleri update olmadığından yani onlar tablo ile taşınmadığından güncellenmeyecek, dolayısıyla buna artık MV demek yanlış olacaktır.

– synonym’ e bakalım, oda yok.

select * from dba_synonyms

where synonym_name = ‘TESTER’

0 rows selected

– dblink control ediyorum, maalesef oda yok J

SELECT

‘create ‘||DECODE(U.NAME,’PUBLIC’,'public ‘)||’database link ‘||CHR(10)

||DECODE(U.NAME,’PUBLIC’,Null, 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#

and u.name = ‘KAMIL’

0 rows selected

Tabi ben burda zaten transportable tablespace’ in olumsuz yönlerini belirtmek istediğim için seçerek bunları gösterdim. Zira kafanızda bu yöntem zaten hiç birşeyi taşımıyormuş gibi algı oluşturmak istemem.

Testin yöntem ile ilgili bazı soru işaretlerini umarım silmenize yardımcı olmuştur.

Bir başka yazıda görüşmek dileğiyle,

Salı, 05 Nisan 2011 23:02

Oracle İnitial Parametreleri

Oracle da database’ ini startup ile açmaya kalktığımız da instance ilk iş olarak parametre dosyasını okumaya çalışacaktır. Dolayısıyla temel initial parametrelerinden bahsederken bizim için çok kritik file’ lerimizden biri olan spfileSID.ora dosyasından da kısaca bahsedeceğiz.

Parametre dosyaları Linux’ da;  $ORACLE_HOME/dbs,  Windos’da $ORACLE_HOME/database  altında bulunur. Database create edilmesiyle birlikte spfileSID.ora dosyamızda oluşur.  Bunun yanısıra parametre değişikliğini database içirisinden Alter system veya Alter database ile yapmak istemediğimiz veya yapamadığımız durumlarda ise kullandığımız birde pfileSID.ora dosyamız olacaktır.

Salı, 05 Nisan 2011 20:29

Global Temporary Table Oluşturmak

Oracle’ da tablo create ederken eğer tablonun tipinibelirtmez iseniz default olarak ilişkisel ve kalıcıolarak tablonuzu oluşturacaktır. Create table komutunuziçerisinde global temporary ifadesini kullanırsanıztemporary segmentlerde tutacağınız geçici bir tablocreate etmiş olursunuz. Temporary tabloları normal tablolardan çok farklı olarak düşünmemek gerekir, bildiğimiz yöntem (create table ile ) ile create etmişolduğunu tablolar üzerinde neler yapabiliyorsanız burada da yapabilirsiniz. Temporary olmasından kaynaklıolarak, temporary olarak create edilmiş bir tablo tümsessionlar tarafından görülebilir ve sadece o sessioniçerisinde varlığını idame ettirir, session sonlandığındatemporary table’ da otomatik olarak drop olacaktır.

Cumartesi, 02 Nisan 2011 11:26

Canlı Bir Transportable Tablespace Operasyonu

19 Mart 2011Canlı Bir Transportable Tablespace Operasyonu Yazılarımdan da anlaşılacağı üzere bu aralar transportable tablespace’ le yakından ilgileniyorum. Bu konudaki yapmış olduğum tüm testleri ve production ortamlarımızda yapmış olduğumuz operasyonlarla ilgili detaylarıda sizinle buradan paylaşmaya çalışıyorum.  Şimdiye kadar tranportable tablespace ile ilgili çalışma mantığından, kıstlarından bahsettik. Neden bu konu üzerine bu kadar yoğunlaştığımdan bahsedeyim, ileride sizlerde benzer bir durumla karşılaşırsanız diğer yöntemler ile karşılaştırmada yardımcı olacaktır. Production ortamda kullandığımız bazı database’ lerimizi yeni alınmış olan (yeni sunucu ibm p795 serisi) sunucular üzerine taşımaya çalışıyoruz. İlk taşınacak olan database yaklaşık 3 tb  büyüklüğündeki bir database,  bu database’ i migrate etme işini bitirdik. Bugün bu taşıma işlemini transportable tablespace yöntemi kullanarak nasıl yaptığımızdan step by step bahsedeceğim ;  (Şunu belirtmemde fayda aşağıdaki stepler bizim taşımış olduğumuz database’ in özellikleri ile şekillenmiş adımlar yani bu database’ de materialized view yoktu, eğer olsaydı bir stepde bunun için olacaktı)

 • Öncelikle yeni sunucu üzerine db block size, nls ayarları ve sid’ i eski sunucu ile aynı olacak şekilde boş bir instance create edilir. (transportable tablespace gereği) 

 
Sys, ve system dışında SYSTEM tablespace’ inin altında user nesnesi olmaması gerekiyor. (system, sysaux, undo, temp gibi tbs’ ler taşınmayacağından dolayı)

 select owner,segment_name,segment_type, tablespace_name,bytes/1024/1024 boyut from dba_segments where tablespace_name = 'SYSTEM'and owner in (select distinct(owner) from dba_segments where tablespace_name = 'SYSTEM' and owner not in('SYS','SYSTEM','OUTLN') )


Taşınacak olan database’ deki tüm tablespace’ lerin aralarındaki ilişkiler check edilir.  Database’ i full olarak taşıdığımızdan dolayı UNDO, TEMP, SYS, SYSAUX şemalarını hariç geri kalan tüm schemaları taşıyoruz.  (Ben  tüm örneklerdeki tablespace isimlerini değiştirerek yazıyorum) Buradaki amaç bu tablespace’ lerin taşınmayacak olan yukarıda belirtilen  diğer tablespace’ ler ile herhangi bir ilişki olmaması.

 EXECUTE DBMS_TTS.TRANSPORT_SET_CHECK('USERS,DENEME,PROD', TRUE);

Procedur çalıştıkdan sonra aşağıdaki select ile kontrol ediyoruz. Sonucun no rows dönmesi gerekiyor. Eğer kayıt dönerse farklı tablepsace’ lerdeki nesneler olması gereken tablespace üzerine taşınır. (nesnelerin nasıl taşınabileceğini daha önceki yazılarından bulabilirsiniz)

 • İlişkileri test ettikden sonra transportable backup’ a hazırlık için expdp alınacağı directory oluşturulur. 
CREATE DIRECTORY  expdp AS '/s4/META_DATA_ISLEM';GRANT READ,WRITE ON DIRECTORY expdp TO SYSTEM;


Atlanmaması gereken bir önemli nokta transportable backup alınmadan önce mutlaka dba_recyclebin purge edilmelidir. Sql>Purge dba_recyclebin;

 • Backup öncesinde taşınacak olan tüm tablespace’ ler read only moda alınır. select 'alter tablespace '||name|| ' read only;' from v$tablespacewhere name not in('SYS','SYSTEM','UNDOTBS1','TEMP','SYSAUX')

Transportable export backupı alınır. expdp "'/ as sysdba'" directory=DWDATA_TT_EXPORT dumpfile=DWDATA_TT_EXPORT.dmp logfile=DWDATA_TT_EXPORT.log transport_tablespaces=USERS,DENEME,PROD

Package, sysnonym, link vs gibi nesnelerin diğer ortama taşınması içinde (bunların scriptleride alınıp manuel diğer tarafa atılabilir ancak private linkleri create  edebilmek için  private linki olan userların şifrelerini bilmeniz gerekir)  no rows  dump alıyoruz.  (burada no rows tablolarında ddl exportunu alacaktır,  bunlar için bir aksiyon almazsanız TABLE ACTION EXIST opsiyonu skip olduğundan var olan tabloyu görüp hata verip devam edecektir.

 Şunu da yapabilirsiniz EXCLUDE=TABLE derseniz tablolara hiç bakma geri kalanı import et de  diyebilirsiniz ki bu mantıklı bir seçim diye düşünüyorum ) Bununla ilgili bir not, exportu schema vermeyip full alıp diğer tarafa schema bazında atabilirsiniz. Atlama olma ihtimalini ortadan kaldırmak için faydası olacaktır.

 Böylelikle ihtiyaç halinde exportu sonrasında tekrar kullanabilirsiniz.expdp "'/ as sysdba'" DIRECTORY=expdp DUMPFILE= metadata_15032011.dmp LOGFILE=metadata_15032011.log  CONTENT=METADATA_ONLY  FULL=Y

Yine bir not, eski ortamda datafile’ lerinizi yeni ortamdaki path’ e taşırken datafile isimlerinizi mutlaka kontrol etmelisiniz, farklı dizinlerde aynı isimle yer alan datafile’ leriniz olabilir, Bunları migration öncesinde rename ile düzeltmeniz faydanıza olacaktır.  (eğer tüm datafile’ leri diğer tarafda aynı lokasyonda tutacaksanız) 

Datafile’ lerin taşınması için OS tarafı için CP scriptlerini oluşturmamız gerekiyor. 
V$datafile’ den name kolonundan datafile’ lerin adı ve pathleri alındıkdan sonra yazılacak bir scp veya rcp komutu ile bu adım yapılabilir. 

Oracle’ ın internel userları haricindeki tüm userlara ait create scriptleri,  role’ lerin create scriptleri oluşturulacak. (Buradan alınacak olan userların default tablespace’ leri not alınır, diğer tarafa create edildiği aşamada tablespace ‘ ler olmayacağı için tüm userların default tablespace’ ini USERS yapıp, işlem bittikden sonra eski haline geri alabilirsiniz. Create scriptleri için toad’ ın generate schema script menüsünü kullanabilirsiniz.  Deafult tablespace’ leri değiştirmek ve eskisinin backupını almak içinse aşağıdaki scriptleri kullanabiliriz.Default tablespace’ leri değiştirmek için; select 'alter user '||username|| ' default tablespace USERS;' from dba_users; Eskisindeki durumu backuplamak için (diğer tarafda işlem bittikden sonra userların default tablespace’ leri orijinal hallerine çevrilmelidir); select 'alter user '||username|| ' default tablespace '||default_tablespace|| ';' from dba_users

 • Eski sistemdeki public dblinkler ile public synonym’ lere ait create scriptleri oluşturulacak. (toad burda da kullanılabilir)

Eski sunucudaki tnsnames.ora dosyasındaki diğer database’ lere ait aliaslar değiştirilmeden diğer tarafa da kopyalanacak. (dblinklerde problem çıkmaması için)Buraya kadar ki olan kısımlar, yapılacak migration öncesinde yapmamız gereken ön hazırlıklardı.

Şimdi operasyona başlıyoruz ;

 • Yeni ortama role’ leri (içleri boş olacak şekilde oluşturuyoruz. Burada henüz hiçbir obje olmadığı için zaten oluşturamayız, ancak create user scriptlerinde role’ lerde olduğundan hata vermemesi için bunları baştan oluşturuyoruz) 

Profile’ leri create ediyoruz. 

Userları create ediyoruz. 

Datafile’ leri taşıyoruz. 

Datafile taşımaları bittikden sonra almış olduğumuz transportable exportu yeni ortama import ediyoruz. impdp system directory=META_DATA_ISLEM dumpfile=DWDATA_TT_EXPORT.dmp logfile=IMP_DWDATA_TT_EXPORT.log  transport_datafiles=/s1/users01.dbf,test01.dbf,prod01.dbf • İmport bittikden sonra no rows exportun importuna geçmeden önce public db linkler ile public synonym’ leri burada create ediyoruz. 

No rows exportu import ediyoruz. 

Artık tablespace’ lerimizi read write moda geri alabiliriz.Normal şartlar altında işimiz bu kadar, artık kontrollerimize başlıyabiliriz. • Yeni sunucunun ip’ si farklı olacağından (tabi diğer sunucuyu kapatıp onun ip’ sini yeni sunucuya vermediyseniz)  diğer sunuculardaki tnsnames.ora dosyalarındaki taşıdığımız instance’ a ait ip (veya hostname hangisini kullanıyor iseniz) bilgisini yenisi ile değiştirmemiz gerekecektir. 

Tüm userların eski ortamda default tablespace’ i ne ise burada da aynısı yapılır. (yukarıda bunun backup scriptini oluşturmuştuk zaten)  

Grantlar kontrol edilir. Eski ortam ile karşılaştırılır. 

User create aşamasından hata almamak için rolleri boş olarak create etmiştik, şimdi o rollerin içini dolduruyoruz.

Burada yapılacak en önemli testi en sona sakladım. Önce user bazında nesne sayılarını her iki ortamda karşılaştırıyoruz. Yenisinde eksik olmamalı. select owner, count(*) from dba_objects  group by owner  order by 1 ;• User bazında yaptığımız karşılaştırmada nesne sayıları eksik çıkan user var ise sadece bu userlar için object type’ ı bazında hangi nesnelerin eksik olduğuna bakılmalıdır. Neden o objenin eksik olduğu araştırılabilir. Eski ortamdan create scripti hazırlanıp yeni ortamda basılarak eksik nesneler tamamlanır. select object_type,count(*) from dba_objects  where owner = ‘NESNESI_EKSIK_OLAN_USER'   group by object_type  order by 1 ;Aslında kontroller sonrasında problem olmadığını düşündüğünüz anda artık yeni sunucu üzerinden database’ imizi diğer kullanıcılara açabiliriz. Bu işlemin süresini etkileyen en önemli kriter database’ inizin büyüklüğü ve iki sunucu arasındaki network bağlantısı olduğunu söyleyebilirim. Zira biz yaklaşık 3 tb’ lik bir database’i bu yöntemle (kontroller dahil)  2,5 saat gibi bir sürede bitirebildik. 

Mihration çalışmalarımız son hızıyla devam ediyor, taşınacak bir sonraki database’ imiz yaklaşık 6 tb, en son Prod database’ imiz ise 19 tb büyüklüğünde, orda da farklı bir durumla karşılaşır isem buradan sizlerle paylaşacağım.

Perşembe, 31 Mart 2011 06:20

Oracle İnitial Parametreleri

Oracle da database’ ini startup ile açmaya kalktığımız da instance ilk iş olarak parametre dosyasını okumaya çalışacaktır. Dolayısıyla temel initial parametrelerinden bahsederken bizim için çok kritik file’ lerimizden biri olan spfileSID.ora dosyasından da kısaca bahsedeceğiz. Parametre dosyaları Linux’ da; $ORACLE_HOME/dbs, Windos’da $ORACLE_HOME/database altında bulunur. Database create edilmesiyle birlikte spfileSID.ora dosyamızda oluşur. Bunun yanısıra parametre değişikliğini database içirisinden Alter system veya Alter database ile yapmak istemediğimiz veya yapamadığımız durumlarda ise kullandığımız birde pfileSID.ora dosyamız olacaktır. Bu dosya db create operasyonu sonrasında oluşmaz, bunu create etmek için sql satırında; Create pfile from spfile; Komutunu çalıştırmamız yeterli olacaktır. Hazır yeri gelmişken bu dosya arasındaki farklardan bahsedelim; Pfile, bir metin dosyasıdır ve bir edit edilebilir. Spfile direk olarak düzenlenemez. Pfile’ de yapılan değişikliklerin etkin hale gelmesi için database’ i restart etmek gerekir. Spfile üzerinde yapılan değişikliklerin birçoğu hemen etkin hale gelir. Pfile’ den spfile, spfile’ den pfile oluşturulabilir. Pfile create etmek için; create pfile from spfile, spfile create etmek içinse create spfile from pfile komutunu kullanabiliriz. Bir farkda dosya isimlerinde var, pfile’ in ismi init(instane_name).ora, spfile’ in ismi ise spfile(instance_name).ora ‘ dır. Çok kullanılan bazı başlangıç parametrelerinin ne olduğunu açıklamaya çalışalım. Aşağıdaki parametrelerin bazıları 11g ile yeni gelmiş olan parametrelerdir. Dolayısıyla 10g versiyonlarında göremiyor olabilirsiniz. (Aşağıdaki notlarım uzun bir zaman aralığında oluşmuştur, bir çoğu oracle dökümantasyonlarından, kişisel tecrübelerden bir kısmı ise kimi net sayfalarından derlenmiştir.) Cluster_database : Real Application Clustersı etkin belirten Real Application Clusters parametresidir. Default değeri false’ dir. True yada False olarak 2 değer alabilir. Modify edilemez. Compatible : Size Oracle’ ın yeni sürümünü kullanmaya izin verir, aynı zamanda geriye doğru bir önceki sürümü ile uyumluluk sağlamayı. Eğer daha önceki sürümden geri dönmek gerekirse bu parametre gerekli ve yeterli olacaktır. Control_files : Database’ in yapısını (veritabanı adını, create edilme zamanını, redologların ve datafile’ lerin adını ve lokasyonunu tutan kontrol dosyaları vardır. Control file denetim dosyaları bir veya daha fazla olabilirler, virgülle birbirinden ayrılarak belirtilirler. Minumum 1 ile 8 tane arasında olabilirler. Lokasyonunu belirtir. Db_block_size: Default değeri 8192 byte’ dir. 2048 ile 32768 byte arasında değer alabilirler. Basic parametredir. DB_BLOCK_SIZE Oracle veritabanı blok boyutunu (bayt olarak belirtir. Tipik 4.096 ve 8.192 bulunmaktadır. Bu parametrenin değeri aygıtı düzeyinde fiziksel blok boyutu katları olmalıdır. Bu değer, database create edilirken karar verilir. Db_create_file_destination: Oracle data file’ lerin varsayılan konumunu belirtir. Bu lokasyon DB_CREATE_ONLINE_LOG_DEST_n parametresi set edilmemişse control files ve redo log larında lokasyonunu belirtir. Dizinin, Oracle kulanıcısının dosyalarını oluşturması için gerekli izinlere sahip olması gerekir. Oracle fileleri uniqe nameler ile dosyaları create eder. Alter system set db_create_file_dest = ‘/u01/oradata’; Create tablespace tbs_1; Db_create_online_log_dest_n: DB_CREATE_ONLINE_LOG_DEST_n (burada = 1, 2, 3, ... 5)varsayılan default konumu, control files ve redol logların konumunu belirler. İlgili tüm dosyalar DB_CREATE_ONLINE_LOG_DEST_n deki tanımlı tüm pathlere multipexlenir. En az iki parametre belirlemek, denetim dosyaları için daha fazla hataya dayanıklılık sağlar ve eğer bir lokasyonda problem olursa fail durumu olmaz. Db_domain : Dağıtılmış bir veritabanı sisteminde, DB_DOMAIN ağ yapısı içinde veritabanının mantıksal konumu belirtir. Bu parametreyi ayarlamak gerekir eğer dağıtılmış bir sistemin parçası olacaksa. Değeri küresel bir veritabanı adının uzantısı bileşenleri, geçerli tanımlayıcılar oluşan, dönemlere ayrılmış oluşur. Oracle sizin belirttiğiniz DB_DOMAIN adı için etki alanındaki tüm veritabanları için benzersiz öneri sunar. Nls_language : NLS_LANGUAGE veritabanının varsayılan dilini belirtir. Bu dil mesajları, gün ve ay adları, AD, BC, am, pm ve semboller için kullanılır. Bu parametre de parametreleri NLS_DATE_LANGUAGE ve NLS_SORT varsayılan değerler belirler. Nls_territory : NLS_TERRITORY gün ve hafta numaralandırma için takip edilecek olan sözleşmeler olan bölgenin adını belirtir. Bu parametre de varsayılan tarih biçimini belirler, varsayılan ondalık karakter ve grup ayırıcı ve varsayılan ISO ve yerel para birimi sembolleri. Open_cursors : (özel SQL alanlara) Bir defada sahip olabilecek açık imleçler sayısını belirtir. Size, cursors sayısının fazla oturum açmasını engellemek için bu parametreyi kullanabilmenize olanak sağlar. OPEN_CURSORS değeri yüksek olması, uygulamaların out of open cursor hatası almasını engeller. Job_queue_processes : JOB_QUEUE_PROCESSES bu işlerin yürütülmesi için oluşturulabilir süreçlerinin sayısını belirtir. Bu iş sıra sayısını belirtir örneği (her J000, J999 ...) işler. Çoğaltma veri yeniler için iş kuyruklarını kullanır. Gelişmiş kuyruk mesaj yayılması için iş kuyruklarını kullanır. Sen DBMS_JOB paketi üzerinden kullanıcı jobları, luşturabilirsin.Bazı iş kuyruğu kişi, otomatik olarak oluşturulur. materialized views için örnek yenileme desteklemektedir. Eğer materialized views otomatik olarak güncellemek istersen, bir veya daha yüksek bir değere JOB_QUEUE_PROCESSES ayarlamanız gerekir. Processes : SÜREÇLER işletim sistemi kullanıcı sayısını belirtir aynı anda Oracle bağlanabilecek sayıyı ifade eder. Değer tüm arka plan processleri için locklar, iş kuyruk süreçleri, ve paralel yürütme süreçleri gibi süreçleri izin vermelidir. Remote_listener : REMOTE_LISTENER ağ adı bir adres veya Oracle Net uzak dinleyici adresini listesine çözümler (yani, listener aynı makinede bu örnek olarak yayınlanmıyor) belirtir. Adresi veya adres listesi sistem için yapılandırılmış olarak TNSNAMES.ORA dosya veya diğer adres deposu belirtilir. Rollback_segments: ROLLBACK_SEGMENTS adıyla bir veya daha fazla rollback segmentini allocate eder. Eğer bu parametre set edilirse, instance rollback_segments adıyla tüm segmentleri kazanır. (İŞLEMLER / TRANSACTIONS_PER_ROLLBACK_SEGMENT olarak hesaplanır.) Dinamik olarak bu parametrenin değerini değiştirmek mümkün değil, ancak değerini değiştirebilir ve sonra instance’ ı yeniden başlatabilirsiniz. Ancak bu parametre genellikle özel rollback segment belirtir, aynı zamanda kullanılmıyorlarsa public geri alma segmentleri belirtebilirsiniz. Database içerisinde adı, segmentID numberı, rollback segmentin statüsü ve DBA_ROLLBACK_SEGS view’ i ile ile bulunabilirler. Undo_management : Alan yönetimi konusunda hangi sistemi kullanmalıyımı belirtir. Parametre Auto olarak set edildiğinde, instance start olduğunda undo management modu atomatic olarak devreye girer. Mauel olarak set edildiğinde ise, rollback segment alanları harici olarak tahsis edilir. Undo_tablespace: Undo Tablespace’ i, instance start oldukdan sonra, kullanılmak üzere ayırır. Bu parametre, instance’ da manuel undo management modda ise, sonrasında hata oluşur ve startup işlemi başarısızlıkla sona erer. Kullanılabilir bir Undo Tablespace’ I yoksa, instance undo tablespace alanı olmadan start olur. Bu gibi durumlarda, user transactionları sistem rollback segmentini kullanarak çalışırlar. Normal şartlar altında bu modda çalışmakdan kaçınmalısınız. Database çalışırken undo tablespace’ ini başka bir undo tablespace ile replace edebilirsiniz. Undo_guarantee : Undo tablespace içerisinde belli bir süre mutlaka dataların tutulmasını sağlar. Alter tablespace undo_guarantee retention guarantee; Alter system set undo_tablespace = undo_noguarantee ; Alter system set undo_tablespace = undo_ guarantee ; ALTER SYSTEM SET UNDO_RETENTION = 3600 Db_block_size : Database create edilirken set edilir. Sonradan değiştirilemez. Database’ deki blockların size’ ını ifade eder. Db_create_online_redo_dest_n: Redologların create ederken default olarak nereye oluşturulacağının bilgisi yer alır. Control_file_record_keep_time : Control filede dosyaların saklanma süresini belirtir.Bu parametre 7 ile 365 arasında bir değer alabilir. (default değeri 7’ dir) remote_os_authent : Bu parametre FALSE ise uzaktan password file dosyası olmadan sysdba ile bağlanamazsın demek. Remote_login_password_file : Uzakdan bağlanmak için gereken parametre Default değeri EXCLUSIVE dir. Parametre dosyası kaybolduğunda bu değer NONE’ a çekilip dosya create edilip tekrar EXCLUSIVE’ e alınması gerekmektedir. Alter system set remote_login_password_file=EXCLUSIVE scope=spfile; Background_dump_dest : Alert logun pathini verir. alter system set background_dump_dest = 'D:\orcl rman backup\' scope=both (alert logun adı = alert_(db_sid).log şeklinde oluşur.) 07_dictionary_accessibility : Select any table yetkisi olan userın data dictionaryi görmemesi için bu parametre = FALSE olmaldır. Log_archive_dest_1 (dest) : Archive logların nerede tutulacağının bilgisinin set edildiği parametre. log_archive_start : Otomatik arşivlemenin doğrudan yapılıp yapılmayacağını gösterir. Buna true demezseniz zaman zaman svrmgrl’ye bağlanarak log archive start diyerek, arşiv dosyalarını yazma işlemini elle kontrol etmeniz gerekir ki bu genelde önerilmez. Ama tape gibi farklı bir yere zaman zaman arşivlemek için bu yöntemi kullanabilirsiniz. B u parametre oracle 10g ile birlikte deprecated olmuştur. log_archive_format : Üretilecek arşiv dosyalarının yazılma biçimini gösteriyor.%s ile logların sıra numarasını .arc ile de uzantısı belirlenebilir. (%s.arc)  • %s: log sequence number • %S: log sequence number, zero filled • %t: thread number • %T: thread number, zero filled • %d: DBID Log_archive_max_processes : Archive process sayısı bu parametre ile set edilir. ALTER SYSTEM SET log_archive_max_processes = 4 SCOPE=SPFILE Db_flashback_retention_target : Veritabanını kaç dakika geriye alabileceğinizin set edildiği parametre. alter system set db_flashback_retention_target=60 scope=memory; Db_recovery_file_dest_size : Yedek işlemleri için ayrılan alanının size’ nın set edildiği parametre. ALTER SYSTEM SET Db_recovery_file_dest_size = 35G SCOPE=SPFILE Db_recovery_file_dest : Flashback bilgisinin nerede tutulacağı bilgisinin set edildiği parametre. Aynı zamanda default backup dizinidir. alter system set db_recovery_fıle_dest ='d:/orcl_backup' scope=both; select * from v$recovery_fıle_dest; Db_block_checking : Db data blocklarında corruption oluşmasını önler.(değer true yapılırsa %10’ lar civarında memory kaybı oluşur) Db_block_checksum : Db corruption oluşmasını engeller, veriyi datafile’ e yazarken çift kontrol yapar. (değer true yapılırsa I/O da %1-2 civarında artış olur.) Db_keep_cache_size : Buffer cache’ in keep alanının size’ ı set edilir. alter system set db_keep_cache_size = 50M scope=MEMORY; Db_recycle_cache_size : Buffer cache’ in recyclebin alanının size’ ı set edilir. alter system set db_recycle_cache_size= 10M scope=MEMORY; Db_cache_size : Buffer cache’ in default alanının size’ ı set edilir. Shared_pool_size : Shared pool’ un size’ ı set edilir. Large_pool_size : Large pool’ un size’ ı set edilir. Java_pool_size : Java pool’ un size’ ı set edilir. Streams_pool_size : Streams pool’ un size’ ı set edilir. Sga_max_size : Sga atanmış olan kullanılabilecek alanı ifade eder. Sga_target : Sga’ nın kullanılabileceği alanı ifade edebilir. Bu değer sga_max_size değerinden büyük olamaz. ALTER SYSTEM SET sga_max_size = 16000M SCOPE=SPFILE; ALTER SYSTEM SET sga_target = 15000M SCOPE=SPFILE ; Pga_aggregate_target : Pga alanına atanan memory alanını ifade eder. Statistics_level : Sistem tarafından toplanan istatistiklerin nasıl toplanacağının set edildiği parametredir. 3 değer alabilir. BASIC; Datanın istatistiğini almaz. Dolayısıyla bu değer set edilmişken ADDM çalışmaz. TYPICAL; default değerdir.segment seviyesinde istatistikleri alır. ALL; operating systeminde istatistiğini alır. Sisteme yük getirir. ALTER SYSTEM SET statistics_level=all Open_cursors : Bir sessionın aynı anda kaç tane select çalıştırabileceğini belirtir. (default değeri 300) Alter system set open_cursors=350; User_dump_dest : user trace dosyalarının pathi burda yer alır. fast_start_mttr_target : Database’ e checkpoint attırma zamanı (değer saniye cinsinden) ALTER SYSTEM SET fast_start_mttr_target = 900 db_writer_processes : Databasede ki db writer procecessinin kaç adet olduğunu bilgisini bu parametreden alır. *.db_writer_processes=1 audit_sys_operations : Database’ in izlenmesi sürecinde Sys userının da denetlenip denetlenmeyeceğini gösteren parametredir. Defaultu FALSE’ dir. audit_file_dest : sysnin auditlenmesi durumunda sys audit kayıtlarının yerini belirtir. Windows da windows application log’ larda, linuxda audit_file_dest parametresine bakar. log_archieve_start : otomatik archive alma parametresidir. İnit.ora dosyasında değeri log_archieve_start=true şeklinde set edilmelidir. Noarchivelog modunda çalışan bir db için bu parametre init.ora dosyasında olmaması gerekmektedir. open_links : OPEN_LINKS uzak veritabanlarına tek oturumda aynı anda açık bağlantı sayısını belirtir. (deafult’ u 4. static bir parametre olduğundan değiştirildiğinde db restart etmek gerekir.) Statistic_level : AWR’ ın çalışmasını sağlayan parametredir. 3 değer alabilir. Defaultu Typical’ dır. All ve Basic’ de olaiblir. Basic olduğunda AWR devredışı kalır. alter system set statistics_level = all; Control_management_pack_acces : Addm’ in çalışması için gereken parametredir. Diadnostic+ tuning default değeridir.Diagnostic veya None olarak da set edilebilir. None olması durumunda ADDM devredışı kalır. remote_dependencies_mode ; İki değer alabilir. timestamp, Clientın istediği procedure ancak serverdaki kayıt tarihi ile, localdeki şimdiki tarih ile uyuşursa çalıştırılır. signature, oracle, bir procedure'nin imzalarının güvenli olarak göz önüne alınmış olması durumunda çalıştırılmasına müsade eder. Bu ayar, PLSQL uygulamalarının tekrar compile edilmeden çalıştırılmasını sağlar. Alter session SET REMOTE_DEPENDENCIES_MODE = ( SIGNATURE / TIMESTAMP ) Alter system SET REMOTE_DEPENDENCIES_MODE=( SIGNATURE / TIMESTAMP ) Ddl_lock_timeout : Ddl işlemlerinde oluşaacak lock’ lardaki bekleme süresini ifade eder. Defaultu “0”. Bu parametre 0 ile 100.000 arasında değer alabilir. system ve session bazında değiştirilebilir. Alter system set ddl_lock_timeout = 10 scope = SPFILE max_dump_file_size : Oluşan trace dosyalarının maximum ne kadar boyutta olacağını belirtir. (bu maximum size sınırlaması alert logu kapsamaz.) alter system set max_dump_file_size = ‘5m’; aq_tm_processes : Parametre enable edildiğinde queue mesajlarının monitör edilmesini sağlar. 0 – 10 arasında değer alır. 0 olduğunda disable olur. Eğer oracle stream kullanılıyorsa bu parametrenin 0 olarak set edilmesi başka problemlere yol açılacaktır. Oracle bu değerin 0’ dan bir değer olarak set edilmesini öneriyor. alter system set aq_tm_processes=0 cursor_sharing : Shared pool içerisinde tutulan sqllerin benzerleri geldiğinde aynı plan ile diğerlerininde çalışıp çalışmayacağının set edildiği parametredir. SIMILAR = Çalışan sql' lerin birebir aynı olmasa da benzeyenler için (execution planlarına da bakar) cache den çalıştırmaya yönlendirir. EXACT = Çalışan sqlerin cache' den çalışması için sorguların birebir aynısı olması gerekmektedir. FORCE = Cache de Çalışan sql lerin benzeri varsa mevcut execeution plan kullanılmasını zorlar ALTER SYSTEM SET cursor_sharing = FORCE SCOPE=MEMORY Utl_file_dir : Bu parametre bir veya daha fazla lokasyonun, oracle tarafından PL/SQL ile kullanılmasını sağlar. Bu parametre ile tüm userlar bu lokasyonlardaki bütün file’ leri okuyup azabilirler. Alter system set url_file_dir=’/u01/file1/’, ‘/u02/file2/’, ‘/tmp’ scope =SPFILE CREATE DIRECTORY log_dir AS '/appl/gl/log'; GRANT READ ON DIRECTORY log_dir TO DBA; CREATE DIRECTORY out_dir AS '/appl/gl/user''; GRANT READ ON DIRECTORY user_dir TO PUBLIC;

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

Sayfa 1 / 2