
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
Transportable Tablespace Yöntemi ile Taşınamayan Nesneler İle İlgili Bir Test
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,
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.
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.
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.
Oracle İnitial Parametreleri
Oracle upgrade (from 10gR1 – 10gR2 to 11gR2)
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 Kurulumu, Konfigurasyonu ve Kullanımı ...
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.
LOBINDEX ve LOBSEGMENT’ lerin create, move, rebuild edilmesi
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
Database’ in DBID ve DB_NAME Değerini Değiştirmek (dbnewid, nid)
Ö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.
Automatic Workload Repository (AWR) Raporlarının Compare Edilmesi
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