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 ;
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
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
------------------------------ -------------------
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.
(kamil.turkyilmaz@gmail.com ) adresinden iletişime
geçebilir varsa diğer sorularınızı da iletebilirsiniz.
Çalıştırmak için;
$ sqlplus / as sysdba
SQL> @dbupgdiag.sql
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
SQL> @utlrp.sql
Sonra kontrol etmek için dbupgdiag.sql scripti tekrar çalıştırılır.
$ sqlplus / as sysdba
SQL> @ dbupgdiag.sql
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.
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';
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;
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
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
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
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;
Media recovery gereken dosyalar olup olmadığı kontrol edilir.
SELECT * FROM v$recover_file;
Backup modda file olup olmadığı kontrol edilir.
SELECT * FROM v$backup WHERE status != 'NOT ACTIVE';
Tüm bu işlemlerin bitmiş olması gerekmektedir.
Aşağıdaki sorgu ile outstanding distributed transaction var mı diye kontrol
edilir.
SELECT * FROM dba_2pc_pending;
Var ise aşağıdaki işlemler yapılarak bunlar sonlandırılır.
SELECT local_tran_id FROM dba_2pc_pending;
EXECUTE dbms_transaction.purge_lost_db_entry('');
COMMIT;
Aşağıdaki sorgu ile standby veritabanı var mı kontrol edilir.
SELECT SUBSTR(value,INSTR(value,'=',INSTR(UPPER(value),'SERVICE'))+1)
FROM v$parameter
WHERE name LIKE 'log_archive_dest%' AND UPPER(value) LIKE 'SERVICE%';
FROM v$parameter
WHERE name LIKE 'log_archive_dest%' AND UPPER(value) LIKE 'SERVICE%';
Eğer herhengi bir satır dönerse standby
db’yi Primary db ile senkron etmek gerekir. Primary db’deki son log switch’den
sonra tüm loglar standby db’ye taşınıp standby db NODELAY ile özelliği ile
recover edilir.
SYS ve SYSTEM kullanıcılarının varsayılan tbs’i SYSTEM mi diye aşağıdaki
SQL ile kontrol edilir. Bu iki userın default tablespace’ leri system
olmalıdır.
SQL> SELECT username, default_tablespace
FROM dba_users
WHERE username in ('SYS','SYSTEM');
Değil ise aşağıdaki SQL’lerden biri yada
her ikisi de çalıştırılır.
ALTER user SYS default tablespace SYSTEM;
ALTER user SYSTEM default tablespace SYSTEM;
ALTER user SYSTEM default tablespace SYSTEM;
Aud$ tablosu mevcut mu, SYS şemasında mı, ve SYSTEM tbs’inde mi diye
kontrol edilir.
SELECT owner,tablespace_name
FROM dba_tables WHERE table_name='AUD$';
Aşağıdaki komutla RecycleBin komple boşaltılır. Bu sayede ORA-00600
hataları engellenir ve upgrade süresi kısaltılır. Buda atlanmaması gereken bir
adımdır.
PURGE DBA_RECYCLEBIN;
Eski ORACLE_HOME/dbs adresindeki spfile’ın aşağıdaki komutla güncel pfile
hali alınır.
SQL>create pfile=/…/…/init.ora from spfile;
Upgrade öncesinde parametre dosyalarının ve listener.ora, tnsnamez.ora,
sqlnet.ora gibi dosyaların backupının allınması faydalı olacaktır.
Backupı alındıktan sonra initSID.ora dosyası yeni ORACLE_HOME/dbs altına
kopyalanarak içeriği düzenlenmelidir.
Sonra init.ora dosyası yeni ORACLE_HOME/dbs dizinine kopyalanarak içeriği
düzenlenmek üzere açılır.
Obsolete olmuş aşağıdaki parametreler init file içerisinden silinir. 11gR2’
de bu parametreler artık kullanılmamaktadır.
DDL_WAIT_FOR_LOCKS
DRS_START
GC_FILES_TO_LOCKS
LOGMNR_MAX_PERSISTENT_SESSIONS
MAX_COMMIT_PROPAGATION_DELAY
PLSQL_COMPILER_FLAGS
PLSQL_NATIVE_LIBRARY_DIR
PLSQL_NATIVE_LIBRARY_SUBDIR_COUNT
SQL_VERSION
Deprecated olmuş aşağıdaki parametreler varsa silinir.
ACTIVE_INSTANCE_COUNT
BACKGROUND_DUMP_DEST à DIAGNOSTIC_DEST
CORE_DUMP_DEST à DIAGNOSTIC_DEST
USER_DUMP_DEST à DIAGNOSTIC_DEST
COMMIT_WRITE
CURSOR_SPACE_FOR_TIME
INSTANCE_GROUPS
LOG_ARCHIVE_LOCAL_FIRST
PARALLEL_IO_CAP_ENABLED
PLSQL_DEBUG à PLSQL_OPTIMIZE_LEVEL
PLSQL_V2_COMPATIBILITY
REMOTE_OS_AUTHENT
RESOURCE_MANAGER_CPU_ALLOCATION
STANDBY_ARCHIVE_DEST
TRANSACTION_LAG
Yukarıdaki Obsolete ve Deprecated listesi 11gR1 ve 11gR2’ye göre
hazırlanmıştır. Upgrade edeceğimiz db 10gR1 ise 10gR2 için obsolete ve
deprecated olmuş parametreleri de dikkate almamız gerekir. Bunlar şu
şekildedir;
Obsolete olmuş aşağıdaki parametreler varsa komple silinir.
LOGMNR_MAX_PERSISTENT_SESSIONS
MAX_COMMIT_PROPAGATION_DELAY
REMOTE_ARCHIVE_ENABLE
SERIAL_REUSE
SQL_TRACE
Deprecated olmuş aşağıdaki parametreler varsa ya silinir yada
karşılıklarıyla değiştirilir.
ENQUEUE_RESOURCES
Compatible parametresi olduğu gibi bırakılır.
Ayrıca upgrade öncesi kontrol aracında (Pre-Upgrade Information Tool)
bununla ilgili çıkan tavsiyeler dikkate alınır.
Eğer cluster bir db upgrade edilecekse hem bu düzenlediğimiz init.ora
dosyasında hem de açık instance’da CLUSTER_DATABASE parametresi FALSE yapılır.
Upgrade bitince eski haline çekilir.
Aşağıdaki sorgular kullanılarak dbf’lerin, redo log’ların ve control
file’ların adresi alınır.
SQL> SELECT name FROM v$controlfile;
SQL> SELECT file_name FROM dba_data_files;
SQL> SELECT group#, member FROM v$logfile;.
SQL> SELECT file_name FROM dba_data_files;
SQL> SELECT group#, member FROM v$logfile;.
11gR2 veritabanı eski sürüm listener’lar ile çalışmaz. Ancak 11gR2 listener
eski sürüm veritabanlarına destek verir.
Listener, dbconsole ve isqlplus processleri down edilir.
$ lsnrctl stop
$ emctl stop dbconsole
$ isqlplusctl stop
$ isqlplusctl stop
Veritabanı kapatılır.
$ sqlplus /as sysdba
SQL> shutdown immediate;
SQL> shutdown immediate;
Cold backup veya RMAN ile dbf’lerin ve
ctf’lerin yedeği alınır.
Upgrade öncesinde üzerinde çalışılacak
database’ in backupının alınması son derece önemlidir.
Rman ile alınacaksa örnek olarak aşağıdaki script kullanılabilir ;
rman target / nocatalog
RUN
{ALLOCATE CHANNEL chan_name TYPE DISK;
RUN
{ALLOCATE CHANNEL chan_name TYPE DISK;
BACKUP DATABASE FORMAT '%U' TAG before_upgrade;
BACKUP CURRENT CONTROLFILE TO '';
}
BACKUP CURRENT CONTROLFILE TO '';
}
NOARCHIVELOG modda upgrade süresi oldukça kısalacağından db’nin ARCHIVELOG
modda ise bu moda alınması tavsiye edilir. Veya upgrade’ in
bir aşamasında yapılan işlemlerin noarchivelog modunda yapılmasını istermisiniz
diye soruyor bu kısmıda seçerek yolunuza devam edebilirsiniz.
Tabi burada bir zorunluluk yoktur.
Yedek alma işlemlerinden sonra veritabanı ve listener service tekrar
açılır.
Upgrade işlemi esnasında database açık olacaktır.
Oracle upgrade (from 10gR1 – 10gR2 to
11gR2) - 2 ile devam ediyoruz ....
Hiç yorum yok:
Yorum Gönder