joomla templates Data Warehouse Türkiye

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;

Product Description