ASM Disk Grubunu Mount Ederken ORA-15063 Hatasının Alınması ve kfed İle Çözümü

Merhaba Arkadaşlar,

Yakın zamanda başıma gelen bir durumu sizlerle paylaşmak istedim.

ASM üzerinde çalışan veritabanımı ve ASM instance’ı başarılı bir şekilde kapattım. ASM  disklerimi yeni bir sunucuya taşıdım. Yeni sunucuda Oracle yazılımlarının (Grid Infrastructure ve RDBMS) kurulumundan sonra DATA diskgrubumu  mount etmeye çalıştığımda aşağıdaki hatayı aldım.

ovmdbtest1.asyalocal.com.tr@09:52:05> asmcmd
ASMCMD> mount DATA
ORA-15032: not all alterations performed
ORA-15017: diskgroup “DATA” cannot be mounted
ORA-15063: ASM discovered an insufficient number of disks for diskgroup “DATA” (DBD ERROR: OCIStmtExecute)
ASMCMD>

Benzer şekilde;

SQL> alter diskgroup DATA mount;
alter diskgroup DATA mount
*
ERROR at line 1:
ORA-15032: not all alterations performed
ORA-15017: diskgroup “DATA” cannot be mounted
ORA-15063: ASM discovered an insufficient number of disks for diskgroup “DATA”

DATA disk grubumdaki disklerden birisinin veya birkaçının header ‘ı sanırım bozulmuştu. Hemen ASMCA ile diskleri kontrol ettim. 2 diskimin durumu “PROVISIONED” olarak görünüyordu.  Benzer şekilde kfod aracı ile de aşağıdaki gibi kontrol ettiğimde  2 diskimin durumu “PROVISIONED” olarak görünüyordu.

# $GRID_HOME/bin/kfod status=TRUE asm_diskstring=’/dev/raw/raw*’ disk=all   dscvgroup=TRUE
——————————————————————————–
Disk          Size Header    Path                                     Disk Group   User     Group
================================================================================
1:     512000 Mb MEMBER    /dev/raw/raw1                            DATA         ora11g   dba
2:     512000 Mb PROVISIONED    /dev/raw/raw2                            DATA         ora11g   dba
3:     512000 Mb MEMBER    /dev/raw/raw3                            DATA         ora11g   dba
4:     512000 Mb PROVISIONED   /dev/raw/raw4                            DATA         ora11g   dba
5:     512000 Mb MEMBER    /dev/raw/raw5                            DATA         ora11g   dba
6:     512000 Mb MEMBER    /dev/raw/raw6                            DATA         ora11g   dba
——————————————————————————–
ORACLE_SID ORACLE_HOME
================================================================================
+ASM /oracle/grid11g

ASM instance ‘ı kapattım ve kfed aracı ile bozulan ASM diskimin header bilgisini çıkarıp inceledim.

# $GRID_HOME/bin/kfed read /dev/raw/raw2

kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                            1 ; 0x002: KFBTYP_DISKHEAD
kfbh.datfmt:                          1 ; 0x003: 0x01
kfbh.block.blk:                       0 ; 0x004: blk=0
kfbh.block.obj:              2147483648 ; 0x008: disk=0
kfbh.check:                   945480537 ; 0x00c: 0x385ae359
kfbh.fcn.base:                        0 ; 0x010: 0x00000000
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfdhdb.driver.provstr:ORCLDISK ; 0x000: length=32
kfdhdb.driver.reserved[0]:     33686018 ; 0x008: 0x02020202
kfdhdb.driver.reserved[1]:     33686018 ; 0x00c: 0x02020202
kfdhdb.driver.reserved[2]:     33686018 ; 0x010: 0x02020202
kfdhdb.driver.reserved[3]:     33686018 ; 0x014: 0x02020202
kfdhdb.driver.reserved[4]:     33686018 ; 0x018: 0x02020202
kfdhdb.driver.reserved[5]:     33686018 ; 0x01c: 0x02020202
kfdhdb.compat:                186646528 ; 0x020: 0x0b200000
kfdhdb.dsknum:                        0 ; 0x024: 0x0000
kfdhdb.grptyp:                        1 ; 0x026: KFDGTP_EXTERNAL
kfdhdb.hdrsts:                        3 ; 0x027: KFDHDR_MEMBER
kfdhdb.dskname:               DATA_0000 ; 0x028: length=9
kfdhdb.grpname:                    DATA ; 0x048: length=4
kfdhdb.fgname:                DATA_0000 ; 0x068: length=9
kfdhdb.capname:                         ; 0x088: length=0
kfdhdb.crestmp.hi:             32983952 ; 0x0a8: HOUR=0x10 DAYS=0x1c MNTH=0x2 YEAR=0x7dd
kfdhdb.crestmp.lo:           3911025664 ; 0x0ac: USEC=0x0 MSEC=0x361 SECS=0x11 MINS=0x3a
kfdhdb.mntstmp.hi:             32984464 ; 0x0b0: HOUR=0x10 DAYS=0xc MNTH=0x3 YEAR=0x7dd
kfdhdb.mntstmp.lo:           3973637120 ; 0x0b4: USEC=0x0 MSEC=0x239 SECS=0xd MINS=0x3b
kfdhdb.secsize:                     512 ; 0x0b8: 0x0200
kfdhdb.blksize:                    4096 ; 0x0ba: 0x1000
kfdhdb.ausize:                  1048576 ; 0x0bc: 0x00100000
kfdhdb.mfact:                    113792 ; 0x0c0: 0x0001bc80
kfdhdb.dsksize:                  512000 ; 0x0c4: 0x0007d000
kfdhdb.pmcnt:                         6 ; 0x0c8: 0x00000006
kfdhdb.fstlocn:                       1 ; 0x0cc: 0x00000001
kfdhdb.altlocn:                       2 ; 0x0d0: 0x00000002
kfdhdb.f1b1locn:                      2 ; 0x0d4: 0x00000002
kfdhdb.redomirrors[0]:                0 ; 0x0d8: 0x0000
kfdhdb.redomirrors[1]:                0 ; 0x0da: 0x0000
kfdhdb.redomirrors[2]:                0 ; 0x0dc: 0x0000
kfdhdb.redomirrors[3]:                0 ; 0x0de: 0x0000
kfdhdb.dbcompat:              168820736 ; 0x0e0: 0x0a100000
kfdhdb.grpstmp.hi:             32983952 ; 0x0e4: HOUR=0x10 DAYS=0x1c MNTH=0x2 YEAR=0x7dd
kfdhdb.grpstmp.lo:           3909777408 ; 0x0e8: USEC=0x0 MSEC=0x29e SECS=0x10 MINS=0x3a
kfdhdb.vfstart:                       0 ; 0x0ec: 0x00000000
kfdhdb.vfend:                         0 ; 0x0f0: 0x00000000
kfdhdb.spfile:                        0 ; 0x0f4: 0x00000000
kfdhdb.spfflg:                        0 ; 0x0f8: 0x00000000
kfdhdb.ub4spare[0]:                   0 ; 0x0fc: 0x00000000
kfdhdb.ub4spare[1]:                   0 ; 0x100: 0x00000000
kfdhdb.ub4spare[2]:                   0 ; 0x104: 0x00000000
kfdhdb.ub4spare[3]:                   0 ; 0x108: 0x00000000
kfdhdb.ub4spare[4]:                   0 ; 0x10c: 0x00000000
kfdhdb.ub4spare[5]:                   0 ; 0x110: 0x00000000
kfdhdb.ub4spare[6]:                   0 ; 0x114: 0x00000000
kfdhdb.ub4spare[7]:                   0 ; 0x118: 0x00000000
kfdhdb.ub4spare[8]:                   0 ; 0x11c: 0x00000000
kfdhdb.ub4spare[9]:                   0 ; 0x120: 0x00000000
kfdhdb.ub4spare[10]:                  0 ; 0x124: 0x00000000
kfdhdb.ub4spare[11]:                  0 ; 0x128: 0x00000000
kfdhdb.ub4spare[12]:                  0 ; 0x12c: 0x00000000
kfdhdb.ub4spare[13]:                  0 ; 0x130: 0x00000000
kfdhdb.ub4spare[14]:                  0 ; 0x134: 0x00000000
kfdhdb.ub4spare[15]:                  0 ; 0x138: 0x00000000
kfdhdb.ub4spare[16]:                  0 ; 0x13c: 0x00000000
kfdhdb.ub4spare[17]:                  0 ; 0x140: 0x00000000
kfdhdb.ub4spare[18]:                  0 ; 0x144: 0x00000000
kfdhdb.ub4spare[19]:                  0 ; 0x148: 0x00000000
kfdhdb.ub4spare[20]:                  0 ; 0x14c: 0x00000000
kfdhdb.ub4spare[21]:                  0 ; 0x150: 0x00000000
kfdhdb.ub4spare[22]:                  0 ; 0x154: 0x00000000
kfdhdb.ub4spare[23]:                  0 ; 0x158: 0x00000000
kfdhdb.ub4spare[24]:                  0 ; 0x15c: 0x00000000
kfdhdb.ub4spare[25]:                  0 ; 0x160: 0x00000000
kfdhdb.ub4spare[26]:                  0 ; 0x164: 0x00000000
kfdhdb.ub4spare[27]:                  0 ; 0x168: 0x00000000
kfdhdb.ub4spare[28]:                  0 ; 0x16c: 0x00000000
kfdhdb.ub4spare[29]:                  0 ; 0x170: 0x00000000
kfdhdb.ub4spare[30]:                  0 ; 0x174: 0x00000000
kfdhdb.ub4spare[31]:                  0 ; 0x178: 0x00000000
kfdhdb.ub4spare[32]:                  0 ; 0x17c: 0x00000000
kfdhdb.ub4spare[33]:                  0 ; 0x180: 0x00000000
kfdhdb.ub4spare[34]:                  0 ; 0x184: 0x00000000
kfdhdb.ub4spare[35]:                  0 ; 0x188: 0x00000000
kfdhdb.ub4spare[36]:                  0 ; 0x18c: 0x00000000
kfdhdb.ub4spare[37]:                  0 ; 0x190: 0x00000000
kfdhdb.ub4spare[38]:                  0 ; 0x194: 0x00000000
kfdhdb.ub4spare[39]:             254613 ; 0x198: 0x0003e295
kfdhdb.ub4spare[40]:                  0 ; 0x19c: 0x00000000
kfdhdb.ub4spare[41]:                  0 ; 0x1a0: 0x00000000
kfdhdb.ub4spare[42]:                  0 ; 0x1a4: 0x00000000
kfdhdb.ub4spare[43]:                  0 ; 0x1a8: 0x00000000
kfdhdb.ub4spare[44]:                  0 ; 0x1ac: 0x00000000
kfdhdb.ub4spare[45]:                  0 ; 0x1b0: 0x00000000
kfdhdb.ub4spare[46]:                  0 ; 0x1b4: 0x00000000
kfdhdb.ub4spare[47]:                  0 ; 0x1b8: 0x00000000
kfdhdb.ub4spare[48]:                  0 ; 0x1bc: 0x00000000
kfdhdb.ub4spare[49]:                  0 ; 0x1c0: 0x00000000
kfdhdb.ub4spare[50]:                  0 ; 0x1c4: 0x00000000
kfdhdb.ub4spare[51]:                  0 ; 0x1c8: 0x00000000
kfdhdb.ub4spare[52]:                  0 ; 0x1cc: 0x00000000
kfdhdb.ub4spare[53]:                  0 ; 0x1d0: 0x00000000
kfdhdb.acdb.aba.seq:                  0 ; 0x1d4: 0x00000000
kfdhdb.acdb.aba.blk:                  0 ; 0x1d8: 0x00000000
kfdhdb.acdb.ents:                     0 ; 0x1dc: 0x0000
kfdhdb.acdb.ub2spare:             43605 ; 0x1de: 0xaa55

Disk header ‘ı bozulmuştu. dd komutu ile disk header ‘ının yedeğini aldım.

# dd if=/dev/raw/raw2 of=/tmp/DATA.dd bs=1M count=10

Bozulan diskimin au (allocation unit) boyutunu aşağıdaki gibi buldum.

# $GRID_HOME/bin/kfed read /dev/raw/raw2 | grep ausize

Artık bozulan disk header’ını aşağıdaki gibi düzeltebiliriz.

# $GRID_HOME/bin/kfed repair /dev/raw/raw2 aus=1048576

Düzelmiş header bilgisini kfed aracı ile tekrar incelediğimizde kfdhdb.acdb.ub2spare:  alanının düzeldiğini görürüz.

# $GRID_HOME/bin/kfed read /dev/raw/raw2

kfbh.endian:                          1 ; 0x000: 0x01
kfbh.hard:                          130 ; 0x001: 0x82
kfbh.type:                            1 ; 0x002: KFBTYP_DISKHEAD
kfbh.datfmt:                          1 ; 0x003: 0x01
kfbh.block.blk:                       0 ; 0x004: blk=0
kfbh.block.obj:              2147483648 ; 0x008: disk=0
kfbh.check:                   945480537 ; 0x00c: 0x385ae359
kfbh.fcn.base:                        0 ; 0x010: 0x00000000
kfbh.fcn.wrap:                        0 ; 0x014: 0x00000000
kfbh.spare1:                          0 ; 0x018: 0x00000000
kfbh.spare2:                          0 ; 0x01c: 0x00000000
kfdhdb.driver.provstr:ORCLDISK ; 0x000: length=32
kfdhdb.driver.reserved[0]:     33686018 ; 0x008: 0x02020202
kfdhdb.driver.reserved[1]:     33686018 ; 0x00c: 0x02020202
kfdhdb.driver.reserved[2]:     33686018 ; 0x010: 0x02020202
kfdhdb.driver.reserved[3]:     33686018 ; 0x014: 0x02020202
kfdhdb.driver.reserved[4]:     33686018 ; 0x018: 0x02020202
kfdhdb.driver.reserved[5]:     33686018 ; 0x01c: 0x02020202
kfdhdb.compat:                186646528 ; 0x020: 0x0b200000
kfdhdb.dsknum:                        0 ; 0x024: 0x0000
kfdhdb.grptyp:                        1 ; 0x026: KFDGTP_EXTERNAL
kfdhdb.hdrsts:                        3 ; 0x027: KFDHDR_MEMBER
kfdhdb.dskname:               DATA_0000 ; 0x028: length=9
kfdhdb.grpname:                    DATA ; 0x048: length=4
kfdhdb.fgname:                DATA_0000 ; 0x068: length=9
kfdhdb.capname:                         ; 0x088: length=0
kfdhdb.crestmp.hi:             32983952 ; 0x0a8: HOUR=0x10 DAYS=0x1c MNTH=0x2 YEAR=0x7dd
kfdhdb.crestmp.lo:           3911025664 ; 0x0ac: USEC=0x0 MSEC=0x361 SECS=0x11 MINS=0x3a
kfdhdb.mntstmp.hi:             32984464 ; 0x0b0: HOUR=0x10 DAYS=0xc MNTH=0x3 YEAR=0x7dd
kfdhdb.mntstmp.lo:           3973637120 ; 0x0b4: USEC=0x0 MSEC=0x239 SECS=0xd MINS=0x3b
kfdhdb.secsize:                     512 ; 0x0b8: 0x0200
kfdhdb.blksize:                    4096 ; 0x0ba: 0x1000
kfdhdb.ausize:                  1048576 ; 0x0bc: 0x00100000
kfdhdb.mfact:                    113792 ; 0x0c0: 0x0001bc80
kfdhdb.dsksize:                  512000 ; 0x0c4: 0x0007d000
kfdhdb.pmcnt:                         6 ; 0x0c8: 0x00000006
kfdhdb.fstlocn:                       1 ; 0x0cc: 0x00000001
kfdhdb.altlocn:                       2 ; 0x0d0: 0x00000002
kfdhdb.f1b1locn:                      2 ; 0x0d4: 0x00000002
kfdhdb.redomirrors[0]:                0 ; 0x0d8: 0x0000
kfdhdb.redomirrors[1]:                0 ; 0x0da: 0x0000
kfdhdb.redomirrors[2]:                0 ; 0x0dc: 0x0000
kfdhdb.redomirrors[3]:                0 ; 0x0de: 0x0000
kfdhdb.dbcompat:              168820736 ; 0x0e0: 0x0a100000
kfdhdb.grpstmp.hi:             32983952 ; 0x0e4: HOUR=0x10 DAYS=0x1c MNTH=0x2 YEAR=0x7dd
kfdhdb.grpstmp.lo:           3909777408 ; 0x0e8: USEC=0x0 MSEC=0x29e SECS=0x10 MINS=0x3a
kfdhdb.vfstart:                       0 ; 0x0ec: 0x00000000
kfdhdb.vfend:                         0 ; 0x0f0: 0x00000000
kfdhdb.spfile:                        0 ; 0x0f4: 0x00000000
kfdhdb.spfflg:                        0 ; 0x0f8: 0x00000000
kfdhdb.ub4spare[0]:                   0 ; 0x0fc: 0x00000000
kfdhdb.ub4spare[1]:                   0 ; 0x100: 0x00000000
kfdhdb.ub4spare[2]:                   0 ; 0x104: 0x00000000
kfdhdb.ub4spare[3]:                   0 ; 0x108: 0x00000000
kfdhdb.ub4spare[4]:                   0 ; 0x10c: 0x00000000
kfdhdb.ub4spare[5]:                   0 ; 0x110: 0x00000000
kfdhdb.ub4spare[6]:                   0 ; 0x114: 0x00000000
kfdhdb.ub4spare[7]:                   0 ; 0x118: 0x00000000
kfdhdb.ub4spare[8]:                   0 ; 0x11c: 0x00000000
kfdhdb.ub4spare[9]:                   0 ; 0x120: 0x00000000
kfdhdb.ub4spare[10]:                  0 ; 0x124: 0x00000000
kfdhdb.ub4spare[11]:                  0 ; 0x128: 0x00000000
kfdhdb.ub4spare[12]:                  0 ; 0x12c: 0x00000000
kfdhdb.ub4spare[13]:                  0 ; 0x130: 0x00000000
kfdhdb.ub4spare[14]:                  0 ; 0x134: 0x00000000
kfdhdb.ub4spare[15]:                  0 ; 0x138: 0x00000000
kfdhdb.ub4spare[16]:                  0 ; 0x13c: 0x00000000
kfdhdb.ub4spare[17]:                  0 ; 0x140: 0x00000000
kfdhdb.ub4spare[18]:                  0 ; 0x144: 0x00000000
kfdhdb.ub4spare[19]:                  0 ; 0x148: 0x00000000
kfdhdb.ub4spare[20]:                  0 ; 0x14c: 0x00000000
kfdhdb.ub4spare[21]:                  0 ; 0x150: 0x00000000
kfdhdb.ub4spare[22]:                  0 ; 0x154: 0x00000000
kfdhdb.ub4spare[23]:                  0 ; 0x158: 0x00000000
kfdhdb.ub4spare[24]:                  0 ; 0x15c: 0x00000000
kfdhdb.ub4spare[25]:                  0 ; 0x160: 0x00000000
kfdhdb.ub4spare[26]:                  0 ; 0x164: 0x00000000
kfdhdb.ub4spare[27]:                  0 ; 0x168: 0x00000000
kfdhdb.ub4spare[28]:                  0 ; 0x16c: 0x00000000
kfdhdb.ub4spare[29]:                  0 ; 0x170: 0x00000000
kfdhdb.ub4spare[30]:                  0 ; 0x174: 0x00000000
kfdhdb.ub4spare[31]:                  0 ; 0x178: 0x00000000
kfdhdb.ub4spare[32]:                  0 ; 0x17c: 0x00000000
kfdhdb.ub4spare[33]:                  0 ; 0x180: 0x00000000
kfdhdb.ub4spare[34]:                  0 ; 0x184: 0x00000000
kfdhdb.ub4spare[35]:                  0 ; 0x188: 0x00000000
kfdhdb.ub4spare[36]:                  0 ; 0x18c: 0x00000000
kfdhdb.ub4spare[37]:                  0 ; 0x190: 0x00000000
kfdhdb.ub4spare[38]:                  0 ; 0x194: 0x00000000
kfdhdb.ub4spare[39]:                  0 ; 0x198: 0x00000000
kfdhdb.ub4spare[40]:                  0 ; 0x19c: 0x00000000
kfdhdb.ub4spare[41]:                  0 ; 0x1a0: 0x00000000
kfdhdb.ub4spare[42]:                  0 ; 0x1a4: 0x00000000
kfdhdb.ub4spare[43]:                  0 ; 0x1a8: 0x00000000
kfdhdb.ub4spare[44]:                  0 ; 0x1ac: 0x00000000
kfdhdb.ub4spare[45]:                  0 ; 0x1b0: 0x00000000
kfdhdb.ub4spare[46]:                  0 ; 0x1b4: 0x00000000
kfdhdb.ub4spare[47]:                  0 ; 0x1b8: 0x00000000
kfdhdb.ub4spare[48]:                  0 ; 0x1bc: 0x00000000
kfdhdb.ub4spare[49]:                  0 ; 0x1c0: 0x00000000
kfdhdb.ub4spare[50]:                  0 ; 0x1c4: 0x00000000
kfdhdb.ub4spare[51]:                  0 ; 0x1c8: 0x00000000
kfdhdb.ub4spare[52]:                  0 ; 0x1cc: 0x00000000
kfdhdb.ub4spare[53]:                  0 ; 0x1d0: 0x00000000
kfdhdb.acdb.aba.seq:                  0 ; 0x1d4: 0x00000000
kfdhdb.acdb.aba.blk:                  0 ; 0x1d8: 0x00000000
kfdhdb.acdb.ents:                     0 ; 0x1dc: 0x0000
kfdhdb.acdb.ub2spare:                 0 ; 0x1de: 0x0000

Artık DATA diskgrubumu başarılı bir şekilde mount edebiliriz.

Yedekleme planınızda mutlaka ASM disk header bilgisi yedeklerinizin olmasını da tavsiye ederim.

Ben bozulan ASM disk header bilgisinin yedeğini almamıştım. Peki yukarıdaki kurtarma işlemi nasıl oldu? ASM diskinin header bilgisinin ikinci bir kopyası daha vardır. kfed repair komutu, bozulan bloğu sağlam kopyadan tekrar oluşturur. Sağlam kopyada bozulmuş olsa idi, elimizdeki yedekten kurtarma işlemini yapabilirdik.

Talip Hakan Öztürk

Bir ASM Ortamından Diğer ASM Ortamına Yedek Dosyaları Nasıl Kopyalanır?

Merhaba Arkadaşlar,

Bu yazımda bir ASM ortamında bulunan yedek dosyalarımızın diğer ASM ortamına nasıl kopyalayacağımızı anlatacağım. TALIP1 ve TALIP2 isimli iki farklı sunucumuz ve bu sunucular üzerinde ASM instance ‘ımız olsun. TALIP1 isimli sunucu üzerinde bulunan ASM disk grubundaki yedek dosyamızı TALIP2 isimli sunucu üzerindeki ASM disk grubuna kopyalamak isteyelim. İşlem adımlarımız aşağıdaki gibi olacaktır.

1- TALIP1 sunucusuna oracle kullanıcısı ile login olalım ve ASM instance için ortam değişkenlerimizi set edelim.

export ORACLE_HOME=/oracle/grid11g
export ORACLE_SID=+ASM

2- Yedek dosyalarımızın dizinine işaret eden Oracle dizin objesi oluşturalım.

sqlplus / as sysdba
SQL> create directory TALIP1 as ‘+RECO/talipdb/backupset/22_06_2012’;

3- TALIP2 sunucusuna oracle kullanıcısı ile login olalım ve ASM instance için ortam değişkenlerimizi set edelim.

export ORACLE_HOME=/oracle/grid11g
export ORACLE_SID=+ASM

4- +RECO/talipdb/backupset dizini altında 22_06_2012 isimli yeni bir klasör oluşturalım.

ASMCMD> cd +RECO/talipdb/backupset
ASMCMD mkdir 22_06_2012

5- Yedek dosyalarımızı kopyalayacağımız dizine işaret eden Oracle dizin objesi oluşturalım.

sqlplus / as sysdba
SQL> create directory TALIP2 as ‘+RECO/talipdb/backupset/22_06_2012’;

6- TALIP1 sunucusuna oracle kullanıcısı ile login olalım ve ASM instance için ortam değişkenlerimizi set edelim.

export ORACLE_HOME=/oracle/grid11g
export ORACLE_SID=+ASM

7- TALIP1 ‘den TALIP2 ‘ye ulaşabilmek için dblink oluşturalım.

sqlplus / as sysdba
SQL> create database link TALIP2link connect to system identified by oracle using ‘TALIP2’;

8- Yedek dosyalarımızı tek tek aşağıdaki gibi kopyalayalım.

SQL> exec dbms_file_transfer.put_file(‘TALIP1′,’users.260.778251563′,’TALIP2′,’users.260.778251563′,’TALIP2link’);

dbms_file_transfer paketi put_file prosedürünün kullanımı aşağıdaki gibidir.

dbms_file_transfer.put_file( SOURCE_DIRECTORY_OBJECT, SOURCE_FILE_NAME, DESTINATION_DIRECTORY_OBJECT, DESTINATION_FILE_NAME, DESTINATION_DATABASE )

 Talip Hakan Öztürk

Veri ve Redo Log Dosyalarının Dosya Sisteminden ASM ‘e RMAN ile Taşınması

Merhaba Arkadaşlar,

Önceki yazımda bir veri dosyasının, dosya sisteminden ASM disk grubuna RMAN ile taşınmasını yazmıştım. Bu yazımda da tüm veritabanının (veri dosyaları, control file, online redo log dosyaları) dosya sisteminden ASM ‘e RMAN ile nasıl taşıyacağımızı adım adım öğreneceğiz.

1- Block Change Tracking aktif ise disable yapılır.

# sqlplus / as sysdba

SQL> alter database disable block change tracking;

2- Veri dosyalarımızın ve control dosyalarımızın varsayılan yerini aşağıdaki gibi +DATA olarak değiştirelim.

SQL> alter system set db_create_file_dest=’+DATA’ scope=spfile;

Benzer şekilde online redo log dosyalarımızın varsayılan yerini aşağıdaki gibi +RECO olarak değiştirelim.

SQL> alter system set db_create_online_log_dest_1=’+RECO’ scope=spfile;

3- Spfile parametre dosyamızda control_files parametresini sıfırlayalım.

SQL> alter system reset control_files scope=spfile sid=’*’;

4- Artık veri dosyalarımızı RMAN ile ASM ‘e taşıyabiliriz. Önce veritabanımızı NOMOUNT modda açıp control dosyamızı aşağıdaki gibi restore ederek +DATA disk grubuna yazılmasını sağlayalım.

$ rman target /

RMAN> startup nomount

RMAN> restore controlfile from ‘/data_TALIPDB/control01.ctl’;

5- Veritbanımızı MOUNT moduna alalım ve RMAN ile +DATA disk grubuna image copy yedek alalım.

RMAN> alter database mount;

RMAN> backup as copy database format ‘+DATA’;

6- Veritabanımızı aşağıdaki gibi +DATA disk grubunda bulunan kopyasına switch edelim.

RMAN> switch database to copy;

7- Veritabanımızı açabiliriz.

RMAN> alter database open;

8- İlk adımda disable ettiğimiz block change tracking ‘i tekrar enable edebiliriz.

SQL> alter database enable block change tracking using file ‘/oracle/ora11g/bct_file.log’;

9- Temp alanın yedeği alınmayacağı için yeni bir temp dosyası ekleyerek işi çözebiliriz. Yeni bir temp dosyası oluşturalım. Varsayılan +DATA disk grubunda oluşturulacaktır. Ve Sonra eskisini silebiliriz.

# sqlplus / as sysdba

SQL> alter tablespace temp add tempfile size 500M;

SQL> alter tablespace temp drop tempfile ‘/data_TALIPDB/temp01.dbf’

10- Şimdide online redo log dosyalarımızı ASM disk grubuna taşıyalım.

# sqlplus / as sysdba

SQL>select b.group# , b.status , a.member from v$logfile a , v$log b where a.group# = b.group# order by 1;

GROUP#           STATUS                 MEMBER

————          ————              —————————

1                            INACTIVE             /data1/redo01.log

2                            INACTIVE            /data1/redo02.log

3                            CURRENT             /data1/redo03.log

Durumu INACTIVE veya UNUSED olan redo log dosyaları drop edilebilmektedir. Ama durumu CURRENT veya ACTIVE ise drop işlemi hemen yapılamamaktadır. Online redo log gruplarımızı tek tek silip, tekrar +RECO disk grubunda oluşturalım.

SQL> alter database drop logfile group 1;

Daha önce db_create_online_log_dest_1 parametresini ‘+RECO’ olarak set ettiğimiz için redo log dosyalarımız varsayılan olarak +RECO disk grubunda oluşturulacaktır.

SQL> alter database add logfile group 1 size 50M;

Aynı şekilde 2. log grubumuzuda drop/create edelim.

SQL> alter database drop logfile group 2;

SQL> alter database add logfile group 2 size 50M;

11- Yukarıdaki sorguyu tekrar çalıştıralım ve redo log dosyalarımızın durumunu kontrol edelim.

SQL> select b.group# , b.status , a.member from v$logfile a , v$log b where a.group# = b.group# order by 1;

GROUP#           STATUS                 MEMBER

————          ————              —————————

1                            INACTIVE            +RECO/talipdb/online log/group_1.257.7782 52603

2                            INACTIVE            +RECO/talipdb/online log/group_2.258.7782 52715

3                            CURRENT             /data1/redo03.log

Sıra geldi 3. redo log grubu drop/create etmeye. Durumu CURRENT olduğu için önce diğer redo log dosyasına switch yapalım.

SQL> alter system switch logfile;

SQL> select b.group# , b.status , a.member from v$logfile a , v$log b where a.group# = b.group# order by 1;

GROUP#           STATUS                 MEMBER

————          ————              —————————

1                            CURRENT             +RECO/talipdb/online log/group_1.257.7782 52603

2                            UNUSED               +RECO/talipdb/online log/group_2.258.7782 52715

3                            ACTIVE                 /data1/redo03.log

Sorgumuzu tekrar çalıştırdığımızda, durumunu ACTIVE olarak görürüz. Durumunun INACTIVE olması için bir süre bekleyebiliriz. Veya aşağıdaki gibi checkpoint atarak redo log dosyamız ile ilgili veritabanı tampon ön belleğinde (database buffer cache) bulunan dirty blokların yazılmasını sağlayabiliriz.

SQL> alter system checkpoint;

SQL> select b.group# , b.status , a.member from v$logfile a , v$log b where a.group# = b.group# order by 1;

GROUP#           STATUS                 MEMBER

————          ————              —————————

1                            CURRENT             +RECO/talipdb/online log/group_1.257.7782 52603

2                            UNUSED               +RECO/talipdb/online log/group_2.258.7782 52715

3                            INACTIVE             /data1/redo03.log

Checkpoint sonrası tekrar kontrol ettiğimizde durumunu INACTIVE olarak görürüz. Şimdi 1. redo log grubumuzu drop/create edebiliriz.

SQL> alter database drop logfile group 3;

SQL> alter database add logfile group 3 size 50M;

Son olarak online redo log dosyalarımızı kontrol edelim.

SQL> set lines 50

SQL> select member from v$logfile;

MEMBER

————————————————–

+RECO/talipdb/onlinelog/group_3.259.778253083

+RECO/talipdb/onlinelog/group_2.258.778252715

+RECO/talipdb/onlinelog/group_1.257.778252603

Veridosyalarımızı da kontrol edelim.

SQL> select name from v$datafile;

NAME

——————————————————————————–

+DATA/talipdb/datafile/system.256.778251403

+DATA/talipdb/datafile/sysaux.257.778251487

+DATA/talipdb/datafile/undotbs1.258.778251553

+DATA/talipdb/datafile/users.260.778251563

SQL> select name from v$tempfile;

NAME

——————————————————————————–

+DATA/talipdb/tempfile/temp.262.778252097

Veri dosyalarımızı, control dosyalarımızı ve online redo log dosyalarımızı ASM disk grubuna taşıdık. ASM ile çalışan mutlu veritabanlarınız olması dileğiyle 🙂 …

Talip Hakan Öztürk

Veri Dosyasının Dosya Sisteminden ASM Disk Grubuna RMAN ile Taşınması

Merhaba Arkadaşlar,

Bu yazımda, dosya sistemi üzerinde oluşturulmuş veri dosyasının RMAN ile ASM ‘e nasıl taşıyacağımızı yazacağım.

1- Önce  veri dosyası dosya sistemi üzerinde olan bir tablespace oluşturalım.

SQL> CREATE TABLESPACE TOASM DATAFILE   ‘/data1/toasm01.dbf’ SIZE 100M AUTOEXTEND ON NEXT 1M ;

2- Veri dosyalarımızı listeleyelim. Bakalım nelerimiz var?

SQL> select name from v$datafile;

NAME

——————————————————————————–

+DATA/talipdb/datafile/system.257.778261279

+DATA/talipdb/datafile/sysaux.258.778261375

+DATA/talipdb/datafile/undotbs1.259.778261441

+DATA/talipdb/datafile/users.260.778261447

/data1/toasm01.dbf

3- Şimdi RMAN ‘e bağlanalım.

 [oracle@DBTALIP /oracle/ora11g]# rman target /

Recovery Manager: Release 11.2.0.1.0 – Production on Sun Mar 18 16:05:09 2012

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

connected to target database: TALIPDB (DBID=4043281188)

4- Taşıyacağımız Tablespace ‘i offline yapalım.

RMAN> sql “alter tablespace toasm offline”;

using target database control file instead of recovery catalog

sql statement: alter tablespace toasm offline

5- RMAN copy komutuyla veri dosyasını +DATA disk grubuna kopyalayalım

RMAN> copy datafile ‘/data1/toasm01.dbf’ to ‘+DATA’;

Starting backup at 18-MAR-12

allocated channel: ORA_DISK_1

channel ORA_DISK_1: SID=58 device type=DISK

channel ORA_DISK_1: starting datafile copy

input datafile file number=00005 name=/data1/toasm01.dbf

output file name=+DATA/talipdb/datafile/toasm.263.778262769 tag=TAG20120318T160609 RECID=13 STAMP=778262779

channel ORA_DISK_1: datafile copy complete, elapsed time: 00:00:15

Finished backup at 18-MAR-12

RMAN> exit

Recovery Manager complete.

6- SQL*Plus a bağlanalım ve veri dosyasının adını değiştirelim.

[oracle@DBTALIP /oracle/ora11g]# sqlplus / as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on Sun Mar 18 16:09:12 2012

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

Connected to: Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 – Production With the Partitioning, Automatic Storage Management, OLAP, Data Mining and Real Application Testing options

SQL> alter database rename file ‘/data1/toasm01.dbf’ to ‘+DATA/talipdb/datafile/toasm.263.778262769’;

Database altered.

7- Tablespace ‘i online yapalım.

SQL> alter tablespace toasm online;

Tablespace altered.

8- Veri dosyalarımızı tekrar sorgulayalım. Bakalım son durum nasıl?

SQL> select name from v$datafile;

NAME ——————————————————————————–

+DATA/talipdb/datafile/system.257.778261279

+DATA/talipdb/datafile/sysaux.258.778261375

+DATA/talipdb/datafile/undotbs1.259.778261441

+DATA/talipdb/datafile/users.260.778261447

+DATA/talipdb/datafile/toasm.263.778262769

 

Tablespace ASM disk grubuna taşınmıştır. 🙂

 

Talip Hakan Öztürk

Oracle ASM Disklerinin Konfigürasyonu

Merhaba Arkadaşlar,

Bir diskin Oracle ASM tarafından kullanılabilmesi için, fdisk ile disk üzerinde partition oluşturup, diskin ASM diski olarak işaretlenmesi gerekmektedir. Örnek bir senaryo üzerinden birlikte inceleyelim.

/dev dizini altında üç adet sdb, sdc ve sdd disklerimiz olsun. Fdisk komutu ile disklerimiz üzerinde partition oluşturmamız gerekiyor. Sdb diskimiz için fdisk komutunu aşağıdaki gibi “root” kullanıcısı ile çalıştıralım. Fdisk bize birtakım sorular soracaktır. Koyu yazdığım yerler bizim vermemiz gereken cevaplardır. n– yeni bir partition oluşturacağımızı, p – primary partition oluşturacağımızı, 1– partition numarasını, w– partition tablosuna değişiklikleri yazar.
1-      Fdisk komutu ile disklerimizde partition oluşturalım.

 # fdisk  /dev/sdb
Command (m for help): n
Command action
e   extended
p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-1305, default 1): [ENTER]
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-1305, default 1305): [ENTER]
Using default value 1305

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

Bu işlemleri sdc ve sdd disklerimiz içinde aynı şekilde uygulayalım.

# fdisk  /dev/sdc
Command (m for help): n
Command action
e   extended
p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-1305, default 1): [ ENTER]
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-1305, default 1305): [ENTER]
Using default value 1305

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.
# fdisk  /dev/sdd
Command (m for help): n
Command action
e   extended
p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-1305, default 1): [ENTER]
Using default value 1
Last cylinder or +size or +sizeM or +sizeK (1-1305, default 1305): [ENTER]
Using default value 1305

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

Partition larımızı kontrol edelim.

# ls -ltrh /dev/sd*
 

2-      “oracle” işletim sistemi kullanıcımızın yukarıda oluşturduğumuz partition lar üzerinde ki disk grubuna dosya yazabilmesi için disklerimizin erişim izini ve sahibini (owner) “oracle” kullanıcısı yapmamız gerekiyor.

 
# chown oracle:oinstall /dev/sdb1
# chown oracle:oinstall /dev/sdc1
# chown oracle:oinstall /dev/sdd1
# chmod 600 /dev/sdb1
# chmod 600 /dev/sdc1
# chmod 600 /dev/sdd1
 

Bu satırları aşağıdaki gibi /etc/rc.local dosyasına ekleyerek kaydedelim. Böylelikle sunucumuz restart olduğunda da uygulanacaktır.
 
# vi /etc/rc.local

 
chown oracle:oinstall /dev/sdb1
chown oracle:oinstall /dev/sdc1
chown oracle:oinstall /dev/sdd1
chmod 600 /dev/sdb1
chmod 600 /dev/sdc1
chmod 600 /dev/sdd1
 

3-      Disklerimizi ASM diski olarak işaretlemek için ASM kütüphaneleri vardır. Bu kütüphaneler Linux kernel sürümüne göre dağıtılmaktadır. Kernel sürümümüzü aşağıdaki gibi öğrenebiliriz.

# uname -r

Aynı zaman işletim sistemimizi de kontrol etmemiz gerekir.

# cat /etc/issue

ASM kütüphane rpm paketlerini http://www.oracle.com/technology/software/tech/linux/asmlib/index.html  adresinden yukarıdaki gibi öğrendiğimiz kernel sürümüne göre indirebiliriz.

İndirdiğimiz 3 rpm paketi (oracleasm-2.6.18-164.el5-2.0.5-1.el5.i686.rpm , oracleasmlib-2.0.4-1.el5.i386.rpm ve oracleasm-support-2.1.4-1.el5.i386.rpm) aşağıdaki gibi yükleyebiliriz.

# rpm -ivh oracleasm*

4-    Şimdi “oracleasm” servisini yapılandıralım. Veritabanı kurulumumuzu işletim sisteminde ki “oracle” kullanıcısı ile yapacağımız için ASM kütüphane sürücüsünde (library driver) bu kullanıcıya ve bu kullanıcının birincil “oinstall” grubuna  aşağıdaki gibi sahiplik (owner) verelim. Bu esnada bize birtakım sorular soracaktır. Koyu yazdığım şekilde cevap verelim.

# service oracleasm configure
 
Configuring the Oracle ASM library driver.
 
This will configure the on-boot properties of the Oracle ASM library
driver.  The following questions will determine whether the driver is
loaded on boot and what permissions it will have.  The current values
will be shown in brackets (‘[]’).  Hitting <ENTER> without typing an
answer will keep that current value.  Ctrl-C will abort.

Default user to own the driver interface []: oracle
Default group to own the driver interface []: oinstall
Start Oracle ASM library driver on boot (y/n) [n]: y
Scan for Oracle ASM disks on boot (y/n) [y]: y
Writing Oracle ASM library driver configuration: done
Initializing the Oracle ASMLib driver:                     [  OK  ]
Scanning the system for Oracle ASMLib disks:     [  OK  ]

5-      Artık disklerimizi ASM diski olarak etiketleyebiliriz.

[root@DBTALIP dev]# service oracleasm createdisk DATA1 /dev/sdb1
Marking disk “DATA1” as an ASM disk:                       [  OK  ]
[root@DBTALIP dev]# service oracleasm createdisk DATA2 /dev/sdc1
Marking disk “DATA2” as an ASM disk:                    [  OK  ]
[root@DBTALIP dev]# service oracleasm createdisk FRA /dev/sdd1
Marking disk “FRA” as an ASM disk:                         [  OK  ]

ASM disklerimizi aşağıdaki gibi listeleyebiliriz;

# service oracleasm listdisks

DATA1

DATA2

FRA

Talip Hakan Öztürk