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.
(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
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;
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%’;
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;
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;.
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
Veritabanı kapatılır.
$ sqlplus /as sysdba
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;
BACKUP DATABASE FORMAT ‘%U’ TAG before_upgrade;
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 ….
