Oracle

17 Ocak 2016

Exadata Yama Çalışması

Uzun süredir güncellenmeyen bir Exadata makinesi için yükseltme yapmamız gerekiyordu. 11.2.3.3.0 sürümünden, 12.1.2.1.3 sürümüne çıkacaktık. Bazı müşterilerim, yükseltme işlemlerinden biraz çekinebiliyor. Bu yazıdaki amacım, endişe etmeye o kadar da gerek olmadığını gösterebilmek. İyi bir hazırlık yaptıktan sonra, yaşanabilecek sorunlar da azalıyor.

888828.1 numaralı temel bir notumuz var. Exadata ile ilgili hemen her şeye bu not üzerinden ulaşıyoruz. Yama geçeceğimiz zaman da mutlaka buraya bakmamız lâzım. Geçmek istenen yamaya karar verdikten sonra, ilgili paketleri indiriyoruz:

Bu dosyaları indirip, compute node sunucusuna uygun bir lokasyona (örn. /u01/EXAPATCH vb...) atabilirsiniz. Dosyaların kopyalanmasıyla ilgili bir iki önerim olacak. root dosya sistemine atmayın. Bir de dosyaları Exadata üzerine transfer ettikten sonra, mutlaka MD5 ve SHA1 değerlerini kontrol edin. Bu sayede, dosyaları indirip, Exadata üzerine atarken, bir bozulma olmadığından emin olabilirsiniz. (Dosyaların orijinal SHA1/MD5 değerlerine erişmek için, Oracle'dan dosya indirirken, "View Digest Details" sekmesine tıklayabilirsiniz.)

Bunlar haricinde, her dökümanı teker teker ve oldukça dikkatli okumak gerekiyor. README dosyalarında her detay olmuyor. Bunun yerine, detay bulabilmek için metalink sayfalarına yönlendirmeler yapılıyor. Örneğin, p21446295_121213_Linux-x86-64.zip yamasının içinde bulunan README dosyası, 2031447.1 notunu mutlaka incelemeyi öneriyor. 2031447.1 notunda da bilinen problemler (Known Issues), dikkat edilmesi gereken konular bulunuyor. Özellikle Known Issues için mutlaka bir liste oluşturup, sizi etkileyecek bir durum olup-olmadığını peşinen belirleyin. Kendi çalışmamdan örnek verirsem:

-- Known Issues (2031447.1)
-- 1. Known Issues New in This Release
-- 2. Known Issues Relevant to This Release Carried Forward From a Previous Release
 2.1 - Alert "RS-7445 [Serv DBRS_BACKUP hang detected]" raised while upgrading 8-socket database servers from 12.1.2.1.0 to 12.1.2.1.1/12.1.2.1.3
     --> UYMUYOR. MAKINE 2 SOKETLI

 2.2 - Virtual machines started on X4 and X5 systems may come up with IP addresses missing on some or all of its InfiniBand interfaces
     --> UYMUYOR. SANAL MAKINE (OVM) KULLANIMDA DEGIL.

 2.3 - Oracle Clusterware does not startup after patching/upgrading database servers to 12.1.2.1.x
     --> DETAYLI INCELE!

 2.4 - 12c Grid Infrastructure 12.1.0.2 BP4 and later requires fix when rolling back from Exadata releases 12.1.2.1.0 and later to releases older than 12.1.2.1.0 in a rolling fashion
     --> UYMUYOR. GI VE VERITABANI 11G

 2.5 - Failed patching due to "SM BIOS Uncorrectable CPU-complex Error" reported in ILOM System Event Log
    --> UYMUYOR. MEVCUT SURUM: 11.2.3.3.0, PROBLEM CIKAN SURUM 11.2.3.2.0 VE ONCESI GOZUKUYOR.

 2.6 - Running mixed cell releases (e.g. during rolling cell patching or rack expansion) using Oracle Database 11.2.0.3 or 11.2.0.2 without patch 17854520 installed can cause database hang or crash
    --> UYMUYOR. FARKLI SURUM STORAGE CELL YOK. AYRICA NON-ROLLING YAMA UYGULANACAK.

 2.7 -  Upgrade Exalogic Virtual environments connected to Exadata over InfiniBand to Exalogic PSU April 2014 before upgrading Exadata InfiniBand switches to 2.1.3-4 (delivered with 12.1.2.1.1)
     --> UYMUYOR. EXALOGIC KULLANIMI YOK.

 2.8 - Instructions on how to manually update ILOM on Storage Servers if patchmgr hangs
     --> UYMUYOR. MEVCUT SURUM: 11.2.3.3.0, PROBLEM CIKAN SURUM 11.2.3.2.0 VE ONCESI GOZUKUYOR.

 2.9 - Cell patching may fail if cells are patched concurrently with InfiniBand switches
     --> DIKKAT EDILECEK! CELL YAMALARI BITINCE, IB SWITCH YAMALARI ATILACAK.

 2.10 - Storage server and database server do not boot during reimage using bootable USB created from makeImageMedia.sh
     --> UYMUYOR. YENIDEN IMAJLAMA YAPILMAYACAK.

 2.11 - Upgrade precheck with patchmgr fails due to missing or incomplete entry in /etc/hosts during InfiniBand switch upgrade
     --> DIKKAT EDILECEK. IB SWITCH TARAFINDA GEREKLI AKSIYON ALINDI.

 2.12 - Database instances fail to start after patching DB nodes
     --> UYMUYOR. ROLLING YAMA GECILMEYECEK VE VERITABANI 11G. YINE DE _exafusion PARAMETRESINI AKILDA TUTMAK GEREKIYOR.

 2.13 - ASM 11.2.0.3 running on Oracle SuperCluster fails to discover grid disks on Exadata Storage Servers running 12.1.2.1.1
     --> UYMUYOR. PROBLEM SUPERCLUSTER ICIN GECERLI. ISLEM EXADATA UZERINDE YAPILACAK.

 2.14 - NFS mounts can become unresponsive after updating database server from Oracle Linux 5 to Oracle Linux 6
     --> DIKKAT EDILECEK! NFS KONUSUNDA DEGISIKLIK VAR. SORUN OLURSA, 1354980.1 NOTUNDA NFS ADIMLARINA DIKKAT ETMEK GEREKLI

 2.15 - Image status shows failure after updating from Oracle Linux 5 to Oracle Linux 6 on non-LVM enabled database servers
    --> UYMUYOR. YINE DE IMAJ SURUMUNU GOSTERMEKLE ILGILI SORUN OLURSA, DUZELTME ADIMLARI GEREKEBILIR.

 2.16 - DBFS not working after update to Oracle Linux 6
    --> PROBLEM! DBFS KURULUMU ETKILENECEK. 1054431.1 NOTUNDAN GUNCEL mount-dbfs.sh SCRIPT'I TEMIN EDILMELI

 2.17 - Access to ZFS storage from Exadata database servers is slow or hangs after updating to Exadata 12.1.2.1.x
    --> UYMUYOR. ZFS BAGLI DEGIL. ANCAK ILERIDE BAGLANIRSA, PERFORMANS ALMAK ADINA IB PORTLARI ICIN MTU BOYUTLARINI 64000 YAPMAK GEREKEBILIR.
		

Ayrıca geçeceğiniz yamanın, kullandığınız veritabanı/grid sürümüyle uygunluğunu da kontrol etmeniz gerekecektir. "Software Release Requirements" kısmından desteklenen sürüm bilgisine ulaşabilirsiniz.

Bu kontroller bitince, en güncel exachk uygumalasıyla sistemi genel olarak tarıyoruz. Oracle Exadata Database Machine exachk or HealthCheck (Doc ID 1070954.1) notundan en güncel Exachk uygulamasını indirebilirsiniz. Burada verilen uyarılara göz atıp, gereken aksiyonları yapmalıyız. Değişiklikler tamamlanınca, güncel bir exachk daha çalıştırıp, tekrar kontrol edebilirsiniz. (Sisteminizde herhangi bir değişiklik yapmasanız veya yapmayacak olsanız bile, ayda en az bir kere güncel exachk ile sisteminizi taramanızı öneririm.)

Yama geçerken bir sorunla karşılaşma ihtimaline karşı, öncesinde bir SR açmak iyi olacaktır. Elde ettiğiniz exachk'i kullanıp, bir SR açıp, yama geçeceğinizi, herhangi bir sorun olup-olmadığını sorabilirsiniz. Eğer düzeltilmesi gereken olumsuz bir yanıt gelmezse, SR'ın uyku moduna alınmasını isteyip, sorun olması durumunda buradan devam edileceğini söyleyebilirsiniz.

Yama geçmeden önce son bir hazırlık daha yapıyoruz. Operasyondan birkaç gün önce, bütün sunucuları yeniden başlatıyoruz. Böylece her şeyin problemsiz başlayabileceğinden emin oluyoruz. Ayrıca NFS kullanıyorsanız, yama öncesi /etc/fstab üzerinden geçici olarak kaldırıyoruz. NFS paylaşım noktaları mount edilirken, takılma/bekleme riskini bu sayede eliyoruz.

Cell tarafında da yapacağımız bazı kontroller var. cellcli ile "ALTER CELL VALIDATE MAIL" yapıp, e-mail gönderimini test ediyoruz. Ayrıca 1383752.1 ve 1341944.1 notlarını takip ederek, Infiniband Switch'lerin konfigürasyon yedeklerini almak gerekiyor.

Şimdi gelelim yama geçmeye... Bağlantı kopma ihtimaline karşı, mutlaka screen veya vnc gibi bir araç kullanmanızı tavsiye ederim.

1. Storage Cell tarafına yama geçilmesi

# STORAGE CELL'LER ICIN cell_group DOSYASI HAZIRLANIR
[root@exadbadm01:~]$ cat cell_group
exaceladm01
exaceladm02
exaceladm03

# SSH EQUIVALENCE KONTROL EDILIR
[root@exadbadm01:~]$ dcli -g ~/cell_group -l root 'hostname -i'

# EGER SSH EQUIVALENCE YOKSA, ASAGIDAKI GIBI OLUSTURULUR
[root@exadbadm01:~]$ ssh-keygen -t rsa
[root@exadbadm01:~]$ dcli -g ~/cell_group -l root -k

# CELL'LERIN root FILESYSTEM'I ICIN BOS ALAN KONTROLU YAPILACAK
# 4GB CIVARI BOS ALAN OLMASI YETERLI
[root@exadbadm01:~]$ dcli -g ~/cell_group -l root 'df -h /'

# YAMA, NON-ROLLING (KESINTILI) GECILECEK
# CRS VE BAGLI BUTUN SERVISLER KAPATILACAK
[root@exadbadm01:~]$ /u01/app/11.2.0.3/grid/bin/crsctl stop cluster -all
[root@exadbadm01:~]$ /u01/app/11.2.0.3/grid/bin/crsctl stop crs
[root@exadbadm02:~]$ /u01/app/11.2.0.3/grid/bin/crsctl stop crs
# CRS VE BAGLI SERVISLERIN KAPATILDIGI KONTROL EDILIR
[root@exadbadm01:~]$ dcli -g dbs_group -l root "/u01/app/11.2.0.3/grid/bin/crsctl check crs"
[root@exadbadm01:~]$ dcli -g dbs_group -l root "ps -ef | grep grid"
[root@exadbadm01:~]$ ps -ef|grep -e crs -e smon -e pmon
[root@exadbadm02:~]$ ps -ef|grep -e crs -e smon -e pmon

# CELL SERVISLERININ BILINEN BIR DURUMA GELMESI ICIN ASAGIDAKI KOMUTU CALISTIRIYORUZ
[root@exadbadm01 patch_12.1.2.1.3.151021]$ ./patchmgr -cells ~/cell_group -reset_force
# BUTUN CELL'LER UZERINDEKI SERVISLERI (cellsrv, ms, rs) KAPATIYORUZ
[root@exadbadm01:~]$ dcli -g ~/cell_group -l root "cellcli -e alter cell shutdown services all"
[root@exadbadm01:~]$ dcli -g ~/cell_group -l root "cellcli -e list cell detail"
# YARIM KALAN BIR YAMA ISLEMINE KARSI TEMIZLEME YAPILIYOR
[root@exadbadm01 patch_12.1.2.1.3.151021]$ ./patchmgr -cells ~/cell_group -cleanup

# YAMA GECMEDEN ONCE, KONTROL YAPILIYOR
[root@exadbadm01 patch_12.1.2.1.3.151021]$ ./patchmgr -cells ~/cell_group -patch_check_prereq \
   -smtp_from "exadata@mydomain.com.tr" -smtp_to "admin.user@mydomain.com.tr"

# HERHANGI BIR SORUN YOKSA, PATCH ISLEMINE BASLANIR
[root@exadbadm01 patch_12.1.2.1.3.151021]$ ./patchmgr -cells ~/cell_group -patch \
    -smtp_from "exadata@mydomain.com.tr" -smtp_to "admin.user@mydomain.com.tr"

# BIR BASKA OTURUMDAN, PATCH ATMA DURUMU TAKIP EDILEBILIR
[root@exadbadm01 patch_12.1.2.1.3.151021]$ tail -f patchmgr.stdout

# ISLEM SONUNDA, imageinfo VE imagehistory ILE KONTROL YAPILACAK
[root@exadbadm01:~]$ dcli -g ~/cell_group -l root 'imageinfo'
[root@exadbadm01:~]$ dcli -g ~/cell_group -l root 'imagehistory'
[root@exadbadm01:~]$ dcli -g ~/cell_group -l root "grep -i fail /var/log/cellos/validations.log"

# SUREC BASARILI BITINCE, PATCH ILE ILGILI TEMIZLIK GERCEKLESTIRILECEK
[root@exadbadm01 patch_12.1.2.1.3.151021]$ ./patchmgr -cells ~/cell_group -cleanup

Bu işlemin başarılı bitmesi durumunda, üç storage cell güncellenmiş demektir. Bu aşamadan sonra, IB Switch'leri yükseltebiliriz.

2. Infiniband Switch'lere yama geçilmesi

# ONCELIKLE HANGI SWITCH UZERINDE SUBNET MANAGER KOSTUGUNU BULALIM
# SUBNET MANAGER KOSAN SWITCH ILK YAMA GECILMESI GEREKEN SWITCH OLACAK
[root@exasw-iba01 ~]# getmaster -l
-- Local SM enabled and running, state MASTER
[root@exasw-ibb01 ~]# getmaster -l
-- Local SM enabled and running, state STAND BY

# SWITCH BILGILERI ibswitches.lst DOSYASINA YAZILACAK
[root@exadbadm01:~]$ cat ibswitches.lst
exasw-iba01
exasw-ibb01

# UPGRADE ONCESI KONTROL YAPILACAK
[root@exadbadm01 patch_12.1.2.1.3.151021]$ ./patchmgr -ibswitches ibswitches.lst -upgrade -ibswitch_precheck
# SORUN YOKSA, UPGRADE ISLEMI TETIKLENIYOR. YAMA ISLEMI, SIRAYLA (ROLLING) GERCEKLESIYOR
[root@exadbadm01 patch_12.1.2.1.3.151021]$ ./patchmgr -ibswitches ibswitches.lst -upgrade

Switch upgrade işlemi başarıyla tamamlandıktan sonra, imageinfo ile teker teker kontrol ediyoruz.

3. Compute Node'lara yama geçilmesi

# dbnodeupdate /u01/EXAPATCH ALTINDA root KULLANICISIYLA ACILIR
[root@exadbadm01:~]$ cp -pv p16486998_121220_Linux-x86-64.zip /u01/EXAPATCH/DBNODE
[root@exadbadm01:~]$ cd /u01/EXAPATCH/DBNODE
[root@exadbadm01:~]$ unzip p16486998_121220_Linux-x86-64.zip

# EGER ACIKSA, ILGILI MAKINEDE BUTUN SERVISLER KAPATILIR
[root@exadbadm01:~]$ /u01/app/11.2.0.3/grid/bin/crsctl stop crs -f
-- ...
-- CRS-4133: Oracle High Availability Services has been stopped.

# CRS'IN OTOMATIK BASLAMASI ENGELLENIR
[root@exadbadm01:~]$ /u01/app/11.2.0.3/grid/bin/crsctl disable crs

# NFS MOUNT'LAR SISTEMDEN UNMOUNT EDILIR
umount -a -t nfs
# /etc/fstab DOSYASINDA DUZENLEME YAPILIR VE AUTOMOUNT NFS DOSYALARI KALDIRILIR
vi /etc/fstab

# ONCE screen VEYA vnc CALISTIRILIR
screen / vnc

# HER SEY TAMAMSA, UPGRADE ISLEMI BASLATILIR.
# ASAGIDAKI ORNEKTE, "-R" PARAMETRESI KULLANILMISTIR
# BUNUN NEDENI, LINUX 5.9'DAN, LINUX 6.7'YE YUKSELTILMESI VE 
# PAKETLERIN KALDIRILMA ZORUNLULUGUDUR
[root@exadbadm01:~]$ ./dbnodeupdate.sh -u -l ./p21821557_121213_Linux-x86-64.zip -R

# YENIDEN BASLADIKTAN SONRA, POST RUN ADIMLARI GERCEKLESTIRILIR
[root@exadbadm01:~]$ ./dbnodeupdate.sh -c

# CRS'IN OTOMATIK BASLAMASI KONTROL EDILIR  
[root@exadbadm01:~]$ /u01/app/11.2.0.3/grid/bin/crsctl config crs
# CRS'IN OTOMATIK BASLAMASI ACILMADIYSA, KONFIGURE EDILIR
[root@exadbadm01:~]$ /u01/app/11.2.0.3/grid/bin/crsctl enable crs
# MAKINE TEST AMACIYLA YENIDEN BASLATILIR
[root@exadbadm01:~]$ shutdown -r -y now

# AYNI ADIMLAR exadbadm02 MAKINESINDE DE TEKRAR EDILIR #

# RDS KONTROLU YAPILIR
dcli -g ~/dbs_group -l oracle /u01/app/oracle/product/11.2.0.3/dbhome_1/bin/skgxpinfo
exadbadm01: rds
exadbadm02: rds

# RDS KULLANIMI ALERT LOG UZERINDEN DE KONTROL EDILEBILIR
cluster interconnect IPC version:Oracle RDS/IP (generic)

Bütün bu işlemler bittikten sonra, Exadata altyapısıyla ilgili güncellemeler de tamamlanmış oluyor. Bu aşamadan sonra, veritabanı ve Grid yamalarını geçebiliriz. Ancak buna bir başka yazıda değiniriz.

İşlemlerin ne kadar süreceğini, Exadata Database Machine Software and Hardware Maintenance Planning Guide [ID 1461240.1] notundan bulabilirsiniz.

Yazmış olduğum yordamlar, fikir vermek açısından şahsi notlarımı içermektedir. Oracle'ın görüş ve önerilerini yansıttığı anlamına gelmez. Bu nedenle bir yama çalışması yapacakken, mutlaka Oracle tarafından sunulan notları incelemenizi ve buna göre hareket etmenizi tavsiye ederim.


Çağatay ÇEBİ