Oracle upgrade (from 10gR1 – 10gR2 to 11gR2) – 1

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 ….

Be Sociable, Share!

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir


+ 7 = onaltı