About DATABASE

이 문서에서

적용 대상:

목적

이 문서는 Exadata Storage Server 의 디스크 장애 발생시, 그리고 DB 노드나 Storage server 의 하드웨어 이슈 발생시 필요한 진단 정보를 수집하는 방법을 제공합니다.

진단 절차

--- 소프트웨어 요구조건 ---

이 스크립트는 디스크 문제가 있는 Exadata Storage server 에서, 그리고 하드웨어 이슈가 있는 DB 노드나 Storage server 에서 root 사용자로 수핻되어야 합니다. 

이 스크립트는 Sun 이나 HP 에서 필요로 하는 진단 정보를 수집합니다.

--- 스크립트 설치 ---

root 사용자로 수행합니다.

--- 스크립트 수행 ---

Sun Oracle Exadata 환경:

이미지 버전이 11.2.3.3.0 이전의 모든 시스템:

1. sundiag.zip 파일을 다운로드 받아 첫번째 컴퓨트 노드의 /tmp 에 복사합니다.
2. dcli 를 사용하여 파일을 모든 노드에 복사하고 압축을 해제합니다. 
      #dcli -l root -g /opt/oracle.SupportTools/onecommand/all_group -f /tmp/sundiag.zip -d /tmp
      #dcli -l root -g /opt/oracle.SupportTools/onecommand/all_group "cd /tmp;unzip sundiag.zip;ls -l sundiag_v1.5.sh;md5sum sundiag_v1.5.sh"

all_group 파일에 언급된 모든 노드에서 이러한 형태로 결과가 나와야 합니다. 

3. 신규 버전의 sundiag.sh 을 기본 위치에 복사합니다. 
     #dcli -l root -g /opt/oracle.SupportTools/onecommand/all_group "cd  /opt/oracle.SupportTools;mv sundiag.sh sundiag.sh.orig"
     #dcli -l root -g /opt/oracle.SupportTools/onecommand/all_group "cd /tmp;cp sundiag_v1.5.sh /opt/oracle.SupportTools/sundiag.sh;md5sum /opt/oracle.SupportTools/sundiag.sh;ls -l /opt/oracle.SupportTools/*sundiag*"

4. sundiag.sh 사용법:

Usage:

# /opt/oracle.SupportTools/sundiag.sh

명령어를 수행하면 /tmp/sundiag_/tar.bz2 에 날짜가 기록된 tar.bz2 파일을 생성할 것입니다. 

이 파일을 서비스 요청에 업로드 하십시오. 

5. 신규 버전의 sundiag.sh 스크립트가 실행중인지 확인해보십시오.

6. 임시 파일들을 삭제하십시오.
 
    #dcli -l root -g /opt/oracle.SupportTools/onecommand/all_group "cd /tmp;rm -fr sundiag.zip;rm -fr sundiag_v1.5.sh"


OS Watcher 데이터와 sundiag 를 함께 수집하려면:  

사용법:

# /opt/oracle.SupportTools/sundiag.sh osw

이 명령을 실행하면 /tmp/sundiag_/tar.bz2 에 OS Watcher 아카이브 로그들과 함께 날짜가 기록된 tar.bz2 파일을 생성할 것입니다. 이 로그들은 매우 클 수 있습니다. 

이 파일을 서비스 요청에 업로드 하십시오.

전체 rack 에 대한 sundiag 데이터를 수집하려면:

dcli 를 사용하여 전체 rack 에 대한 sundiag.sh 결과를 수집하면 결과물이 같은 이름을 가질 수 있어 압축 해제시 오버라이트될 수 있습니다. 이것을 방지하기 위해 DB01 에서 다음을 사용하십시오:

1. [root@exadb01 ~]# cd /opt/oracle.SupportTools/onecommand (혹은 rack 호스트이름 목록을 가진 all_group 의 위치)

2. [root@exadb01 onecommand]# dcli -g all_group -l root /opt/oracle.SupportTools/sundiag.sh 2>&1
<약 2분 정도 소요>

3. 각 노드의 /tmp 에 결과물이 생성되었는지 확인하십시오:
[root@exadb01 onecommand]# dcli -g all_group -l root --serial 'ls -l /tmp/sundiag* '

4. 같은 날짜기록을 가진 같은 파일이름이 있을 수 있으므로 호스트명으로 디렉토리를 정렬하십시오:
[root@exadb01 onecommand]# for H in `cat all_group`; do mkdir /root/rack-sundiag/$H ; scp -p $H:/tmp/sundiag*.tar.bz2 /root/rack-sundiag/$H ; done

5. [root@exadb01 onecommand]# cd /root/rack-sundiag

6. [root@exadb01 ~]# ls exa*
exacel01:
sundiag_2011_05_24_10_11.tar.bz2

exacel02:
sundiag_2011_05_24_10_11.tar.bz2
...
exadb08:
sundiag_2011_05_24_10_11.tar.bz2

7. [root@exadb01 ~]# tar jcvf exa_rack_sundiag_oracle.tar.bz2 exa*
exacel01/
exacel01/sundiag_2011_05_24_10_11.tar.bz2
exacel02/
exacel02/sundiag_2011_05_24_10_11.tar.bz2
...
exadb08/
exadb08/sundiag_2011_05_24_10_11.tar.bz2

8. [root@exadb01 ~]# ls -l exa_rack_sundiag_oracle.tar.bz2
-rw-r--r-- 1 root root 3636112 May 24 10:21 exa_rack_oracle.tar.bz2

이 파일을 서비스 요청에 업로드 해주십시오.


HP Oracle Exadata 환경:

1. 디스크 장애가 있는 Exadata Storage Server 로 deaddisk.zip 파일을 다운로드 하십시오.
2. 적당한 디렉토리에 압축을 해제합니다. 
3. deaddisk.sh 파일의 권한을 700 으로 바꾸고 실행하십시오:
    # chmod 700 deaddisk.sh
    #./deaddisk.sh
4. 생성된 zip 파일을 업로드 하십시오. 이 스크립트의 실행으로 /tmp 디렉토리에 info_deaddisk_.zip 형식의 zip 파일이 생성될 것입니다. 
    Example: info_deaddisk_2009-01-18-19:52:14.zip


만일 deaddisk.zip 에 대한 링크가 깨졌다면, 이 코드를 복사하여 사용하십시오:

적용 대상:

목적

이 문서는 ASM에 영향을 주지 않고 엑사데이타 스토리지 셀장비를 리붓하거나 전원차단(power down)하는 절차를 제공합니다.

해결책

ASM에 영향을 주지 않고 엑사데이타 스토리지 셀장비를 셧다운하거나 리붓하는 절차:

엑사데이타 셀장비에 유지보수 작업을 수행할때, 셀장비를 리붓하거나 전원차단이 필요할 수가 있습니다. 데이터베이스가 운영중에 스토리지 서버가 다운되면, 스토리지 서버 오프라인이 오라클 ASM 디스크그룹과 데이타베이스의 가용성에 영향을 주지는 않는지 검증하세요. 오라클 ASM 리던던시 레벨과 현재 다운하려는 셀서버 디스크의 미러가 있는 다른 셀서버의 디스크 상태에 따라, 데이타베이스의 가용성에 영향을 주지 않고 엑사데이타 셀서버를 다운할수 있는지 여부가 결정됩니다.
=====================================================================================================================================================

1)  기본적으로 ASM은 디스크가 오프라인된 후 잠시후 드롭을 합니다. 디스크를 복구하고 다시 온라인하는 시간인 DISK_REPAIR_TIME의 값을 변경하여 오프라인후 드롭되는 것을 연기할수 있습니다. DISK_REPAIR_TIME의 기본값은 3.6시간인데 이정도의 값이면 거의 모든 환경에서 적당합니다.

(a) 마운트 되어있는 모든 디스크 그룹의 리페어 타임을 확인하기위해 ASM 인스턴스에 접속 후 다음 sql을 수행하세요:

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';

(b) ASM 디스크를 3.6시간 이상 오프라인해야 할 필요가 있다면, 다음 명령어로 변경할 수있습니다:

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

2)  다음으로는 그리드디스크가 오프라인 상태인지의 여부를 확인할 필요가 있습니다. 다음 명령어는 해당 그리드디스크에 대해 반드시 ‘Yes’가 나타나야합니다:

cellcli -e list griddisk attributes name,asmmodestatus,asmdeactivationoutcome

3) 한 개 이상의 디스크가 asmdeactivationoutcome=’Yes’ 로 나타나지 않으면, 해당 디스크그룹을 확인하고 그 디스크그룹의 데이터 리던던시를 복구해야 합니다. 디스크그룹의 데이터 리던던시가 모두 리스토어된 후에 Step 2) 의 명령어를 다시 수행하세요. 일단 모든 디스크들이 asmdeactivationoutcome=’Yes’로 나타나야만 다음 step 4)에서 그리드디스크 오프라인을 진행할 수 있습니다.

Note: 한개 이상의 그리드 디스크가 asmdeactivationoutcome=’Yes’ 가 아닌 상태에서 셀 서비스들을 셧다운 하면, ASM은 디스크 그룹을 디스마운트 하고, 결국 데이타베이스가 뜻하지않게 다운됩니다.

4) 전원차단/리붓을 하려는 셀장비에서 모든 그리드디스크를 비활성화(inactive)하기 위해 cellcli 명령을 수행하세요:

* Please note - 이 작업은 disk의 작업량에 따라 10분 이상 소요될 수 있습니다. 셀서버를 셧다운 하기전에 모든 디스크들을 오프라인 해야 하는 것은 매우 중요합니다. 그리드디스크를 비활성화(inactivate)하면 ASM 인스턴스 내의 디스크들은 자동적으로 오프라인 됩니다. 

5) 다음 작업들을 수행하여 그리드디스크들이 현재 오프라인이 되었는지를 확인하세요:

(a) ASM에서 일단 디스크들이 오프라인이 되면, 다음 명령어를 수행시 asmmodestatus=OFFLINE or UNUSED, asmdeactivationoutcome=Yes로 나타나야 합니다. 이 경우에만 셧다운이나 리붓을 진행하는것이 안전합니다:

cellcli -e list griddisk attributes name,asmmodestatus,asmdeactivationoutcome

( asmmodestatus=OFFLINE으로 나타나는 경우도 있습니다. 이것은 ASM이 이 그리드디스크를 오프라인한것을 의미합니다. 이상태에서도 마찬가지로 나머지 절차를 진행할수 있습니다)

(b) 모든 그리드디스크가 오프라인인지 확인하기위해 다음 명령어를 수행하세요:

cellcli -e list griddisk

6) 이제 셀서버를 리붓할 수 있습니다. 오라클 엑사데이타 스토리지 서버는 리눅스 명령어를 사용하여 전원 차단하거나 리붓할 수 있습니다.

(a) 다음 명령어는 오라클 엑사데이타 스토리지 서버를 즉시 셧다운합니다: (root 로 실행):

#shutdown -h now

( 오라클 엑사데이타 스토리지 서버가 전원차단이 되면, 모든 스토리지 서비스도 자동으로 중단됩니다.)

(b) 다음 명령어는 오라클 엑사데이타 스토리지 서버를 즉시 리붓하고, 리붓시 강제로 fsck를 수행합니다:

#shutdown -F -r now

7) 일단 셀서버가 다시 온라인이되면 다음 명령어로 그리드디스크를 활성화 해야 합니다:

cellcli -e alter griddisk all active

8) 다음 명령어를 수행하면 모든 디스크들이 ‘active’로 나타나야 합니다:

cellcli -e list griddisk

9)  그리드디스크의 상태를 점검하세요:

(a) 다음 명령어를 이용하여 모든 그리드디스크들이 성공적으로 온라인이 되었는지 확인하세요:

cellcli -e list griddisk attributes name, asmmodestatus

(b) 모든 그리드디스크에 대해 asmmodestatus가 ONLINE으로 나타날 때까지 기다리세요. 각각의 디스크들은 처음에는 ‘SYNCING’상태였다가 ‘ONLINE’으로 변경됩니다. 다음은 결과의 한 예입니다:

DATA_CD_00_dm01cel01 ONLINE
DATA_CD_01_dm01cel01 SYNCING
DATA_CD_02_dm01cel01 OFFLINE
DATA_CD_03_dm01cel01 OFFLINE
DATA_CD_04_dm01cel01 OFFLINE
DATA_CD_05_dm01cel01 OFFLINE
DATA_CD_06_dm01cel01 OFFLINE
DATA_CD_07_dm01cel01 OFFLINE
DATA_CD_08_dm01cel01 OFFLINE
DATA_CD_09_dm01cel01 OFFLINE
DATA_CD_10_dm01cel01 OFFLINE
DATA_CD_11_dm01cel01 OFFLINE

(c) 오라클 ASM 동기화(synchronization)는 모든 그리드디스크가 asmmodestatus=ONLINE이 될 때 완료됩니다.

( Please note:  이 동작은 Fast Mirror Resync operation을 사용하며, ASM 리발란스를 하지 않습니다. Resync operation은 단지 디스크가 오프라인된 동안 쓰여진 익스텐드들만 저장합니다.)

  

10) 다른 스토리지 서버를 오프라인하기전에, 새로 기동된 오라클 엑사데이타 스토리지 서버에서 오라클 ASM 동기화(synchronization)가 반드시 완료되어야 합니다. 만약 이 동기화가 완료되지 않았다면, 다른 스토리지 서버의 점검이 실패하게 됩니다. 다음은 이런 경우의 예입니다:

CellCLI> list griddisk attributes name where asmdeactivationoutcome != 'Yes'
DATA_CD_00_dm01cel02 "Cannot de-activate due to other offline disks in the diskgroup"
DATA_CD_01_dm01cel02 "Cannot de-activate due to other offline disks in the diskgroup"
DATA_CD_02_dm01cel02 "Cannot de-activate due to other offline disks in the diskgroup"
DATA_CD_03_dm01cel02 "Cannot de-activate due to other offline disks in the diskgroup"
DATA_CD_04_dm01cel02 "Cannot de-activate due to other offline disks in the diskgroup"
DATA_CD_05_dm01cel02 "Cannot de-activate due to other offline disks in the diskgroup"
DATA_CD_06_dm01cel02 "Cannot de-activate due to other offline disks in the diskgroup"
DATA_CD_07_dm01cel02 "Cannot de-activate due to other offline disks in the diskgroup"
DATA_CD_08_dm01cel02 "Cannot de-activate due to other offline disks in the diskgroup"
DATA_CD_09_dm01cel02 "Cannot de-activate due to other offline disks in the diskgroup"
DATA_CD_10_dm01cel02 "Cannot de-activate due to other offline disks in the diskgroup"
DATA_CD_11_dm01cel02 "Cannot de-activate due to other offline disks in the diskgroup"