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 bi riliş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$tablespace
where 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.
Migration ç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.
