Upgrade operayonuna devam 🙂
Yeni ORACLE_HOME/bin adresinden DBUA çalıştırılır.
Listede upgrade etmek istediğimiz database yoksa etc/oratab (/var/opt/oracle altında da olabilir)dosyasında adı geçip geçmediği kontrol edilir.
Daha önceden almadıysak eğer eski database’in yedeğini al seçeneği işaretlenir. DBUA upgrade öncesi database’i kapatarak cold backupını alır. Dbf’lerin yanısıra bunları geri dönmek için gerekli db_name_restore.sh scriptini de oluşturur. (Bu işlemi biz yapmış olduğumuzu varsayarak devam ediyoruz)
Invalid nesnelerin compile edilmesi için paralellik cpu sayısı -1 olarak belirlenir.
Database File’lar move edilmez. (upgrade sonrasında da aynı lokayonda olacaklar)
“Configure the Database with Enterprise Manager” ve “Configure Database Control for local management” seçenekleri işaretlenir.
“Use the Same Password for All Accounts” seçeneği ile DBSNMP ve SYSMAN için yeni şifre belirlenir.
Özet kısmında tüm bilgiler kontrol edilir ve FINISH denilerek upgrade başlatılır.
İşlem bitince sonradan kontrol edilmek üzere logların dizin bilgisi not edilir .
Upgrade olmuş veritabanını asla eski software ile açmamalıyız!!!
Yeni software içindeki executable’lar ile açmalıyız. Bunun içinde aslında profile dosyasını güncelleyip (burdaki path bilgilerini yeni home olacak şekilde set edip) sessionınızı kapatıp tekrar açarsanız problem olmayacaktır.
Not: Upgrade herhangi bir nedenden dolayı kesilirse ve db’yi DBUA ile değil de manuel olarak kendimiz restore edip eski software ile çalışır hale getirirsek bir sonraki upgrade girişiminden önce (yeni)$ORACLE_HOME/cfgtoollogs/dbua/logs/Welcome_SID.txt dosyasını silmemiz gerekir.
Upgrade bittikden sonra ilk iş olarak eski listener’ı kapatıyoruz.
(eski)$ORACLE_HOME/network/admin adresindeki listener.ora dosyası düzenlenerek upgrade olmuş db’ye ait bilgiler silinir.
Unix ortamları için ;
etc altındaki (/var/opt/oracle altında da olabilir) oratab dosyası yeni ORACLE_HOME’u gösterecek şekilde düzenlenir. Eski ORACLE_HOME’a ait kayıt kalmamalı.
#TESTDB:/oracle/10g:N
TESTDB:/oracle/11gR2:N
oratab düzenlenip komut satırında oraenv komutu çalıştırılıp belirttiğimiz SID girilirse doğru ORACLE_HOME’u göstermeli
[oracle@localhost ~]$ . oraenv
ORACLE_SID = [orcl] ? orcl
The Oracle base for ORACLE_HOME=/opt/oracle/product/11.2/db_1 is /u01/app/oracle
[oracle@localhost ~]$
WINDOWS için
C:\> NET STOP OracleService
C:\> ORADIM -DELETE -SID
C:\> ORADIM -NEW -SID -INTPWD 123456 -STARTMODE AUTO -PFILE %ORACLE_HOME%\DATABASE\INIT.ORA
Bir önceki adımdaki tüm işlem ve kontroller, DB cluster ise tüm instance’ların bulunduğu makinalarda yapılır.
DBUA yeni listener’ı ve yeni listener.ora dosyasını yaratmış olmalı. Yeni listener açıksa kapatılır. Sonra listener.ora dosyası düzenlenerek upgrade olmuş db’ye ait bilgi eklenir. Eklenmesi gereken kısım için aşağıdaki örnek verilebilir. Eklenecek paşka parametreler varsa bunlar da eklenir. LOGGING_LISTENER gibi. Sonra yeni listener yeniden başlatılır.
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = TESTDB)
(ORACLE_HOME = /oracle/11gR2)
(SID_NAME = TESTDB)
)
)
LOGGING_LISTENER = ON
Sqlplus veya toad gibi toollarla db connectionı test edilir.
(yeni)ORACLE_HOME/dbs adresinde spfile DBUA tarafından otomatik olarak oluşturulmuş olması gerekiyor, bu kontrol edilir.
(eski)ORACLE_HOME/network/admin adresindeki tnsnames.ora dosyası (yeni)ORACLE_HOME/network/admin adresine kopyalanıri içeriği konrol edilir.
Yeni kurulan software içinde ($ORACLE_HOME/oracore/zoneinfo) aslında 1’den 11’e kadar tüm TimeZone dosyaları vardır. Bu aynı ORACLE_HOME’u kullanan farklı db’lerin farklı TimeZone’lara sahip olabilmeleri içindir. Dolayısıyla TimeZone güncelleme işlemleri her db için ayrı ayrı yapılır.
Bizde upgrade ettiğimiz mevcut veritabanımızı TimeZone 11 versiyonuna yükseltiriz.
Timezone güncellenmesi için yapılacaklar sırasıyla ;
SYSDBA ile aşağıdaki 2 sorgu çalıştırılır ve mevcut db’nin TimeZone versiyonu öğrenilir. İkinci sorguda, DST_UPGRADE_STATE=NONE çıkmalı. Mevcut herhangi bir güncelleme olmadığını gösterir.
SELECT version FROM v$timezone_file;
SELECT PROPERTY_NAME, SUBSTR(property_value, 1, 30) value
FROM DATABASE_PROPERTIES
WHERE PROPERTY_NAME LIKE ‘DST_%’
ORDER BY PROPERTY_NAME;
Güncelleme sonrası etkilenip otomatik olarak çözümlenemeyecek veri olup olmadığı kontrol edilir. Tabi bu kontrol çalışan, canlı bir db’de yapılabilir.
sqlplus / as sysdba
exec DBMS_DST.BEGIN_PREPARE(11)
Aşağıdaki sorgu sonucunda; DST_PRIMARY_TT_VERSION eski DST versiyonunu,
DST_SECONDARY_TT_VERSION yeni DST versiyonunu, DST_UPGRADE_STATE ise PREPARE göstermelidir.
SELECT PROPERTY_NAME, SUBSTR(property_value, 1, 30) value
FROM DATABASE_PROPERTIES
WHERE PROPERTY_NAME LIKE ‘DST_%’
ORDER BY PROPERTY_NAME;
Aşağıdaki log tabloları mevcut iseler truncate edilir ;
TRUNCATE TABLE SYS.DST$TRIGGER_TABLE;
TRUNCATE TABLE sys.dst$affected_tables;
TRUNCATE TABLE sys.dst$error_table;
Güncelleme işleminden etkilenecek verini bilgisi log tablolarına atılır.
BEGIN
DBMS_DST.FIND_AFFECTED_TABLES
(affected_tables => ‘sys.dst$affected_tables’,
log_errors => TRUE,
log_errors_table => ‘sys.dst$error_table’);
END;
/
Güncellemeden etkilenip otomatik olarak çözülemeyecek veri olup olmadığı aşağıdaki sorgu ile öğrenilir. Satır dönmezse sorun yok demektir.
SELECT * FROM sys.dst$affected_tables;
Satır döner ise problem olacak demektir. Ne tür problem olacağı ise aşağıdaki sorgu ile öğrenilir.
SELECT * FROM sys.dst$error_table;
Bu kısımda problem olması durumunda aşağıdaki yol izlenir.
Error Handling when Upgrading Time Zone File and Timestamp with Time Zone Data
There are three major semantic errors that can occur during an upgrade. The first is when an existing time becomes a non-existing time, the second is when a time becomes duplicated, and the third is when a duplicate time becomes a non-duplicate time.
As an example of the first case, consider the change from Pacific Standard Time (PST) to Pacific Daylight Saving Time (PDT) in 2007. This change takes place on Mar-11-2007 at 2AM according to version 4 when the clock moves forward one hour to 3AM and produces a gap between 2AM and 3AM. In version 2, this time change occurs on Apr-01-2007. If you upgrade the time zone file from version 2 to version 4, any time in the interval between 2AM and 3AM on Mar-11-2007 is not valid, and will raise an error (ORA-1878) if ERROR_ON_NONEXISTING_TIME is set to TRUE. Therefore, there is a non-existing time problem. When ERROR_ON_NONEXISTING_TIME is set to FALSE, which is the default value for this parameter, the error will not be reported and Oracle preserves UTC time in this case. For example, “Mar-11-2007 02:30 PST” in version 2 becomes “Mar-11-2007 03:30 PDT” in version 4 as they both are translated to the same UTC timestamp.
An example of the second case occurs when changing from PDT to PST. For example, in version 4 for 2007, the change occurs on Nov-04-2007, when the time falls back from 2AM to 1AM. This means that times in the interval <1AM, 2AM> on Nov-04-2007 can appear twice, once with PST and once with PDT. In version 2, this transition occurs on Oct-28-2007 at 2AM. Thus, any timestamp within <1AM, 2AM> on Nov-04-2007, which is uniquely identified in version 2, will result in an error (ORA-1883) in version 4, if ERROR_ON_OVERLAP_TIME is set to TRUE. If you leave this parameter on its default setting of FALSE, then the UTC timestamp value is preserved and no error will be raised. In this situation, if you change the version from 2 to 4, timestamp “Nov-04-2007 01:30 PST” in version 2 becomes “Nov-04-2007 01:30 PST” in version 4.
The third case happens when a duplicate time becomes a non-duplicate time. Consider the transition from PDT to PST in 2007, for example, where <1AM, 2AM> on Oct-28-2007 in version 2 is the overlapped interval. Then both “Oct-28-2007 01:30 PDT” and “Oct-28-2007 01:30 PST” are valid timestamps in version 2. If ERROR_ON_OVERLAP_TIME is set to TRUE, an ORA-1883 error will be raised during an upgrade from version 2 to version 4. If ERROR_ON_OVERLAP_TIME is set to FALSE (the default value of this parameter), however, the LOCAL time will be preserved and no error will be reported. In this case, both “Oct-28-2007 01:30 PDT” and “Oct-28-2007 01:30 PST” in version 2 convert to the same “Oct-28-2007 01:30 PDT” in version 4. Note that setting ERROR_ON_OVERLAP_TIME to FALSE can potentially cause some time sequences to be reversed. For example, a job (Job A) scheduled at “Oct-28-2007 01:45 PDT” in version 2 is supposed to be executed before a job (Job B) scheduled at “Oct-28-2007 01:30 PST”. After the upgrade to version 4, Job A is scheduled at “Oct-28-2007 01:45 PDT” and Job B remains at “Oct-28-2007 01:30 PDT”, resulting in Job B being executed before Job A. Even though unchained scheduled jobs are not guaranteed to be executed in a certain order, this issue should be kept in mind when setting up scheduled jobs.
Kontrol süreci aşağıdaki komut ile sona erdirilir.
EXEC DBMS_DST.END_PREPARE;
Bittiği aşağıdaki sorgu çalıştırılarak öğrenilir. DST_PRIMARY_TT_VERSION eski DST versiyonu, DST_SECONDARY_TT_VERSION 0, DST_UPGRADE_STATE NONE olmalıdır.
SELECT PROPERTY_NAME, SUBSTR(property_value, 1, 30) value
FROM DATABASE_PROPERTIES
WHERE PROPERTY_NAME LIKE ‘DST_%’
ORDER BY PROPERTY_NAME;
UPGRADE(dikkat bu işlemde veri güncellenecektir)
Bu işlem RAC’ta yapılıyorsa db’nin single instance modda olması gerekmektedir.
sqlplus / as sysdba
shutdown immediate;
startup upgrade;
purge dba_recyclebin;
Log tabloları truncate edilir. Tabi mevcut iseler.
TRUNCATE TABLE SYS.DST$TRIGGER_TABLE;
TRUNCATE TABLE sys.dst$affected_tables;
TRUNCATE TABLE sys.dst$error_table;
Güncelleme işleminde aşağıdaki komut ile başlanır. Sonucunda “An upgrade window has been successfully started.” gibi yazı çıkması gerek.
EXEC DBMS_DST.BEGIN_UPGRADE(11);
Aşağıdaki sorgu sonucu; DST_PRIMARY_TT_VERSION yeni DST versiyonu, DST_SECONDARY_TT_VERSION eski DST versiyonu, DST_UPGRADE_STATE UPGRADE olmalıdır.
SELECT PROPERTY_NAME, SUBSTR(property_value, 1, 30) value
FROM DATABASE_PROPERTIES
WHERE PROPERTY_NAME LIKE ‘DST_%’
ORDER BY PROPERTY_NAME;
Hangi tabloların güncelleneceği aşağıdaki sorgu ile öğrenilebilir. Opsiyoneldir.
SELECT OWNER, TABLE_NAME, UPGRADE_IN_PROGRESS FROM ALL_TSTZ_TABLES where UPGRADE_IN_PROGRESS=’YES’;
DB yeniden başlatılır.
shutdown immediate
startup
Etkilenen tablolar aşağıdaki prosedür ile güncellenir.
VAR numfail number
BEGIN
DBMS_DST.UPGRADE_DATABASE(:numfail,
parallel => TRUE,
log_errors => TRUE,
log_errors_table => ‘SYS.DST$ERROR_TABLE’,
log_triggers_table => ‘SYS.DST$TRIGGER_TABLE’,
error_on_overlap_time => FALSE,
error_on_nonexisting_time => FALSE);
DBMS_OUTPUT.PUT_LINE(‘Failures:’|| :numfail);
END;
/
Hata olup olmadığı aşağıdaki iki sorgu ile kontrol edilir. Her ikisi de satır döndürmüyorsa hata yok demektir.
select * from SYS.DST$ERROR_TABLE;
select * from SYS.DST$TRIGGER_TABLE;
Hata yoksa aşağıdaki prosedür ile TimeZone güncelleme işlemi bitirilir.
VAR fail number
BEGIN
DBMS_DST.END_UPGRADE(:fail);
DBMS_OUTPUT.PUT_LINE(‘Failures:’|| :fail);
END;
/
Son olarak aşağıdaki sorgularla güncelleme işleminin başarılı olup olmadığı kontrol edilir.
SELECT PROPERTY_NAME, SUBSTR(property_value, 1, 30) value
FROM DATABASE_PROPERTIES
WHERE PROPERTY_NAME LIKE ‘DST_%’
ORDER BY PROPERTY_NAME;
SELECT * FROM v$timezone_file;
—————————————————————————————————————————-
Önceki sürümde kullanılan istatistik tabloları zamanında DBMS_STATS.CREATE_STAT_TABLE prosedürü ile yaratılmış ise bu tablolar tek tek aşağıdaki şekilde upgrade edilmelidir.
EXECUTE DBMS_STATS.UPGRADE_STAT_TABLE(‘SYS’,’dictionarystattable1′);
EXECUTE DBMS_STATS.UPGRADE_STAT_TABLE(‘SYS’,’dictionarystattable2′);
…
WARNING: –> Database contains schemas with objects dependent on network packages
Upgrade işleminden önce aldığımız yukarıdaki uyarıyı çözümlemek için upgrade sonrasında aşağıdaki prosedür çalıştırılır.
Upgrade yapılan database üzerinden webservice ile farklı database’ lere connect kuruluyor ise bunların çalıştığı webservislerinin kurulu olduğu client lara aşağıdaki yöntem ile user, host ve kullanılan port bazında tek tek yetki verilmesi gerekmektedir.
Aşağıdaki örnek de kullanılan web servisi utl_http‘ yi kullandığından webservisin kurulu olduğu sunucuların ip’ si kullanıldı. utl_smtp‘ yi kullanıyor olsaydı mail sunucunun ip’ si (mail sunucusu ip si girilecekti) ve portu girilmesi gerekecekti.
BEGIN
dbms_network_acl_admin.create_acl (acl => ‘utl_http.xml’,
description => ‘HTTP Access’,
principal => ‘ATMSEKER’,
is_grant => TRUE,
PRIVILEGE => ‘connect’,
start_date => NULL,
end_date => NULL
);
dbms_network_acl_admin.add_privilege (acl =>’utl_http.xml’,
principal => ‘ATMSEKER’,
is_grant => TRUE,
PRIVILEGE => ‘resolve’,
start_date => NULL,
end_date => NULL
);
dbms_network_acl_admin.assign_acl (acl => ‘utl_http.xml’,
HOST => ‘10.13.101.28’,
lower_port => 38080,
upper_port => 38080
);
COMMIT;
END;
Bu yapılmaz ise aşağıdaki hata mesajı alınır.
Alınan Hata mesajı;
ORA-24247: network access denied by access control list (ACL)
E.M konsolu upgrade edilir. DBUA kullanılarak db upgrade edilmişse bu işleme gerek yok. Ama kimi upgrade işlemleri sırasında en azından benim başıma her upgrade işlemi sonrasında geldi. Konsolu drop create ederek tanıtmak durumunda kaldım ama merak etmeyin mutlaka çalışıyor J
Upgrade öncesi SYS ve SYSTEM şemalarındaki objeler registry$sys_inv_objs tablosuna, non-SYS ve non-SYSTEM şemalarındaki objeler ise registry$nonsys_inv_objs tablosuna kaydedilir. Veritabanı upgrade sonrası invalide düşmüş nesneleri tespit etmek için (yeni)ORACLE_HOME/rdbms/admin adresindeki utluiobj.sql çalıştırılır.
cd (yeni)ORACLE_HOME/rdbms/admin
$ sqlplus / as sysdba
SQL> @utluiobj.sql
Eğer invalid durumda nesne çıkar ise (yeni)$ORACLE_HOME/rdbms/admin adresindeki utlrp.sql dosyası hiç invalid nesne kalmayıncaya kadar tekrar tekrar çalıştırılır.
cd (yeni)ORACLE_HOME/rdbms/admin
$ sqlplus / as sysdba
SQL> @utlrp.sql
Aşağıdaki komutla upgrade sonrası veritabanının versiyonu kontrol edilir.
SELECT name, value FROM v$parameter WHERE name = ‘compatible’;
Eski versiyonu gösteriyor ise aşağıdaki komut ile upgrade yaptığımız versiyona yükseltilir.
alter system set compatible=‘11.2.0.1.0’ scope=SPFILE;
Aynı şekilde aşağıdaki komut ile de optimizer versiyonu kontrol edilir.
select * from v$parameter where lower(name) like ‘%optimizer_features_enable%’;
ALTER SYSTEM SET optimizer_features_enable=’11.2.0.1.0’;
Aşağıdaki komut ile dba_recyclebin açılır ;
alter system set recyclebin=ON scope=SPFILE;
Eski versiyonu gösteriyor ise aşağıdaki komut ile son versiyona yükseltilir. Bu üç parametre statik parametre olduğu için yapılan değişikliklerin aktive olması için veritabanını kapatıp açmamız gerekecek.
Aslında yapmamız gerekenler buraya kadar ancak bu aşamada yani upgrade bittikden sonra database’ in bir backupının alınması her zaman önerilir.
Oracle 11g ile birlikte password politikasınca büyük küçük harf duyarlılığı getirilmiştir. Dolayısıyla kullanıcılar ilk girişlerinde problem yaşayabilirler, o yüzden kullanıcı şifrelerini expire ederseniz işk girişte değiştirmeleri gerekeceğinden bu sorunu da bir anlamda çözmüş olursunuz.
11gR2 kurulumu sonrasında bir takım sorunlarla karşılaştık. Bunlardan bir tanesi şu şekilde idi.
11gR2 database’ i içerisinde yer alan bir package içerisinden dblink kullanılarak bir başka database’ e gidiyor ise, gittiği database’ in versiyonu mutlaka 10.2.0.2 den büyük olması gerekiyor. 10.2.0.1 ise hata alırsınız çünkü bu bir bug.
Başka bir sorunumuz daha var ama şu anda metalink ile yazşmamış devam ettiği için onu çözüme kavuştuğunda buraya ekleyeceğim.
