Konu biraz uzun ancak ASM ile ilgili birçok bilgiyi Türkçe olarak içermektedir. Sıkılmadan sonunu getirebilmeniz için belki ara vermeniz faydalı olacaktır Açıkçası ben yazarken çok keyif aldığım için hiç ara vermedim. Her zamanki gibi öncelikle Automatic Storage Management yani ASM nedir ve Türkçesi ne bunu açıklamak istiyorum. Otomatik depolama yönetimi, bundan sonra ASM olarak devam edelim. ASM’nin nasıl kullanıldığını, disk group ifadesinin ne anlama geldiğini, hangi dinamik performans görüntülerini sorguladığımız zaman ASM bilgilerine erişebiliyoruz gibi konular üzerinde duracağım. Başlarken söylemem gereken ilk şey tabii ki ASM’nin normal bir disk yönetiminden farkının ne olduğu ve neden tercih edilebileceği.

1) I/O yaparken gerçekleşebilecek performans kayıplarını azaltması ve yönetimi.
2) Datafile (indexfile) taşıma ve yeniden organize etme probleminin ortadan kalkması.
3) Datafile isimlendirmesini bizim için yerine getirmesi.
4) Mantıksal küme (logical volume) yönetimini sağlaması.
5) File sistem raw device ve Cluster File sisteme gereksinim hissettirmemesi.
6) Veritabanı yöneticisinin, sistem yöneticisi olan bağımlılığını kısmi olarak azaltması.

Yukarıdaki özellikler arasında belki de en önemlileri arasında datafile’ların normal bir disk üzerinde tutulması ile oluşabilecek dengesiz dağılımların elimine edilmesi sayılabilir. ASM sayesinde, ASM’ye tanıtılan disk’lerin içerisinde bulunan datafile’ların ne durumda olduğunu veya disk alanının hangisinin, ne kadar dolduğunu dert etmemize gerek kalmıyor. Yaşanabilecek risklerden bir tanesi de farklı tablespace’ler içerisinde bulunacak aynı isimlendirmeye sahip dosyaların taşınması sırasında birbirlerini ezmeleri (*nix işletim sistemleri) ortadan kalkacaktır.  Bunun yanı sıra veritabanı yöneticisinin elinde birden çok mantıksal mount point (SAN’den paylaştırıldığını varsayalım) olması ve bunların içinde kaybolması sonucu sürekli sistem yöneticisinin kapısını çalması da engellenmiş olacaktır.

ASM’de bir instance’dır. Hatırlayalım, bir Oracle Server “database” yani veritabanı ve “instance” yani Oracle anından oluşmaktadır. ASM de bir instance olduğuna göre klasik instance yapısına çok benzer bir yapıya sahiptir. Varsayılan olarak 256M kadar SGA alanına sahip olacaktır ve bir ASM instance’ının data dictionary’si yoktur. Yalnızca SYSDBA, SYSOPER ve en önemlisi SYSASM kullanıcılarına sahiptir. Gelelim ASM instance’ının hangi bileşenlerden oluştuğuna;

1) Memory – SGA
a) Shared Pool
b) Large Pool
c) ASM Cache
d) Free Memory

2) Processes
a) RBAL
b) ARBn
c) GMON
ç) Onnn
d) PZ9n
e) MARK
f) LMON
g) Diğer işlemler

Yukarıda gördüğünüz üzere ASM instance’ının sahip olduğu SGA biraz daha farklı bileşenlerden oluşmaktadır. Bir veritabanı instance’ından farklı olarak ASM Cache ve Free Memory alanlarına sahiptir ve normal bir instance gibi buffer cache, redolog buffer veya streams/java pool’a sahip değildir. Zaten ASM de bir veritabanı instance’ı değildir, yalnızca sahip olduğu disk’leri yöneten bir araçtır, instance’dır.

Shared Pool: Metada bilgisini içerir.
Large Pool: Paralel operasyonlar için kullanılmaktadır.
ASM Cache: Neyin okunması gerektiğini veya nereye yazılmasını gerektiğini bilir ve rebalance işlemlerinde kullanılır.
Free Memory: Tahsis edilmemiş diğer memory alanı.

Bir ASM instance’ı için otomatik kaynak yönetimi (automatic memory magement) varsayılan olarak aktif haldedir ve bu SGA bileşenlerini, ona tanımlanan yer ölçüsünde yönetir.

Diğer konu ise ASM instance’ının sahip olduğu arka plan görevleri. ASM instance’ının birden çok arka plan görevi olabilir ancak ben olmazsa olmaz olan görevlerden bahsetmek istiyorum;

RBAL: Adından da anlaşılacağı üzere “Rebalance” işlemidir ve ASM disk üniteleri arasındaki verinin dengelenmesi görevini üstlenir.
ARBn: Bir veya birden çok destek görevden oluşan ARBn’in amacı rebalance aktivitesine destek vermektir.
GMON: Disk seviyesindeki aktivitelerin yönetilmesinden sorumludur.
MARK: ASM tahsis ünitelerinin (allocation unit) işaretlenmesinden sorumludur. Allocation unit ile ilgili daha sonra bilgi vereceğim.
Onnn: ASM instance’ına gelecek bağlantıların bir havuzda toplanmasını ve yönetimi sağlayan görevdir. Instance ilk açıldığı zaman ortaya çıkar ve sonra gerektiği zaman yeniden çalışır ve durur.
PZ9n: Bir veya birden fazla paralel göreve sahip olan bu görevin amacı GV$ görüntüsünden cluster sistemler için veri çekmek.

ASM instance’ının bir takım parametreleri bulunmaktadır ve bunları Oracle instance’ı kullanmaktadır;

1) INSTANCE_TYPE
2) ASM_POWER_LIMIT
3) ASM_DISKSTRING
4) ASM_DISKGROUPS
5) ASM_PREFERRED_READ_FAILURE_GROUPS
6) DIAGNOSTIC_DEST
7) LARGE_POOL_SIZE
8 ) REMOTE_LOGIN_PASSWORD_FILE

INSTANCE_TYPE: Bu parametre bir ASM instance’ı için olmazsa olmazdır ve mutlaka tanımlanması gerekmektedir, zorunlu alandır. ASM instance’ları için “ASM” olarak tanımlanmalıdır. Örnek olarak veritabanı instance’ları için bu tip RDBMS olarak tanımlanmaktadır.

SQL> show parameter instance_type; --> Oracle instance

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
instance_type                        string      RDBMS

SQL> show parameter instance_type; --> ASM instance
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
instance_type                        string       asm

SQL> show parameter asm_power_limit
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
asm_power_limit                      integer     1

ASM_DISKSTRING: Bu değerin null olması kimi zaman bir ASM instance’ı için yeterli olmaktadır ancak işletim sistemi seviyesinde tanımlanmış disk’lerin dizin adlarını yazdığımız zamansa ASM’nin disk ünitelerinin mount sürelerini uzatabiliriz. Birçok koşulda null olması yeterlidir.

ASM_DISKGROUPS: Bir ASM instance’ının sahip olduğu disk gruplarını göstermektedir. Bu parametrenin de bir varsayılan değeri yoktur ve 11g ile gelen “Oracle Restart” özelliğinde ASM instance’ının sahip olduğu bütün disk gruplar otomatik olarak mount edilir. Bilmiyorum dikkat ettiniz mi çok fazla otomatik kullanıyoruz ve Oracle 11gR2 ile birlikte hayatımız gerçekten otomatik ve kolay hale gelmeye başladı

ASM_PREFFERED_READ_FAILURE_GROUPS: İleride olası durumlar için tanımladığımız failure, yani başarısızlık gruplarını ifade eden parametredir. Amacı arttırılmış kopyalama ve daha fazla sağlamlık için kullanılacak disk’lerin gruplanmasıdır.

DIAGNOSTIC_DEST: 11g ile hayatımıza giren bu parametre aslında bir nevi DUMP_DEST olarak düşünülebilir. Örneğin eskiden BACKGROUND_DUMP_DEST parametresinin altında trace dosyaları ve alert.log bulunurken şimdi DIAGNOSTIC_DEST parametresi içerisinde bütün bu diğer dump’ların bulunduğu dizinlerin kümelenmiş dizin ismi durmaktadır. Örneğin ORACLE_BASE parametresi gibi ve ORACLE_BASE, DIAGNOSTIC_DEST için varsayılandır ve bütün isimlendirmeler bunun üzerinden gerçekleşir. Yalnızca ASM instance’ına özel bir parametre değildir ve Oracle instance’larında da kullanılmaktadır. Ufak bir bilgi daha, isimlendirmeler sertifika sınavlarında çıkmaktadır ve bilmeniz gerekmektedir. Birkaç örnek vermeden önce V$DIAG_INFO görüntüsüne giderek hangi dizinlerin, ne isimlendirme ile tanımladığına bakabilirsiniz.

$ORACLE_BASE/diag///trace –> trace dosyaları ve alert.log içindir.

$ORACLE_BASE/diag///alert –> alert.log’un “log.xml” adında bir xml kopyasını barındırır.

LARGE_POOL_SIZE: Paralel veritabanı operasyonlarında kullanılan bu alan ASM tarafından otomatik olarak yönetilmektedir.

REMOTE_LOGIN_PASSWORD_FILE: Oracle’ın password dosyası kontrol edip etmeyeceğini kontrol eden parametredir ve varsayılan değeri EXCLUSIVE’dir.

Yaklaşık olarak 70 civarında oracle parametresi ASM instance’ı için kullanılabilmektedir. Hemen bir dipnot, pfile tarafından kullanılabilen 110 parametre, spfile tarafından güncellenebilen 234 parametre bulunmaktadır ve toplamda 344 tane oracle parametresi bulunmaktadır. ASM instance’ı için 11g özelliği olan “Automatic Memory Management” (MEMORY_TARGET) parametresini tanımlamamış olsanız dahi ASM otomatik kaynak yönetimini kullanacaktır.

ASM instance’ı ve veritabanı instance’ı arasında sürekli olarak kurulan bir bağlantı bulunmaktadır. Bu bağlantı sayesinde veritabanı instance’ı tarafından oluşturulmak istenen datafile komutlarının ASM’de nasıl işlenmesi gerektiği bilinir ve “extent map”e kaydedilir. Bu extent map içerisinde kimin nerede olduğu bilgisi bulunmaktadır. Biz hangi datafile’ın nerede olduğunu şimdilik bilmiyoruz.

ASM hakkında bilgiye sahip olabilmemiz için inceleyebileceğimiz bir takım görüntüler bulunmaktadır.

10gR2

SQL> SELECT NAME FROM V$FIXED_TABLE WHERE NAME LIKE 'V$ASM%';
NAME
------------------------------
V$ASM_TEMPLATE
V$ASM_ALIAS
V$ASM_FILE
V$ASM_CLIENT
V$ASM_DISKGROUP
V$ASM_DISKGROUP_STAT
V$ASM_DISK
V$ASM_DISK_STAT
V$ASM_OPERATION
9 rows selected.

11gR2

SQL> SELECT NAME FROM V$FIXED_TABLE WHERE NAME LIKE 'V$ASM%';
NAME
------------------------------
V$ASM_TEMPLATE
V$ASM_ALIAS
V$ASM_FILE
V$ASM_CLIENT
V$ASM_DISKGROUP
V$ASM_DISKGROUP_STAT
V$ASM_DISK
V$ASM_DISK_STAT
V$ASM_OPERATION
V$ASM_ATTRIBUTE
V$ASM_DISK_IOSTAT
11 rows selected.

Şimdi, X$ ve V$’ın farklarından kısaca bahsedelim. X$ genelde dokümante edilmeyen objelerdir ve V$ görüntüleri tarafından kullanılmaktadırlar. Hatırlayacağınız üzere bu objelerin tamamının sahibi SYS’dir. Bu tipte görüntülerin tamamı veritabanı yöneticileri içindir ve yönetici yetkileri ile donatılmış kişiler tarafından görüntülenebilmektedirler. Unutmayınız ki bu tipte meta data içeren ve veritabanı ile ilgili bilgiler sağlayan görüntülerin, farklı veritabanı açılış zamanlarında erişilebilmektedir. Ufak bir örnek vermem gerekirse;

SQL> select status from v$instance;
STATUS
------------
OPEN
SQL> alter system checkpoint;
System altered.
SQL> shu abort;
ORACLE instance shut down.
SQL> startup nomount;
ORACLE instance started.
Total System Global Area 1375731712 bytes
Fixed Size                  2056088 bytes
Variable Size             553648232 bytes
Database Buffers          805306368 bytes
Redo Buffers               14721024 bytes

SQL> select count(*) from v$fixed_table where name like 'V$ASM%';
COUNT(*)
----------
9

SQL> select count(*) from dictionary where table_name like 'ASM%';
select count(*) from dictionary where table_name like 'ASM%'
*
ERROR at line 1:
ORA-01219: database not open: queries allowed on fixed tables/views only

–> Veritabanı açık değil ve yalnızca fixed tablo (X$) veya fixed görüntülere (V$) erişim hakkına sahibiz.

SQL> alter database mount;
Database altered.
SQL> select count(*) from dictionary where table_name like 'ASM%';
select count(*) from dictionary where table_name like 'ASM%'
*
ERROR at line 1:
<strong>ORA-01219: database not open: queries allowed on fixed tables/views only</strong>

SQL> alter database open;
Database altered.
SQL> select count(*) from dictionary;
COUNT(*)
----------
1811

Bunun dışında çok daha fazla sayıda dinamik performans görüntüsü bulunmaktadır ancak kontrol dosyasının mount edilmiş olması gerekmektedir ancak ASM instance’ı bir kontrol dosyası mount etmez. Bir başka ASM dışı bilgi ise USER_ ve ALL_ görüntülerine her kullanıcının erişebileceği. DBA_ görüntülerine  ise yalnızca SELECT ANY DICTIONARY hakkı olanlar erişebilmektedir. USER_ görüntüleri yalnızca sorgulayan kişinin sahibi olduğu objeleri temsil ederken ALL_ görüntüleri ise hem kullanıcının sahip olduğu hem de o kullanıcının erişim hakkı olduğu objelerdir.

Konumuzu geri dönecek olursak eğer ASM instance’ına ait görüntülerin ne olduğunu gösterdik. Daha önce gösterdiğim ASM kullanıcılarından biraz bahsetmek istiyorum. ASM instance’ının sahibi SYSASM’dir.

10gR2

SQL> desc v$pwfile_users;
Name                                      Null?    Type
----------------------------------------- -------- ----------------------------
USERNAME                                           VARCHAR2(30)
SYSDBA                                             VARCHAR2(5)
SYSOPER                                            VARCHAR2(5)

11gR2

SQL> desc v$pwfile_users;
Name                                      Null?    Type
----------------------------------------- -------- ----------------------------
USERNAME                                           VARCHAR2(30)
SYSDBA                                             VARCHAR2(5)
SYSOPER                                            VARCHAR2(5)

SYSASM                                              VARCHAR2(5)

Buraya dikkat, SYSASM kullanıcısı 11g ile birlikte aramıza katıldı ve ASM instance’ını yönetmek için kullanılan bu sistem hakkı, tam yetkili kullanıcı olan SYSASM’ye devredilmiştir. 10g’de ise SYSDBA herşeyin sahibiydi, buna ASM instance da dahil. Tabii SYSASM sistem yetkisini SYS’ye tanıyarak, ASM instance’ını yönettiredebiliriz ancak 10 için değil. 11g’de SYS kullanıcısı otomatik olarak SYSASM yetkisi ile yaratılmaktadır.

SQL> grant sysasm to sys;
grant sysasm to sys
*
ERROR at line 1:
<strong>ORA-01919: role 'SYSASM' does not exist</strong>

Eğer bir ASM instance’ına SYSDBA olarak bağlanırsak, ASM instance’ını kapatmak istediğimiz zaman “insufficient privileges” hatasıyla karşılaşacağız. ASM instance’ına;

# sqlplus / as sysasm

şeklinde bağlabilirsiniz.

SYSOPER’le ilgili olaraksa söylemek istediğim, CREATE DISKGROUP gibi komutları çalıştıramayacak olması. ALTER DISKGROUP koşabilir ve hatırlayınız, SYSOPER’in bir veritabanı instance’ında SYSDBA’den farklı olarak create / drop database yetkileri bulunmamaktaydı fakat veritabanını açıp kapatabiliyordu.

ASM instance’ı “Enterprise Manager” tarafından da yönetilmektedir. EM ana sayfasında yer alan ASM isminin üzerine tıkladığımız zaman ASM instance’ının ana sayfasına geçiş yapabiliyoruz.

“Disk Group” ekranında ise ASM için tanımlanmış disk’lerin bir arada toplandığı disk grupları gösterilmektedir. Hemen bir açıklama, bir ASM instance’ı birden çok veritabanı instance’ını yönetebilmektedir (cluster veya standalone)

Disk gruplarını yaratmak için;

ASM instance’ını kapatıp açabileceğiniz bir yöntem ise SQL*PLUS’tır. İlk önce ORACLE_SID ve ORACLE_HOME parametrelerini ASM instance’ı için değiştirmeliyiz. Grid kurulumu yapıldıysa /grid içeren ORACLE_HOME bilgisi ASM’nin, /dbhome_1 dizinine sahip ORACLE_BASE ise veritabanı instance’ının ORACLE_HOME’udur.

# sqlplus / as sysasm
SQL> startup;
SQL> shutdown abort;

Yukarıdaki komutlarla ASM instance’ını açıp, kapatabiliyoruz. Diğer shutdown seçenekleri de geçerlidir ancak ASM instance’ına hiçbir veritabanı instance’ının bağlı olmaması gerekmektedir aksi halde;

ORA-15097: cannot shutdown ASM instance with connected client

hatasını alırsınız. Yeri gelmişken sıralamadan bahsedelim.

Açarken

1) ASM Instance (MOUNT)

2) Veritabanı Instance (OPEN)

Kaparken

1) Veritabanı Instance (Instance shutdown, veritabanı dismount + closed)

2) ASM Instance (Instance shutdown)

Varsayılan ASM instance’ının ORACLE_SID tanımlamasını “+ASM” olarak gerçekleştirebilirsiniz. Instance tipini yine INSTANCE_TYPE’tan alabilirsiniz. STARTUP komutunu bir +ASM instance’ına verdiğiniz zaman bir kontrol dosyasını mount etmek ve veritabanını açık konuma getirmek (datafile ve redolog’ları kullanılabilir hale getirmek) yerine ASM_DISKGROUPS parametresi içerisinde tanımlanmış disk gruplarını mount etmeye çalışmaktadır. Bu disk grupları içerisindeki bütün disk’lerle olan bağlantı sağlanacak ve disk grupları mount edilecektir. Yine hatırlayacağınız üzere ASM_DISKGROUPS parametresi tanımlanmadan da +ASM hayatını sürdürebiliyordu. Daha sonradan ilgili disk gruplarını mount edebilmek için “ALTER DISKGROUP … MOUNT” komutunu koşabilirsiniz. NOMOUNT modda ise hiçbir disk grubu mount edilmeyecektir ve yalnızca +ASM açılacaktır (SGA + Arka plan görevleri devreye girecek). RESTRICT özelliği ile +ASM’yi açarsak hiçbir client’ın bu disk’lere erişemeyeceğini belirtebilirim. Genelde bakım süreçlerinde ve disk gruplarına kimsenin erişmesini istemediğimiz zaman bu opsiyon ile +ASM’yi açabilirsiniz. Buradaki veritabanı instance’ı ile farklılık şudur, bir veritabanı instance’ını RESTRICT ile açtığınız zaman veritabanı açılmışken veritabanını bu moddan çıkartabilirsiniz ancak bir ASM instance’ına ait restrict edilmiş disk gruplarını önce DISMOUNT etmek ardından da MOUNT etmeniz ve yeniden kullanıma açmanız gerekir.

SRVCTL hizmeti ile de (Oracle yazılımını kurduğumuz zaman gelen hizmetlerden bir tanesidir) ASM instance’ını açıp kapatabiliriz.

# srvctl start asm -o mount
# srvctl stop asm -f
# srvctl status asm
ASM is running on vals1

Bunun dışında ASMCMD kullanılarakta ASM instance kapatılıp açılabilir.

# asmcmd
ASMCMD> startup [--nomount | --restrict]
ASMCMD> shutdown [--abort | --immediate]

ASMCMD’nin en büyük özelliği unix komutlarını kabul etmesidir. Örneğin ls (list). ASMCMD’nin içerisine girerek, nerede, neyin olduğunu ve bu datafile’ların hangi adlarla kaydedildiğini görebilirsiniz. Örnek olarak /CONTROLFILE dizininin altında ASM kontrol dosyasını bulunduracaktır.

Sırada bir disk grubunun hangi redundancy tiplerine sahip olabileceğini inceleyebiliriz. Bu arada bir disk grubunu SAN’a ait mantıksal alanlara benzetebilirsiniz.

1) External Redundancy: ASM’nin hiçbir mirroring yapmadığı tiptir. Bu tipte yaratılan disk’e yalnızca yazma gerçekleştirilir ve bir kopyası diğer disk’ler üzerinde bulundurulmaz.

2) Normal Redundancy: ASM’nin 2 yönlü mirroring yaptığı konfigürasyondur. Bu durumda veri tutarlılığı artar ancak disk alanından taviz verilir.

3) High Redundancy: ASM’nin 3 yönlü mirroring yaptığı konfigürasyondur. Bu durumda veri tutarlılığı artar ancak disk alanından taviz verilir. Daha fazla veri sağlamlığı tesis edilmektedir.

ASM disk’leri ise disk gruplarının içerisinde yer alan depolama alanlarıdır. Sistem yöneticisinin sağladığı formatlanmış disk’leri bir veya birden çok disk grubu içerisinde toplayabiliriz. Mutlaka erişilebilir olmaları gerekmektedir ama sadece ASM sahibi için. Erişilemediği durumlarla ilgili bahsedeceğim. ASM, disk’ler üzerinde “striping ve mirroring” yapmaktadır.

ASM “Allocation Units” konusundan bahsedecek olursak eğer bunları veritabanı instance’ının blokları veya extent’leri olarak düşünebilirsiniz. Amaçları bu miktar kadar alanın tahsis edilerek ilerlenmesini göstermektir. Disk grupları yaratılırken tanımlanabilirler ve varsayılan olarak 1 MB olurlar. 11g ile birlikte bu miktar da değişebilmektedir ve 2, 4, 8, 16, 32 ve en fazla 64 MB olarak yeniden tanımlanabilmektedirler. Aynı db_block_size’da olduğu gibi düşük olursa daha hızlı cache’lenecek ve büyük olursa da arka arkaya okuma yapıldığı zaman daha efektif olacaktır. VLDB (Very Large Database) tipi veriambarlarında yüksek AU kullanmak faydalı olacaktır. AU’nun miktarını disk grup yaratılırken gösterebiliyoruz ancak sonradan değiştiremiyoruz.

ASM “Files” ise AU’lardan oluşan extent’lerdir. Dosya adları + ile başlarlar ve ASM instance’ı tarafından yönetilirler. Dosya isimleri genelde değişken sayılardan oluşmaktadır ancak bu dosya isimlerine (örneğin bir datafile) alias verme şansımız bulunmaktadır. Bu dosya isimleri benzersizdir ve hiçbir zaman başka bir datafile ismi ile çakışmaz. Bu da yine ASM’nin bize sağladığı faydalardan yalnızca bir tanesidir. ASM’nin yönettiği dosyalar disk’ler üzerinde SAME metodolojisi ile tutulmaktadır (Stripe-And-Mirror Everything). ASM dosyalarından kastımız nedir? Datafile, kontrol dosyası, redolog dosyası, RMAN yedekleri gibi. Burası önemli, 11g Release 2′ye kadar ASM, OCR dosyaları, cluster-voting disk, alert log dosyaları, trace dosyaları ve Oracle binary’leri gibi dosyaları desteklemiyordu ancak 11gR2 bu kısıtı ortadan kaldırarak, bu tipte dosyaların da ASM tarafından desteklenmesini sağladı. 11gR2′yi tercih etmek ve kullanmak için yine çok ufak ama büyük bir neden. Yazımın başında belirttiğim “Extent Map” ile ilgili de şunları ifade edebilirim. Extent map, ASM’nin yönettiği dosyaların disk üzerinde nerede olduğu bilgisine sahiptir. Tabii tabloların veya objelerin nerede olduğundan öte bu objelerin bulunduğu extent’lerin nerede durduğunun bilgisine sahiptir.

Striping Granularity

ASM’nin 2 türlü işlediği striping yani yazma şekli ve tarzı bulunmaktadır.

1) Coarse-grain

2) Fine-grain

Bu iki tipte I/O yük dağılımını disk’ler üzerinde gerçekleştirmek veya I/O gecikmelerini azaltmak hedeflenebilir.  Coarse-grain striping özelliği ile AU’lar disk ünitleri üzerinde dağıtılmaktadır. Bu durumda bir “load balancing” yani yük dengelemesi söz konusu olacaktır. Bu dağılımın %100 eşit olacağını ifade edemeyiz. Disk üniteleri üzerinde eşit bir dağılım yapmamaktadır. Örneğin 1 MB’lık AU’ya ve 5 MB’lık veriye sahibiz ve 10 tane de disk ünitemiz var. Coarse-grain striping ile AU tahsisi yapıldığı zaman 1 MB’lık AU’lar toplamda 5 tane diske yayılacak ve diğer 5 disk içerisinde hiçbir şey olmayacaktır. Fine-grain striping özelliğinde ise toplamdaki 5 MB’lık AU, 10 disk ünitesine de eşit olarak yazılacaktır ve bu durumda sahip olduğumuz verinin parçalarının her bir disk ünitesi üzerinde eşit olarak bulunacağını söyleyebiliriz. Böylece 1 MB’lık extent alanımız daha ufak parçalara bölünerek, eşit miktarlarda veri saklayacaktır.

Yazımın başlarında ASM_PREFFERED_READ_FAILURE_GROUPS parametresini gösterirken bahsettiğim “Failure Groups” tanımından bahsedelim. ASM mirroring yapmaktaydı ve eğer bu parametre tanımlıysa yapacağı mirroring’i failure grupları içerisinde yapacaktır. Disk kayıplarının oluştuğu senaryolar için kullanılabilecek olan bu tanımlama ile varsayılan olarak her bir diskin kendine ait failure grubu olması sağlanabilir. ASM’nin normal redundancy ile çalıştığı durumlarda disk grup içerisinde yaratılan bir extent’in birincil durumda performans (striping), ikinci durumda (mirroring) sağlamlık için yaratıldığını ifade edebilirim. Olası disk kayıplarında veya diske erişilemediği durumlarda RBAL kaybolan disk içerisindeki extent’lerin, extent map aracılığı ile nerede olduklarını bilecek ve elimizde kalan disk’ler üzerinde dağıtım yapmaya başlayacaktır. Bunu 10g’de diske erişmediği durumda hemen yapmaya başlarken 11g ile birlikte varsayılan olarak 3.6 saat beklemektedir. Bunun sebebi eğer diskin gerçekten bozulmadığını düşünürsek ve bağlantısı yeniden tesis edildiği zaman yalnızca o diskin içerisindeki extent’lere striping yapılmış bilgiler mirroring yapılmaya, RBAL tarafından başlanacaktır. Bu da ciddi bir performans ve zaman kaybını engelleyecektir. Disk kendine geldiği zaman senkronizasyon tesis edilecektir.

Disk gruplarını nasıl yönetiriz? Enterprise Manager’dan dediğinizi duyar gibiyim. Haklınız ancak bunu yapmanın bir başka yolu da eski yoldaş SQL*PLUS;

# sqlplus / as sysasm
SQL> CREATE DISKGROUP MY_GROUP1 HIGH REDUNDANCY
2 FAILGROUP MY_FAIL1 DISK
3 '/dev/ora1' NAME DISK1 SIZE 120G FORCE,
4 '/dev/ora2',
5 FAILGROUP MY_FAIL2 DISK
6 '/dev/ora3',
7 '/dev/ora4';

Şimdi burada FORCE komutu ile ne yapmamız gerektiğini göstermiş olabiliriz? Öncelikle yukarıdaki komuttan söyleyebilirim ki ora2, ora3 ve ora4 120′şer gigabyte’tır ama ora1 daha fazla alana sahip bir disktir. Önemli not, disk grup içerisindeki disklerin tamamının aynı boyutta olması gerekmektedir. FORCE komutu ile örneğin 380 gigabyte’lık bir disk’in yalnızca 120 gigabyte’nın ASM instance’ı tarafından yönetilmesi şartını koşuyoruz. Bu şekilde kalan alan ASM tarafından tahsis edilmeyecek ve diğer disklerle birlikte tutarlı bir alana sahip olacağız. FORCE opsiyonun gerçekleştirdiği başka bir durumda ise ora1′in mutlaka bir başka disk grup için formatlanmış olması gerekmektedir aksi halde FORCE kullanımı ile hata alacağımız bir gerçektir. Disk grubunu düşürmek içinse;

SQL> DROP DISKGROUP MY_GROUP1 INCLUDING CONTENTS;

INCLUDING CONTENTS’in çalışma prensibi aslında bir tablespace’i düşürürkenki ile aynı diyebiliriz. ASM metadata’sının içerisinde dosya bulunduran bir disk grup düşürmek istersek INCLUDING CONTENTS’i mutlaka eklemeliyiz. Bir disk grubu düşürebilmemiz için mutlaka mount edilmiş olması gerekmektedir. Yeni bir diski disk grubuna eklemek istersek;

SQL> ALTER DISKGROUP MY_GROUP1 ADD DISK
2 'dev/ora5' NAME DISK5,
3 'dev/ora6' NAME DISK6;

Disk gruplarını eklediğimiz zaman GMON ve RBAL devrede ve senkronizasyon başlıyor. Burada söyleyebilirim ki RBAL çalışmakta iken veritabanı üzerinde hiçbir operasyonu engellememektedir. RBAL önce tanımladığımız yeni diski, o disk grubu için formatlar ve ardından rebalance operasyonu devreye girer. ASM_POWER_LIMIT’e göre sistem üzerindeki I/O artacaktır, o kadar. Bir disk’i, ilgili disk grubundan düşürmek istersek;

SQL> ALTER DISKGROUP MY_GROUP1 DROP DISK DISK1;

Bir disk’i tek bir komut ile disk grubundan çıkarabilir ve ekleyebiliriz;

SQL> ALTER DISKGROUP MY_GROUP1 DROP DISK DISK1
2 ADD FAILGROUP MY_FAIL3 DISK
3 '/dev/ora7' NAME DISK7;

Diyelim bir disk’i, disk grubundan çıkartmak istediniz ve DROP DISK komutunu gönderdiniz ama operasyonun ortasında pişman oldunuz ve geri almak istiyorsunuz

SQL> ALTER DISKGROUP MY_GROUP1 UNDROP DISKS;

Bir disk grubunun rebalance gücünü değiştirmek istersek;

SQL> ALTER DISKGROUP MY_GROUP1 REBALANCE POWER 3;

Bir disk grubunu DISMOUNT etmek için;

SQL> ALTER DISKGROUP MY_GROUP1 DISMOUNT;

Şimdi ise biraz geri planda kalan ancak çok önemli olan bir bilgi vermek istiyorum. “Disk Group Compatibility” yani disk grubun Oracle’ın nimetlerinden hangi mertebede yararlandığını açıklayan durum Diyelim 11gR2 kurdunuz ve disk grubunun compatibility ayarını 11gR2 için yaptınız. Bir de veritabanı compatibility parametresi var ve onu da 10gR1 olarak görmektesiniz. Bu demek oluyor ki ASM instance’nın yönettiği disk grupları 11gR2′nin sağladığı özelliklerden yararlanacak ve 10gR1 bir veritabanının depolamasını da yapacaksak bunun da ASM tarafından bilinmesini sağlıyoruz. Önemli, compatibility yalnızca arttırılabilir ancak azaltılamaz. Veritabanı ayarını 10gR1′den 11gR2 yaparsanız eğer bir daha 10gR1′e dönemiyorsunuz, hata veriyor. Bunu Enterprise Manager üzerinden de ASM ekranındaki özellikler bölümünde “Edit” tuşuna basarak da yapabilirsiniz veya deneyebiliriz. Komut satırından yapmak isterseniz eğer kullanmanız gereken parametre compatible.asm’dir.

SQL> CREATE DISKGROUP MY_GROUP2 NORMAL REDUNDANCY DISK
2 'dev/ora8' NAME DISK8
3 ATTRIBUTE 'compatible.asm' = '11.2';

ASM’nin sahip olduğu özellikler ve nasıl yönetilebileceği ile ilgili sahip olduğum bilgileri aktarmaya çalıştım. Yukarıda bahsettiğim sebeplerden dolayı ASM’ye geçiş yapmak isteyebilirsiniz ve lokal disk yönetimini bırakıp, “Migrate to ASM” seçeneğini de değerlendirmenizde fayda görüyorum tabii durumunuz ve sisteminiz müsait ise. Bu arada son bir bilgi, 11gR2 ile birlikte grid kurulumlarını “Standalone” olarak da yapabiliyorsunuz. İllaki bir real application cluster yapısına sahip olmanız gerekmiyor ve grid yönetimi kurulumu sırasında ASM tanımlamasında da bulunabiliyorsunuz.

Ogan Özdoğan tarafından yayınlandı