joomla templates Data Warehouse Türkiye

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.

Merhaba arkadaşlar,

Bu yazımda Oracle’ın flashback özelliğini kullanarak değiştirdiğimiz veya sildiğimiz verilere nasıl erişeceğimizi anlatacağım.

Önce örneğimiz için aşağıdaki gibi bir tablo oluşturalım :

Oracle versiyon yükseltilmesi hakkında...

Merhaba,

Oracle versiyonunu yükseltirken en kritik noktalardan birisi belkide her sistemin en kritik varlığı olan "veri"nin taşınmasıdır. Gelin, en baştan başlayalım...

Diyelim veritabanınızın versiyonu 9i ve siz bu versiyonu 10g'ye yükseltmek istiyorsunuz. Peki ilk adım ne olmalı? İlk adım, sahip olduğunuz bütün verinin sağlam bir şekilde yedeğinin alınmasıdır. Bu verinin yediğini RMAN (Recovery Manager) ile almak istemek en doğal hakkınız. Zira incomplete recovery yapabilmeniz için de control file ve spfile yedeği RMAN ile alınabilmektedir. Ancak, burada çok kritik bir nokta vardır. O da RMAN'in sadece aynı Oracle versiyonlarında ve sadece aynı işletim sistemlerinde çalışabilmesi. RMAN'dan alınan yedek, ancak ve ancak belirttiğim sistemi sağlayabilirseniz ayağa kalkacaktır. Onun için de RMAN kullanımını gözden çıkarmalısınız.

Tabii Oracle'da çareler tükenmez. Elimizdeki bir diğer koz ise, "export/import" özelliğidir. Veritabanının "exp" ile komut satırındayken tam yedeğini alalım. Mutlaka hata oluşmadan aldığından emin olalım. Bu aşamada "yaşasın export aldım, hadi 10g'yi kuralım" deyip, hızlı bir adım atmayalım. Çünkü bu aşamadan sonra password file ile spfile'ı da mutlaka export ile birlikte bir yere kopyalayalım. Netice itibariyle, ayağa kalkacak olan veritabanı, halihazırda passwordfile ve spfile'ı aynı olacak bir veritabanı olacaktır.

Oracle Profiles

Bugün, aslında hepimizin çok detaylı bilmesi gerektiği bir konuyu ele almak istedim. Oracle Profilleri. Peki Profil nedir?
Bağlı bütün kullanıcıları yaratırken, öncelikle bir profile belirleriz. Eğer, kullanıcı yaratırken belirtmezsek default profile ile yaratılacaktır. Tabii ki bu şekilde bir sistem oluşturmak son derece sakıncalı olabilmektedir. Profillerin içinde barındırdığı özellikleri sayesinde çoğu zaman oluşabilecek güvenlik açıklarından kurtulabilmekteyiz.
En çok kullanılan kaynakları ise;
CONNECT_TIME : Dakika bazında, sessionlar için kabul edilen bağlantı zamanını düzenler.
alter profile limit connect_time 300;
*** Burada belirtmeliyim ki, profile'a ait bir kaynağı değiştirirken mutlaka "limit" kullanılması gerekmektedir. Sık sık unuttuğum için belirtmem de fayda var :)
IDLE_TIME : En kritiklerinden birisi de idle_time'dır. Adından da anlaşılabileceği gibi, herhangi bir schemaya bağlı bir session'ın hiçbir DML/DDL komutu kullanmadan beklediği süreye denir. Eğer kullanıcı bu süreyi aşarsa, session'ı Oracle tarafından öldürülür. Yine dakika bazında değer verilebilmektedir.
alter profile limit idle_time 10;

Product Description