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
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 ~]$
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;
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)
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.
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;
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;
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;
/
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;
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.
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;
/
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;
/
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;
----------------------------------------------------------------------------------------------------------------------------
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
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
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.
Hiç yorum yok:
Yorum Gönder