Oracle Exadata infiniband switch portları AutomaticHighErrorRate sebebiyle down olduğunda nasıl up yapılır ?

Oracle Exadata infiniband switch portlarındaki hata sayısı belirtilen eşik değerlere ulaştığında otomatik olarak AutomaticHighErrorRate olacak şekilde down duruma getirilmektedir. Sorun giderildikten sonra aşağıdaki şekilde up duruma getirilebilir.

Öncelikle sorun olan infiniband switch’e ssh ile bağlanılmalıdır.

Down durumdaki portun tespiti :

[root@exasw-iba01 ~]# listlinkup
Connector  0A Not present
Connector  1A Not present
Connector  2A Present <-> Switch Port 24 is up (Enabled)
Connector  3A Not present
Connector  4A Not present
Connector  5A Present <-> Switch Port 30 is up (Enabled)
Connector  6A Not present
Connector  7A Not present
Connector  8A Present <-> Switch Port 31 is up (Enabled)
Connector  9A Present <-> Switch Port 14 is up (Enabled)
Connector 10A Present <-> Switch Port 16 is up (Enabled)
Connector 11A Present <-> Switch Port 18 is up (Enabled)
Connector 12A Not present
Connector 13A Not present
Connector 14A Not present
Connector 15A Not present
Connector 16A Not present
Connector 17A Not present
Connector  0B Not present
Connector  1B Present <-> Switch Port 21 is up (Enabled)
Connector  2B Not present
Connector  3B Not present
Connector  4B Present <-> Switch Port 27 is up (Enabled)
Connector  5B Present <-> Switch Port 29 is up (Enabled)
Connector  6B Present <-> Switch Port 36 is down (AutomaticHighErrorRate)
Connector  7B Not present
Connector  8B Not present
Connector  9B Present <-> Switch Port 13 is up (Enabled)
Connector 10B Present <-> Switch Port 15 is up (Enabled)
Connector 11B Present <-> Switch Port 17 is up (Enabled)
Connector 12B Not present
Connector 13B Not present
Connector 14B Not present
Connector 15B Not present
Connector 16B Not present
Connector 17B Not present

Yukardaki çıktıdan görüldüğü üzere 36 numaralı port down durumdadır. Bu portu aşağıdaki şekilde up duruma getirebilirsiniz.

[root@exasw-iba01 ~]# enableswitchport --automatic Switch 36
Enable connector 6B Switch port 36
Adminstate:......................Enabled
LinkWidthEnabled:................1X or 4X
LinkWidthSupported:..............1X or 4X
LinkWidthActive:.................4X
LinkSpeedSupported:..............2.5 Gbps or 5.0 Gbps or 10.0 Gbps
LinkState:.......................Down
PhysLinkState:...................Polling
LinkSpeedActive:.................2.5 Gbps
LinkSpeedEnabled:................2.5 Gbps or 5.0 Gbps or 10.0 Gbps
NeighborMTU:.....................2048
OperVLs:.........................VL0-7

Bir müddet bekledikten sonra listlinkup komutu ile kontrol ettiğinizde ilgili port Up ve Enabled durumda olacaktır. 

[root@exasw-iba01 ~]# listlinkup
Connector  0A Not present
Connector  1A Not present
Connector  2A Present <-> Switch Port 24 is up (Enabled)
Connector  3A Not present
Connector  4A Not present
Connector  5A Present <-> Switch Port 30 is up (Enabled)
Connector  6A Not present
Connector  7A Not present
Connector  8A Present <-> Switch Port 31 is up (Enabled)
Connector  9A Present <-> Switch Port 14 is up (Enabled)
Connector 10A Present <-> Switch Port 16 is up (Enabled)
Connector 11A Present <-> Switch Port 18 is up (Enabled)
Connector 12A Not present
Connector 13A Not present
Connector 14A Not present
Connector 15A Not present
Connector 16A Not present
Connector 17A Not present
Connector  0B Not present
Connector  1B Present <-> Switch Port 21 is up (Enabled)
Connector  2B Not present
Connector  3B Not present
Connector  4B Present <-> Switch Port 27 is up (Enabled)
Connector  5B Present <-> Switch Port 29 is up (Enabled)
Connector  6B Present <-> Switch Port 36 is up (Enabled)
Connector  7B Not present
Connector  8B Not present
Connector  9B Present <-> Switch Port 13 is up (Enabled)
Connector 10B Present <-> Switch Port 15 is up (Enabled)
Connector 11B Present <-> Switch Port 17 is up (Enabled)

Oracle Exadata Database Machine ile ilgili yararlı My Oracle Support (MOS) dokümanları

Exadata ile ilgili birçok konuda MOS dokümanları bulunmaktadır. Bu dokümanlardan işinize en çok yarayanları aşağıdaki listede bulabilirsiniz.

• 888828.1 Database Machine and Exadata Storage Server Supported Versions *** Exadata yama ve sürüm dokümanı, düzenli okuyun!
• 1270094.1 Exadata Critical Issues *** Düzenli olarak okuyun!
• 1353073.1 Exadata Diagnostics Collection Guide
• 1187674.1 Master Note for Oracle Exadata Database Machine and Oracle Exadata Storage Server
• 1483344.1 Exadata Platinum Customer Outage Classifications and Restoration Action Plans
• 757552.1 Oracle Exadata Best Practices
• 1274318.1 Oracle Sun Database Machine Setup/Configuration Best Practices
• 1571965.1l Maximizing Availability with Engineered Systems – Exadata
• 1262380.1 Exadata Testing Practices and Patching Explained
• 1306814.1 Oracle Software Patching with OPLAN
• 1110675.1 Oracle Exadata Database Machine Monitoring
• 1070954.1 Database Machine Healthcheck (Exachk) *** Düzenli olarak exachk çalıştırın!
• 1071221.1 Oracle Sun Database Machine Backup and Recovery Best Practices
• 1054431.1 Configuring DBFS on Oracle Exadata Database Machine
• 1084360.1 Bare Metal Restore Procedure for Compute Nodes on an Exadata Environment (Linux)
• 1339769.1 Master Note for Oracle Database Resource Manager
• 960510.1 Data Guard Transport Considerations on Oracle Database Machine

Exadata üzerindeki veriabanlarında 12c upgrade sonrasında yaşanan library cache lock , gc cr request ve gc buffer busy acquire bekleme olayları

Exadata üzerindeki veritabalarında 12.2 versiyonuna yükseltildiğinde , veritabanında birçok işlemlerde “gc cr request” ile “gc buffer busy acquire” bekleme olayları görülmektedir. Aynı zamanda kullanıcılar giriş yapmaya çalıştığında ” select spare6 from user$ where user#=:1 ” ya da “SELECT privilege# FROM sysauth$ WHERE (grantee# = 1 OR grantee# = 1) AND privilege# > 0 “şeklindeki sorguların “library cache lock” bekleme olayına sebep olduğu görülebilmektedir.

Login işlemlerini bekleten “update user$ set spare6=DECODE(to_char(:2, ‘YYYY-MM-DD’), ‘0000-00-00’, to_date(NULL), :2) where user#=:1” şeklinde bir güncelleme yapmaya çalışan başka bir session olduğu tespit edilmiştir. Bu update işlemini yapmaya çalışan session kill edildiğinde beklemedeki diğer session’lar işlemlerini yapabilmektedir. Fakat yoğun veritabanlarında “gc cr request ve gc buffer busy acquire” bekleme olayları , veritabanının cevap veremez duruma getirmektedir.

Sorunun kök nedeni aşağıda belirtilen bug’lar olduğu görülmektedir. Sorunun tamamen çözümü için 25163866 numaralı veritabanı yaması , eğer bu yama çözmez ise de 25730857 numaralı UEK4 kernel yaması uygulanmalıdır. Kernel için gerekli yamayı 2207063.1  numaralı dokümanı takip ederek uygulayabilirsiniz. Veritabanı yamasını uygulamak için RAC ve single bile olsa veritabanı kapalı olmalıdır. RAC sistemlerde bir noda uyguladığınızda uygulanan node’daki instance açılmamaktadır. Veritabanı kapatıp , tüm node’lara yamayı uygulayıp sonrasında açılmalıdır.

Internal Bug 25163866 – SAGEASM-E DB HANG AT ‘GC CR REQUEST'<=’LIBRARY CACHE LOAD LOCK’
Internal Bug 25730857 – UEK4: Cache Fusion Fails Because of Data Corruption in LWIPC

Sorun , 18.1 versiyonlu veritabanlarında çözülmüş durumdadır.

DBMCLI ile Exadata veritabanı sunucularında e-posta ayarları

Exadata veritabanı sunucularında da cell node’lardaki gibi e-posta ayarlarının yapılıp , sunucu hakkında otomatik bildirimlerin gönderilmesi mümkündür.

E-posta sunucunuzda , Exadata db sunucuları için relay tanımlanması gerekmektedir. Aksi takdirde şifre ile doğrulama gerektirecektir. Bu da bazı durumlarda sorunlara yol açabilmektedir.

DBMCLI ile compute node’lardaki mevcut e-posta konfigürasyonunu aşağıdaki gibi görüntüleyebiliriz.

[root@exadb01 ~]# dbmcli
DBMCLI: Release  - Production on Tue May 28 11:43:43 EET 2019

Copyright (c) 2007, 2016, Oracle and/or its affiliates. All rights reserved.

DBMCLI> list dbserver detail
	 name:                   exadb01
	 bbuStatus:              normal
	 cpuCount:               24/24
	 diagHistoryDays:        7
	 fanCount:               16/16
	 fanStatus:              normal
	 id:                     1111111111
	 interconnectCount:      2
	 ipaddress1:             192.168.10.67/22
	 kernelVersion:          4.1.12-61.33.1.el6uek.x86_64
	 locatorLEDStatus:       off
	 makeModel:              Oracle Corporation SUN FIRE X4170 M2 SERVER
	 metricHistoryDays:      7
	 msVersion:              OSS_12.2.1.1.1_LINUX.X64_170419
	 notificationMethod:     mail
	 notificationPolicy:     critical,warning,clear
	 powerCount:             2/2
	 powerStatus:            normal
	 releaseImageStatus:     success
	 releaseVersion:         12.2.1.1.1.170419
	 releaseTrackingBug:     25512521
	 smtpFrom:               "Exadata"
	 smtpFromAddr:           exadata@interiva.com
	 smtpServer:             relay.interiva.com
	 smtpToAddr:             oracle.bilgi@interiva.com
	 smtpUseSSL:             FALSE
	 status:                 online
	 temperatureReading:     28.0
	 temperatureStatus:      normal
	 upTime:                 63 days, 23:32
	 msStatus:               running
	 rsStatus:               running

E-posta ayarlarını aşağıdaki şekilde yapabilirsiniz.

DBMCLI> alter dbserver smtpServer='relay.interiva.com', smtpFrom='Exadata',  smtpFromAddr='exadata@interiva.com', smtpToAddr='oracle.bilgi@interiva.com', notificationPolicy='critical,warning,clear', notificationMethod=mail,smtpUseSSL=FALSE
DBServer exadb01 successfully altered

Relay tanımlanamadığı durumlarda şifre bilgisinin de belirtilmesi gerekmektedir. Kullanıcı adı smtpFromAddr ile belirtilen adres olacaktır.

DBMCLI> ALTER DBSERVER smtpServer='mailserver.interiva.com', smtpFromAddr='exadata@interiva.com', smtpFrom='exadata', smtpToAddr='exadata@interiva.com,sistem@interiva.com', notificationPolicy='critical,warning,clear', notificationMethod='mail', smtpPort=25, smtpPwd=sifre, smtpUseSSL=FALSE

Ayarlar yapıldıktan sonra test mesajı göndermek için aşağıdaki komutu kullanabilirsiniz.

DBMCLI> alter dbserver validate mail
DBServer exadb01 successfully altered

Herşey düzgün konfigre edildi ise , yukarıdaki komut sonrasında “DB Server sunucu_adi Test Message” konulu bir e-posta gelecektir.

Exadata’da dcli kullanarak şifresiz ssh nasıl kurulur?

Exadata kurulumu sorasında compute node ve cell node’lar arasında şifresiz ssh bağlantısı kurulmasına rağmen , sonradan yaşanan sorunlar sebebiyle bu bağlantı bozulabilmektedir. Infiniband switch’lere yama uygularken de öncelikle şifresiz ssh bağlantısının yapılabiliyor olması gerekmektedir.

Bu işlemleri dcli ile basitçe yapabiliriz.

Öncelikle şifresiz ssh bağlantısı yapılacak sunucu yada switch’leri içeren bir dosya oluşturulmalıdır. Örneğin all_group ismiyle aşağıdaki gibi bir dosya oluşturulabilir. Dosyada sunucu isimleri kısa formatta olmalı ve DNS ile bu isimler çözülebiliyor olmalıdır.

dbnode1
dbnode2
cellnode1
cellnode2
cellnode3
ibswitch1
ibswitch2

Sonrasında hangi kullanıcı ile bağlantı yapılmak isteniyorsa , genellikle root olacaktır , o kullanıcı ile aşağıdaki komut çalıştırılarak SSH için kimlik doğrulama anahtarları oluşturulur.

# ssh-keygen -t rsa

Sonrasında bu anahtarlar all_group ismiyle oluşturduğumuz dosyada yer alan tüm sunuculara dağıtılır. Komut çalıştırıldığında sunucuların şifrelerini girmeniz istenecektir.

# dcli -g ./all_group -l root -k -s '-o StrictHostKeyChecking=no'

Son olarak şifresiz giriş kontrol edilir. Aşağıdkai komut ile sunuculardaki tarih sorgulanabilir. Tüm sunuculardaki tarihler görüntülenirse , şifresiz ssh bağlantısında sorun yoktur diyebiliriz.

# dcli -g all_group -l root date