Oracle 12.2 ile Online tablespace şifreleme TDE (Transparent Data Encryption)

Oracle 12c release 2 versiyonuyla gelen özellik sayesinde artık tablespaceleri canlı olarak şifreleyebiliyoruz(ENCRYPT).

Öncelikle bir tablespace’i encpt etmediğimiz durumlarda karşılaşabileceğimiz durumları inceleyelim.

12.2 veritabanımıza bağlanarak users tablespace üzerinde bir tablo oluşturup, bu tabloya bir kayıt ekleyeceğiz. Sonrasında da sadece işletim sisteminde read yetkisi olan birinin, tabloya yazdığımız bu datayı görüp göremediğini kontrol edeceğiz.

[oracle@exadata_node1 ~]#sqlplus / as sysdba
SQL*Plus: Release 12.2.0.1.0 Production on Tue Apr 11 15:59:28 2017
Copyright (c) 1982, 2016, Oracle. All rights reserved.
Connected to:
Oracle Database 12c Enterprise Edition Release 12.2.0.1.0 - 64bit Production
SQL> create table tahsinc.very_important_data
( name varchar2(50),
 kimlik varchar2(20)
)
tablespace users; 2 3 4 5
Table created.
SQL> insert into tahsinc.very_important_data values ('Tahsin','12345678901234567890');
1 row created.
SQL> commit;
Commit complete.
SQL> alter system checkpoint;
System altered.

Checkpoint komutu çalıştırarak yaptığımız insert işleminin datafile a yazıldığına emin oluyoruz. Sonrasında ilgili datafile’ı asmden normal bir dizine kopyalarak strings komutu ile içeriğine bakıyoruz.

Ekran görüntüsünde de gördüğümüz üzere Tabloya insert olarak attığımız değerleri açık olarak görebiliyoruz. Bu durumda datafilelarımızı bir şekilde kötü ellere düşerse veritabanı kurmadan bile verilerimize erişme şansı oluyor.

Bunun önüne geçmek için Oracle ın sağladığı TDE özelliği ile artık online olarak da tablespacelerimizi encrypt edebiliyoruz.

Tabloyu encrypt etmek için öncelikle bir ketstore oluşturmamız gerekiyor.  v$encryption_wallet  tablosundan veritabanının mevcutta gördüğü wallet lokasyonunu kontrol ediyoruz. Bizim veritabanımızda bu alan default olarak  /u01/app/oracle/admin/TESTDB/wallet olduğundan aşağıdaki işlemleri bu dizine göre yapacağız. Sırasyıla aşağıdaki komutları çalıştırıyoruz.

ADMINISTER KEY MANAGEMENT CREATE KEYSTORE '/u01/app/oracle/admin/TESTDB/wallet' identified by Deneme123;
ADMINISTER KEY MANAGEMENT SET KEYSTORE OPEN IDENTIFIED BY Deneme123;
ADMINISTER KEY MANAGEMENT SET KEY IDENTIFIED BY Deneme123 with backup;

Keystore’u tanımladıktan sonra aşağıdaki şekilde talbespace imizi online olarak encrypt edebiliyoruz. Bizde datafile asm üzerinde tutulduğundan db file name management auto olduğundan yeni tablespace ismi vermiyoruz. Ama datafile’ınız asm üzerinde değilse komut sonuna FILE_NAME_CONVERT=(‘users’,’users_enc_ts’)  komutunu ekleyerek tablespace’in adını da değiştirebilirsiniz.

alter tablespace users ENCRYPTION ONLINE USING 'AES192' ENCRYPT;

Bu işlem sonrasında tekrar işletim sistemi üzerinden  strings komutu ile datafile’ın içeriğine bakıyoruz. eklediğimiz kayıtları datafile içerisinde grepliyoruz ancak bir sonuç alamıyoruz. Bu da datafile’ımızın başarılı bir şekilde encrypt edildiğini gösteriyor.

 

ORA-28040 – no matching authentication protocol

ORA-28040 – no matching authentication protocol. ORA-28040 Eşleşen doğrulama protokolü yok.

12.2.0.1 upgrade işlemini yaptıktan sonra 11g client ile 12.2.0.1 veritabanına bağlanmaya çalıştığımızda  ORA-28040 hatası aldık.

Bu hatanın çözümü için database ve grid home altında sqlnet.ora dosyasına aşağıdaki parametrelieri ekledik.

vi /u01/app/oracle/product/12.2.0.1/dbhome_1/network/admin/sqlnet.ora

SQLNET.ALLOWED_LOGON_VERSION_CLIENT = 8
SQLNET.ALLOWED_LOGON_VERSION_SERVER = 8
vi /u01/app/12.2.0.1/grid/network/admin/sqlnet.ora

SQLNET.ALLOWED_LOGON_VERSION_CLIENT = 8
SQLNET.ALLOWED_LOGON_VERSION_SERVER = 8

Parametreleri cluster’ın tüm node’larında ekledikten sonra, SCAN listener dahil tüm listenerları restart ettik.

Support üzerindeki dökümanda  SEC_CASE_SENSITIVE_LOGON parametresi FALSE olarak set edildiyse parametreyi  8 e olarak set edilmesi

SQLNET.ALLOWED_LOGON_VERSION_SERVER = 8

SEC_CASE_SENSITIVE_LOGON parametresi TRUE ise de 10 olarak set edilmesi gerektiği belirtilmiş.

SQLNET.ALLOWED_LOGON_VERSION_SERVER = 10

Biz SEC_CASE_SENSITIVE_LOGON parametresi TRUE olan  12.2.0.1 veritabanı ve 11g client için  “8”   olarak set ettik ve hatadan kurtulduk. Eğer tüm uygulama ve clientlarınızda 11g üzeri client kullanıyorsanız bu parametreyi 11 olarak de set edebilirsiniz.

Eğer  E-BUsiness Suite 12.0kullanıyorsanız   sqlnet_ifile.ora dosyasını da SEC_CASE_SENSITIVE_LOGON parametresine göre set etmeniz gerekiyor.

Exadata db node üzerinde yeni disk oluşturma

Exadata db nodelar üzerindeki fisiksel diskler ilk kurulumda bir logical volume e atanmış olarak geliyor. Bu nedenle disk eklerken ve büyütürken linux logical volume yönetme komutlarını kullanacağız. Öncelikle mevcut sistem durumuna bakmak için aşağıdaki komutları kullanabiliriz.

Exadata X6-2 quarter rac üzerinde komutların çıktıları aşağıdaki gibidir. pvdisplay komutu ile fiziksel diskleri görebiliriz.

root@exadata_node1 ~]#pvdisplay
 --- Physical volume ---
 PV Name /dev/sda2
 VG Name VGExaDb
 PV Size 114.00 GiB / not usable 4.00 MiB
 Allocatable yes
 PE Size 4.00 MiB
 Total PE 29184
 Free PE 7424
 Allocated PE 21760
 PV UUID mExRS4-yLkj-8mq6-LTug-d4xZ-fwHl-2kYob3

 --- Physical volume ---
 PV Name /dev/sda3
 VG Name VGExaDb
 PV Size 1.52 TiB / not usable 1.95 MiB
 Allocatable yes
 PE Size 4.00 MiB
 Total PE 399124
 Free PE 347924
 Allocated PE 51200
 PV UUID HWptgO-6DEq-P2Tf-IJlK-tHyH-wnzn-8NoO8F

vgdisplay komutu ile bu fiziksel diskler üzerinde tanımlanmış logical volume grupları görebiliriz. Mevcut sistemde VGExaDb isminmde bir adet volume grubumuz var. Free PE alanında gördüğümüz VGExaDb  volume grubumuzun üzere de 1.3 TB boş alan var. Bu alan gerektiği anlarda mevcut disklerin snapshotlarını alabilmemiz veya yeni disk ekleyebilmemiz için boş olarak geliyor.

root@exadata_node1 ~]#vgdisplay
 --- Volume group ---
 VG Name VGExaDb
 System ID
 Format lvm2
 Metadata Areas 2
 Metadata Sequence No 17
 VG Access read/write
 VG Status resizable
 MAX LV 0
 Cur LV 6
 Open LV 4
 Max PV 0
 Cur PV 2
 Act PV 2
 VG Size 1.63 TiB
 PE Size 4.00 MiB
 Total PE 428308
 Alloc PE / Size 72960 / 285.00 GiB
 Free PE / Size 355348 / 1.36 TiB
 VG UUID V4rqmL-Efaq-ASFt-jo6a-46Cs-VS9B-uTaUPr

lvdisplay komutu ile de volume gruplarımız üzerindeki lofical volumeleri listeleyebiliriz. tek bir logical volume listelemek için lvdisplay LV Path olarak da çalıştırabiliriz. Liste uzun olduğundan sadece LVDbOra1 için çıktıyı paylaşıyorum.

root@exadata_node1 ~]#lvdisplay /dev/VGExaDb/LVDbOra1
 --- Logical volume ---
 LV Path /dev/VGExaDb/LVDbOra1
 LV Name LVDbOra1
 VG Name VGExaDb
 LV UUID W6gknw-WoKo-LuzB-G1Ov-aIBP-uNlZ-L9yeo9
 LV Write Access read/write
 LV Creation host, time exadata_node1.kkbdomain.com, 2017-03-07 14:30:19 +0300
 LV Status available
 # open 1
 LV Size 100.00 GiB
 Current LE 25600
 Segments 1
 Allocation inherit
 Read ahead sectors auto
 - currently set to 256
 Block device 251:3

Sistemde bu kontrolleri yaptıktan sonra adım adım yeni diskimizi oluşturabiliriz. Bunun için kullanacağımız komut lvm lvcreate komutu. Bu komuta -n parametresi ile logical volume ismini -l parametresi ile size bilgisini ve volume grup bilgisini ileteceğiz. Biz mevcut sistemimizde bir adet /u02 oluşturduğumuz için örnekte yeni diskimizi /u03 olarak oluşturacağız.

lvm lvcreate -n LVDbOra3 -L100G VGExaDb

,

Oluşturduğumuz logical volume’u aşağıdaki gibi kontrol edebiliriz.

/u01 diskgrubumuz ext4 olarak formatlandığı için yeni disk grubumuzu da ext4 olarak formatlayacağız.

formatladığımız diske label atamak için e2label komutunu kullanacağız.

e2label /dev/VGExaDb/LVDbOra3 DBORA3

Sunucu reboot olduğunda yeni diskimizin otomatik mount olması için gerekli bilgileri fstab a yazmamız gerekiyor. Burada her ihtimale karşı fstabın bir yedeğini alabilirsiniz. eklenecek satır LABEL=DBORA3 /u03 ext4 defaults,nodev 1 1

root@exadata_node1 ~]#vi /etc/fstab

Root dizini altında bir adet /u03 dizini oluşturarak diskimizi buraya mount ediyoruz. Ve /u01 diskinin owner’ı root:oinstall olduğu için yeni diskimizin owner’ını da bu şekilde düzenliyoruz.

mkdir /u03

mount -t ext4 /dev/VGExaDb/LVDbOra3 /u03 
ya da 
mount -a

chgrp oinstall /u03

İşlemler bir db node üzerinde tamamlandığında diğer nodelar üzerinde de aynı işlemleri tekrarlamamız gerekiyor. Eklediğimiz bu yeni disklerde farklı versiyonlarda oracle home lar kullanarak ihtiyaca göre birbirinden yalıtabiliriz.

 

 

12.2.0.1 grid üzerine 11.2.0.4 database kurulumunda PRVF-4037 hatası

PRVF-4037 hatası 11.2.0.3 versiyonundan beri bazı kurulumlarda ve clustera node eklerken yaşanabiliyor. Hatayı aldığınızda benzer semptromlar görüyorsanız bu yazımdaki çözümü uygulayabilirsiniz.

12.2.0.1 grid üzerine 11.2.0.4 database kurulumu yaparken prerequsite  check adımında aşağıda görülen hataları aldık.

More details alanına tıkladığımızda Hata detaylarının aşağıdaki gibi olduğunu gördük.

Error:

PRVF-4037 : CRS is not installed on any of the nodes  – Cause:  Could not identify a CRS installation on any node.  – Action:  Ensure that CRS is installed on all the nodes participating in the operation.

Operation Failed on Nodes: [exadata_node2, exadata_node1]
Verification result of failed node: exadata_node2

Details:

PRVF-7593 : CRS is not found to be installed on node “exadata_node2”  – Cause:  Could not identify CRS installation on the specified node.  – Action:  Ensure that CRS is installed on the specified node.
Back to Top
Verification result of failed node: exadata_node1

Details:

PRVF-7593 : CRS is not found to be installed on node “exadata_node1”  – Cause:  Could not identify CRS installation on the specified node.  – Action:  Ensure that CRS is installed on the specified node.
Back to Top

Hata mesajından yola çıkarak 12.2 grid ortamımızın integrity kontrollerini yaptık.

cluvfy comp crs

cluvfy comp ocr

Komutlar sonucunda crs ve ocr da bir problem olmadığını görüyoruz.

Bunun üzerine installer ın neye takıldığını analamak için oracle inventory altındaki  installActions logunu kontrol ediyoruz. Burada gördüğümüz kadarıyla Cluster nodes parametresi boş olarak gelmiş görünüyor.

Bunun sebebini anlamak için  /u01/app/oraInventory/ContentsXML altındaki inventory.xml dosyasını kontrol ediyoruz. We bu dosya altında da cluster nodeların tanımlı olmadığını görüyoruz.

<?xml version="1.0" standalone="yes" ?>
<!-- Copyright (c) 1999, 2017, Oracle and/or its affiliates.
All rights reserved. -->
<!-- Do not modify the contents of this file by hand. -->
<INVENTORY>
<VERSION_INFO>
 <SAVED_WITH>12.2.0.1.4</SAVED_WITH>
 <MINIMUM_VER>2.1.0.6.0</MINIMUM_VER>
</VERSION_INFO>
<HOME_LIST>
<HOME NAME="OraGI12Home1" LOC="/u01/app/12.2.0.1/grid" TYPE="O" IDX="1" CRS="true"/>
<HOME NAME="OraDB12Home1" LOC="/u01/app/oracle/product/12.2.0.1/dbhome_1" TYPE="O" IDX="2"/>
</HOME_LIST>
<COMPOSITEHOME_LIST>
</COMPOSITEHOME_LIST>
</INVENTORY>

Bu hatayı düzeltmek için grid home altında aşağıdaki komutu çalıştırıyoruz.

$GRID_HOME/oui/bin/runInstaller -silent -ignoreSysPrereqs -updateNodeList ORACLE_HOME=$GRID_HOME "CLUSTER_NODES={exadata_node1,exadata_node2}" CRS=true

Komutu çalıştırdıktan sonra inventory.xml dosyasını tekrar kontrol ettiğimizde cluster node ların artık burada set edildiğini görüyoruz.

<?xml version="1.0" standalone="yes" ?>
<!-- Copyright (c) 1999, 2017, Oracle and/or its affiliates.
All rights reserved. -->
<!-- Do not modify the contents of this file by hand. -->
<INVENTORY>
<VERSION_INFO>
 <SAVED_WITH>12.2.0.1.4</SAVED_WITH>
 <MINIMUM_VER>2.1.0.6.0</MINIMUM_VER>
</VERSION_INFO>
<HOME_LIST>
<HOME NAME="OraGI12Home1" LOC="/u01/app/12.2.0.1/grid" TYPE="O" IDX="1" CRS="true"/>
 <NODE_LIST>
 <NODE NAME="exadata_node1"/>
 <NODE NAME="exadata_node2"/>
 </NODE_LIST>
</HOME>
<HOME NAME="OraDB12Home1" LOC="/u01/app/oracle/product/12.2.0.1/dbhome_1" TYPE="O" IDX="2"/>
</HOME_LIST>
<COMPOSITEHOME_LIST>
</COMPOSITEHOME_LIST>
</INVENTORY>

11.2.0.4 kurulumunu tekrar denediğimizde de bu sefer hiçbir uyarı almadan kurulumumuzu tamamlıyoruz.

Bu komutu oracle support üzerinde   1316815.1  numaralı not içerisinde bulduk. Daha önceki bir versiyonda bir bug için önerilmiş. Siz de kurulumda benzer bir hata ile karşılaşıp aynı semptomları gözlerseniz bu komutu kullanbilirsiniz.

Exadata parça değişimi için asm etkilenmeden cell node kapatıp açma

Exadata cell sunucu üzerinde bir parça değişimi ya da restart  işlemlerinin , ASM’i etkilemeden yapılması için öncelikle ASM üzerinde disk_repair_time parametresi kontrol edilmelidir.

Bunun için ASM ortamına bağlanıp aşağıdaki komut ile değer kontrol edilmelidir.

[oracle@exadata_dbnode1~]$ sqlplus / as sysasm

SQL*Plus: Release 11.2.0.4.0 Production on Mon Feb 27 11:25:49 2017
Copyright (c) 1982, 2013, Oracle. All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Real Application Clusters and Automatic Storage Management options

SQL> select dg.name,a.value from v$asm_diskgroup dg, v$asm_attribute a where dg.group_number=a.group_number and a.name='disk_repair_time';

NAME VALUE
------------------------------
DATA_DM 3.6H
DBFS_DG 3.6H
RECO_DM 3.6H

Bizim sistemimizde bu değer 3.6 saat görünüyor. Yani bi bakım işlemi esnasında cell server 3.6 saat kapalı kalsa bile asm diskleri drop edip yeniden rebalance başlatmıyor. 3.6 saat içerisinde CELL üzerindeki diskler tekrar online olduğunda sadece resync işlemi yaparak çalışmaya devam ediyor.

Eğer bakım işleminiz daha uzun sürecekse bu değeri aşağıdaki komut ile arttırabilirsiniz.

SQL> ALTER DISKGROUP DATA_DM SET ATTRIBUTE 'DISK_REPAIR_TIME'='8.5H';

Bakım işlemine başlanmadan önce kesinlikle aşağıdaki komut ile disklerin offline duruma çekilebilir olup olmadıklarını kontrol etmeliyiz. Aşağıdaki komut tüm diskler için yes olarak dönmelidir.

[root@exadata_celnode3 tmp]# cellcli -e list griddisk attributes name,asmmodestatus,asmdeactivationoutcome
 DATA_DM_CD_00_exadata_celnode3 ONLINE Yes
 DATA_DM_CD_01_exadata_celnode3 ONLINE Yes
 DATA_DM_CD_02_exadata_celnode3 ONLINE Yes
 DATA_DM_CD_03_exadata_celnode3 ONLINE Yes
 DATA_DM_CD_04_exadata_celnode3 ONLINE Yes
 DATA_DM_CD_05_exadata_celnode3 ONLINE Yes
 DATA_DM_CD_06_exadata_celnode3 ONLINE Yes
 DATA_DM_CD_07_exadata_celnode3 ONLINE Yes
 DATA_DM_CD_08_exadata_celnode3 ONLINE Yes
 DATA_DM_CD_09_exadata_celnode3 ONLINE Yes
 DATA_DM_CD_10_exadata_celnode3 ONLINE Yes
 DATA_DM_CD_11_exadata_celnode3 ONLINE Yes
 DBFS_DG_CD_02_exadata_celnode3 ONLINE Yes
 DBFS_DG_CD_03_exadata_celnode3 ONLINE Yes
 DBFS_DG_CD_04_exadata_celnode3 ONLINE Yes
 DBFS_DG_CD_05_exadata_celnode3 ONLINE Yes
 DBFS_DG_CD_06_exadata_celnode3 ONLINE Yes
 DBFS_DG_CD_07_exadata_celnode3 ONLINE Yes
 DBFS_DG_CD_08_exadata_celnode3 ONLINE Yes
 DBFS_DG_CD_09_exadata_celnode3 ONLINE Yes
 DBFS_DG_CD_10_exadata_celnode3 ONLINE Yes
 DBFS_DG_CD_11_exadata_celnode3 ONLINE Yes
 RECO_DM_CD_00_exadata_celnode3 ONLINE Yes
 RECO_DM_CD_01_exadata_celnode3 ONLINE Yes
 RECO_DM_CD_02_exadata_celnode3 ONLINE Yes
 RECO_DM_CD_03_exadata_celnode3 ONLINE Yes
 RECO_DM_CD_04_exadata_celnode3 ONLINE Yes
 RECO_DM_CD_05_exadata_celnode3 ONLINE Yes
 RECO_DM_CD_06_exadata_celnode3 ONLINE Yes
 RECO_DM_CD_07_exadata_celnode3 ONLINE Yes
 RECO_DM_CD_08_exadata_celnode3 ONLINE Yes
 RECO_DM_CD_09_exadata_celnode3 ONLINE Yes
 RECO_DM_CD_10_exadata_celnode3 ONLINE Yes
 RECO_DM_CD_11_exadata_celnode3 ONLINE Yes

Eğer disklerden birinde bile asmdeactivationoutcome=yes dönmezse işleme başlamadan önce bu diskin miror’ı ile yedeklemesinin düzgün olduğu kontrol edilmeli ve bir problem varsa düzeltilmelidir.

Yedekleme tamamlandığında komut tekrar çekilerek, tüm değerlerin yes olarak döndüğü kontrol edildikten sonra, diskleri offline duruma çekebiliriz.  Bu işlem disklerdeki aktiviteye göre 10 dakikaya kadar sürebilir.  Bakım yapılacak cell kapatılmadan önce tüm disklerin inactive duruma geçtiğini kontrol etmek çok önemlidir.  Diskleri cell üzerinde inactive etmek ASM de disklerin otomatik olarak offline olmasını sağlayacaktır. Bakım yapacağımız sunucuda Diskleri offline duruma çekmek için aşağıdaki komutu cellcli üzerinde çalıştırmamız gerekiyor.

cellcli -e alter griddisk all inactive

Aşağıdaki komut ile Disklerin asmmodestatus = offline ya da UNUSED  olduğu ve asmdeactivationoutcome=yes olarak döndüğü teyit edilir.

[root@exadata_celnode3 tmp]# cellcli -e list griddisk attributes name,asmmodestatus,asmdeactivationoutcome
 DATA_DM_CD_00_exadata_celnode3 OFFLINE Yes
 DATA_DM_CD_01_exadata_celnode3 OFFLINE Yes
 DATA_DM_CD_02_exadata_celnode3 OFFLINE Yes
 DATA_DM_CD_03_exadata_celnode3 OFFLINE Yes
 DATA_DM_CD_04_exadata_celnode3 OFFLINE Yes
 DATA_DM_CD_05_exadata_celnode3 OFFLINE Yes
 DATA_DM_CD_06_exadata_celnode3 OFFLINE Yes
 DATA_DM_CD_07_exadata_celnode3 OFFLINE Yes
 DATA_DM_CD_08_exadata_celnode3 OFFLINE Yes
 DATA_DM_CD_09_exadata_celnode3 OFFLINE Yes
 DATA_DM_CD_10_exadata_celnode3 OFFLINE Yes
 DATA_DM_CD_11_exadata_celnode3 OFFLINE Yes
 DBFS_DG_CD_02_exadata_celnode3 OFFLINE Yes
 DBFS_DG_CD_03_exadata_celnode3 OFFLINE Yes
 DBFS_DG_CD_04_exadata_celnode3 OFFLINE Yes
 DBFS_DG_CD_05_exadata_celnode3 OFFLINE Yes
 DBFS_DG_CD_06_exadata_celnode3 OFFLINE Yes
 DBFS_DG_CD_07_exadata_celnode3 OFFLINE Yes
 DBFS_DG_CD_08_exadata_celnode3 OFFLINE Yes
 DBFS_DG_CD_09_exadata_celnode3 OFFLINE Yes
 DBFS_DG_CD_10_exadata_celnode3 OFFLINE Yes
 DBFS_DG_CD_11_exadata_celnode3 OFFLINE Yes
 RECO_DM_CD_00_exadata_celnode3 OFFLINE Yes
 RECO_DM_CD_01_exadata_celnode3 OFFLINE Yes
 RECO_DM_CD_02_exadata_celnode3 OFFLINE Yes
 RECO_DM_CD_03_exadata_celnode3 OFFLINE Yes
 RECO_DM_CD_04_exadata_celnode3 OFFLINE Yes
 RECO_DM_CD_05_exadata_celnode3 OFFLINE Yes
 RECO_DM_CD_06_exadata_celnode3 OFFLINE Yes
 RECO_DM_CD_07_exadata_celnode3 OFFLINE Yes
 RECO_DM_CD_08_exadata_celnode3 OFFLINE Yes
 RECO_DM_CD_09_exadata_celnode3 OFFLINE Yes
 RECO_DM_CD_10_exadata_celnode3 OFFLINE Yes
 RECO_DM_CD_11_exadata_celnode3 OFFLINE Yes

asmmodestatus=offline olduktan sonra Griddisklerin inactive olduğu kontrol edilir.

 [root@exadata_celnode3 tmp]# cellcli -e list griddisk
 DATA_DM_CD_00_exadata_celnode3 inactive
 DATA_DM_CD_01_exadata_celnode3 inactive
 DATA_DM_CD_02_exadata_celnode3 inactive
 DATA_DM_CD_03_exadata_celnode3 inactive
 DATA_DM_CD_04_exadata_celnode3 inactive
 DATA_DM_CD_05_exadata_celnode3 inactive
 DATA_DM_CD_06_exadata_celnode3 inactive
 DATA_DM_CD_07_exadata_celnode3 inactive
 DATA_DM_CD_08_exadata_celnode3 inactive
 DATA_DM_CD_09_exadata_celnode3 inactive
 DATA_DM_CD_10_exadata_celnode3 inactive
 DATA_DM_CD_11_exadata_celnode3 inactive
 DBFS_DG_CD_02_exadata_celnode3 inactive
 DBFS_DG_CD_03_exadata_celnode3 inactive
 DBFS_DG_CD_04_exadata_celnode3 inactive
 DBFS_DG_CD_05_exadata_celnode3 inactive
 DBFS_DG_CD_06_exadata_celnode3 inactive
 DBFS_DG_CD_07_exadata_celnode3 inactive
 DBFS_DG_CD_08_exadata_celnode3 inactive
 DBFS_DG_CD_09_exadata_celnode3 inactive
 DBFS_DG_CD_10_exadata_celnode3 inactive
 DBFS_DG_CD_11_exadata_celnode3 inactive
 RECO_DM_CD_00_exadata_celnode3 inactive
 RECO_DM_CD_01_exadata_celnode3 inactive
 RECO_DM_CD_02_exadata_celnode3 inactive
 RECO_DM_CD_03_exadata_celnode3 inactive
 RECO_DM_CD_04_exadata_celnode3 inactive
 RECO_DM_CD_05_exadata_celnode3 inactive
 RECO_DM_CD_06_exadata_celnode3 inactive
 RECO_DM_CD_07_exadata_celnode3 inactive
 RECO_DM_CD_08_exadata_celnode3 inactive
 RECO_DM_CD_09_exadata_celnode3 inactive
 RECO_DM_CD_10_exadata_celnode3 inactive
 RECO_DM_CD_11_exadata_celnode3 inactive

Tüm disklerin inactive olduğu teyit edildikten sonra cell sunucu aşağıdaki komut ile shutdown edilir edilir. Sistem shutdown edilirken tüm storage servisleri otomatik olarak kapatılır.

#shutdown -h now

The system is going down for system halt NOW!

Bakım işlemleri yapıldıktan sonra sunucu power düğmesinden veya ilom üzerinden açılır. Sunucu açılırken konsol  ekranını takip etmek için ilom üzerinden consola bağlanabiliriz. Bunun için ilom sunucuya root user ile ssh üzerinden login olduktan sonra aşağıdaki komutu çalıştırmamız gerekir.

start /sp/console

Sunucu açıldıktan sonra aşağıdaki komut ile diskler tekrar aktive edilir.

cellcli -e alter griddisk all active

Komut çalıştırıldıktan sonra disklerin active duruma geçip geçmedikleri kontrol edilir.

[root@exadata_celnode3 tmp]# cellcli -e list griddisk
 DATA_DM_CD_00_exadata_celnode3 active
 DATA_DM_CD_01_exadata_celnode3 active
 DATA_DM_CD_02_exadata_celnode3 active
 DATA_DM_CD_03_exadata_celnode3 active
 DATA_DM_CD_04_exadata_celnode3 active
 DATA_DM_CD_05_exadata_celnode3 active
 DATA_DM_CD_06_exadata_celnode3 active
 DATA_DM_CD_07_exadata_celnode3 active
 DATA_DM_CD_08_exadata_celnode3 active
 DATA_DM_CD_09_exadata_celnode3 active
 DATA_DM_CD_10_exadata_celnode3 active
 DATA_DM_CD_11_exadata_celnode3 active
 DBFS_DG_CD_02_exadata_celnode3 active
 DBFS_DG_CD_03_exadata_celnode3 active
 DBFS_DG_CD_04_exadata_celnode3 active
 DBFS_DG_CD_05_exadata_celnode3 active
 DBFS_DG_CD_06_exadata_celnode3 active
 DBFS_DG_CD_07_exadata_celnode3 active
 DBFS_DG_CD_08_exadata_celnode3 active
 DBFS_DG_CD_09_exadata_celnode3 active
 DBFS_DG_CD_10_exadata_celnode3 active
 DBFS_DG_CD_11_exadata_celnode3 active
 RECO_DM_CD_00_exadata_celnode3 active
 RECO_DM_CD_01_exadata_celnode3 active
 RECO_DM_CD_02_exadata_celnode3 active
 RECO_DM_CD_03_exadata_celnode3 active
 RECO_DM_CD_04_exadata_celnode3 active
 RECO_DM_CD_05_exadata_celnode3 active
 RECO_DM_CD_06_exadata_celnode3 active
 RECO_DM_CD_07_exadata_celnode3 active
 RECO_DM_CD_08_exadata_celnode3 active
 RECO_DM_CD_09_exadata_celnode3 active
 RECO_DM_CD_10_exadata_celnode3 active
 RECO_DM_CD_11_exadata_celnode3 active

Tüm disklerin online duruma geçip geçmedikleri aşağıdaki komut ile takip edilir. Yoğun kullanılan sistemlerde diskler uzun süre SYNCING işlemi yapabilir. SYNCING işlemi tamamlandığında disklerin otomatik olarak ONLINE duruma geçmesi gerekir.

[root@exadata_celnode1 tmp]# cellcli -e list griddisk attributes name,asmmodestatus
 DATA_DM_CD_00_exadata_celnode3 SYNCING
 DATA_DM_CD_01_exadata_celnode3 SYNCING
 DATA_DM_CD_02_exadata_celnode3 SYNCING
 DATA_DM_CD_03_exadata_celnode3 SYNCING
 DATA_DM_CD_04_exadata_celnode3 SYNCING
 DATA_DM_CD_05_exadata_celnode3 SYNCING
 DATA_DM_CD_06_exadata_celnode3 SYNCING
 DATA_DM_CD_07_exadata_celnode3 SYNCING
 DATA_DM_CD_08_exadata_celnode3 SYNCING
 DATA_DM_CD_09_exadata_celnode3 SYNCING
 DATA_DM_CD_10_exadata_celnode3 SYNCING
 DATA_DM_CD_11_exadata_celnode3 SYNCING
 DBFS_DG_CD_02_exadata_celnode3 SYNCING
 DBFS_DG_CD_03_exadata_celnode3 SYNCING
 DBFS_DG_CD_04_exadata_celnode3 SYNCING
 DBFS_DG_CD_05_exadata_celnode3 SYNCING
 DBFS_DG_CD_06_exadata_celnode3 SYNCING
 DBFS_DG_CD_07_exadata_celnode3 SYNCING
 DBFS_DG_CD_08_exadata_celnode3 SYNCING
 DBFS_DG_CD_09_exadata_celnode3 SYNCING
 DBFS_DG_CD_10_exadata_celnode3 SYNCING
 DBFS_DG_CD_11_exadata_celnode3 SYNCING
 RECO_DM_CD_00_exadata_celnode3 SYNCING
 RECO_DM_CD_01_exadata_celnode3 SYNCING
 RECO_DM_CD_02_exadata_celnode3 SYNCING
 RECO_DM_CD_03_exadata_celnode3 SYNCING
 RECO_DM_CD_04_exadata_celnode3 SYNCING
 RECO_DM_CD_05_exadata_celnode3 SYNCING
 RECO_DM_CD_06_exadata_celnode3 SYNCING
 RECO_DM_CD_07_exadata_celnode3 SYNCING
 RECO_DM_CD_08_exadata_celnode3 SYNCING
 RECO_DM_CD_09_exadata_celnode3 SYNCING
 RECO_DM_CD_10_exadata_celnode3 SYNCING
 RECO_DM_CD_11_exadata_celnode3 SYNCING

SYNCING operasyonu, rebalance işlemi yapmamaktadır. Sadece disk offline olduğu süreçte miror da yazılan blokları online olan disklere yazmaktadır.

Eğer bakım işlemi rolling olarak yapılacaksa bir sonraki cell  sunucusuna geçmeden önce SYNCING işleminin tamamlandığı ve asmdeactivationoutcome parametresinin yes olduğu kontrol edilmelidir. SYNCING işlemi devam ederken asmdeactivationoutcome çıktısı “Cannot de-activate due to other offline disks in the diskgroup” şeklinde gelir.

Örnek ekran görüntüsü:

[root@exadata_celnode3 tmp]# cellcli -e list griddisk attributes name where asmdeactivationoutcome != 'Yes'
 DATA_DM_CD_00_exadata_celnode3 "Cannot de-activate due to other offline disks in the diskgroup"
 DATA_DM_CD_01_exadata_celnode3 "Cannot de-activate due to other offline disks in the diskgroup"
 DATA_DM_CD_02_exadata_celnode3 "Cannot de-activate due to other offline disks in the diskgroup"
 DATA_DM_CD_03_exadata_celnode3 "Cannot de-activate due to other offline disks in the diskgroup"
 DATA_DM_CD_04_exadata_celnode3 "Cannot de-activate due to other offline disks in the diskgroup"
 DATA_DM_CD_05_exadata_celnode3 "Cannot de-activate due to other offline disks in the diskgroup"
 DATA_DM_CD_06_exadata_celnode3 "Cannot de-activate due to other offline disks in the diskgroup"
 DATA_DM_CD_07_exadata_celnode3 "Cannot de-activate due to other offline disks in the diskgroup"
 DATA_DM_CD_08_exadata_celnode3 "Cannot de-activate due to other offline disks in the diskgroup"
 DATA_DM_CD_09_exadata_celnode3 "Cannot de-activate due to other offline disks in the diskgroup"
 DATA_DM_CD_10_exadata_celnode3 "Cannot de-activate due to other offline disks in the diskgroup"
 DATA_DM_CD_11_exadata_celnode3 "Cannot de-activate due to other offline disks in the diskgroup"
 DBFS_DG_CD_02_exadata_celnode3 "Cannot de-activate due to other offline disks in the diskgroup"
 DBFS_DG_CD_03_exadata_celnode3 "Cannot de-activate due to other offline disks in the diskgroup"
 DBFS_DG_CD_04_exadata_celnode3 "Cannot de-activate due to other offline disks in the diskgroup"
 DBFS_DG_CD_05_exadata_celnode3 "Cannot de-activate due to other offline disks in the diskgroup"
 DBFS_DG_CD_06_exadata_celnode3 "Cannot de-activate due to other offline disks in the diskgroup"
 DBFS_DG_CD_07_exadata_celnode3 "Cannot de-activate due to other offline disks in the diskgroup"
 DBFS_DG_CD_08_exadata_celnode3 "Cannot de-activate due to other offline disks in the diskgroup"
 DBFS_DG_CD_09_exadata_celnode3 "Cannot de-activate due to other offline disks in the diskgroup"
 DBFS_DG_CD_10_exadata_celnode3 "Cannot de-activate due to other offline disks in the diskgroup"
 DBFS_DG_CD_11_exadata_celnode3 "Cannot de-activate due to other offline disks in the diskgroup"
 RECO_DM_CD_00_exadata_celnode3 "Cannot de-activate due to other offline disks in the diskgroup"
 RECO_DM_CD_01_exadata_celnode3 "Cannot de-activate due to other offline disks in the diskgroup"
 RECO_DM_CD_02_exadata_celnode3 "Cannot de-activate due to other offline disks in the diskgroup"
 RECO_DM_CD_03_exadata_celnode3 "Cannot de-activate due to other offline disks in the diskgroup"
 RECO_DM_CD_04_exadata_celnode3 "Cannot de-activate due to other offline disks in the diskgroup"
 RECO_DM_CD_05_exadata_celnode3 "Cannot de-activate due to other offline disks in the diskgroup"
 RECO_DM_CD_06_exadata_celnode3 "Cannot de-activate due to other offline disks in the diskgroup"
 RECO_DM_CD_07_exadata_celnode3 "Cannot de-activate due to other offline disks in the diskgroup"
 RECO_DM_CD_08_exadata_celnode3 "Cannot de-activate due to other offline disks in the diskgroup"
 RECO_DM_CD_09_exadata_celnode3 "Cannot de-activate due to other offline disks in the diskgroup"
 RECO_DM_CD_10_exadata_celnode3 "Cannot de-activate due to other offline disks in the diskgroup"
 RECO_DM_CD_11_exadata_celnode3 "Cannot de-activate due to other offline disks in the diskgroup"

Detaylı bilgi için Oracle Support üzerinde Doc ID 1188080.1 incelenebilir.

 

Oracle veritabanında bir kullanıcıya başka bir şemada yetki vermek

Oracle veritabanlarında bir kullanıcıya başka bir kullanıcının objeleri üzerinde yetki vermek için, normal şartlarda objelere tek tek yetki vermeniz gerekir. Ancak bu yöntemde yeni eklenen objeler için ayrıca yetki verilmesi gerekmektedir.

Bunun yanında bir kullanıcıya başka bir kullanıcının altında  DDL (Data Definition Language) yetkisi vermek için ise tüm diğer şemalarda DDL yetkisi vermek gerekiyor.

Bu işlem de güvenlik ve kontrol açısından zaaflar doğuruyor.

Yazının devamında verilen DDL yetkilerini belirli bir şema ile sınırlamak ve yeni oluşan objelere otomatik DML yetkilerini vermek için yazdığım bazı prosedür ve triggerları paylaşacağım. Bu yapıyı ortak şema kullanması gereken bir yazılım yada raporlama grubu için rahatlıkla kullanbilirsiniz.

Senaryomuzda User1, User2 ve User3  isminde üç kullanıcımız olacak. User1 ve User2 kullanıcılarına User3 kullanıcısı üzerinde obje oluşturma ve okuma yazma gibi yetkileri vereceğiz. Kullanıcıları oluşturmak için username’i değiştirerek aşağıdaki sciprti kullanbilirsiniz.

CREATE USER USER1
 IDENTIFIED by test
 DEFAULT TABLESPACE USERS
 TEMPORARY TABLESPACE TEMP
 PROFILE DEFAULT
 ACCOUNT UNLOCK;
 -- 2 Roles for USER1 
 GRANT CONNECT TO USER1;
 ALTER USER USER1 DEFAULT ROLE ALL;
 -- 1 System Privilege for USER1 
 GRANT UNLIMITED TABLESPACE TO USER1;

Gördüğünüz gibi ilk etapta kullanıcılarımıza bir yetki vermedik. Sysdba hakkına sahip bir kullanıcı ile sisteme bağlanarak aşağıdaki sciptleri çalıştırıyoruz. Bu scriptler ile önce USER1 ve USER2 ye tüm şemalarda create ve drop table yetkisi veriyoruz. Daha sonra da bu yetkiyi sadece kendi şemalarında ve USER3 altında kullanabilecekleri şekilde kısıtlayacak bir trigger yazıyoruz.

grant create any table to user1;
grant create any table to user2;

grant drop any table to user1;
grant drop any table to user2;


CREATE OR REPLACE TRIGGER SYS.DDL_TRIGGER_USER1 BEFORE DDL ON USER1.SCHEMA
BEGIN
 -- USER1 için ddl('CREATE','ALTER','DROP','TRUNCATE','RENAME') yapılabilecek şemaları USER1 ve USER3 ile kısıtlar 
 IF ora_dict_obj_owner NOT IN ('USER1','USER3') AND ora_sysevent IN ('CREATE','ALTER','DROP','TRUNCATE','RENAME') THEN
 raise_application_error(-20001 , 'USER2 şeması haricinde Bu islem yapilamaz.');
 END IF;

END;
/


CREATE OR REPLACE TRIGGER SYS.DDL_TRIGGER_USER2 BEFORE DDL ON USER2.SCHEMA
BEGIN
 -- USER2 için ddl('CREATE','ALTER','DROP','TRUNCATE','RENAME') yapılabilecek şemaları USER2 ve USER3 ile kısıtlar 
 IF ora_dict_obj_owner NOT IN ('USER2','USER3') AND ora_sysevent IN ('CREATE','ALTER','DROP','TRUNCATE','RENAME') THEN
 raise_application_error(-20001 , 'USER3 şeması haricinde Bu islem yapilamaz.');
 END IF;

END;
/

Hakları verip triggerı oluşturduktan sonra aşağıdaki şekilde deneme yapabiliriz. Deneme sonucunda USER1 ile USER3 şeması altında tablo oluşturabilirken, USER2 altında oluşturamadığımızı görüyoruz.

-bash-4.1$ sqlplus user1/test@tahsinc
SQL*Plus: Release 11.2.0.3.0 Production on Wed Feb 15 16:00:18 2017
Copyright (c) 1982, 2011, Oracle. All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> create table user3.deneme ( a varchar2(10));

Table created.

SQL>
SQL> create table user2.deneme ( a varchar2(10));
create table user2.deneme ( a varchar2(10))
*
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-20001: USER3 şeması haricinde Bu islem yapilamaz.
ORA-06512: at line 4

SQL>

 

 

USER1 ve USER2 ye User3 altında oluşan ve gelecekte oluşacak tüm tablolara yetki vermek için aşağıda tanımladığımız proesdürü ve trigger’ı oluşturmamız gerekiyor. Aşağıda oluşturduğumuz prosedür ile tablo ismi ve owner bilgisini alarak bu tablolarda USER1 ve USER2 ye yetki veren bir prosedür oluşturduk.

CREATE OR REPLACE PROCEDURE SYS.USER3_GRANT
(p_table_name IN VARCHAR2,p_table_owner IN VARCHAR2) IS
BEGIN
EXECUTE IMMEDIATE 'grant select,insert,update,delete on ' ||p_table_owner||'.'||p_table_name || ' to USER1';
EXECUTE IMMEDIATE 'grant select,insert,update,delete on ' ||p_table_owner||'.'||p_table_name || ' to USER2';
END;
/

Şimdi de bu prosedürü USER3 Altında bir obje oluşturulduğunda çağıracak triggerları yazacağız. Bizim senaryomuzda USER3 altına tablo oluşturabilen 3 user olduğundan bu üç user için birer trigger oluşturduk.

Not: Burada trigger içerisinde yaptığımız grant işlemini, obje oluştuktan 1 saniye sonra çalışacak şekilde set ettik. Eğer bunu yapmazsak obje tam oluşturulmadan grant vermeye çalışarak hata alabiliyor.

CREATE OR REPLACE TRIGGER SYS.DDL_TRIGGER_USER1_GRANT AFTER CREATE ON USER1.SCHEMA
declare l_jobno PLS_INTEGER;
BEGIN
 IF ora_dict_obj_owner IN ('USER3') and ora_dict_obj_type IN ('TABLE') THEN

 dbms_job.submit( l_jobno,
 'BEGIN USER3_GRANT( ''' || ora_dict_obj_name || ''' , ''' || ora_dict_obj_owner || ''' ); END;',
 sysdate + interval '1' second );
 END IF;
END;
/

CREATE OR REPLACE TRIGGER SYS.DDL_TRIGGER_USER2_GRANT AFTER CREATE ON USER2.SCHEMA
declare l_jobno PLS_INTEGER;
BEGIN
 IF ora_dict_obj_owner IN ('USER3') and ora_dict_obj_type IN ('TABLE') THEN

 dbms_job.submit( l_jobno,
 'BEGIN USER3_GRANT( ''' || ora_dict_obj_name || ''' , ''' || ora_dict_obj_owner || ''' ); END;',
 sysdate + interval '1' second );
 END IF;
END;
/

CREATE OR REPLACE TRIGGER SYS.DDL_TRIGGER_USER3_GRANT AFTER CREATE ON USER3.SCHEMA
declare l_jobno PLS_INTEGER;
BEGIN
 IF ora_dict_obj_owner IN ('USER3') and ora_dict_obj_type IN ('TABLE') THEN

 dbms_job.submit( l_jobno,
 'BEGIN USER3_GRANT( ''' || ora_dict_obj_name || ''' , ''' || ora_dict_obj_owner || ''' ); END;',
 sysdate + interval '1' second );
 END IF;
END;
/

Bunun yanında önceden oluşturulan tablolar için de bir kereliğine aşağıdaki scipri çalıştırıp;

select 'grant select on ' ||owner||'.'||table_name||' to USER1,USER2;' from dba_tables where owner in ('USER3');

Script sonucunda elde ettiğimiz outputu execute ederek geçmişte oluşturulmuş tablolara da yetki vermiş oluruz.

grant select on USER3.DENEME to USER1,USER2;

Bu sayede, select any table yetkisi vermeden veya tablo oluştuğunda manuel yetki vermemize gerek kalmadan, USER3 altındaki tüm objelere USER1 ve USER2 ile erişebileceğiz.

Şimdi testimizi yapalım. USER2 ile USER2 ve USER3 altına birer obje oluşturup sonrasında USER1 ile bu tablolardan select çekmeyi deneyeceğiz.

-bash-4.1$ sqlplus USER2/test@tahsinc

SQL*Plus: Release 11.2.0.3.0 Production on Wed Feb 15 16:45:10 2017
Copyright (c) 1982, 2011, Oracle. All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> create table user2.deneme ( a varchar2(10));

Table created.

SQL> create table user3.deneme ( a varchar2(10));

Table created.

SQL>
-bash-4.1$ sqlplus user1/test@tahsinc

SQL*Plus: Release 11.2.0.3.0 Production on Wed Feb 15 16:46:59 2017

Copyright (c) 1982, 2011, Oracle. All rights reserved.


Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> select * from user3.deneme;

no rows selected

SQL> select * from user2.deneme;
select * from user2.deneme
 *
ERROR at line 1:
ORA-01031: insufficient privileges

Sonuçta beklediğimiz gibi USER1, USER3 altında oluşan tabloya erişebilirken USER2 altında oluşan tabloya erişemiyor.

Bu prosedür ve trigger’ı ihtiyaçlarınız doğrultusunda modifiye ederek. Tüm şemlara yetki vermeden sadece  başka bir şema altındaki objelere yetki verebilirsiniz. Örneğin raporlama grubu için oluşturmanız gereken ortak bir şema bulunuyorsa bu sciptler çok işinize yarayacaktır.

 

Exadata db node üzerinde, e-mail alert ve asr tanımlarının yapılması

Db node için image versiyon 12.1.2 ve sonrasi ise dbmcli ile ‘list dbserver detail’ komutunu çalıştırarak, mevcut parametreleri kontrol edebilirsiniz. İlgili parametreler henüz ayarlanmadıysa bu komut ile görünmezler. Imageinfo komutu ile mevcut imaj versionunuzu görebilirsiniz.

[root@exadata_dbnode1 ~]# imageinfo

Kernel version: 2.6.39-400.243.1.el6uek.x86_64 #1 SMP Wed Nov 26 09:15:35 PST 2014 x86_64
Image version: 12.1.2.1.0.141206.1
Image status: success

Burada  ayarlanması gereken parametreler:

notificationMethod:     mail,snmp / /bir hata yada uyarı olduğunda hem mail ile uyarı yollar, hem de asr (automatic service request) servera sr açmak üzere bilgi yollar. Bu parametreyi  set etmek için:

dbmcli -e alter dbserver notificationMethod=\'mail,snmp\'

notificationPolicy: critical,warning,clear // burada uyarı verilecek olayların seviyeleri belirlenir. Bu parametreyi set etmek için.

dbmcli -e alter dbserver notificationPolicy='critical,warning,clear'

smtpFrom: exadata_dbnode1 // atılan maillerde görünecek isim. set etmek için:

dbmcli -e alter dbserver smtpFrom=\'exadata_dbnode1\'

smtpFromAddr: exadata_dbnode1@mehmettahsincan.com // atılan maillerde görünecek adres

dbmcli -e alter dbserver smtpFromAddr=\'exadata_dbnode1@mehmettahsincan.com\'

smtpPort: 25 // mail serverınızın portu. / bu bilgileri mail server  yöneticinizden alabilirsiniz. biz örnekte ssl kullanmadığımızdan portumuz ’25’. Bu parametreyi set etmek için

dbmcli -e alter dbserver smtpPort='25'

smtpServer:             mail.mehmettahsincan.com // mail server adresimiz. Bu parametreyi set etmek için.

dbmcli -e alter dbserver smtpServer='mail.mehmettahsincan.com'

smtpUseSSL: FALSE // mail için ssl kullanıp kullanmayacağımızı belirler aşağıdaki şekilde set edilir.

dbmcli -e alter dbserver smtpUseSSL='false'

snmpSubscriber:  // bu  parametre ile bir hata olduğunda otomatik sr açılmasını sağlayan asr serverımızın bilgilerini gireceğiz. Bu bilgileri asr server’ınızın ip ve port bilgileri ile doldurmanız gerekir.

dbmcli -e alter dbserver snmpSubcriber=((host='<ASR Manager host name orIP>',port=162,community=public,type=asr))

Ayarları yapılmış bir dbnode üzerinden örnek görüntü.

[root@exadata_dbnode1 ~]# dbmcli
DBMCLI: Release - Production on Fri Feb 10 14:46:01 EET 2017

Copyright (c) 2007, 2014, Oracle. All rights reserved.

DBMCLI> list dbserver detail
 name: exadata_dbnode1
 bbuStatus: normal
 coreCount: 18
 cpuCount: 36
 diagHistoryDays: 7
 fanCount: 16/16
 fanStatus: normal
 id: xxxxxx
 interconnectCount: 2
 interconnect1: ib0
 interconnect2: ib1
 ipaddress1: xxx.xxx.xxx.xxx/xxx
 ipaddress2: xxx.xxx.xxx.xxx/xxx
 kernelVersion: 2.6.39-400.243.1.el6uek.x86_64
 locatorLEDStatus: off
 makeModel: Oracle Corporation ORACLE SERVER X5-2
 metricHistoryDays: 7
 msVersion: OSS_12.1.2.1.0_LINUX.X64_141206.1
 notificationMethod: mail,snmp
 notificationPolicy: critical,warning,clear
 powerCount: 2/2
 powerStatus: normal
 releaseImageStatus: success
 releaseVersion: 12.1.2.1.0.141206.1
 releaseTrackingBug: xxxxx
 smtpFrom: exadata_dbnode1
 smtpFromAddr: exadata_dbnode1@mehmettahsincan.com
 smtpPort: 25
 smtpServer: mail.mehmettahsincan.com
 smtpToAddr: tahsincan@mehmettahsincan.com
 smtpUseSSL: FALSE
 snmpSubscriber: host=testasrsrv.mehmettahsincan.com,port=162,community=public,type=ASR
 status: online
 temperatureReading: 25.0
 temperatureStatus: normal
 upTime: 110 days, 23:44
 msStatus: running

Bu ayarlamaları yaptıktan sonra aşağıdaki komut ile test maili gönderebiliriz.

[root@exadata_dbnode1 ~]# dbmcli
DBMCLI: Release - Production on Fri Feb 10 15:13:39 EET 2017

Copyright (c) 2007, 2014, Oracle. All rights reserved.

DBMCLI>

DBMCLI> alter dbserver validate mail
DBServer exadata_dbnode1 successfully altered

 

Bu adımdan sonra, belirtilen mail adreslerine,  aşağıdaki gibi bir mail gelmesi gerekiyor.

DB Server exadata_dbnode1 Test Message

This test e-mail message from Oracle DB Server exadata_dbnode1 indicates successful configuration of your e-mail address and mail server.

Aynı şekilde asr ayarlarımızı da kontrol edebiliyoruz.

[root@exadata_dbnode1 ~]# dbmcli
DBMCLI: Release - Production on Fri Feb 10 15:13:39 EET 2017

Copyright (c) 2007, 2014, Oracle. All rights reserved.

DBMCLI>

DBMCLI> alter dbserver validate snmp type=asr
DBServer exadata_dbnode1 successfully altered

Oracle support hesabınızla Doc ID 1450112.1 id li  sayfadan indireceğiniz asrexachk tool’u ile de konfigürasyonlarınızı kontrol edebilirsiniz.

 

[root@exadata_dbnode1 ~]# /home/tahsinc/asrexachk

ASRExachk 3.2
Tue Feb 14 10:52:57 +03 2017
Hostname: exadata_dbnode1 
Device Type: Exadata Database Machine X5-2 xxxxxxx
Serial Number: xxxxxxxxx
Server Type: ORACLE-SERVER-X5-2
OS Type: LINUX
ASR Manager IP: xxx.xxx.xxx.xxx
SNMP Trap Destinations: ((host=testasrsrv.mehmettahsincan.com,port=162,community=public,type=ASR))
Exadata Node Image: Image version: 12.1.2.1.0.141206.1

#########ASR Validation#########
Linux DB Node IP Interface Check
 Validating ASR Manager IP to Interface bondeth0
 Validating ASR Manager IP to Interface eth0
 Validating ASR Manager IP to Interface eth5
 Validating ASR Manager IP to Interface ib0
 Validating ASR Manager IP to Interface ib1
 Validating ASR Manager IP to Interface lo

Management IP Interface check completed
 ASR is supported on this Management Interface configuration

Checking the BMC Status
 BMC Communication is Currently running

Checking for Pre-Existing Errors

Checking for HDD Faults
 No HDD Faults Found

Checking for FMA Faults
 No FMA faults found

Checking for ILOM Hardware Faults
 No Hardware ILOM Faults

DB Node validation Progress

 Checking for ASR/Exadata Process Running
Checking for Type of ASR

Validating ASR Configuration with Validate SNMP

DB OS Validation
 OS Test event sent to xxx.xxx.xxx.xxx
 #########Warning#########
 ASRExachk has determined that there was a failure during the SNMP Trap Verification.
 The failure will not inhibit the ability for ASR to create a SR but can cause delay
 Diagnostic time due to System Identifier missing.
 To fix this error, please open a Service Request with the Oracle Exadata Team

DB ILOM Validation
 ILOM Test event sent to xxx.xxx.xxx.xxx from xxx.xxx.xxx.xxx



Validation Complete
 Based on the Status, the email account registered to the ASR Manager
 should receive 2 emails. One from the OS Hostname, and the
 second from the ILOM Hostname
 If 2 emails has not been received, please work with the ASR Backline
 Team for further troubleshooting of the issue

[root@exadata_dbnode1 ~]#

 

Çıktıda da belirtildiği gibi işlem sonucunda ASR manager hesabına iki email gitmesi gerekiyor.

Yukarıda anlattığımız işlemlerde tanımları sadece bir db node üzerinde gerçekleştirdik. FULL rack bir sistemde aynı işlemleri 8 kere yapmamak için dcli üzerinde  bir grup belirleyerek, Çalıştırdığımız komutların bu grup üzerinde çalışmasını sağlayabiliriz.

Bunun için öncelikle

/opt/oracle.SupportTools/onecommand/ dizini altında istediğimiz cluster node’ları ekleyerek bir grup tanımı oluşturabiliriz.

[root@exadata_dbnode1 ~]# cd /opt/oracle.SupportTools/onecommand/
[root@exadata_dbnode1  onecommand]# vi dbs_group

dbs_group dosyasının içini aşağıdaki şekilde db node hostanemeler ile dolduruyoruz.

exadata_dbnode1
exadata_dbnode2
exadata_dbnode3
exadata_dbnode4
exadata_dbnode5
exadata_dbnode6
exadata_dbnode7
exadata_dbnode8

Dosyamızı oluşturduktan sonra aşağıdaki formatta parametrelerimizi bir kerede tüm dbnode’lar için tanımlayabiliriz.

[root@exadata_dbnode1 onecommand]# dcli -g dbs_group -l root "dbmcli -e alter dbserver notificationMethod=\'mail,snmp\'"
exadata_dbnode1 : DBServer exadata_dbnode1 successfully altered
exadata_dbnode2 : DBServer exadata_dbnode2 successfully altered

işlemi daha sonra aşağıdaki komut ile tüm node’lar üzerinde kontrol edebiliriz.

[root@exadata_dbnode1 onecommand]# dcli -g dbs_group -l root "dbmcli -e list dbserver attributes notificationMethod"
exadata_dbnode1 : mail,snmp
exadata_dbnode2 : mail,snmp

 

12.1.2 öncesi image versiyonları için dbmcli bulunmadığından bu versiyondan önce, asr konfigürasyonları için daha farklı bir yol izliyoruz. Aşağıdaki komutu tek tek ilgili nodelarda node iplerini belirterek çalıştırarak set ediyoruz.

/opt/oracle.cellos/compmon/exadata_mon_hw_asr.pl -set_snmp_subscribers"(type=asr,host=testasrsrv.mehmettahsincan.com,fromip=db_node_1_ip,port=162,community=public)
/opt/oracle.cellos/compmon/exadata_mon_hw_asr.pl -set_snmp_subscribers"(type=asr,host=testasrsrv.mehmettahsincan.com,fromip=db_node_2_ip,port=162,community=public)
/opt/oracle.cellos/compmon/exadata_mon_hw_asr.pl -set_snmp_subscribers"(type=asr,host=testasrsrv.mehmettahsincan.com,fromip=db_node_3_ip,port=162,community=public)
/opt/oracle.cellos/compmon/exadata_mon_hw_asr.pl -set_snmp_subscribers"(type=asr,host=testasrsrv.mehmettahsincan.com,fromip=db_node_4_ip,port=162,community=public)
/opt/oracle.cellos/compmon/exadata_mon_hw_asr.pl -set_snmp_subscribers"(type=asr,host=testasrsrv.mehmettahsincan.com,fromip=db_node_5_ip,port=162,community=public)
/opt/oracle.cellos/compmon/exadata_mon_hw_asr.pl -set_snmp_subscribers"(type=asr,host=testasrsrv.mehmettahsincan.com,fromip=db_node_6_ip,port=162,community=public)
/opt/oracle.cellos/compmon/exadata_mon_hw_asr.pl -set_snmp_subscribers"(type=asr,host=testasrsrv.mehmettahsincan.com,fromip=db_node_7_ip,port=162,community=public)
/opt/oracle.cellos/compmon/exadata_mon_hw_asr.pl -set_snmp_subscribers"(type=asr,host=testasrsrv.mehmettahsincan.com,fromip=db_node_8_ip,port=162,community=public)

 

Flashback Table ile Tabloyu Geçmişteki Bir Ana Döndürme

Flashback table özelliği, Oracle’ın undo tablespace sayesinde bir tablonun belirli bir zaman kadar önceki haline erişmemize yardımcı olur. Gidebileceğimiz maksimum süre undo retention değerimiz ve undo tablespace büyüklüğümüz ile alakalıdır. Flashback database özelliği ile karıştırılmamalıdır. Flashback database özelliği flashback loglarını kullanırken, flashback table özelliği undo’yu kullanır.

Bu özelliği kullanmak için tablonun row movement özelliği enable olmalıdır,  row movement enable olmadan bir tabloda flashback özelliği denenirse aşağıdaki hata alınır.

“ORA-08189: cannot flashback the table because row movement is not enabled”

Herhangi bir tabloda özelliğin açık olup olmadığı aşağıdaki script ile kontrol edilebilir.

SQL> select owner, table_name, row_movement from all_tables where table_name = 'TAHSINC';

OWNER                          TABLE_NAME                     ROW_MOVE
------------------------------ ------------------------------ --------
SYS                            TAHSINC                        ENABLED

Tüm kontroller yapıldıktan sonra, İstenilen bir tarih zamana geri dönmek için aşağıdaki kod kullanılabilir.

SQL> FLASHBACK TABLE table_name TO TIMESTAMP  TO_TIMESTAMP('01-01-2017 01:00:00','DD-MM-YYYY HH24:MI:SS');

System change number (scn) ile geri dönme, bir işlem başarısız olduğunda, işlem yapılmadan önceki hale  geri dönmek için çok faydalıdır. mevcut scn’yi aşağıdaki komut ile görebilirsiniz

SQL> SELECT current_scn FROM V$DATABASE;

SCN’ye geri dönme.

SQL> FLASHBACK TABLE table_name TO SCN 123456;

Kayıt ettiğiniz bir scn’nin hangi zaman dilimine ait olduğuna bakmak isterseniz, aşağıdaki komutu kullanabilirsiniz.

SQL> SELECT SCN_TO_TIMESTAMP(123456) AS TIMESTAMP FROM DUAL;

Drop olan bir tabloyu recyle bin den geri döndürmek için

SQL> FLASHBACK TABLE table_name TO BEFORE DROP;

Drop olan bir tabloyu recyle bin den, yeni bir isimle geri döndürmek için

SQL> FLASHBACK TABLE table_name TO BEFORE DROP rename to table_name2;

Not: Drop olan tablo system tablesapce’inde ise recycle bin e gitmez ve bu şekilde geri döndürülemez.

 

WordPress eklenti kullanmadan sayaç oluşturma

Wordpres kullanılarak, oluşturulan bir blog’da bir eklenti(plugin) kullanmadan, basit birkaç kod yardımı ile  sayfanızın görüntülenme sayısını gösteren bir sayaç oluşturabiliriz. Bu işlemi yaparken, görüntülenmeleri ip ile eşleştirerek, aynı ipden yapılan birden fazla görüntülemeyi, tek bir görüntüleme olarak sayacağız. Bu da bize daha tutarlı bir sayaç sağlayacak.

Bunun için appearance menüsü altından editöre girerek, temanızın functions.php ve single.php dosyalarını aşağıda anlatılan şekilde güncellemeniz gerekiyor. Bu işleme başlamadan önce sitenizin komple yedeğinizi almanızı ve ayrıca functions.php ve single.php dosyalarının da orjinal hallerini kolay geri dönebilmek adına yedeklemenizi tavsiye ederim.

Güncelleme yapacağınız ekranı daha rahat bulabilmeniz için aşağıda ekran görüntüsünü paylaşıyorum.

Aşağıdaki fonksiyonları  functions.php dosyasına eklemeniz gerkiyor.

// izlenme değerini oluşturur
function setPostViews($postID) {
 $user_ip = $_SERVER['REMOTE_ADDR']; //ziyaretçinin ip adresini alır
 $key = $user_ip . 'x' . $postID; //post idniz ile ip yi birleştirir
 $value = array($user_ip, $postID); //post id ve ip yi ayrı değerler olarak bir diziye yazar
 $visited = get_transient($key); // oluşan keyin kayıtlı olup olmadığını kontrol eder ve visited için boolean değer oluşturur.
 // ID/IP ile oluşturduğumuz ($key) değerinin geçici değişkenimizde kayıtlı olup olmadığını kontrol eder.
 if ( false === ( $visited ) ) {
 //id ve ip ile oluşturdupumuz key değerini, Post ID ve IP address değerini 12 saatliğine kayıt eder.
 set_transient( $key, $value, 60*60*12 );
 // eğer ip daha önce gelmediyse view değerini bir arttırır.
 $count_key = 'views';
 $count = get_post_meta($postID, $count_key, true);
 if($count==''){
 $count = 1;
 delete_post_meta($postID, $count_key);
 add_post_meta($postID, $count_key, '0');
 }else{
 $count++;
 update_post_meta($postID, $count_key, $count);
 }
 }
}

// oluşturdupumuz izlenme değerini çeker
function getPostViews($postID){
 $count_key = 'views';
 $count = get_post_meta($postID, $count_key, true); 
 return $count.' Görüntüleme';
}

Bu adımı tamamlayarak fonksiyonlarımız oluşturduk. Şimdi görüntülenme sayısının görünmesini istediğimiz sayfalar için aşağıdaki kodu döngü içerisine eklememiz gerekiyor. Blog postlarına görüntülenmesini istiyorsak single.php dosyamızdaki loop içerisine aşağıdaki gibi ekliyoruz. Ben yorum kısmının hemen üzerinde görünmesi için  ”  if ( comments_open() || get_comments_number() ) :”  kodunun hemen üzerine ekledim.

setPostViews(get_the_ID());
echo getPostViews(get_the_ID());

 

Docker nedir?

Docker, uygulamaların build ve deploy edilmesini kolaylaştıran açık kaynak kodlu bir araçtır. Mart 2013 tarihinde ilk versiyonu yayınlanan docker, cloud teknolojilerinin yaygınlaşmasıyla, günümüzde popülerliğini gittikçe arttırmaktadır.

Docker sayesinde geliştiriciler uygulmalarının çalışması için gerekli tüm parçaları belirleyerek bunlarla bağımsız bir container oluşturabilirler. Bu container ile uygulama, ortamdan bağımsız olarak istenilen yere deploy edilerek, çalıştırılabilir hale getirilir.

Ben Docker’a daha çok sistem yöneticisi gözüyle yaklaşacağım. Uygulamalar, docker sayesinde, artık geliştirildiği linux kernel den bağımsız olarak, deploy edildiği ortamın kerneli ile uyumlu çalışabiliyorlar. Tüm gerekli parçalar container’a eklebiliyor ve tüm manuel configürasyonlar container’da yapılabiliyor. Bu sayede docker, deployment esnasında yapılan birçok manuel ayarlamadan(paket kurulumları, yetkilendirme vs. ) sistem yöneticilerini kurtarıyor.

Bu sayede test ve production ortamlarda configürasyon farklılıkları artık bir sorun olmaktan çıkıyor. Geliştiriciler için de artık uygulamayı farklı ortamlara göre yazma derdi ortadan kalkıyor. Ayrıca çözümleri için kullandıkları farklı uygulamaları da docker container olarak kurarak, development adımına hızlıca geçebiliyorlar. Artık birçok bilinen uygulama, docker için hazırlanmış verified containerları, normal kurulum seçenekleri yanında indirmeye sunuyor. Geliştirici ve sistem yöneticilerine sağladığı faydalar yanında cloud ortamlarında PaaS ve SaaS uygulamaları için de çok büyük kolaylıklar sağlıyor.

Docker, linux çekirdeğinin, cgroups gibi kaynak izolasyonu özelliklerini kullanarak, sadece ihtiyaç duyduğu parçalar ile, işletim sistemi ve sunucu konfigürasyonundan bağımsız uygulama container’ları oluşturmanızı sağlıyor. Bu sayede her uygulama için arka planda kurulan ve kullanılmadığı halde birsürü kaynak tüketen işletim sistemi yükünden kurtulmanızı sağlıyor. Minimum paket ile kurulan bir linux işletim sitemi üzerinde çalışan docker engine bir Hypervisor katmanın sahip olmadığından, klasik sanal makinalara göre daha az kaynak tüketmektedir. Bir docker engine üzerinde, farklı uygulama container’lar ile sanki hepsi ayrı bir sanal makinada çalışıyormuş gibi birçok uygulama kurabiliyorsunuz. Ancak bu özellik Docker Engine üzerinde çalışan uygulamaların konak linux sistemin kütüphanelerini, paylaşımlı olarak kullandıklarından izolasyonu bir miktar düşürmektedir.

Windows Server 2016 için de desteklenecek olan docker .net uygulama geliştiricilerinin de işlerini artık çok kolay bir hale getirecek.

İlerleyen günlerde docker containerlar ile kendi sunucunuza mysql ve wordpres kurulumunun nasıl yapıldığını anlatacağım. Bu sayede kendi sunucunuzda, ya da satın aldığını uygun fiyatlı bir wps üzerinde, kendi websitenizi, minimum sistem yöneticisi bilgisi ile hayata geçirebileceksiniz.