Exadata 점검 레포트

오라클 엑사데이타 점검 스크립트인 Exacheck (엑사체크) 입니다.

부분 부분을 나눠 보면 Oracle RAC Database 의 Config Detail Check 방법을 확인 할 수 있습니다.

[Sample]    
Oracle Exadata ExaCheck Report

Customer    :    [Sample]

Author    :

Team        :

Creation Date:    2017년 09월 13일

Last Updated    :    2017년 11월 28일

Version    :    1.1

Table of Contents

Document Control    5

Document Guide    6

Database Server Summary    9

Storage Server Summary    12

Cluster Wide Summary    13

InfiniBand Switch Summary    14

Maximum Availability Architecture Summary    15

Database Server    16

ASM Check    16

All disk groups should have compatible.advm attribute set to recommended values    16

All disk groups should have compatible.rdbms attribute set to recommended values    16

One or more disk groups do not have appliance mode attribute set to true    17

There should be enough freespace in all diskgroups to reestablish redundancy after a single disk failure    18

ASM Audit file destination file count > 100,000    19

Database Check    20

Database parameters log_archive_dest_n with Location attribute are NOT all set to recommended value    20

The bundle patch version installed does not match the bundle patch version registered in the database    21

Database control files are not configured as recommended    22

Database parameter CLUSTER_INTERCONNECTS is NOT set to the recommended value    23

Database parameter Db_create_online_log_dest_n is not set to recommended value    25

Database should not be in DST upgrade state    25

OS Check    27

One or more non-default AWR baselines should be created    27

Exadata Storage Server GI software version does not meet requirement for rolling cell patching    27

Active system values should match those defined in configuration file “cell.conf”    28

CRS_LIMIT_NPROC should be greater than 65535 and not “UNLIMITED”    29

CSS misscount should be set to the recommended value of 60    30

The CRS_HOME should be properly locked.    31

Hidden database initialization parameters should be set per best practice recommendations    32

One or more database servers have stateful alerts that have not been cleared    32

The InfiniBand Address Resolution Protocol (ARP) Configuration on Database Servers should be as recommended    33

Oracle Enterprise Linux 5 rpms are installed on Oracle Enterprise Linux 6    37

The database server file systems should have “Check interval” = “0”    38

The database server file systems should have “Maximum mount count” = “-1”    39

Database parameter _enable_NUMA_support should be set to recommended value    40

Database parameter db_recovery_file_dest_size is NOT set to recommended value    41

Operating system hugepages count does not satisfy total SGA requirements    42

Number of SCAN listeners is NOT equal to the recommended number of 3    43

System model number is not correct    43

Downdelay attribute is not set to recommended value on bonded client interface    44

One or more Ethernet network cables are not connected    48

_reconnect_to_cell_attempts parameter in cellinit.ora is not set to recommended value    49

PGA allocation for all databases is more than total memory available on this system    50

SQL Check    51

Some data or temp files are not autoextensible    51

Application objects were found to be invalid    51

SYS or SYSTEM objects were found to be INVALID    52

Table AUD$[FGA_LOG$] should use Automatic Segment Space Management    53

SQL Parameter Check    54

ASM parameter ASM_POWER_LIMIT is not set to the default value.    54

ASM parameter AUDIT_SYS_OPERATIONS should be set to the recommended value    55

Database parameter AUDIT_SYS_OPERATIONS should be set to the recommended value    56

Database parameter AUDIT_TRAIL should be set to the recommended value    57

Database parameter OS_AUTHENT_PREFIX is NOT set to recommended value    57

Database parameter PARALLEL_ADAPTIVE_MULTI_USER is not set to recommended value    58

Database parameter PARALLEL_THREADS_PER_CPU is not set to recommended value    59

Database parameter SQL92_SECURITY is NOT set to recommended value    60

Database parameter USE_LARGE_PAGES is not set to recommended value    60

filesystemio_options is not set to recommended value    61

Database parameter _parallel_adaptive_max_users is not set to recommended value    62

Database parameter _SMM_AUTO_MAX_IO_SIZE should be set to the recommended value    63

Storage Server    64

Storage Server Check    64

Hardware and firmware profile check not is successful on one or more storage servers    64

Storage Server alerts are not configured to be sent via email    65

One or more storage servers have stateful alerts that have not been cleared    66

One or more storage server has non-test stateless alerts with null “examinedby” fields.    66

Active system values should match those defined in configuration file “cell.conf”    67

RAID controller version does not match on all storage servers    69

ILOM Power Up Configuration for HOST_LAST_POWER_STATE should be set to recommended value    69

Management network is not separate from data network on all storage servers    70

Cluster Wide    72

Cluster Wide Check    72

Localtime configuration does not match on all Infiniband switches    72

NTP server does not match across all database and storage servers    73

InfiniBand Switch    74

InfiniBand Switch Check    74

Hostname is not set in /etc/hosts    74

Maxinum Availability Architecture    75

MAA Check    75

Redo log files should be appropriately sized    75

Local archive destination does not alternate destination configured    77

Exadata Critical Issues (Doc ID 1270094.1):- DB1-DB4,DB6,DB9-DB35, EX1-EX21, EX23-EX26,EX29 and IB1-IB3,IB5    79

The SYS and SYSTEM user ids should have a default tablespace of SYSTEM    86

RMAN controlfile autobackup should be set to ON    87

Database parameter DB_LOST_WRITE_PROTECT is NOT set to recommended value    88

Database parameter LOG_BUFFER is NOT set to recommended value    89

fast_start_mttr_target should be greater than or equal to 300    89

The data files should be recoverable    90

제목1 : Ctrl + 1

제목2 : Ctrl + 2 (제목2위Bar)

제목2 : Ctrl + Shift + 2 (제목2 Title)

제목3 : Ctrl + 3 (밑줄)

제목4 : Ctrl + 4 (네모 점)

제목5 : Ctrl + 5 (동그라미 점)

제목6 : Ctrl + 6 (>)

제목7 : Ctrl + 7 (결론부분 제목. 네모)

본문1 : Alt + 1

본문2 : Alt + 2

본문2 : Alt + Shift + 2 (파란색 결론설명)

본문3 : Alt + 3

본문4 : Alt + 4

본문5 : Alt + 5 (작은글)

본문6 : Alt + 6 (작은글, 회색바탕)

본문-글꼴색만 바다색으로 : Alt + 8

본문-숨김글 : Alt + 9 (Word에서만 보임)

본문SQL : Alt + 0 ( Full Line Small Fixed Font)

Document Control

Change Record

Document Guide

Considerations

본 문서는 작성 당시의 권장 사항을 바탕으로 Exachk 수행시 나타나는 점검 결과에 대한 분석 결과 샘플을 작성 했으므로 이후 또는 신규 Exachk로 수행시 권장 사항이 변경될 수 있겠습니다.

분석 결과 작성시 본 분석 샘플을 활용하되 권장사항이 변경된 부분이 있는지 관련 문서를 확인하시기 바랍니다.

Database Server Summary

Storage Server Summary

Cluster Wide Summary

InfiniBand Switch Summary

Maximum Availability Architecture Summary

Database Server

ASM Check

All disk groups should have compatible.advm attribute set to recommended values

ASM의 ACFS 속성을
확인함

ASM diskgroup의 다음의 설정이 BP와 일치하는지 확인함.

* COMPATIBLE.ADVM attribute is set to the Oracle ASM version in use.

#설정확인

ASM@SQL> col diskgroup for a20

col name for a50

col value for a20

SELECT DG.NAME AS DISKGROUP, SUBSTR(A.NAME,1,40) AS NAME,

SUBSTR(A.VALUE,1,24) AS VALUE, READ_ONLY

FROM V$ASM_DISKGROUP DG, V$ASM_ATTRIBUTE A

WHERE 1=1

AND DG.GROUP_NUMBER = A.GROUP_NUMBER

AND A.NAME LIKE ‘%advm%’;

#설정변경

ASM@SQL> alter diskgroup <DG명> set attribute ‘<속성>’=’ 12.1.0.2.0′ ;

=================================================================

수행결과샘플: 현재 다음과 같이 advm 설정 되어있지 않음. ACFS를 사용하는 경우 상기와 같이 ADVM 속성을 12.1.0.2.0으로 설정할것

DATA FROM PRODDB01 – ASM DISK GROUP COMPATIBLE.ADVM ATTRIBUTE

Oracle Clusterware active version on the cluster is [12.1.0.2.0]

None of the diskgroups have compatible.advm attribute set

All disk groups should have compatible.rdbms attribute set to recommended values

ASM의 RDBMS 버전
속성을
확인함

ASM diskgroup의 다음의 설정이 BP와 일치하는지 확인함.

* COMPATIBLE.RDBMS attribute is set to the minimum Oracle database software version in use.

#설정확인

ASM@SQL> col diskgroup for a20

col name for a50

col value for a20

SELECT DG.NAME AS DISKGROUP, SUBSTR(A.NAME,1,40) AS NAME,

SUBSTR(A.VALUE,1,24) AS VALUE, READ_ONLY

FROM V$ASM_DISKGROUP DG, V$ASM_ATTRIBUTE A

WHERE 1=1

AND DG.GROUP_NUMBER = A.GROUP_NUMBER

AND A.NAME LIKE ‘%rdbms%’;

#설정변경

ASM@SQL> alter diskgroup <DG명> set attribute ‘<속성>’='<값>’ ;

=================================================================

수행결과샘플: 현재 설치 DB의 최소 버전이 12.1.0.2이나 rdbms 호환 버전은 11.2.0.2.0으로 설정되어 있음. 12c DB만 존재하므로 다음의 속성들은 모두 12.1.0.2.0으로 변경 할것을 권장함

DATA FROM PRODDB01 – ASM DISK GROUP COMPATIBLE.RDBMS ATTRIBUTE

lowest rdbms version = 121020

ASM DATAC1.compatible.rdbms = 11.2.0.2.0

ASM DBFS_DG.compatible.rdbms = 11.2.0.2.0

ASM RECOC1.compatible.rdbms = 11.2.0.2.0

One or more disk groups do not have appliance mode attribute set to true

ASM Diskgroup의
설정을
확인함

Exadata의 ASM diskgroup은 ASM 작업의 안정성, 보안, 성능 향상을 위해 appliance 모드를 TRUE로 설정할 것을 권장함

#설정확인

ASM@SQL> col diskgroup for a20

col name for a50

col value for a20

SELECT DG.NAME AS DISKGROUP, SUBSTR(A.NAME,1,40) AS NAME,

SUBSTR(A.VALUE,1,24) AS VALUE, READ_ONLY

FROM V$ASM_DISKGROUP DG, V$ASM_ATTRIBUTE A

WHERE 1=1

AND DG.GROUP_NUMBER = A.GROUP_NUMBER

AND A.NAME LIKE ‘%appliance.mode%’;

#설정변경

ASM@SQL> alter diskgroup <DG명> set attribute ‘<속성>’=’TRUE’ ;

• Rebalance 수행됨
  

  =================================================================
  

  수행결과샘플: 현재 다음과 같이 모든 Diskgroup에 appliance 모드가 설정되지 않음. 권장설정에 맞게 변경 권장
  

  Status on proddb01:
  

  FAIL => One or more disk groups do not have appliance mode attribute set to true
  

  DATA FROM PRODDB01 – ASM DISK GROUP APPLIANCE.MODE ATTRIBUTE
  

  DATAC1.appliance.mode = FALSE
  

  DBFS_DG.appliance.mode = FALSE
  

  RECOC1.appliance.mode = FALSE
  

There should be enough freespace in all diskgroups to reestablish redundancy after a single disk failure

ASM의
잔여
공간
확인

ASM에 Rebalance 작업시 필요한 여유 공간이 있는 확인함

#설정확인

ASM@SQL> SELECT dg.name, dg.total_mb, dg.free_mb, dg.total_mb-dg.free_mb used_mb, (dg.total_mb-dg.free_mb)*0.15 required_free_mb, round(free_mb/total_mb * 100) pct_free

FROM v$asm_diskgroup dg

WHERE dg.free_mb < (dg.total_mb-dg.free_mb)*0.15

ORDER BY 1;

수행결과가 다음과 같이 있는 경우 잔여 공간이 부족함

NAME TOTAL_MB FREE_MB USED_MB REQUIRED_FREE_MB PCT_FREE

—————————— ———- ———- ———- —————- ———-

DBFS_DG 4845120 484476 4360644 654096.6 10

=================================================================

수행결과샘플: 현재 다음과 같이 DATAC1 Diskgroup의 경우 FREE 공간이 Disk 장애시 필요한 REQUIRED_FREE_MB 보다 작음. REBAL 수행이 가능하도록 잔여 공간 확보 또는 용량 증설 필요

DATA FROM PRODDB01 – VERIFY THERE IS ENOUGH DISKGROUP FREESPACE FOR A REBALANCE OPERATION [SINGLE DISK FAILURE]

NAME     TOTAL_MB FREE_MB USED_MB REQUIRED_FREE_MB PCT_FREE

———————————————————— ———- ———- ———– ———-

DATAC1     40697856 2277464 38420392 5763058.8     6

ASM Audit file destination file count > 100,000

ASM의 Audit 설정을
확인함

ASM의 Audit 파일 디렉토리는 주기적으로 관리를 하지 않을 경우 파일 증가로 인해 사이즈가 지속적으로 커질 수 있음. 이를 방치할 경우 파일 수 증가로 인해 공간 부족 또는 Oracle 엔진의 성능저하로 ASM 인스턴스 기동시 hang이 걸릴 수 있음. 이를 방지하기 위해 crontab을 통해 30일이 지난 파일은 삭제하도록 관리가 필요함

#경로확인

$ . /usr/local/bin/oraenv

ORACLE_SID = [+ASM1] ? +ASM1

The Oracle base for ORACLE_HOME=/u01/app/12.1.0.2/grid is /u01/app/oracle

$ echo $ORACLE_HOME/rdbms/audit

예) /u01/app/12.1.0.2/grid/rdbms/audit

$ echo $ORACLE_BASE/admin/$ORACLE_SID/adump

예) /u01/app/oracle/admin/+ASM1/adump

$ sqlplus ‘/ as sysasm’

SQL> select value from v$parameter where name = ‘audit_file_dest’;

VALUE

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

예) /u01/app/12.1.0.2/grid/rdbms/audit

각 경로의 파일 수 및 용량 확인할 것

#Crontab 등록(각 DB노드에서 수행)

root# echo oracle >> /etc/cron.allow

oracle$ crontab –e

0 2 * * sun /usr/bin/find /u01/app/12.1.0.2/grid/rdbms/audit /u01/app/12.1.0.2/grid/rdbms/audit /u01/app/oracle/admin/+ASM1/adump -maxdepth 1 -name ‘*.aud’ -mtime +30 -delete

oracle$ crontab -l

0 2 * * sun /usr/bin/find /u01/app/12.1.0.2/grid/rdbms/audit /u01/app/12.1.0.2/grid/rdbms/audit /u01/app/oracle/admin/+ASM1/adump -maxdepth 1 -name ‘*.aud’ -mtime +30 -delete

=================================================================

수행결과샘플: 다음과 같이 양쪽 DB노드 모두 audit 파일수가 10만개 이상 적재 되어 있음. 상기의 절차에 따라 crontab을 통한 관리 설정이 필요함

Status on PROD01:

FAIL => ASM Audit file destination file count > 100,000

DATA FROM PROD01 – MANAGE ASM AUDIT FILE DIRECTORY GROWTH WITH CRON

Number of audit files at /apps/oracle/12.1.0.2/grid/rdbms/audit = 1166588

Database Check

Database parameters log_archive_dest_n with Location attribute are NOT all set to recommended value

Log archive 경로
설정
확인함

Exadata의 경우 log archive 경로를 다음과 같이 FRA영역인 recovery_file_dest를 지정하는 것을 권장함.

*.log_archive_dest_1= ‘LOCATION=USE_DB_RECOVERY_FILE_DEST’

#확인방법

SQL> show parameter log_archive_dest_1;

#설정변경

SQL>alter system set log_archive_dest_1=’LOCATION=USE_DB_RECOVERY_FILE_DEST’ scope=both sid=’*’;

=================================================================

수행결과샘플: 수행 결과 PROD DB의 경우 권장과 달리 RECO영역이 직접 지정됨. 권장설정에 맞게 USE_DB_RECOVERY_FILE_DEST로 지정이 필요함

DATA FROM PRODDB01 – PROD DATABASE – LOG_ARCHIVE_DEST_N

log_archive_dest_1 = LOCATION=+RECOC1

The bundle patch version installed does not match the bundle patch version registered in the database

Bundle Patch 버전
정보를
확인함

DB에 등록된 Bundle Patch 버전 정보과 실제 엔진에 설치된 버전을 비교 확인함

# DB엔진에 설치된 버전 확인

oracle$ $ORACLE_HOME/OPatch/opatch lspatches

# DB에 등록된 버전 확인

SQL> select distinct comments from registry$history where comments like ‘%BP%’;

=================================================================

수행결과샘플: 엔진에는 BP170418 버전이 설치된 것이 확인되었으며 DB에 등록된 정보는 없는 것으로 나타났으나 직접 체크시 엔진과 동일한 BP가 설치된 것으로 확인됨. 특이사항 없음

Status on PROD02:PROD:

FAIL => The bundle patch version installed does not match the bundle patch version registered in the database

DATA FROM PROD02 – PROD DATABASE – VERIFY BUNDLE PATCH VERSION INSTALLED MATCHES BUNDLE PATCH VERSION REGISTERED IN DATABASE

Bundle patch installed in software home = 170418

Bundle patch installed database registry = –

SQL> select * from dba_registry_history;

ACTION_TIME ACTION NAMESPACE VERSION ID BUNDLE_SERIES COMMENTS

—————————— —————————— —————————— —————————— ———- —————————— ——————–

26-NOV-14 01.53.43.536028 PM APPLY SERVER 11.2.0.4 12 EXA BP12

26-NOV-14 01.55.57.923755 PM APPLY SERVER 11.2.0.4 12 EXA BP12

19-MAY-17 07.12.23.603224 PM jvmpsu.sql SERVER 11.2.0.4.170418OJVMPSU 0 RAN jvmpsu.sql

19-MAY-17 07.12.55.860326 PM APPLY SERVER 11.2.0.4 170418 EXA BP170418

19-MAY-17 07.13.30.552684 PM APPLY SERVER 11.2.0.4.170418OJVMPSU 0 OJVM PSU post-instal

l

19-MAY-17 07.13.30.554259 PM APPLY 25434033 Patch 25434033 appli

Database control files are not configured as recommended

Controlfile 설정이 BP와
일치하는지
확인

안정성을 위해 controlfile을 삼중화된 diskgroup에 위치 시키고 Write 부하를 줄이기 위해 단일 파일로 구성할 것을 권장함. 만약 삼중화된 diskgroup이 없는 경우 controfile은 DATA diskgroup에 위치 시키고 자동 백업을 다른 diskgroup(RECO)에 저장할 것을 권장함

# Controlfile 위치 확인

SQL> select substr(cf.name,1,instr(cf.name,’/’,1,1) – 1) cf_name,dg.name dg_name,dg.type redundancy from v$controlfile cf,v$asm_diskgroup dg where replace(substr(cf.name,1,instr(cf.name,’/’,1,1) – 1),’+’) = dg.name;

# Controlfile 변경방법

• Controlfile 경로 확인
  

  SQL> show parameter control_files;
  

  NAME TYPE VALUE
  

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

  control_files string +DATA … current….
  

• Controlfile을 단일 Diskgroup 으로 변경
  

  SQL> alter system set control_files=’+<기존 controlfile>‘ scope=spfile;
  

• Controlfile autobackup 설정
  
• RMAN controlfile autobackup should be set to ON 확인
  

  적용을 위해 DB 재기동 필요
  

  =================================================================
  

  수행결과샘플: 모든 DB의 controlfile 들이 삼중화된 Diskgroup에 존재하나 단일파일이 아닌 두개의 파일로 존재함. Controlfile Write 부하를 줄이기 위해 단일 파일로 구성할 것을 권장함
  

  Status on PROD02:PROD:
  

  FAIL => Database control files are not configured as recommended
  

  DATA FROM PROD02 – PROD DATABASE – HIGH REDUNDANCY CONTROLFILE
  

  Control files = +DATA/PROD/controlfile/current.650.944411567
  

  +RECO/PROD/controlfile/current.320.944411567
  

  High redundancy diskgroups = 2
  

  High redundancy diskgroups where control files are multiplexed = 2
  

  Normal redundancy diskgroups where control files are multiplexed = 0
  

  Flash Recovery Area disk group Name = +RECO
  

Database parameter CLUSTER_INTERCONNECTS is NOT set to the recommended value

CLUSTER_INTERCONNECTS 파라메터
설정을
확인함

Exadata는 Clusterware HAIP address를 지원하지 않으므로 다음과 같이 CLUSTER_INTERCONNECTS에 Infiniband IP 지정이 필요함

cluster_interconnects = <bondib0 ip> # Active-passive bonding인 경우

cluster_interconnects = <ib0 ip>:<ib1 ip> # Active-active bonding인 경우

#설정확인

SQL> show parameter cluster_interconnects;

#설정변경

Root# ifconfig bondib0 # Active-passive bonding인 경우

Ifconfig is obsolete! For replacement check ip.

bondib0 Link encap:InfiniBand HWaddr 80:00:00:48:FE:80:00:00:00:00:00:00:00:00:00:00:00:00:00:00

inet addr:192.168.10.1 Bcast:192.168.11.255 Mask:255.255.252.0

inet6 addr: fe80::210:e000:10a:2961/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:65520 Metric:1

RX packets:12007177 errors:0 dropped:0 overruns:0 frame:0

TX packets:9922836 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1024

RX bytes:6369193304 (5.9 GiB) TX bytes:1918110229 (1.7 GiB)

Root# ifconfig ib0 # Active-active bonding인 경우

ib0 Link encap:InfiniBand HWaddr 80:00:00:48:FE:80:00:00:00:00:00:00:00:00:00:00:00:00:00:00

inet addr:192.168.10.1 Bcast:192.168.11.255 Mask:255.255.252.0

inet6 addr: fe80::210:e000:159:994d/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:65520 Metric:1

RX packets:52579150 errors:0 dropped:0 overruns:0 frame:0

TX packets:53498933 errors:0 dropped:70 overruns:0 carrier:0

collisions:0 txqueuelen:4096

RX bytes:38074606650 (35.4 GiB) TX bytes:21473236047 (19.9 GiB)

Root# ifconfig ib1 # Active-active bonding인 경우

ib1 Link encap:InfiniBand HWaddr 80:00:00:49:FE:80:00:00:00:00:00:00:00:00:00:00:00:00:00:00

inet addr:192.168.10.2 Bcast:192.168.11.255 Mask:255.255.252.0

inet6 addr: fe80::210:e000:159:994e/64 Scope:Link

UP BROADCAST RUNNING MULTICAST MTU:65520 Metric:1

RX packets:11426719 errors:0 dropped:0 overruns:0 frame:0

TX packets:10728153 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:4096

RX bytes:4180159176 (3.8 GiB) TX bytes:5689112887 (5.2 GiB)

SQL> alter system set cluster_interconnects='<bonding ip>’ scope=spfile sid='<SID>’;

적용 후 DB 재기동 필요

=================================================================

수행결과샘플: 수행 결과 PROD DB의 경우 CLUSTER_INTRECONNECTS 파라메터 설정이 되어 있지 않음. BP에 맞도록 각 노드의 bondib0의 IP를 설정 할 것을 권고함

DATA FROM PRODDB01 – PROD DATABASE – CLUSTER_INTERCONNECTS

Cluster Interconnect Value from instance = 192.168.10.1

Network card name and IP from oifcfg

bondib0 = 192.168.10.1

DATA FROM PRODDB01 – PROD DATABASE – CLUSTER_INTERCONNECTS

Cluster Interconnect Value from instance =

Network card name and IP from oifcfg

bondib0 = 192.168.10.1

Database parameter Db_create_online_log_dest_n is not set to recommended value

Online redo log의
설정이 BP와
일치하는지
확인

안정성을 위해 Redo log file을 삼중화된 diskgroup에 위치 시킬 것을 권고함. 만약 삼중화된 diskgroup이 없는 경우 두 logfile member를 서로 다른 diskgroup(DATA, RECO)에 위치 시킬 것을 권고함

# redolog 경로 설정 확인

SQL> show parameter db_create_online_log_dest;

# redolog 경로 변경

SQL> alter system set db_create_online_log_dest_2=’+<RECO diskgroup>‘ scope=both sid=’*’;

SQL> alter database add logfile member ‘+<RECO Diskgroup>‘ to group <group number>;

SQL> alter system switch logfile;

Log file group 별로 반복해서 수행

=================================================================

수행결과샘플: 수행 결과 DB DB의 경우 redolog 파일들이 2중화된 diskgroup에 할당되어 있으며 다중화가 되어 있지 않은 상태임. 상기의 절차를 참고하여 RECO diskgroup에도 redolog member를 추가 할것을 권장함

Status on proddb01:DB:

FAIL => Database parameter Db_create_online_log_dest_n is not set to recommended value

DATA FROM PRODDB01 – DB DATABASE – HIGH REDUNDANCY REDOLOG FILES

High redundancy disk groups =      0

Number of redo log groups with more than 1 member =      0

Number of diskgroup where redo log members are multiplexed =          1

Database should not be in DST upgrade state

DB timezone 모드
확인

DB Timezone이 upgrade 모드 이거나 inconsistent 모드인 경우 DB node에서 Cell로 요청된 I/O작업이 Smart scan이 아닌 block I/O나 passthru로 전환되어 수행될 수 있으며 이로 인해 RDS 통신에 과부하를 일으켜 성능 저하가 발생 할 수 있음.

# 설정 확인

Oracle# unset DST_UPGRADE_STATE_VALUE;

DST_UPGRADE_STATE_VALUE=$($ORACLE_HOME/bin/sqlplus -s “/ as sysdba” <<EOF

set head off lines 80 feedback off timing off serveroutput on

select upper(property_value) from sys.database_properties where property_name = ‘DST_UPGRADE_STATE’;

exit

EOF);

if [ $DST_UPGRADE_STATE_VALUE = “NONE” ]

then

echo -e “SUCCESS: DB is not in DST upgrade state. \”DST_UPGRADE_STATE\” column value = “$DST_UPGRADE_STATE_VALUE””

else

echo -e “FAILURE: DB is in DST upgrade state. \”DST_UPGRADE_STATE\” column value = “$DST_UPGRADE_STATE_VALUE””

fi;

The expected output should be similar to:

SUCCESS: DB is not in DST upgrade state. “DST_UPGRADE_STATE” column value = NONE

# 설정변경(Doc ID 1583297.1 참고)

1. Enable event 30090:

SQL> ALTER SESSION SET EVENTS ‘30090 TRACE NAME CONTEXT FOREVER, LEVEL 32’;

2. Execute the following:

SQL> exec dbms_dst.unload_secondary;

3. Validate that the database is not in DST upgrade mode

SQL> select property_value from sys.database_properties where property_name = ‘DST_UPGRADE_STATE’;

PROPERTY_VALUE

———————————-

NONE

=================================================================

수행결과샘플: 수행 결과 PROD DB의 경우 DST upgrade 상태로 확인됨. 상기의 절차에 따라 설정을 변경할 것을 권고함

DATA FROM PRODDB01 – PROD DATABASE – VERIFY DATABASE IS NOT IN DST UPGRADE STATE

FAILURE: DB is in DST upgrade state. “DST_UPGRADE_STATE” column value = DATAPUMP(2)

OS Check

One or more non-default AWR baselines should be created

AWR baseline 설정을
확인함

필요시 보다 정확한 성능 분석을 위해 AWR의 기본 baseline 이외에 추가적으로 워크로드별로 baseline을 설정하는 것을 권장하는 내용으로 다음의 문서를 참고하여 설정이 가능함

현재 디폴트 AWR baseline만 설정되어 있으므로 필요시 다음의 문서를 참고하여 설정 할 것

http://docs.oracle.com/database/121/ARPLS/d_workload_repos.htm#ARPLS69128

Exadata Storage Server GI software version does not meet requirement for rolling cell patching

Exadata Storage Server Rolling 업그레이드시
필요한
버전을
체크함

다음의 버그로 인해 스토리지 서버 롤링 업그레이드시 Grid Home의 버전이 12.1.0.2 BP1~3이 설치된 경우 Grid Home에 추가적으로 Interim Patch 19883038 적용이 필요하며 12.1.0.2 BP160119 이상 부터는 별도 패치 불필요

Bug 19883038 : XDMG NOT RESPONDING DUE TO DISKMON HANG

# 확인방법

oracle# opatch -lspatches -oh <Grid_home> | grep 19883038

=================================================================

수행결과샘플: 다음과 같이 Interim patch가 미적용 상태로 스토리지 소프트웨어 패치를 Rolling으로 적용이 필요한 경우 상기의 Interim 패치를 적용하거나 최신 BP로 업그레이드 할 것

oracle@PROD01:/home/oratis> opatch lspatches -oh /apps/oracle/12.1.0.2/grid -customLogDir /home/oratis/imsi/

20157569;OCW Patch Set Update : 12.1.0.2.1 (20157569)

19878106;DATABASE BUNDLE PATCH: 12.1.0.2.3 (19878106)

19392590;ACFS Patch Set Update : 12.1.0.2.1 (19392590)

oracle@PROD02:/home/oratis> opatch lspatches -oh /apps/oracle/12.1.0.2/grid/ -customLogDir /home/oratis/imsi/

20157569;OCW Patch Set Update : 12.1.0.2.1 (20157569)

19878106;DATABASE BUNDLE PATCH: 12.1.0.2.3 (19878106)

19392590;ACFS Patch Set Update : 12.1.0.2.1 (19392590)

Active system values should match those defined in configuration file “cell.conf”

스토리지
서버의 Runtime 설정
환경파일 crosscheck

스토리지 서버 환경설정 파일인 cell.conf와 runtime 설정이 일치하는지 확인

#확인방법

• 각 스토리지 서버에서 수행
  

  Root# IPCONF_RAW_OUTPUT=$(/opt/oracle.cellos/ipconf -verify -semantic -at-runtime -check-consistency -verbose 2>/dev/null);
  

  IPCONF_RESULT=$(echo “$IPCONF_RAW_OUTPUT” | egrep “Consistency check PASSED” | wc -l);
  

  IPCONF_SUMMARY=$(echo “$IPCONF_RAW_OUTPUT” | tail -1);
  

  if [ $IPCONF_RESULT = “1” ]
  

  then
  

  echo -e “SUCCESS: $IPCONF_SUMMARY”
  

  else
  

  echo -e “FAILURE: $IPCONF_SUMMARY\n”
  

  echo -e “echo -e "$IPCONF_RAW_OUTPUT" | grep FAILED”
  

  fi;
  

  The expected output is:
  

  SUCCESS: [Info]: Consistency check PASSED
  

  또는
  

  FAILURE: Info. Consistency check FAILED
  

  =================================================================
  

  수행결과샘플: 확인 결과 전체 스토리지 서버의 NTP 동기화가 수행되지 않음이 확인됨. 이는 NTP relay를 설정한 DB node의 ntp.conf 파일에 restrict 설정 이슈로 인해 발생함. DB node #1,2번의 /etc/ntp.conf에서 다음과 같이 변경할 것. 스토리지 서버의 설정엔 이상이 없음.
  

  Root# vi /etc/ntp.conf
  

  #restrict default ignore -> 주석처리
  

  #restrict -6 default ignore -> 주석처리
  

  restrict default kod nomodify notrap nopeer noquery -> 주석처리 해제
  

  restrict -6 default kod nomodify notrap nopeer noquery -> 주석처리 해제
  

  Root# service ntpd stop
  

  Root# service ntpd start
  

  PROCEL01~07
  

  Checking NTP server on 192.168.1.10 : FAILED
  

  Checking NTP server on 192.168.1.12 : FAILED
  

CRS_LIMIT_NPROC should be greater than 65535 and not “UNLIMITED”

OS 파라메터
중 CRS_LIMIT_NPROC 값
확인

CRS_LIMIT_NPROC 파라메터의 경우 자원 부족에 따른 노드 Eviction 또는 잠재적 클러스터 크래쉬를 피하기 위해 65535 이상이되 “UNLIMITED”가 아닌 값으로 설정 할것을 권장함

# 확인방법

Grid User로 다음의 쿼리 수행(통상 root 유저)

CONFG_CRS_LIMIT_NPROC=$(grep -w CRS_LIMIT_NPROC $CRS_HOME/crs/install/s_crsconfig_hostname -s_env.txt|grep -v ^#|cut -d= -f2);

if [[ echo $CONFG_CRS_LIMIT_NPROC | tr -s '[:upper:]' '[:lower:]' != “unlimited” && $CONFG_CRS_LIMIT_NPROC -ge 65535 ]]

then

echo “SUCCESS: CRS_LIMIT_NPROC is set to a value greater than or equal to 65535, but not \”UNLIMITED\”: $CONFG_CRS_LIMIT_NPROC”;

else

echo “FAILURE: CRS_LIMIT_NPROC is not set as recommended: $CONFG_CRS_LIMIT_NPROC”;

fi;

# 설정방법

각 db노드의 다음 파일을 열어 CRS_LIMIT_NPROC 값을 65536으로 수정 할 것

GRID_HOME/crs/install/s_crsconfig_hostname -s_env.txt

=================================================================

수행결과샘플: 다음과 같이 양 노드의 CRS_LIMIT_NPROC 값이 16384로 권장 설정과 다름이 확인됨

상기의 절차에 따라 권장값으로 변경이 필요함

Status on PROD01:

FAIL => CRS_LIMIT_NPROC should be greater than 65535 and not “UNLIMITED”

DATA FROM PROD01 – VERIFY THAT CRS_LIMIT_NPROC IS GREATER THAN 65535 AND NOT “UNLIMITED”

TZ=ROK

NLS_LANG=AMERICAN_AMERICA.AL32UTF8

CRS_LIMIT_STACK=2048

CRS_LIMIT_OPENFILE=65536

CRS_LIMIT_NPROC=16384

TNS_ADMIN=

Status on PROD02:

FAIL => CRS_LIMIT_NPROC should be greater than 65535 and not “UNLIMITED”

DATA FROM PROD02 – VERIFY THAT CRS_LIMIT_NPROC IS GREATER THAN 65535 AND NOT “UNLIMITED”

TZ=ROK

NLS_LANG=AMERICAN_AMERICA.AL32UTF8

CRS_LIMIT_STACK=2048

CRS_LIMIT_OPENFILE=65536

CRS_LIMIT_NPROC=16384

TNS_ADMIN=

CSS misscount should be set to the recommended value of 60

CSS 설정값 확인

CSS misscount 값이 권장값인 60으로 설정되어 있는지 확인함. 11gR2의 디폴트 설정은 30초이나 Exadata의 경우 Best Practice에 따라 보수적으로 60으로 설정을 권장함. 다만, Mission Critical 시스템의 경우 단절 시간을 최소화 하기 위해 30으로 설정하는 것도 가능함

# CSS misscount 값 확인 – root로 수행

<GI_HOME>/bin/crsctl get css miscount

# CSS misscount 값 설정 – root로 수행

<GI_HOME>/bin/crsctl set css misscount 60

=================================================================

수행결과샘플: 현재 css misscount 값은 11gR2 디폴트 값이 30초로 설정되어 있음. 아래 명령어를 수행하여 Exadata 권장값인 60초로 변경을 권장함

Status on PROD01:

DATA FROM PROD01 – VERIFY CLUSTER SYNCHRONIZATION SERVICES (CSS) MISSCOUNT = 60

CRS-4678: Successful get misscount 30 for Cluster Synchronization Services.

The CRS_HOME should be properly locked.

CRS Home의 lock 상태
확인

패치 적용후 CRS HOME의 lock이 적절히 수행되어 있는지 확인함

#설정확인

export CRS_HOME=$(awk -F: ‘/^+ASM[0-9].*/{printf “%s\n”, $2}’ /etc/oratab)

CRS_CHECK=$(stat -c %U $CRS_HOME);

if [[ $CRS_CHECK == “root” ]];

then echo -e “SUCCESS:CRS Home is locked.”;

else echo -e “WARN:CRS Home is NOT locked.”

fi;

정상인 경우

SUCCESS:CRS Home is locked.

=================================================================

수행결과샘플: 1번 노드의 경우 GRID HOME이 lock이 안되어 있음. PM시 lock수행 필요. SR을 통해 조치 사항 확인할 것

Status on PRODdb01:

WARNING => The CRS_HOME should be properly locked.

DATA FROM PRODDB01 – VERIFY THE CRS_HOME IS PROPERLY LOCKED

WARN:CRS Home (/u01/app/12.1.0.2/grid) is NOT locked.

Hidden database initialization parameters should be set per best practice recommendations

Hidden parameter 설정 확인

기본 설정 이외에 추가로 설정한 Hidden parameter 내역을 나타내며 Exadata의 경우 best practice에 따라 별도로 권고 받지 않은 hidden parameter 설정은 권장하지 않음

일반적으로 히든 파라메터는 특정 문제 해결을 위한 조치사항으로 설정이 되며 해당 문제의 Fix가 포함된 버전으로 업그레이드 되는 경우 제거 되어야 함을 원칙으로 함

# Hidden Parameter 확인

SQL> select name,value from gv$parameter where substr(name,1,1)=’_’;

=================================================================

수행결과샘플: 고객사 환경에 따라 추가적으로 설정 파라메터들이 확인 되었으며 특이사항은 없음

Status on PROD01:

_optimizer_use_feedback is Not Expected or has an incorrect Value

_optimizer_extended_cursor_sharing_rel is Not Expected or has an incorrect Value

_optimizer_extended_cursor_sharing is Not Expected or has an incorrect Value

_optimizer_adaptive_cursor_sharing is Not Expected or has an incorrect Value

_optim_peek_user_binds is Not Expected or has an incorrect Value

_gc_read_mostly_locking is Not Expected or has an incorrect Value

Status on PROD02:

_optimizer_use_feedback is Not Expected or has an incorrect Value

_optimizer_extended_cursor_sharing_rel is Not Expected or has an incorrect Value

_optimizer_extended_cursor_sharing is Not Expected or has an incorrect Value

_optimizer_adaptive_cursor_sharing is Not Expected or has an incorrect Value

_optim_peek_user_binds is Not Expected or has an incorrect Value

_gc_read_mostly_locking is Not Expected or has an incorrect Value

One or more database servers have stateful alerts that have not been cleared

DB서버의 alert history 확인

Image 12.1.2.1.0 부터 DB서버에도 Cell서버에서 사용되었던 Management Server 데몬이 추가됨

MS에 의해 하드웨어 및 소프트웨어에 대한 모니터링이 가능해졌고 이러한 모니터링 결과에 따라 주의가 필요한 사항은 alert이 생성됨

Alert메세지 중 해결 되지 않은 이슈가 있는지 확인함

# 확인방법

root# dbmcli

SQL> list alerthistory

=================================================================

수행결과샘플: PROD02 서버의 root(/) 파일시스템 전체 30G중 23G를 사용중이며 임계치 80%를 초과함. 불필요한 파일을 삭제하여 임계치 75% 미만으로 삭제시 경고 메시지는 자동 클리어됨

Status on PROD01:

PASS => No database server has stateful alerts that have not been cleared

DATA FROM PROD01 FOR CHECK ALERTHISTORY FOR STATEFUL ALERTS NOT CLEARED [DATABASE SERVER]

Seq ID     Severity

Status on PROD02:

FAIL => One or more database servers have stateful alerts that have not been cleared

DATA FROM PROD02 FOR CHECK ALERTHISTORY FOR STATEFUL ALERTS NOT CLEARED [DATABASE SERVER]

Seq ID     Severity

13_1     “After initial accelerated space reclamation, file system “/” is 83% full, which is equal to or above the 80% threshold. Accelerated space reclamation will continue. This alert will be cleared when file system “/” becomes less than 75% full. Top three directories ordered by total space usage are as follows: /home : 7.85G /opt : 7.02G /nbu : 2.87G”

The InfiniBand Address Resolution Protocol (ARP) Configuration on Database Servers should be as recommended

DB서버의 ARP설정이
적절한지
확인

Real Application Clusters(RAC)가 정상 작동하기 위해서는 정확한 ARP 설정이 필요함. ARP 설정이 다음과 같은지 확인함

Active-passive 모드의 경우 권장값은 다음과 같음

net.ipv4.conf.ib0.accept_local = 1

net.ipv4.conf.ib1.accept_local = 1

net.ipv4.conf.bondib0.accept_local = 1

net.ipv4.conf.ib0.rp_filter = 0

net.ipv4.conf.ib1.rp_filter = 0

net.ipv4.conf.bondib0.rp_filter = 0

Active-active 모드의 경우 권장값은 다음과 같음

net.ipv4.conf.ib0.accept_local = 1

net.ipv4.conf.ib1.accept_local = 1

net.ipv4.conf.ib0.rp_filter = 0

net.ipv4.conf.ib1.rp_filter = 0

net.ipv4.conf.all.rp_filter = 0

net.ipv4.conf.default.rp_filter = 0

net.ipv4.conf.all.accept_local = 1

# 설정확인

Root#

RAW_OUTPUT=$(sysctl -a)

RF_OUTPUT=$(echo “$RAW_OUTPUT” | egrep -i “\.ib|bondib” | egrep -i “\.rp_filter”)

AL_OUTPUT=$(echo “$RAW_OUTPUT” | egrep -i “\.ib|bondib” | egrep -i “\.accept_local”)

if [ echo "$RAW_OUTPUT" | grep -i bondib | wc -l -ge 1 ]

then #active/passive case

if [[ echo "$AL_OUTPUT" | cut -d" " -f3 | sort -u | wc -l -eq 1 && echo "$AL_OUTPUT" | cut -d" " -f3 | sort -u | head -1 -eq 1 ]]

then

AL_RSLT=0 #all AL same value and value is 1

else

AL_RSLT=1

fi;

if [[ echo "$RF_OUTPUT" | cut -d" " -f3 | sort -u | wc -l -eq 1 && echo "$RF_OUTPUT" | cut -d" " -f3 | sort -u | head -1 -eq 0 ]]

then

RF_RSLT=0 #all RF same value and value is 0

else

RF_RSLT=1

fi;

if [[ $AL_RSLT -eq 0 && $RF_RSLT -eq 0 ]]

then

echo -e “Success: The active/passive ARP configuration is as recommended:\n”

else

echo -e “Failure: The active/passive ARP configuration is not as recommended:\n”

fi;

echo -e “$AL_OUTPUT\n\n$RF_OUTPUT”

else #active/active case

NICARF_OUTPUT=$(echo “$RAW_OUTPUT” | egrep -i “net.ipv4.conf.all.rp_filter”)

NICDRF_OUTPUT=$(echo “$RAW_OUTPUT” | egrep -i “net.ipv4.conf.default.rp_filter”)

NICAAL_OUTPUT=$(echo “$RAW_OUTPUT” | egrep -i “net.ipv4.conf.all.accept_local”)

NICARF_RSLT=$(echo “$NICARF_OUTPUT” | cut -d” ” -f3)

NICDRF_RSLT=$(echo “$NICDRF_OUTPUT” | cut -d” ” -f3)

NICAAL_RSLT=$(echo “$NICAAL_OUTPUT” | cut -d” ” -f3)

IB_INTRFCE_CNT=$(echo “$RAW_OUTPUT” | egrep “\.ib.\.” | cut -d”.” -f4 | sort -u | wc -l)

if [[ echo "$AL_OUTPUT" | cut -d" " -f3 | sort -u | wc -l -eq 1 && echo "$AL_OUTPUT" | cut -d" " -f3 | sort -u | head -1 -eq 1 ]]

then

AL_RSLT=0 #all AL same value and value is 1

else

AL_RSLT=1

fi;

if [[ echo "$RF_OUTPUT" | cut -d" " -f3 | sort -u | wc -l -eq 1 && echo "$RF_OUTPUT" | cut -d" " -f3 | sort -u | head -1 -eq 0 ]]

then

RF_RSLT=0 #all RF same value and value is 0

else

RF_RSLT=1

fi;

if [ $IB_INTRFCE_CNT -eq 2 ] # 2 socket case

then

if [[ $AL_RSLT -eq 0 && $RF_RSLT -eq 0 && $NICARF_RSLT -eq 0 && $NICDRF_RSLT -eq 0 && $NICAAL_RSLT -eq 1 ]]

then

echo -e “Success: The active/active ARP configuration is as recommended:\n”

else

echo -e “Failure: The active/active ARP configuration is not as recommended:\n”

fi;

echo -e “$AL_OUTPUT\n\n$RF_OUTPUT\n\n$NICARF_OUTPUT\n$NICDRF_OUTPUT\n$NICAAL_OUTPUT”

else # 8 socket case

NICIAA_OUTPUT=$(echo “$RAW_OUTPUT” | egrep “\.ib.\.” | egrep arp_announce)

if [[ echo "$NICIAA_OUTPUT" | cut -d" " -f3 | sort -u | wc -l -eq 1 && echo "$NICIAA_OUTPUT" | cut -d" " -f3 | sort -u | head -1 -eq 2 ]]

then

NICIAA_RSLT=0 #all arp_announce same value and value is 2

else

NICIAA_RSLT=1

fi;

if [[ $AL_RSLT -eq 0 && $RF_RSLT -eq 0 && $NICIAA_RSLT -eq 0 && $NICARF_RSLT -eq 0 && $NICDRF_RSLT -eq 0 && $NICAAL_RSLT -eq 1 ]]

then

echo -e “Success: The active/active ARP configuration is as recommended:\n”

else

echo -e “Failure: The active/active ARP configuration is not as recommended:\n”

fi;

echo -e “$AL_OUTPUT\n\n$RF_OUTPUT\n\n$NICIAA_OUTPUT\n\n$NICARF_OUTPUT\n$NICDRF_OUTPUT\n$NICAAL_OUTPUT”

fi;

fi;

# 설정변경

Root# /etc/sysctl.conf 파일을 열어 다음과 같이 변경

• Active-passive 모드의 경우 권장값은 다음과 같음
  

  net.ipv4.conf.ib0.accept_local = 1
  

  net.ipv4.conf.ib1.accept_local = 1
  

  net.ipv4.conf.bondib0.accept_local = 1
  

  net.ipv4.conf.ib0.rp_filter = 0
  

  net.ipv4.conf.ib1.rp_filter = 0
  

  net.ipv4.conf.bondib0.rp_filter = 0
  

  Root# sysctl -p
  

  =================================================================
  

  수행결과샘플: 확인 결과 다음과 같이 권장사항과 불일치함. 권장 사항에 맞게 변경 필요
  

  Status on proddb01:
  

  FAIL => The InfiniBand Address Resolution Protocol (ARP) Configuration on Database Servers should be as recommended
  

  DATA FROM PRODDB01 FOR VERIFY INFINIBAND ADDRESS RESOLUTION PROTOCOL (ARP) CONFIGURATION ON DATABASE SERVERS
  

  net.ipv4.conf.ib0.accept_local = 0
  

  net.ipv4.conf.ib1.accept_local = 0
  

  net.ipv4.conf.bondib0.accept_local = 0
  

  net.ipv4.conf.ib0.rp_filter = 1
  

  net.ipv4.conf.ib1.rp_filter = 1
  

  net.ipv4.conf.bondib0.rp_filter = 1
  

Oracle Enterprise Linux 5 rpms are installed on Oracle Enterprise Linux 6

OS에
설치된 RPM 확인

OS의 Kernel 버전에 맞는 RPM이 설치 되어 있는지 확인함

#설정확인

Root#

EL5_OUTPUT=$(rpm -aq | grep “\.el5”)

if [ -z “$EL5_OUTPUT” ]

then

echo -e “SUCCESS: No Oracle Enterprise Linux 5 (el5) rpms were found.\nel5 list:\n\n$EL5_OUTPUT”

else

echo -e “FAILURE: Oracle Enterprise Linux 5 (el5) rpms were found.\nel5 list:\n\n$EL5_OUTPUT”

fi

=================================================================

수행결과샘플:
다음과 같이 현재 Oracle Linux 6 버전용이 아닌 OL5용 RPM들이 설치되어 있음. 하기의 목록 확인후 EL6용으로 설치 필요

Status on proddb01:

FAIL => Oracle Enterprise Linux 5 rpms are installed on Oracle Enterprise Linux 6

DATA FROM PRODDB01 – VERIFY NO ORACLE ENTERPRISE LINUX 5 RPMS EXIST ON DATABASE SERVERS RUNNING ORACLE LINUX 6

libgfortran-4.1.2-52.el5_8.1.x86_64

openmpi-libs-1.4-4.el5.x86_64

Status on proddb02:

FAIL => Oracle Enterprise Linux 5 rpms are installed on Oracle Enterprise Linux 6

DATA FROM PRODDB02 – VERIFY NO ORACLE ENTERPRISE LINUX 5 RPMS EXIST ON DATABASE SERVERS RUNNING ORACLE LINUX 6

openmpi-libs-1.4-4.el5.x86_64

unix2dos-2.2-26.2.3.el5.x86_64

The database server file systems should have “Check interval” = “0”

filesystem check(fsck) 체크 주기 설정 확인

Check interval 내에 fsck를 수행하지 않을 경우 향후 재 부팅시 fsck가 자동으로 실행 된다. PM, 패치, 확장 등의 시간이 한정되어 있는 작업시 부팅시간이 길어 지는 문제가 생길 수 있어 Check interval=0을 권장함

# Check interval 확인

tune2fs -l [Device Path] | grep “Check interval:”|awk ‘{print $3}’

예)

tune2fs -l /dev/sda1 | grep “Check interval:”|awk ‘{print $3}’

tune2fs -l /dev/VGExaDb/LVDbSys1 | grep “Check interval:”|awk ‘{print $3}’

tune2fs -l /dev/VGExaDb/LVDbSys2 | grep “Check interval:”|awk ‘{print $3}’

tune2fs -l /dev/VGExaDb/LVDbOra1 | grep “Check interval:”|awk ‘{print $3}’

# Check interval 변경

tune2fs –i 0 [Device Path]

예)

tune2fs –i 0 /dev/sda1

tune2fs –i 0 /dev/VGExaDb/LVDbSys1

tune2fs –i 0 /dev/VGExaDb/LVDbSys2

tune2fs –i 0 /dev/VGExaDb/LVDbOra1

=================================================================

수행결과샘플:
초기 설치 이후에 추가된
/dev/VGExaDb/Lvetc, /dev/VGExaDb/Lvbackup 볼륨의 경우 권장 설정과 다르게 설정되어 있음. 상기의 권장 설정 값으로 변경 필요

Status on proddb01:

FAIL => The database server file systems should have “Check interval” = “0”

DATA FROM PRODDB01 FOR VERIFY DATABASE SERVER FILE SYSTEMS HAVE CHECK INTERVAL = 0

/dev/VGExaDb/LVDbSys1: 0

/dev/VGExaDb/LVDbSys2: 0

/dev/VGExaDb/LVDbOra1: 0

/dev/VGExaDb/Lvetc: 15552000

/dev/VGExaDb/Lvbackup: 15552000

Status on proddb02:

FAIL => The database server file systems should have “Check interval” = “0”

DATA FROM PRODDB02 FOR VERIFY DATABASE SERVER FILE SYSTEMS HAVE CHECK INTERVAL = 0

/dev/VGExaDb/LVDbSys1: 0

/dev/VGExaDb/LVDbSys2: 0

/dev/VGExaDb/LVDbOra1: 0

/dev/VGExaDb/Lvetc: 15552000

The database server file systems should have “Maximum mount count” = “-1”

Filesystem의 maximum mount count 설정 확인

reboot이나 기타 작업에 의해 filesystem의 mount가 발생하여 그 횟수가 maximum mount count를 초과할 경우 자동으로 filesystem check(fsck)가 수행이 되는데 PM, 패치, 확장 등의 시간이 한정되어 있는 작업시 부팅시간이 길어 지는 문제가 생길 수 있어 fsck를 수행하지 않도록 -1로 설정할 것을 권장함

# Maximum mount count 확인

tune2fs -l [Device Path] | grep “Maximum mount count:”|awk ‘{print $4}’

예)

tune2fs -l /dev/sda1 | grep “Maximum mount count:”|awk ‘{print $4}’

tune2fs -l /dev/VGExaDb/LVDbSys1 | grep “Maximum mount count:”|awk ‘{print $4}’

tune2fs -l /dev/VGExaDb/LVDbSys2 | grep “Maximum mount count:”|awk ‘{print $4}’

tune2fs -l /dev/VGExaDb/LVDbOra1 | grep “Maximum mount count:”|awk ‘{print $4}’

# Check interval 변경

tune2fs –c -1 [Device Path]

예)

tune2fs –c -1 /dev/sda1

tune2fs –c -1 /dev/VGExaDb/LVDbSys1

tune2fs –c -1 /dev/VGExaDb/LVDbSys2

tune2fs –c -1 /dev/VGExaDb/LVDbOra1

=================================================================

수행결과샘플:
초기 설치 이후에 추가된
/dev/VGExaDb/Lvetc, /dev/VGExaDb/Lvbackup 볼륨의 경우 권장 설정과 다르게 설정되어 있음. 상기의 권장 설정 값으로 변경 필요

Status on proddb01:

FAIL => The database server file systems should have “Maximum mount count” = “-1”

DATA FROM PRODDB01 FOR VERIFY DATABASE SERVER FILE SYSTEMS HAVE MAXIMUM MOUNT COUNT = -1

/dev/VGExaDb/LVDbSys1: -1

/dev/VGExaDb/LVDbSys2: -1

/dev/VGExaDb/LVDbOra1: -1

/dev/VGExaDb/Lvetc: 20

/dev/VGExaDb/Lvbackup: 25

Status on proddb02:

FAIL => The database server file systems should have “Maximum mount count” = “-1”

DATA FROM PRODDB02 FOR VERIFY DATABASE SERVER FILE SYSTEMS HAVE MAXIMUM MOUNT COUNT = -1

/dev/VGExaDb/LVDbSys1: -1

/dev/VGExaDb/LVDbSys2: -1

/dev/VGExaDb/LVDbOra1: -1

/dev/VGExaDb/Lvetc: 38

Database parameter _enable_NUMA_support should be set to recommended value

DB 파라메터 중 _enable_NUMA_support 설정 확인

NUMA 기술은 Memory Intensive 워크로드의 경우 성능을 향상 시켜주는 기술로 권장 설정은 다음과 같음

• X4이하의 2 Socket 서버: (default) FALSE
  
• 2 또는 8 Socket 서버로 DB 12.1.0.2.6 이상인 경우: (default) FALSE
  
• 8 Socket 서버로 DB 12.1.0.2.6 미만 경우: TRUE
  
• X5-2 서버로 DB 12.1.0.2.5 이하인 경우: TRUE
  
• OVM 구성인 경우: (default) FALSE
  

# configuration 점검

SQL> show parameter _enable_NUMA_support

=================================================================

수행결과샘플: 수행결과샘플 해당 값은 권고 값인 false로 설정 되어 있음

Status on PROD01:

_enable_NUMA_support = FALSE

Status on PROD02:

_enable_NUMA_support = FALSE

Database parameter db_recovery_file_dest_size is NOT set to recommended value

DB 파라메터 db_recovery_file_dest_size 설정
확인

Db_recovery_file_dest_size 영역은 최대 RECO diskgroup의 90%를 할당하는 것이 권장 사항임

# 설정확인

SQL> show parameter db_recovery_file_dest_size;

# 설정변경

SQL> alter system set db_recovery_file_dest_size=<size> scope=both sid=’*’;

=================================================================

수행결과샘플: 확인 결과 PROD DB의 recovery area 크기는 3994GB로 RECO 영역의 90%에 해당하는 3983GB를 초과함. 권장 설정에 따라 3983GB로 변경이 필요함

DATA FROM PRODDB01 – PROD DATABASE – DB_RECOVERY_FILE_DEST_SIZE

90% of RECO_PROD Total Space =              3983GB

db_recovery_file_dest_size=              3994GB

Operating system hugepages count does not satisfy total SGA requirements

운영체제의 HugePage 설정
확인

Hugepage는 best practice에 따른 설정 권장 사항으로 메모리의 효율을 높이고 성능 향상을 가져올 수 있도록 설정하는 2MB 단위의 page를 말함. SGA 사이즈에 맞게끔 설정을 해야 하며 SGA사이즈 변경시 hugepage 사이즈도 함께 변경이 필요함

#설정확인

Root# TOTAL_HUGEPAGES=grep HugePages_Total /proc/meminfo | cut -d":" -f 2 | sed -e 's/^[ \t]*//;s/[ \t]*$//';

HPG_SZ=grep Hugepagesize /proc/meminfo | awk '{print $2}';

NUM_PG=0;

for SEG_BYTES in ipcs -m | cut -c44-60 | awk '{print $1}' | grep "[0-9][0-9]*"

do

MIN_PG=echo "$SEG_BYTES/($HPG_SZ*1024)" | bc -q;

if [ $MIN_PG -gt 0 ]; then

NUM_PG=echo "$NUM_PG+$MIN_PG+1" | bc -q;

fi;

done;

if [ $TOTAL_HUGEPAGES -ge $NUM_PG ]

then echo -e “\nSUCCESS: Total current hugepages ($TOTAL_HUGEPAGES) are greater than or equal to”;

echo -e ” estimated requirements for all currently active SGAs ($NUM_PG).\n”;

else echo -e “\nFAILURE: Total current hugepages ($TOTAL_HUGEPAGES) should be greater than or equal to”;

echo -e ” estimated requirements for all currently active SGAs ($NUM_PG).\n”;

fi;

#설정변경(각 DB서버 별로 수행)

root## grep “hugepage” /etc/sysctl.conf

vm.nr_hugepages = 10000

root# /etc/sysctl.conf 파일의 vm.nr_hugepages 값을 수정

root# sysctl -p

root# grep Huge /proc/meminfo

=================================================================

수행결과샘플: 현재 모든 1번 노드와 나머지 노드의 hugepage값이 상이함. 1번 노드의 값으로 통일 할 것

Status on PRODdb01:

PASS => Operating system hugepages count satisfies total SGA requirements

DATA FROM PRODDB01 – VERIFY OPERATING SYSTEM HUGEPAGES COUNT SATISFIES TOTAL SGA REQUIREMENTS

Total current hugepages (68326) are greater than or equal to estimated requirements for all currently active SGAs (68296)

Status on PRODdb02:

FAIL => Operating system hugepages count does not satisfy total SGA requirements

DATA FROM PRODDB02 – VERIFY OPERATING SYSTEM HUGEPAGES COUNT SATISFIES TOTAL SGA REQUIREMENTS

Total current hugepages (65000) should be greater than or equal to estimated requirements for all currently active SGAs (69007 )

Number of SCAN listeners is NOT equal to the recommended number of 3

SCAN listener 구성 확인

SCAN listener는 3개를 사용할 것을 권장하나 DNS를 구성하여 SCAN listener를 실제로 사용하는 경우가 아닌 경우 설치용으로 하나만 구성 가능함

=================================================================

수행결과샘플: scan_listener를 사용하지 않으므로 무시할 것

Status on PROD01:

DATA FROM PROD01 – NUMBER OF SCAN LISTNERS

SCAN Listener LISTENER_SCAN1 exists. Port: TCP:1521

System model number is not correct

시스템 모델 확인

Exadata 시스템 모델 넘버를 확인함

# Model number 확인

Root# ipmitool sunoem cli

• show /SP system_description
  

  =================================================================
  

  수행결과샘플: Exachk수행 결과 PROD01의 경우 모델넘버가 확인 안 되는 것으로 나타났으나 실제 커맨드 수행 결과 정상으로 확인됨
  

  Status on PROD01:
  

  Connected. Use ^D to exit.
  

  -> show /SP system_description
  

  /SP
  

  Properties:
  

  system_description = ORACLE SERVER X5-2, ILOM v3.2.4.52, r10111
  

  -> Session closed
  

  Disconnected
  

  Total Memory on pcpos01 = 257967
  

  Status on PROD02:
  

  Connected. Use ^D to exit.
  

  -> show /SP system_description
  

  /SP
  

  Properties:
  

  system_description = ORACLE SERVER X5-2, ILOM v3.2.4.52, r10111
  

  -> Session closed
  

  Disconnected
  

  Total Memory on pcpos01 = 257967
  

Downdelay attribute is not set to recommended value on bonded client interface

DB서버
네트웍
인터페이스
설정을
확인함

서비스 네트웍 인터페이스의 downdelay 값을 디폴트로 사용시 단일 인터페이스 장애 타이밍에 따라 VIP Failover 또는 단절이 생길 수 있음. 이러한 가능성을 피하기 위해 Active-backup 모드의 경우 값을 2000으로 설정할 것을 권장함. LACP 모드의 경우 200으로 설정 필요

권장 설정과 일치하는지 확인함

# 설정확인

#!/bin/bash

############################################################################## #

# Purpose: Check downdelay is set appropriately for the bonded interfaces #

# #

#############################################################################

## Variable declarations

exit_code=0

## Function Definitions

usage()

{

echo “Usage: check_downdelay.sh [-o check|report] [-h]”;

}

check_downdelay()

{

downDelayActiveBackup=2000

downDelayLACP=200

while read bonintf

do

bondingType=$(grep “^Bonding Mode:” $bonintf|awk -F “:” ‘{print $2}’)

downdelaySet=$(grep “^Down Delay (ms):” $bonintf|awk ‘{print $4}’)

if [ “${bondingType}” == ” fault-tolerance (active-backup)” ]

then

if [ $downdelaySet -ne $downDelayActiveBackup ]

then

exit_code=1

downdelayFailMsgTmp=”Down delay not set to 2000 for the active-backup bonded interface $(echo $bonintf|awk -F”/” ‘{print $NF}’)”

downdelayFailMsg=$(printf “$downdelayFailMsgTmp\n$downdelayFailMsg”)

fi

elif [ “${bondingType}” == ” IEEE 802.3ad Dynamic link aggregation” ]

then

if [ $downdelaySet -ne $downDelayLACP ]

then

exit_code=1

downdelayFailMsgTmp=”Down delay not set to 200 for the LACP bonded interface $(echo $bonintf|awk -F”/” ‘{print $NF}’)”

downdelayFailMsg=$(printf “$downdelayFailMsgTmp\n$downdelayFailMsg”)

fi

fi

if [ $exit_code -eq 0 ]

then

downdelayPassMsg=”Down delay correctly set to correct value(s) for all bonded interfaces”

fi

done << EOF

$(ls -1 /proc/net/bonding/bondeth*)

EOF

}

check_main()

{

check_downdelay

}

print_result()

{

echo $exit_code

}

print_report()

{

if [ $exit_code -eq 0 ]

then

printf “\n$downdelayPassMsg\n”

else

printf “\n$downdelayFailMsg, current downdelay value: $downdelaySet\n”

fi

}

NumArgs=$#

if [ $NumArgs -lt 1 ]

then

echo “Invalid or missing command line arguments…”

usage;

exit 1

fi

while getopts “o:h” opt;

do

case “${opt}” in

h) usage;

exit 0

;;

o)

swch=${OPTARG};

;;

*) echo “Invalid or missing command line arguments…”

usage;

exit 1

;;

esac

done

if [ $swch = “check” ]

then

check_main;

print_result;

elif [ $swch == “report” ]

then

check_main;

print_report;

else

echo “Invalid or missing command line arguments…”

usage;

exit 1

fi

정상인 경우

Down delay correctly set to correct value(s) for all bonded interfaces

# 설정변경

다음 파일의 downdelay 값 변경

/etc/sysconfig/network-scripts/ifcfg-<client network interface name>

=================================================================

수행결과샘플: 수행결과 다음과 같이 downdelay값이 권장 설정과 다름. 권장 설정으로 적용 필요

Status on PRODdb01:

FAIL => Downdelay attribute is not set to recommended value on bonded client interface

DATA FROM PRODDB01 – VERIFY “DOWNDELAY=2000” FOR BONDED CLIENT INTERFACES

Down delay not set to 2000 for the active-backup bonded interface bondeth0, current downdelay value: 5000

Status on PRODdb02:

FAIL => Downdelay attribute is not set to recommended value on bonded client interface

DATA FROM PRODDB02 – VERIFY “DOWNDELAY=2000” FOR BONDED CLIENT INTERFACES

Down delay not set to 2000 for the active-backup bonded interface bondeth0, current downdelay value: 5000

One or more Ethernet network cables are not connected

DB서버의 Ethernet 케이블
연결
확인

DB서버의 Ethernet 케이블 연결 상태 정상 여부를 확인함

# 확인방법

Root# for cable in ls /sys/class/net | grep ^eth; do printf “$cable: “; cat /sys/class/net/$cable/carrier; done

=================================================================

수행결과샘플: 다음과 같이 PROD01 노드의 경우 eth5 인터페이스에 케이블이 절체되어 있는 상태임. 임시로 사용하는 경우 무시할 것

Status on PROD02:

PASS => All Ethernet network cables are connected

DATA FROM PROD02 – VERIFY ETHERNET CABLE CONNECTION QUALITY

/sys/class/net/eth0/carrier = 1

/sys/class/net/eth1/carrier = 1

/sys/class/net/eth2/carrier = 1

/sys/class/net/eth3/carrier = cat: /sys/class/net/eth3/carrier: Invalid argument

/sys/class/net/eth4/carrier = cat: /sys/class/net/eth4/carrier: Invalid argument

/sys/class/net/eth5/carrier = 1

Status on PROD01:

FAIL => One or more Ethernet network cables are not connected.

DATA FROM PROD01 – VERIFY ETHERNET CABLE CONNECTION QUALITY

/sys/class/net/eth0/carrier = 1

/sys/class/net/eth1/carrier = 1

/sys/class/net/eth2/carrier = 1

/sys/class/net/eth3/carrier = cat: /sys/class/net/eth3/carrier: Invalid argument

/sys/class/net/eth4/carrier = cat: /sys/class/net/eth4/carrier: Invalid argument

/sys/class/net/eth5/carrier = 0

_reconnect_to_cell_attempts parameter in cellinit.ora is not set to recommended value

Cell구성
정보
파일
확인

최적의 가용성을 위해 X6 스토리지 서버로 접근하는 DB 서버는 다음의 파라메터를 cellinit.ora 파일에 포함되어야 함. 다음의 파라메터가 설정되지 않은 경우 문제시 시스템의 중단 기간이 길어질 수 있음

_reconnect_to_cell_attempts=9

# 설정확인

root# grep “_reconnect_to_cell_attempts” /etc/oracle/cell/network-config/cellinit.ora

_reconnect_to_cell_attempts=9 => 정상

# 설정변경

1. 모든 DB서버의 cellinit.ora 파일에 다음의 라인 추가
   

   Root# vi /etc/oracle/cell/network-config/cellinit.ora
   

   _reconnect_to_cell_attempts=9
   

2. X6 스토리지 서버의 Cell 서버 데몬 재시작(Offline)
   

   Cellcli> alter cell restart services all;
   

   ===============================================================
   

   #수행결과: 수행 결과 모든 DB서버에 상기의 파라메터가 적용되어 있지 않음. 절차에 따라 DB서버에 해당 파라메터를 추가 후 Cell 서비스 데몬 재시작이 필요함
   

   Status on prod01:
   

   FAIL => _reconnect_to_cell_attempts parameter in cellinit.ora is not set to recommended value
   

   DATA FROM PROD – VERIFY “_RECONNECT_TO_CELL_ATTEMPTS=9” ON DATABASE SERVERS WHICH ACCESS X6 STORAGE SERVERS
   

   ipaddress1=192.168.10.1/22
   

   ipaddress2=192.168.10.2/22
   

PGA allocation for all databases is more than total memory available on this system

PGA 메모리 설정을 확인함

PGA_AGGREGATE_TARGET 설정을 시스템의 메모리를 초과하지 않도록 설정했는지 확인함

11g DB의 경우 PGA_AGGREGATE_TARGET x 3 x 인스턴스 수 < 전체 메모리 – Hugepage 메모리

12g DB의 경우 PGA_AGGREGATE_TARGET x 2 x 인스턴스 수 < 전체 메모리 – Hugepage 메모리

=================================================================

수행결과: 실제 PGA를 위해 사용가능한 메모리 63,738MB를 초과하는 122,880MB 설정됨. 상기의 계산 방식을 참고하여 적정값으로 변경이 필요함

Status on prod01:

WARNING => PGA allocation for all databases is more than total memory available on this system

DATA FROM PROD01 – VERIFY DATABASE MEMORY ALLOCATION IS NOT GREATER THAN PHYSICAL MEMORY INSTALLED ON DATABASE NODE

Total memory on prodb01 = 96738 MB

Total memory allocated to hugepages = 33000 MB

Total available memory for PGA allocation = 63738 MB

Memory allocated to all PGAs = 122880 MB

Status on prod02:

WARNING => PGA allocation for all databases is more than total memory available on this system

DATA FROM PROD02 – VERIFY DATABASE MEMORY ALLOCATION IS NOT GREATER THAN PHYSICAL MEMORY INSTALLED ON DATABASE NODE

Total memory on prod02 = 96738 MB

Total memory allocated to hugepages = 33000 MB

Total available memory for PGA allocation = 63738 MB

Memory allocated to all PGAs = 122880 MB

SQL Check

Some data or temp files are not autoextensible

Datafile 또는 tempfile의 autoextend 여부 확인

autoextend 설정이 안되어 있는 Datafile 또는 tempfile이 있는지 확인함

용량 부족에 따른 장애가 발생하지 않도록 autoextend로 설정할 것을 권장함

# non-autoextend로 설정된 테이블 스페이스 확인

SQL> select file_id, file_name, tablespace_name from dba_data_files where autoextensible <>’YES’

union

select file_id, file_name, tablespace_name from dba_temp_files where autoextensible <> ‘YES’;

=================================================================

수행결과샘플: 확인 결과 다음에 PROD DB의 다수의 datafile들이 autoextend 설정이 되어 있지 않음. 용량 부족에 따른 장애 상황이 발생하지 않도록 autoextend로 설정할 것을 권장함

Status on PROD:

FAIL => Some data or temp files are not autoextensible

DATA FOR PROD FOR NON-AUTOEXTENSIBLE DATA AND TEMP FILES

+DATAC1/PROD/DATAFILE/dbfile_dat.278.915299781

+DATAC1/PROD/DATAFILE/dbfile_dat.279.915299783

+DATAC1/PROD/DATAFILE/dbfile_dat.280.915299783

+DATAC1/PROD/DATAFILE/dbfile_dat.281.915299785

…

Application objects were found to be invalid

Application object의 상태 확인

User의 FUNCTION, PROCEDURE, SYNONYM 등 INVALID OBJECT를 확인함

# Invalid object 확인

SQL> dbupgdiag.sql 수행

또는

SQL> select owner, object_name, object_type, status from dba_objects

where status<>’VALID’

and owner not in (‘SYS’,’SYSTEM’);

# recompile 방법

SQL> ALTER [OBJECT TYPE] [OBJEC OWNER].[OBJECT_NAME] COMPILE;

=================================================================

# 수행결과샘플: 하기와 같이 invalid object들이 확인 됨. 대상 확인 후 조치 필요

Status on PROD:

WARNING => Application objects were found to be invalid

OBJ_DMD

OBJ302

SYNONYM

OBJ_DMD

OBJ305

SYNONYM

… (이하 생략) …

• 각 오브젝트 확인 후 컴파일 수행 필요
  

SYS or SYSTEM objects were found to be INVALID

sys 및 system object의 상태 확인

DB의 sys 및 system object의 상태 확인

# Invalid object 확인

SQL> dbupgdiag.sql 수행

또는

SQL> select owner, object_name, object_type, status from dba_objects

where status<>’VALID’

and owner in (‘SYS’,’SYSTEM’);

# recompile 방법

SQL> ALTER [OBJECT TYPE] [OBJEC OWNER].[OBJECT_NAME] COMPILE;

=================================================================

수행결과샘플: 일부 system object들이 invalid인것으로 확인 됨. 각 오브젝트 확인 후 recompile 수행 권장

Status on PROD:

WARNING => SYS or SYSTEM objects were found to be INVALID

DATA FOR PROD FOR INVALID SYS/SYSTEM OBJECTS

PG_VOC_GET_COM PACKAGE BODY

Table AUD$[FGA_LOG$] should use Automatic Segment Space Management

Audit Segment가 ASSM 테이블
스페이스에
존재하는지
확인

AUD$, FGA_LOG$ 테이블의 로그인이 몰릴 경우 성능저하 발생할 수 있어 기본적으로 ASSM 테이블 스페이스인 SYSAUX에 할당됨. 해당 테이블들이 초기 설정과 동일하게 구성 되어 있는지 확인함

# 확인방법

SQL> select t.table_name,ts.segment_space_management from dba_tables t, dba_tablespaces ts where ts.tablespace_name = t.tablespace_name and t.table_name in (‘AUD$’,’FGA_LOG$’);

* 수행결과 다음과 같이 AUTO이면 정상

TABLE_NAME SEGMEN

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

FGA_LOG$ AUTO

AUD$ AUTO

#변경방법

SQL> BEGIN

DBMS_AUDIT_MGMT.set_audit_trail_location(audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_AUD_STD,–this moves table AUD$

audit_trail_location_value => ‘SYSAUX’);

END;

/

SQL> BEGIN

DBMS_AUDIT_MGMT.set_audit_trail_location(audit_trail_type => DBMS_AUDIT_MGMT.AUDIT_TRAIL_FGA_STD,–this moves table FGA_LOG$

audit_trail_location_value => ‘SYSAUX’);

END;

/

===============================================================

# 수행결과샘플: 다음과 같이 다수의 DB에서 해당 테이블들이 ASSM이 아닌 테이블스페이스에 존재함

위의 변경 명령어를 통해 SYSAUX 테이블스페이스로 이동 할 것을 권장함. 다만 audit이 필요하지 않은 DB의 경우 설정은 꺼둘 것

Status on prod:

FAIL => Table AUD$[FGA_LOG$] should use Automatic Segment Space Management for PROD

AUD$ MANUAL

FGA_LOG$ MANUAL

SQL Parameter Check

ASM parameter ASM_POWER_LIMIT is not set to the default value.

ASM Power Limit을 확인함

ASM Operation시의 성능을 나타내는 파라메터로 안정적인 운영 및 성능을 모두 만족하는 권장 설정은 4에 해당함

#설정확인

Oracle$ . oraenv

+ASM1

Oracle$

for record in asm_power_limit,4 audit_syslog_level,local0.info audit_sys_operations,true

do

parameter_name=echo $record | awk -F, '{print $1}'

pass_value=echo $record | awk -F, '{print $2}'

current_value=sqlplus -S "/ as sysasm" << eof


set head off

select lower(value) from v\\$parameter where name='$parameter_name';

exit

eof

current_value=echo $current_value | tr -d '\r'

if [ $current_value == $pass_value ]

then

ret_val=0

echo -e “SUCCESS: $parameter_name current value $current_value matches best practice value $pass_value”

else

echo -e “FAILURE: $parameter_name current value $current_value does not match best practice value $pass_value”

ret_val=1

fi

done

# 설정변경

ASM@SQL> alter system set ASM_POWER_LIMIT=4 sid=’*’;

=================================================================

수행결과샘플: 확인 결과 1로 지정됨. 상기의 절차에 따라 권장 설정으로 변경이 필요함

Status on +ASM1:

WARNING => ASM parameter ASM_POWER_LIMIT is not set to the default value.

+ASM1.asm_power_limit = 1

Status on +ASM2:

WARNING => ASM parameter ASM_POWER_LIMIT is not set to the default value.

+ASM2.asm_power_limit = 1

ASM parameter AUDIT_SYS_OPERATIONS should be set to the recommended value

ASM Parameter 중 AUDIT_SYS_OPERATIONS 설정 확인

해당 파라메터는 보안 최적화로 SYSASM으로 접속한 유저에 의해 실행된 최상위 작업들은 로깅 여부를 지정하는 파라메터임

# configuration 점검(ASM 인스턴스로 접속 후 수행)

Oracle#. oraenv

+ASM1

Oracle# sqlplus / as sysasm

SQL> show parameter AUDIT_SYS_OPERATIONS

# 설정 방법(ASM 인스턴스로 접속 후 수행)

SQL> ALTER SYSTEM SET AUDIT_SYS_OPERATIONS=TRUE SCOPE=BOTH SID=’*’;

=================================================================

수행결과샘플: 확인 결과 다음과 같이 false로 설정 되어 있음. 고객사 정책에 따라 필요시 설정 할 것

Status on +ASM1:

audit_sys_operations = FALSE

Status on +ASM2:

audit_sys_operations = FALSE

Database parameter AUDIT_SYS_OPERATIONS should be set to the recommended value

보안 최적화 설정을 확인함

AUDIT_SYS_OPERATIONS 파라메터는 보안측면에서 DB의 SYSDBA 및 SYSOPER 권한으로 수행되는 작업에 대한 로깅을 설정하는 파라메터로 추적을 위해 TRUE로 설정하는 것을 권장함

# 확인방법

SQL> show parameter AUDIT_SYS_OPERATIONS;

#변경 방법

SQL> alter system set AUDIT_SYS_OPERATIONS=’TRUE’ scope=spfile sid=’*’;

• DB 재기동 필요
  

  =================================================================
  

  수행결과샘플: 확인 결과 일부 DB의 경우 FALSE로 지정되어 있음. 권장 설정에 맞게 TRUE로 변경을 권고함
  

  Status on PROD:
  

  WARNING => Database parameter AUDIT_SYS_OPERATIONS should be set to the recommended value
  

  PROD01.audit_sys_operations = FALSE
  

Database parameter AUDIT_TRAIL should be set to the recommended value

DB파라메터 AUDIT_TRAIL 설정을 확인함

AUDIT_TRAIL 파라메터는 db의 audit 레코드를 기록할 지 여부를 결정함.

Exadata BP에 의한 권장 설정은 db에 해당함. db로 설정시 audit 기록을 DB의 AUD$ 테이블이 기록함. 단 audit를 사용하지 않을 경우 NONE으로 설정 가능

# 설정확인

SQL> show parameter audit_trail;

# 설정변경

SQL> alter system set global_names=DB scope=both sid=’*’;

=================================================================

수행결과샘플: 확인 결과 PRODD DB의 해당 파라메터가 NONE으로 지정됨. Audit 기능이 필요한 경우 상기의 절차에 따라 BP 설정으로 변경할 것을 권장함.

PASS => Database parameter AUDIT_TRAIL is set to the recommended value

PROD1.audit_trail = DB

PROD2.audit_trail = DB

PROD3.audit_trail = DB

PROD4.audit_trail = DB

WARNING => Database parameter AUDIT_TRAIL should be set to the recommended value

PRODD1.audit_trail = NONE

PRODD2.audit_trail = NONE

PRODD3.audit_trail = NONE

PRODD4.audit_trail = NONE

Database parameter OS_AUTHENT_PREFIX is NOT set to recommended value

DB파라메터 OS_AUTHENT_PREFIX 설정을 확인함

Exadata는 BP에 보안 최적화를 위해 OS_AUTHENT_PREFIX 파라메터를 ”(NULL)로 설정하는 것을 권장함

#설정확인

SQL> show parameter os_authent_prefix;

#설정변경

SQL> alter system set os_authent_prefix=” scope=spfile sid=’*’;

적용후 DB 재기동 필요

=================================================================

수행결과샘플: 확인 결과 PRODD DB의 해당 파라메터가 $ops로 지정됨. 상기의 절차에 따라 BP 설정으로 변경할 것을 권장함

FAIL => Database parameter OS_AUTHENT_PREFIX is NOT set to recommended value

PRODD1.os_authent_prefix = ops$

PRODD2.os_authent_prefix = ops$

PRODD3.os_authent_prefix = ops$

PRODD4.os_authent_prefix = ops$

PASS => Database parameter OS_AUTHENT_PREFIX is set to recommended value

PROD1.os_authent_prefix =

PROD2.os_authent_prefix =

PROD3.os_authent_prefix =

PROD4.os_authent_prefix =

Database parameter PARALLEL_ADAPTIVE_MULTI_USER is not set to recommended value

PARALLEL_ADAPTIVE_MULTI_USER 파라메터 설정을 확인함

PARALLEL_ADAPTIVE_MULTI_USER 파라메터는 Parallel execution시 multi user환경에서 성능 향상을 위한 알고리즘이 사용되나 Exadata의 경우 권장 사항은 false 임

#설정확인

SQL> show parameter PARALLEL_ADAPTIVE_MULTI_USER

#설정변경

SQL> alter system set PARALLEL_ADAPTIVE_MULTI_USER=false scope=spfile sid=’*’;

적용 후 DB 재기동 필요

=================================================================

수행결과샘플: 확인 결과 해당 파라메터가 true로 지정됨. 상기의 절차에 따라 권장 설정으로 변경이 필요함

Status on PROD1:

FAIL => Database parameter PARALLEL_ADAPTIVE_MULTI_USER is not set to recommended value

PROD1.parallel_adaptive_multi_user = TRUE

Status on PRODD1:

FAIL => Database parameter PARALLEL_ADAPTIVE_MULTI_USER is not set to recommended value

PRODD1.parallel_adaptive_multi_user = TRUE

Database parameter PARALLEL_THREADS_PER_CPU is not set to recommended value

PARALLEL_THREADS_PER_CPU 파라메터 설정을 확인함

PARALLEL_THREADS_PER_CPU 파라메터를 CPU당 사용할 병렬 쓰레드 수를 지정하는 파라메터로 Exadata는 기본적으로 hyper threading 기술을 사용하므로 과다한 할당을 막기 위해 1로 지정할 것을 권장함

#설정확인

SQL> show parameter PARALLEL_THREADS_PER_CPU

#설정변경

SQL> alter system set PARALLEL_THREADS_PER_CPU=1 scope=spfile sid=’*’;

적용 후 DB 재기동 필요

=================================================================

수행결과샘플: 확인 결과 해당 파라메터가 2로 지정됨. 상기의 절차에 따라 권장 설정으로 변경이 필요함

Status on PROD1:

FAIL => Database parameter PARALLEL_THREADS_PER_CPU is not set to recommended value

PROD1.parallel_threads_per_cpu = 2

Status on PRODD1:

FAIL => Database parameter PARALLEL_THREADS_PER_CPU is not set to recommended value

PRODD1.parallel_threads_per_cpu = 2

Database parameter SQL92_SECURITY is NOT set to recommended value

DB파라메터 SQL92_SECURITY 설정을 확인함

Exadata는 BP에 보안 최적화를 위해 SQL92_SECURITY 파라메터를 TRUE로 설정하는 것을 권장함

# 설정확인

SQL> show parameter sql92_security;

# 설정변경

SQL> alter system set sql92_security=true scope=spfile sid=’*’;

적용후 DB 재기동 필요

=================================================================

수행결과샘플: 확인 결과 해당 파라메터가 FALSE로 지정됨. 상기의 절차에 따라 BP 설정으로 변경할 것을 권장함

Status on PROD1:

FAIL => Database parameter sql92_security is not set to recommended value

PROD1.sql92_security = FALSE

Status on PRODD1:

FAIL => Database parameter sql92_security is not set to recommended value

PRODD1.sql92_security = FALSE

Database parameter USE_LARGE_PAGES is not set to recommended value

Init parameter 값 중 use_large_pages 설정 확인

use_large_pages는 hugepage를 사용하기 위해 설정하는 파라메터로 Exadata는 SGA 영역을 hugepage에 할당하는 것을 권장하며 이를 위해 파라메터를 only로 설정할 것을 권장함

# 설정 확인

SQL> show parameter use_large_pages;

# 설정 변경

SQL> alter system set use_large_pages=only scope=spfile sid=’*’;

적용 후 instance 재기동 필요

=================================================================

수행결과샘플: 확인 결과 모든 DB들이 FALSE로 설정 되어 있음. 권장 설정에 따라 SGA영역은 Hugepage에 할당이 되도록 hugepage 설정 변경 후 해당 파라메터 설정도 함께 변경 할 것을 권장함

Status on PROD1:

FAIL => Database parameter USE_LARGE_PAGES is not set to recommended value

PROD1.use_large_pages = FALSE

Status on PROD2:

FAIL => Database parameter USE_LARGE_PAGES is not set to recommended value

PROD2.use_large_pages = FALSE

Status on PRODD1:

FAIL => Database parameter USE_LARGE_PAGES is not set to recommended value

PRODD1.use_large_pages = FALSE

Status on PRODD2:

FAIL => Database parameter USE_LARGE_PAGES is not set to recommended value

PRODD2.use_large_pages = FALSE

filesystemio_options is not set to recommended value

filesystemio_options 파라메터 설정을 확인함

Exadata는 BP에 따라 DB node에서 데이터로드 등의 filesystem I/O시 성능 향상을 위해 async 및 direct I/O를 사용 하는 것을 권장함. 단, 실제 DB I/O의 경우 데이터가 Cell서버에 있기에 해당하지 않음.

BP 권장 설정: filesystemio_options=setall

#설정확인

SQL> show parameter filesystemio_options;

#설정변경

SQL> alter system set filesystemio_options=setall scope=spfile sid=’*’;

적용 후 DB 재기동 필요

=================================================================

수행결과샘플: 확인 결과 해당 파라메터가 none으로 지정됨. 상기의 절차에 따라 권장 설정으로 변경이 필요함

Status on PROD1:

WARNING => filesystemio_options is not set to recommended value

PROD1.filesystemio_options = none

Status on PRODD1:

WARNING => filesystemio_options is not set to recommended value

PRODD1.filesystemio_options = none

Database parameter _parallel_adaptive_max_users is not set to recommended value

Hidden parameter 중 _parallel_adaptive_max_users 값 확인

PARALLEL_MAX_SERVERS와 PARALLEL_SERVERS_TARGET 파라메터 값은 다음의 방식으로 계산됨

PARALLEL_MAX_SERVERS=parallel_threads_per_cpu*cpu_count*concurrent_parallel_users*5

PARALLEL_SERVERS_TARGET=parallel_threads_per_cpu*cpu_count*concurrent_parallel_users*2

여기서 concurrent_parallel_users 값은 _PARALLEL_ADAPTIVE_MAX_USERS 파라메터가 제공함.

일반적으로 _PARALLEL_ADAPTIVE_MAX_USERS 값은 4이나 이는 PARALLEL_MAX_SERVERS 값이 권장 값을 초과함에 따라 현재의 권장 값은 2로 변경됨. 권장 설정 보다 높게 설정시 메모리를 과다 사용하거나 성능에 영향을 줄 수 있음

# _PARALLEL_ADAPTIVE_MAX_USERS 설정 확인

SQL> show parameter _PARALLEL_ADAPTIVE_MAX_USERS;

# _PARALLEL_ADAPTIVE_MAX_USERS 설정 변경

SQL> alter system set “_PARALLEL_ADAPTIVE_MAX_USERS”=2 scope=both sid=’*’;

=================================================================

수행결과샘플: 확인 결과 모든 DB들이 4로 설정 되어 있음. 권장 설정에 따라 2로 변경 할 것

Status on PROD1:

FAIL => Database parameter _parallel_adaptive_max_users is not set to recommended value

_parallel_adaptive_max_users = 4

Status on PROD2:

FAIL => Database parameter _parallel_adaptive_max_users is not set to recommended value

_parallel_adaptive_max_users = 4

Database parameter _SMM_AUTO_MAX_IO_SIZE should be set to the recommended value

DB 파라메터 확인

_SMM_AUTO_MAX_IO_SIZE 파라메터는 disk I/O로 수행 되는 hash join시의 IO 사이즈를 결정함

Exadata BP에 의한 권장 설정은 1024에 해당함. 1024로 설정시 해쉬 조인시 40%까지의 성능 향상 효과를 볼 수 있음

.

_SMM_AUTO_MAX_IO_SIZE 파라메터 값이 권장설정인 1024로 되어 있는지 확인함

# _SMM_AUTO_MAX_IO_SIZE 설정 확인

SQL> show parameter _SMM_AUTO_MAX_IO_SIZE;

# _SMM_AUTO_MAX_IO_SIZE 설정 변경

SQL> alter system set “_SMM_AUTO_MAX_IO_SIZE”=1024 scope=both sid=’*’;

=================================================================

수행결과샘플: _SMM_AUTO_MAX_IO_SIZE는 설치 디폴트 값인 248로 확인됨. BP에 해당하는 1024로 설정할 것을 권장함

Status on PROD1:

FAIL => Database parameter _smm_auto_max_io_size should be set to the recommended value

_smm_auto_max_io_size = 248

Status on PROD2:

FAIL => Database parameter _smm_auto_max_io_size should be set to the recommended value

_smm_auto_max_io_size = 248

Storage Server

Storage Server Check

Hardware and firmware profile check not is successful on one or more storage servers

Firmware 버전 점검

하드웨어의 firmware 버전이 권장 설정과 동일 한지 확인함

# Configuration 점검

Root# /opt/oracle.cellos/CheckHWnFWProfile

=================================================================

수행결과샘플: PRODCEL03번 Cell의 경우 메인보드 교체 후 firmware 버전이 불일치 하는 것으로 확인됨. SSD팀과 일정 조정을 통해 수행이 필요함

Status on PRODCEL03:

[WARNING][0m The hardware and firmware does not match with the profile. See details below

<Check_Result Server_Model=”ORACLE_SERVER_X5-2L”>

<Check_Result_for_BIOS>

<BIOS>

<BIOSVersion>

<Required VALUE=”31050100″/>

<Found VALUE=”31030800″/>

</BIOSVersion>

</BIOS>

</Check_Result_for_BIOS>

<Check_Result_for_ILOM>

<ILOM>

<ILOMVersion>

<Required VALUE=”3.2.4.54 r101650″/>

<Found VALUE=”3.2.4.36 r95733″/>

</ILOMVersion>

</ILOM>

</Check_Result_for_ILOM>

</Check_Result>

Storage Server alerts are not configured to be sent via email

스토리지
서버의 Alert 설정을
확인함

스토리지 서버에서 Alert 발생시 메일을 발송하는 기능이 설정 되어 있는지 확인함

다만, 관리망이 메일서버와 연결이 되어 있어야 하며 대부분 Exadata는 EM을 통해 모니터링 하므로 EM이 구성되어 있는 경우 불필요함

#설정확인

• 각 스토리지 서버에서 수행
  

  Root# cellcli
  

  Cellcli> list cell attributes smtpserver
  

  #설정방법
  

  ALTER CELL smtpServer=’mailserver.maildomain.com’, –
  

  smtpFromAddr=’firstname.lastname@maildomain.com’, –
  

  smtpToAddr=’firstname.lastname@maildomain.com’, –
  

  smtpFrom=’Exadata cell’, –
  

  smtpPort='<port for mail server>’, –
  

  smtpUseSSL=’TRUE’, –
  

  notificationPolicy=’critical,warning,clear’, –
  

  notificationMethod=’mail’;
  

  Cellcli> alter cell validate mail;
  

  =================================================================
  

  수행결과샘플: EM서버가 구성되어 있어 다음과 같이 EM으로의 SNMP가 설정된 것이 확인됨. 특이사항 없음
  

  Status on prodcel03, prodcel02, prodcel01:
  

  FAIL => Storage Server alerts are not configured to be sent via email
  

  DATA FROM PRODCEL01 FOR CONFIGURE STORAGE SERVER ALERTS TO BE SENT VIA EMAIL
  

       notificationMethod: snmp
  

       notificationPolicy: critical,warning,clear
  

  DATA FROM PRODCEL02 FOR CONFIGURE STORAGE SERVER ALERTS TO BE SENT VIA EMAIL
  

       notificationMethod: snmp
  

       notificationPolicy: critical,warning,clear
  

  DATA FROM PRODCEL03 FOR CONFIGURE STORAGE SERVER ALERTS TO BE SENT VIA EMAIL
  

       notificationMethod: snmp
  

       notificationPolicy: critical,warning,clear
  

One or more storage servers have stateful alerts that have not been cleared

Exadata 스토리지의 경고 메세지를 확인함

스토리지의 경고 메세지를 확인함

#설정확인

Root# cellcli -e “list alerthistory”

=================================================================

수행결과샘플: PRODCEL03 Cell의 경우 firmware 이슈로 인해 메세지 발생함. 해당 메세지 확인 후 SR을 통한 분석을 요청 할것

Status on PRODCEL03

Seq ID Severity

2     critical

3     critical

4     warning

One or more storage server has non-test stateless alerts with null “examinedby” fields.

스토리지
서버의 Alert history 확인

스토리지 서버의 MS 데몬과 ILOM에 의해 확인된 경고 메세지를 확인함

# 확인방법

root# cellcli

SQL> list alerthistory

=================================================================

수행결과샘플: 수행결과샘플 다음과 같이 3대의 Cell서버 모두에서 Critical Alert이 기록됨. Cell prodcel01, prodcel02의 경우 둘다 동일한 ORA-00600 에러가 발생함. 유사한 이슈로 다음의 버그가 있으나 현재 보다 낮은 버전에 이미 패치가 된 상태라 유사 이슈이거나 재발생한 이슈 일 수 있으므로 SR통해 검증이 필요함

BUG:18155937 – CELL THROWS ORA-600 [SCHEDULER::ONE_OR_MORE_CELLSRV_THREADS_STUCK]

• 이슈 발생시 Cellsrv 프로세스가 중단됨
  

  Cell prodcel03의 디스크 컨트롤러의 hang 이슈의 경우 다음 두가지 이슈와 유사한 것으로 판단됨. 두 이슈 모두 HBA 펌웨어 버전의 문제로 해결 방안은 Image 버전을 12.1.2.3.2 이상으로 업그레이드로 제시됨. 현재 발생한 이슈가 정확히 다음의 버그에 해당 또는 다른 이슈에 해당하는지 SR을 통해 확인이 필요함
  

  Bug 21669752 : TE: Aspen logged thousands of correctable errors and then reset
  

  Bug 23625327 : Aspen : Controller encountered a fatal error and was reset
  

• 이슈 발생시 Cell서버 리붓이 발생함
  

  Status on prodcel03, prodcel02, prodcel01:
  

  FAIL => One or more storage server has non-test stateless alerts with null “examinedby” fields.
  

  DATA FROM PRODCEL01 FOR CHECK ALERTHISTORY FOR NON-TEST OPEN STATELESS ALERTS [STORAGE SERVER]
  

  name         alertmessage
  

       3     “ORA-00600: internal error code, arguments: [Scheduler::One_Or_More_Cellsrv_Threads_Stuck], [1], [], [], [], [], [], [], [], [], [], []”
  

  DATA FROM PRODCEL02 FOR CHECK ALERTHISTORY FOR NON-TEST OPEN STATELESS ALERTS [STORAGE SERVER]
  

  name         alertmessage
  

       3     “ORA-00600: internal error code, arguments: [Scheduler::One_Or_More_Cellsrv_Threads_Stuck], [1], [], [], [], [], [], [], [], [], [], []”
  

Active system values should match those defined in configuration file “cell.conf”

스토리지
서버의 Runtime 설정
환경파일 crosscheck

스토리지 서버 환경설정 파일인 cell.conf와 runtime 설정이 일치하는지 확인

#확인방법

• 각 스토리지 서버에서 수행
  

  Root# IPCONF_RAW_OUTPUT=$(/opt/oracle.cellos/ipconf -verify -semantic -at-runtime -check-consistency -verbose 2>/dev/null);
  

  IPCONF_RESULT=$(echo “$IPCONF_RAW_OUTPUT” | egrep “Consistency check PASSED” | wc -l);
  

  IPCONF_SUMMARY=$(echo “$IPCONF_RAW_OUTPUT” | tail -1);
  

  if [ $IPCONF_RESULT = “1” ]
  

  then
  

  echo -e “SUCCESS: $IPCONF_SUMMARY”
  

  else
  

  echo -e “FAILURE: $IPCONF_SUMMARY\n”
  

  echo -e “echo -e "$IPCONF_RAW_OUTPUT" | grep FAILED”
  

  fi;
  

  The expected output is:
  

  SUCCESS: [Info]: Consistency check PASSED
  

  또는
  

  FAILURE: Info. Consistency check FAILED
  

  =================================================================
  

  수행결과샘플: 확인 결과 전체 스토리지 서버의 NTP 동기화가 수행되지 않음이 확인됨. 이는 NTP relay를 설정한 DB node의 ntp.conf 파일에 restrict 설정 이슈로 인해 발생함. DB node #1,2번의 /etc/ntp.conf에서 다음과 같이 변경할 것. 스토리지 서버의 설정엔 이상이 없음.
  

  Root# vi /etc/ntp.conf
  

  #restrict default ignore -> 주석처리
  

  #restrict -6 default ignore -> 주석처리
  

  restrict default kod nomodify notrap nopeer noquery -> 주석처리 해제
  

  restrict -6 default kod nomodify notrap nopeer noquery -> 주석처리 해제
  

  Root# service ntpd stop
  

  Root# service ntpd start
  

  PRODCEL01~03
  

  Checking NTP server on 192.168.1.101 : FAILED
  

  Checking NTP server on 192.168.1.102 : FAILED
  

RAID controller version does not match on all storage servers

스토리지
서버의 Raid Controller 버전을
확인함

스토리지 서버의 Raid Controller 버전 확인

#확인방법

Root# /opt/MegaRAID/MegaCli/MegaCli64 -AdpAllInfo -a0 | grep ‘FW Package Build’ |awk -F: ‘{print $2}’

=================================================================

수행결과샘플: 확인 결과 prodcel01의 경우 FW version이 2.130.373-4378로 해당 이미지 버전에 해당하는 2.130.373-4871보다 낮은것으로 확인됨. 패치 작업 후 reboot이 시행될때 rollback 되었을 가능성이 존재함. 현 이슈 SR을 통한 확인 및 조치가 필요함

dcli -g cell_group -l root /opt/MegaRAID/MegaCli/MegaCli64 -AdpAllInfo -a0 | grep ‘FW Version’

prodcel01: FW Version : 2.130.373-4378

prodcel02: FW Version : 2.130.373-4871

prodcel03: FW Version : 2.130.373-4871

prodcel04: FW Version : 2.130.373-4871

prodcel05: FW Version : 2.130.373-4871

prodcel06: FW Version : 2.130.373-4871

prodcel07: FW Version : 2.130.373-4871

ILOM Power Up Configuration for HOST_LAST_POWER_STATE should be set to recommended value

ILOM 설정 확인

데이터 센터의 파워장애로 인해서 엑사데이타의 PDU 에 공급되는 2중화된 파워가 중단된 후 다시 연결될때, 호스트의 기존 파워상태를 기억했다가 자동으로 전 상태로 가동함

Default 설정은 전원부 재 연결시 호스트의 기존 파워 상태로 복구하지 않는 모드임

고객사의 정책에 맞게끔 해당 설정을 변경하길 권고함

# 설정 확인

ipmitool sunoem cli force “show /SP/policy” | grep -i power

=>

HOST_AUTO_POWER_ON = disabled

HOST_LAST_POWER_STATE = disabled

# 설정 변경

ipmitool sunoem cli force “set /SP/policy HOST_LAST_POWER_STATE=enabled”

=================================================================

수행결과샘플: 현재 3번 Cell server(prodcel03)의 경우 다음과 같이 HOST_LAST_POWER_STAT 설정이 DISABLE 되어 있음. 타 노드와 동일하게 ENABLE로 변경할 것

Status on prodcel03:

DATA FROM PRODCEL03 FOR VERIFY ILOM POWER UP CONFIGURATION FOR HOST_LAST_POWER_STATE ON STORAGE SERVER

Connected. Use ^D to exit.

-> show /SP/policy

/SP/policy

Targets:

Properties:

ENHANCED_PCIE_COOLING_MODE = disabled

HOST_AUTO_POWER_ON = disabled

HOST_LAST_POWER_STATE = disabled

Commands:

cd

set

show

-> Session closed

Disconnected

Management network is not separate from data network on all storage servers

Management network 설정 확인

관리망 네트웍크의 각 노드별 설정 확인

#설정확인

root# grep -i network /etc/sysconfig/network-scripts/ifcfg* | cut -f5 -d”/” | grep -v “#”

=================================================================

수행결과샘플: 하기와 같이 prodcel03 장비에 불필요한 인터페이스(eth0.org) 확인됨. eth0.org는 사용 하지 않는 인터페이스 이므로 삭제 할 것

Status on prodcel03:

DATA FROM PRODCEL03 FOR VERIFY DATA NETWORK IS SEPARATE FROM MANAGEMENT NETWORK

ifcfg-eth0:NETWORK=10.10.1.0

ifcfg-eth0.org:NETWORK=10.10.1.0

ifcfg-ib0:NETWORK=192.168.8.0

ifcfg-ib1:NETWORK=192.168.8.0

Cluster Wide

Cluster Wide Check

Localtime configuration does not match on all Infiniband switches

Infiniband switch의 localtime 설정 확인

Infiniband Switch의 시간설정 값이 다른 switch가 있는지 확인함

# ntp 서비스 기동 확인

Root# service ntp status

=================================================================

수행결과샘플: prodsw-ibb01만 시간 설정이 다르게 나옴. 해당 스위치에 Ntp 서비스가 기동 되어 있는지 확인이 필요함

Status on Cluster Wide:

DATA FROM PRODDB01 – VERIFY SWITCH LOCALTIME CONFIGURATION ACROSS SWITCHES

DATA FROM PRODSW-IBA01 FOR INFINIBAND SWITCH LOCALTIME CONFIGURATION

0a36916e2e979dbcfd37c789955f1aba /conf/localtime

DATA FROM PRODSW-IBA02 FOR INFINIBAND SWITCH LOCALTIME CONFIGURATION

0a36916e2e979dbcfd37c789955f1aba /conf/localtime

DATA FROM PRODSW-IBB01 FOR INFINIBAND SWITCH LOCALTIME CONFIGURATION

fcccbcf95c718cf2fdee557763e460be /conf/localtime

DATA FROM PRODSW-IBB02 FOR INFINIBAND SWITCH LOCALTIME CONFIGURATION

0a36916e2e979dbcfd37c789955f1aba /conf/localtime

DATA FROM PRODSW-IBS01 FOR INFINIBAND SWITCH LOCALTIME CONFIGURATION

0a36916e2e979dbcfd37c789955f1aba /conf/localtime

DATA FROM PRODSW-IBS02 FOR INFINIBAND SWITCH LOCALTIME CONFIGURATION

0a36916e2e979dbcfd37c789955f1aba /conf/localtime

NTP server does not match across all database and storage servers

Database서버와 Cell 서버의 NTP 설정이 동일하게 구성 되어 있는지 확인

Database서버와 Cell 서버의 NTP 설정이 동일하게 구성 되어 있는지 확인

# ntp 설정

root# /opt/oracle.cellos/ipconf.pl

=================================================================

수행결과샘플: Cell서버는 폐쇄망 구성에 따라 NTP서버로 접근이 안되므로 DB node #2에 relay 설정함

Status on Cluster Wide:

prod01 = 10.10.10.137

prodcel01 = 192.168.10.3

prodcel02 = 192.168.10.3

prodcel03 = 192.168.10.3

prod02 = 10.10.10.137

InfiniBand Switch

InfiniBand Switch Check

Hostname is not set in /etc/hosts

Infiniband switch의 hostname 확인

Infiniband switch의 hostname 설정을 확인함

#설정확인

[Infiniband-sw root]# cat /etc/hosts

=================================================================

수행결과샘플: 확인 결과 두대의 Infiniband switch에 hostname이 설정 안되어 있음. 아래와 같이 각 Infiniband swith에 접속하여 설정 필요

Status on prodsw-ibb01:

DATA FROM PRODSW-IBB01 FOR HOSTNAME IN /ETC/HOSTS

# Do not remove the following line, or various programs

# that require network functionality will fail.

127.0.0.1        localhost.localdomain localhost

::1        localhost6.localdomain6 localhost6

10.10.1.102 prodsw-ibb01.inexpia.com prodsw-ibb01

Status on prodsw-iba01:

DATA FROM PRODSW-IBA01 FOR HOSTNAME IN /ETC/HOSTS

# Do not remove the following line, or various programs

# that require network functionality will fail.

127.0.0.1        localhost.localdomain localhost

::1        localhost6.localdomain6 localhost6

10.10.1.101 prodsw-iba01.inexpia.com prodsw-iba01

Maxinum Availability Architecture

MAA Check

Redo log files should be appropriately sized

Redo log 사이즈가
적정한지
확인

Redo log 발생량 대비 권장 Redo log 사이즈는 다음과 같음.

Peak Redo 기준으로 다음과 같음

EM 또는 AWR reports 기준 발생량 권장 redo log group size

<1 MB/sec      1 GB

<=3 MB/sec      3 GB

<= 5 MB/sec      4 GB

<= 25 MB/sec      16 GB

<= 50 MB/sec      32 GB

> 50 MB/sec      64 GB

# Redo 발생량 확인

• 각 DB환경에서 다음의 명령어 수행
  

  Oracle$ function logswitches {
  

  $ORACLE_HOME/bin/sqlplus -s ‘/ as sysdba’ <<EOF
  

  set feedback off newpage none termout on
  

  alter session set nls_date_format=’YYYY/MM/DD HH24:MI:SS’;
  

  select * from (
  

  select thread#,sequence#,first_time “LOG START TIME”,(blocks*block_size/1024/1024)/((next_time-first_time)*86400) “REDO RATE(MB/s)”, \
  

  (((blocks*block_size)/a.average)*100) pct_full
  

  from v\$archived_log, (select avg(bytes) average from v\$log) a
  

  where ((next_time-first_time)*86400<300)
  

  and first_time > (sysdate-90)
  

  and (((blocks*block_size)/a.average)*100)>80
  

  and dest_id=1
  

  order by 4 desc
  

  )
  

  where rownum<11;
  

  exit
  

  EOF
  

  }
  

  export SWITCHES=$(logswitches)
  

  if [ $(echo “$SWITCHES”| wc -l) -le 1 ]
  

  then
  

  echo -e “SUCCESS: Redo logs are appropriately sized”
  

  else
  

  echo
  

  echo -e “WARNING: Redo logs are potentially mis-sized. Below is a list of archived logs from”
  

  echo -e “the previous 90 days which were active for less than 5 minutes and the redo rate seen”
  

  echo -e “for the duration of that log. These indicate the peak redo rate. Resizing of the log”
  

  echo -e “files to accomodate this rate may be required.\n”
  

  echo “$SWITCHES”
  

  fi
  

• 정상일 경우 결과
  

  SUCCESS: Redo logs are appropriately sized
  

• 변경이 필요한 경우 결과
  

  Example of a “WARNING” result:
  

  WARNING: Redo logs are potentially mis-sized. Below is a list of archived logs from
  

  the previous 90 days which were active for less than 5 minutes and the redo rate seen
  

  for the duration of that log. These indicate the peak redo rate. Resizing of the log
  

  files to accomodate this rate may be required.
  

  THREAD# SEQUENCE# LOG START TIME REDO RATE(MB/s) PCT_FULL
  

  ———- ———- ——————- ————— ———-
  

  2 12374 2017/02/24 15:03:04 412.881913 95.7611859
  

  2 12382 2017/02/24 15:15:10 408.75571 89.8144871
  

  2 12296 2017/02/24 12:06:26 396.99937 92.0774907
  

  2 12380 2017/02/24 15:09:31 371.651196 90.7351553
  

  2 12385 2017/02/24 15:17:28 370.488538 90.4513031
  

  2 12378 2017/02/24 15:06:18 362.405012 95.1136202
  

  2 12389 2017/02/24 15:20:51 356.672996 95.7862049
  

  2 12377 2017/02/24 15:05:32 354.660687 99.5751441
  

  2 12350 2017/02/24 13:27:40 353.577854 97.113058
  

  2 12354 2017/02/24 13:30:45 347.344079 97.5209206
  

  =================================================================
  

  수행결과샘플: 이번 결과는 운영DB에서 다음과 같이 확인을 수행했으며 결과는 다음과 같음. PROD, PRODD의 경우 redo log 사이즈 8~16GB로 증가시킬 것을 권장함
  

  ## PROD
  

  THREAD# SEQUENCE# LOG START TIME REDO RATE(MB/s) PCT_FULL
  

  ———- ———- ——————- ————— ———-
  

  1 16803 2017/06/15 21:00:54 225.63878 99.1576672
  

  1 16804 2017/06/15 21:01:12 186.805664 95.7743883
  

  2 42706 2017/06/15 21:01:02 183.150019 93.900156
  

  1 17016 2017/06/21 12:55:44 139.037783 98.4398365
  

  1 16788 2017/06/15 13:29:20 132.565332 97.093749
  

  1 17015 2017/06/21 12:55:14 132.511621 97.05441
  

  1 17017 2017/06/21 12:56:13 132.341448 90.4677868
  

  1 16787 2017/06/15 13:28:50 122.162467 89.4744635
  

  2 39770 2017/05/15 15:28:06 119.883919 87.8056049
  

  2 39771 2017/05/15 15:28:36 119.365999 87.4262691
  

  ## PRODD
  

  THREAD# SEQUENCE# LOG START TIME REDO RATE(MB/s) PCT_FULL
  

  ———- ———- ——————- ————— ———-
  

  1 13301 2017/05/19 10:55:39 211.881836 93.1121349
  

  1 13310 2017/05/19 13:56:32 209.226345 91.9451714
  

  2 28698 2017/05/19 13:55:48 203.456132 94.3766236
  

  2 28699 2017/05/19 13:56:07 203.088672 99.1643906
  

  2 28697 2017/05/19 13:55:28 202.879614 99.0623116
  

  2 28701 2017/05/19 13:56:48 196.357987 91.0840273
  

  2 28689 2017/05/19 10:55:38 193.671433 99.294436
  

  1 13309 2017/05/19 13:56:11 193.532459 99.2231846
  

  1 13307 2017/05/19 13:55:29 193.376837 99.1433978
  

  2 28700 2017/05/19 13:56:27 193.344285 99.1267085
  

Local archive destination does not alternate destination configured

Local archive 경로에
대체
경로가
설정되어
있는지
확인

Archive 영역이 용량 부족 또는 장애로 이용 불가 한 경우 사용할 대체 경로를 지정하는 것을 권장함.

#설정확인

SQL> select count(*) from v$asm_diskgroup where name=(select substr(value,2) from v$parameter where name=’db_recovery_file_dest’) and type!=’HIGH’;

• 수행결과가 없는 경우 패스, 있는 경우 다음의 쿼리 수행
  

  SQL> select count(*) from v$archive_dest where destination=’USE_DB_RECOVERY_FILE_DEST’ and status=’VALID’ and alternate=’NONE’;
  

• 수행 결과가 있는 경우 대체경로 지정이 필요함
  

  #설정방법
  

  Doc ID 2059780.1 노트의 Section A: Configuration Prerequisites 부분 참고
  

  =================================================================
  

  수행결과샘플: 수행 결과 대체 경로가 지정되어 있지 않음. 상기의 절차에 따라 대체 경로를 지정할 것을 권장함
  

  Status on PROD01:
  

  WARNING => Local archive destination does not alternate destination configured
  

  DATA FROM PROD01 – PROD DATABASE – VERIFY ALTERNATE DESTINATION CONFIGURATION FOR LOCAL ARCHIVE DESNTINATION
  

  DESTINATION STATUS ALTERNATE
  

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

  USE_DB_RECOVERY_FILE_DEST VALID NONE
  

  INACTIVE NONE
  

  INACTIVE NONE
  

  …
  

  Status on PROD02:
  

  WARNING => Local archive destination does not alternate destination configured
  

  DATA FROM PROD02 – PROD DATABASE – VERIFY ALTERNATE DESTINATION CONFIGURATION FOR LOCAL ARCHIVE DESNTINATION
  

  DESTINATION STATUS ALTERNATE
  

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

  USE_DB_RECOVERY_FILE_DEST VALID NONE
  

  INACTIVE NONE
  

  …
  

Exadata Critical Issues (Doc ID 1270094.1):- DB1-DB4,DB6,DB9-DB35, EX1-EX21, EX23-EX26,EX29 and IB1-IB3,IB5

Exadata Critical Issue에
노출
되어
있는지
확인

현재 사용하는 버전에서 Exadata Critical Issues (Doc ID 1270094.1) 노트에 등록된 Critical Issue에 해당하는게 있는지 확인함

# 확인방법

Exachk 수행 결과를 바탕으로 Exadata Critical Issues (Doc ID 1270094.1) 노트 확인

=================================================================

수행결과샘플:

현재 사용중인 버전:

Database: 12.1.0.2 BP3

Exadata Storage Software: 12.1.1.1.1

Infiniband Switch Firmware: 2.1.3-4

현재 사용중인 상기의 버전은 다수의 Critical Issue에 노출됨

– Database Issue: 총 6개

– Storage Software Issue: 총 4개

– InfiniBand Switch Firmware Issue: 총 1개

# Database Critical Issue:

Critical Issue# DB28

버그 18607546 으로 인해 유효하지 않은 자기참조로 연결된 row(자기 자신을 가르키는 잘못된 chained row의 row 조각)에 있는 chained rows(다른 row로 row 확장)에 따라 Wrong result 또는 Table Corruption 발생. 주로 많은 컬럼 수를 가지는 테이블에서 발생(i.e. 컬럼 수 255개 초과)하나 이에 국한된 것은 아님. 자세한 사항은 1944645.1 문서 확인

조치사항:

문제의 row를 제외하고 해당 테이블을 재생성 하거나 영향받은 block들을 dbms_repair를 사용하여 soft corrupt 하여 DML시 skip 하게 할 것

해결방안:

12.1.0.2 BP6, 11.2.0.4 BP16 이상으로 업그레이드

또는 Interim Patch 18607546 적용

Critical Issue# DB29

Image 12.1.1.1.1~12.1.2.1.2 버전과 DB 12.1.0.2에서 ACFS를 사용하는 경우 다음의 이슈로 인해 패치 적용 필요

Bug 20688221 – 초기화 I/O를 수행하는 동안 ACFS 볼륨에서 쓰는 ASM file extent map이 제대로 락킹이 되지 않아 데이터 corruption 발생 가능

Bug 21124596 – 2TB 이상의 griddisk를 사용하고 ACFS 볼륨을 2TB 이상 할당하는 경우 ASM 메타데이터가 여러 디스크에 겹쳐써져 diskgroup이 손실될 수 있음. Diskgroup 재생성 및 백업으로 부터 데이터 복구 필요

ASM alertlog에 Error “ORA-15196: invalid ASM block header” 메세지 발생

Bug 21369858 – 하나의 diskgroup이 2TB 이상의 griddisk를 사용하고 생성된 ACFS 볼륨이 공간을 할당 하는 경우 ASM 메타데이터가 여러 디스크에 겹쳐써져 전체 diskgroup이 손실될 수 있음. Diskgroup 재생성 및 백업으로 부터 데이터 복구 필요

ASM alertlog에 Error “ORA-15196: invalid ASM block header” 메세지 발생

ACFS 로그에 Error “ASSERTION FAILURE: physA->startBlk >= auLimit File” 메세지 발생

조치사항:

없음

해결방안:

12.1.0.2 BP13 이상으로 업그레이드

Critical Issue# DB30

디스크 resync 작업이 수행되는 동안 ASM의 오래된 registry의 corruption으로 인해 ORA-600 [kfdsBlk_verCb] 에러 발생. 2028222.1 Note 참고

현상:

ASM resync 작업이 수행되는 동안 다음과 유사한 에러들이 지속적으로 발생

WARNING: verification failed for all mirrors of Staleness Registry

ORA-00600: internal error code, arguments: [kfdsBlk_verCb]

조치사항:

21131289 패치(BP10에 포함됨) 적용 후 다음의 절차에 따라 복구 수행

Step1 – corruption 확인

SQL> oradebug unit_test kfdsSR_scrub <DGNAME> 0

Step2 – corruption 정정

SQL> oradebug unit_test kfdsSR_scrub <DGNAME> 1

Step3 – corruption 정정 확인

SQL> oradebug unit_test kfdsSR_scrub <DGNAME> 0

Step4 – rebalance 수행

SQL> alter diskgroup <DGNAME> rebalance power 11;

해결방안:

GI Home 및 DB Home DBBP11 적용 또는 20904530 패치 적용

Critical Issue# DB31

ORA-600 [kfdAtbUpdate_11_02] 와 ORA-600 [kfdAtUnlock00] 메시지가 발생하며 ASM rebalance가 중단됨. 2031709.1 Note 참고

현상:

ASM rebalance가 수행되는 동안 다음과 유사한 에러가 발생하며 갑작스런 ASM shutdown 발생

ORA-00600: internal error code, arguments: [kfdAtbUpdate_11_02], [128], [4], [DATA], [367936], [1], [27], [409], [0], [94119], [], []

ORA-00600: internal error code, arguments: [kfdAtUnlock00], [kfCheckDG], [DATA], [27], [367936], [128], [], [], [], [], [], []

Oracle Clusterware에 의해 해당 ASM instance는 재기동 되나 동일한 에러로 인해 계속적으로 갑작스런 shutdown 발생

조치사항:

만약 이러한 이슈가 발생한 경우, 복구를 위해서는 rebalance가 실패한 extent를 가지고 있는 ASM 파일을 제거하는 작업이 필요함. 지원을 우해서는 Oracle Support 연락 할 것

해결방안:

GI Home DBBP11 적용 또는 21281532 패치 적용

Critical Issue# DB32

ASM diskgroup이 이중화 구성으로 되어 있고 Exadata 스토리지가 오프라인 일때 오라클 클러스터웨어가 시작된 경우, Primary extent가 오프라인 상태인 스토리지에 존재 하는 경우 온라인 ASM mirror extent에 I/O를 수행할 수 없어 발생하는 현상. 2057731.1 Note 참고

다음의 모든 조건을 만족하는 경우 발생 가능

1. Database Patch for Engineered Systems and DB In-Memory 12.1.0.2.4 또는 이전 버전과 함께 GI 12.1.0.2 버전인 경우

2. ASM diskgroup이 이중화인 경우

3. Exadata storage 서버가 offline인 상태에서 CRS를 기동한 경우

현상:

Exadata의 일반적인 ASM diskgroup 구성인 경우 다음을 예상해 볼 수 있음

OCR 및 voting 파일들이 이중화 diskgroup에 저장된 경우

=> Oracle Clusterware fails to start due to I/O errors on OCR

OCR 및 voting 파일들은 삼중화 disgkroup에 있고 DB controlfile과 데이터파일들은 이중화 diskgroup에 있는 경우

=> Oracle Clusterware and ASM instance start, Oracle Database fails to start or crashes due to I/O errors

조치사항: 오프라인된 스토리지 기동. ASM 및 Clusterware가 정상 작동할 경우 추가적인 액션은 필요 없음. Clusterware가 작동을 안하거나 부분적으로 작동할 경우 CRS 기동(필요시 재시작)

해결방안:

DBBP5 이상 적용 또는 Patch 20217875 GI Home에 적용(단, 패치 readme 파일에 rootcrs.pl 수행문이 빠져 있으므로 현 노트를 참고하여 수행 할 것)

Critical Issue# DB36

이슈: bug 20509482로 인해 RAC DB에서 인접한 데이터 블록들의 Parallel direct insert시 병렬처리 슬레이브 프로세스들에 의해 겹처써질 수 있으며 이에 따라 ORA-600 [3020], ORA-752, Wrong result 또는 Fast incremental backup 수행시 DB hang으로 이러질 수 있는 RMAN ORA-600 [krcrfr_nohist]가 나타날 수 있음. 2139374.1 Note 참고

대상: 11.2.0.3~12.1.0.2 버전에서 Parallel Direct insert를 수행하는 경우

현상:

다음과 같은 현상들이 나타날 수 있음

1. Insert시의 결과 건수와 이를 조회시 결과 건수가 다른 경우 데이터 손실 발생

2. Parallel Direct Load 복구가 ORA-752 or ORA-600 [3020] 에러와 함께 실패함.

3. RMAN fast incremental backup이 ORA-600 [krcrfr_nohist] 에러와 함께 실패하며 이로 인해 DB hang으로 이어질 수 있음

조치사항:

20509482.8 노트 확인할 것

해결방안:

12.1.0.2 BP160119 패치 적용 또는 Interim patch 20509482 적용할것

# Storage Software Critical Issue:

Critical Issue# EX16

11.2.3.3.1 또는 12.1.1.1.1 버전이 설치된 linux kernel에서 semtimedop라는 함수가 timeout이 지연되면서 호출 되어지는데 이로 인해 오프로드 작업이 실패함. 에러 메시지는 다음과 유사함

ORA-700 [Offload issue job timed out]

ORA-700 [Offload group not open]

RS-700 [Celloflsrv hang detected. It will be terminated]

이 문제는 Oracle Linux DB서버에도 존재하나 현재까지는 부정적인 결과는 나타나지 않음

조치사항:

DB서버와 스토리지 서버 모두 다음과 같이linux kernel 파라메터 rcu_delay=1 설정

Step 1: Set rcu_delay for runtime

# echo 1 > /proc/sys/kernel/rcu_delay

Verify the setting

# cat /proc/sys/kernel/rcu_delay

1

Step 2: Set rcu_delay in /etc/sysctl.conf for proper setting upon reboot

Add “kernel.rcu_delay=1” to /etc/sysctl.conf

Step 3: Restart cellsrv on storage servers

CellCLI> alter cell restart services cellsrv;

다음 케이스들의 경우 자동적으로 workaround가 적용되어 있음

1. 9월 이후에 나온 OEDA로 11.2.3.3.1 또는 12.1.1.1.1 이미지를 설치한 경우

2. 스토리지 서버를 11.2.3.3.1 또는 12.1.1.1.1 버전으로 업그레이드 했고 문서에서 처럼 patchmgr plugins patch가 patchmgr 수행 전에 제대로 올려진 경우

3. DB서버를 dbnodeupdate.sh(v3.58 이상) tool을 사용해서 11.2.3.3.1 또는 12.1.1.1.1 버전으로 업그레이드 한 경우

해결방안:

12.1.1.1.2 또는 12.1.2.1.0 이상으로 업그레이드

Critical Issue# EX19

12.1.1.1.1 이하 버전에서 동일 CELL DISK에 ALTER GRIDDISK, CREATE GRIDDISK 명령어를 다수 수행시 CELL DISK metadata curroption 발생 및 데이터 손실 발생. 1991445.1 노트 참고

다음 스크립트를 수행하여 조치사항 확인

check_bug19695225.sh

조치사항:

복구가 필요한 cell disk, grid disk, ASM disk group 재생성 후 backup 으로 영향 받은 database 복구

해결방안:

1. Image 12.1.2.1.1 또는 12.1.1.1.2 이상으로 업그레이드(12.1.2.1.0도 패치 포함되어 있으나 12.1.2.1.1이 권장 버전임)

2. 12.1.1.1.1, 11.2.3.3.1, 11.2.3.3.0의 경우 patch 19695225 적용

3. 패치 나 업그레이드 수행 전에는 CellCLI CREATE/ALTER griddisk 명령어 수행을 피할 것

Critical Issue# EX20

Database 리소스 메니저 플랜이 sub plan들을 포함하고 OTHER_GROUP이 최상위 plan 대신 sub plan에 존재하는 경우 CELLSRV가 ORA-600 [DiskIOSched::GetCatIndex:2] 메시지와 함께 FAIL될 수 있음. 만약 여러 CELL에서 동시에 CELLSRV들이 FAIL 될 경우 ASM과 databsae들이 crash 될 수 있음

1967985.1 노트 참고

조치사항:

1) 문제가 있는 데이터베이스의 resource manager disable

SQL> alter system set resource_manager_plan=” scope=both sid=’*’;

2) OTHER_GROUP 확인 후 최상위 plan에 추가

SQL> select unique name from v$rsrc_plan_history where name not in (select plan from dba_rsrc_plan_directives where plan in (select unique name from v$rsrc_plan_history) and GROUP_OR_SUBPLAN = ‘OTHER_GROUPS’);

SQL> sys.dbms_resource_manager.create_plan_directive (

plan => ‘NIGHT_PLAN’

,group_or_subplan => ‘OTHER_GROUPS’

,mgmt_p2 => 80

,switch_estimate => FALSE

,comment => NULL );

해결방안:

Image 12.1.1.1.2이상 또는 12.1.2.1.1 이상으로 업그레이드

또는 patch 19211091 적용

Critical Issue# EX27

버그 21299486으로 인해 “list activerequest” CellCli명령어 수행시 간혹 I/O hang으로 인해 데이터베이스가 hang 걸릴 수 있음. 2095255.1 Note 참고

다음의 조건에 해당하는 경우 발생할 수 있음

– Exadata storage software 버전 12.1.1.1.0~12.1.2.1.2에서 “list activerequest” 명령어를 수행하는 경우

현상은 다음과 같음

*스토리지 서버의 IO 고착상태에 의해 데이터베이스가 hang에 걸릴 수 있으며 이는 다음의 다양한 방식으로 나타날 수 있음

– “Terminating pid nnnn hung on an I/O operation” 메시지와 함께 데이터베이스 프로세스가 종료됨

– ‘log file parallel write’이벤트에 LGWR가 갖혀 많은 다은 세션을 블라킹 함

– “Shutdown immediate” 수행시 DB가 hang 걸림

– “alter database open” 수행시 DB가 hang 걸림

*다른 CellCli 명령어는 다 정상이나 “list activerequest” 수행시 다음의 에러 메시지가 나타나며 hang걸림: “CELL-02559: There is a communication error between MS and CELLSRV.”

*RS-7445 [Serv CELLSRV hang detected]

조치사항:

1. 스토리지 서버에서 다음의 명령어를 수행하여 cellsrv dump를 생성할 것

CellCLI> alter cell events = “immediate cellsrv.cellsrv_statedump(0,0)”

2. Cell 서비스 재시작 할것(hang이 풀림)

CellCLI> alter cell restart services all

3. bug 21299486에 해당하는지 확인을 위해 다음의 트레이스 파일들을 SR에 올릴 것

트레이스 파일들은 $CELLTRACE 경로에 있음

트레이스 파일 목록은 스텝 1에서 확인

예) /opt/oracle/cell/log/diag/asm/cell/dm01cel01/trace/svtrc_19330_75.trc

$CELLTRACE/ms-odl.*

$CELLTRACE/alert.log

해결방안:

스토리지 소프트웨어 버전을 12.1.2.1.3이상으로 업그레이드

# Infiniband Firmware Critical Issue:

Critical Issue# IB5

Bug 23528420 – HTTP나 HTTPS를 통한 손상된 POST 요청을 받은 후 InfiniBand 스위치가 높은 CPU사용율을 보일수 있으며 이로 인해 서브넷 매니저가 네트웍 관리 역할을 위한 CPU를 할당받지 못할 수 있으며 결국 데이터베이스 서버 또는 스토리지 서버 Eviction으로 이어질 수 있음. 이러한 요청들은 주로 보안 스캔 툴에 의해 발생될 수 있음.

조치사항:

새로운 펌웨어 버전이 나오기 전까지는 ILOM의 HTTP, HTTPS 서비스를 DISABLE 할 것

각 Infiniband Switch에 접속후 순차적으로 다음과 같이 수행

1. root# spsh

2. 다음의 명령어 수행

-> set /SP/services/http secureredirect=disabled

-> set /SP/services/http servicestate=disabled

-> set /SP/services/https servicestate=disabled

-> exit

The SYS and SYSTEM user ids should have a default tablespace of SYSTEM

Sys, System 계정의 디폴트 테이블스페이스 확인

SYS, SYSTEM 계정의 디폴트 테이블스페이스가 지정 되어 있는지 확인함

#설정확인

SQL> SELECT username, default_tablespace

FROM dba_users

WHERE username in (‘SYS’,’SYSTEM’);

#설정변경

Note 1111111.2 참고

=================================================================

수행결과샘플: 확인 결과 다음과 같이 SYSTEM 계정의 디폴트 스페이스가 SYSTEM이 아닌 USERS로 지정 되어 있음. 상기의 노트를 참고하여 변경할 것을 권장함

Status on PROD:

WARNING => The SYS and SYSTEM user ids should have a default tablespace of SYSTEM

DATA FOR PROD FOR VERIFY SYS AND SYSTEM USERS DEFAULT TABLESPACE IS SYSTEM

SYSTEM

USERS

Status on PRODD:

WARNING => The SYS and SYSTEM user ids should have a default tablespace of SYSTEM

DATA FOR PRODD FOR VERIFY SYS AND SYSTEM USERS DEFAULT TABLESPACE IS SYSTEM

SYSTEM

USERS

RMAN controlfile autobackup should be set to ON

RMAN 백업 설정 확인

RMAN BP설정에 따른 controlfile 자동 백업이 설정되어 있는지 확인함

#설정확인

• 각 DB별로 확인 필요
  

  Oracle# RMAN_AUTOBACKUP_STATUS=””;
  

  RMAN_AUTOBACKUP_STATUS=$(echo -e “set heading off feedback off\n select value from V\$RMAN_CONFIGURATION where name = ‘CONTROLFILE AUTOBACKUP’;” | $ORACLE_HOME/bin/sqlplus -s “/ as sysdba”);
  

  if [ -n “$RMAN_AUTOBACKUP_STATUS” ] && [ “$RMAN_AUTOBACKUP_STATUS” = “ON” ]
  

  then echo -e “\nPASS: RMAN “CONTROLFILE AUTOBACKUP” is set to \”ON\”:” $RMAN_AUTOBACKUP_STATUS;
  

  else
  

  echo -e “\nFAIL: RMAN “CONTROLFILE AUTOBACKUP” should be set to \”ON\”:” $RMAN_AUTOBACKUP_STATUS;
  

  fi;
  

  #설정변경
  

• 각 DB별 수행
  

  Oracle# rman target / — rman catalog 사용시 접속 필요
  

  Rman> CONFIGURE SNAPSHOT CONTROLFILE NAME TO ‘+DBFS_DG/snapcf_ora<SID>.f’;
  

  Rman> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO ‘+<Diskgroup명>/%F’;
  

  Rman> CONFIGURE CONTROLFILE AUTOBACKUP ON;
  

  =================================================================
  

  수행결과샘플: 모든 DB에 controlfile autobackup이 설정되어 있지 않음. 상기의 절차에 따라 controlfile autobackup을 설정할 것을 권장함
  

  Status on PROD:
  

  WARNING => RMAN controlfile autobackup should be set to ON
  

  DATA FOR PROD FOR VERIFY RMAN CONTROLFILE AUTOBACKUP IS SET TO ON
  

  Status on PRODD:
  

  WARNING => RMAN controlfile autobackup should be set to ON
  

  DATA FOR PRODD FOR VERIFY RMAN CONTROLFILE AUTOBACKUP IS SET TO ON
  

Database parameter DB_LOST_WRITE_PROTECT is NOT set to recommended value

DB Protection 설정을 확인함

Exadata는 BP에 따라 DB_LOST_WRITE_PROTECT 파라메터를 TYPICAL로 설정 할 것을 권장함. TYPICAL로 설정시 인스턴스는 lost-write를 감지하기 위해 read-write 테이블스페이스를 buffer cache로 읽은 작업을 redo log에 기록하게 됨

# 설정확인

SQL> show parameter db_lost_write_protect;

# 설정변경

SQL> alter system set db_lost_write_protect=typical scope=both sid=’*’;

=================================================================

수행결과샘플: 확인 결과 PROD DB의 해당 파라메터가 NONE로 지정됨. 상기의 절차에 따라 BP 설정으로 변경할 것을 권장함

FAIL => Database parameter DB_LOST_WRITE_PROTECT is NOT set to recommended value

PROD1.db_lost_write_protect = NONE

PROD2.db_lost_write_protect = NONE

PASS => Database parameter DB_LOST_WRITE_PROTECT is set to recommended value

PRODD1.db_lost_write_protect = typical

PRODD2.db_lost_write_protect = typical

Database parameter LOG_BUFFER is NOT set to recommended value

DB 파라메터 중 log_buffer 설정을 확인함

Exadata는 BP에 따라 lgwr 전송에 최적화된 log_buffer 사이즈는 128MB임. 현재 설정된 값이 일치하는지 확인함

#설정확인

SQL> show parameter log_buffer;

#설정변경

SQL> alter system set log_buffer=134217728 scope=spfile sid=’*’;

적용 후 DB 재기동 필요

=================================================================

수행결과샘플: 확인 결과 PROD DB의 해당 파라메터가 54M로 지정됨. 상기의 절차에 따라 권장 설정으로 변경이 필요함

FAIL => Database parameter LOG_BUFFER is NOT set to recommended value

PROD1.log_buffer = 57540608

PROD2.log_buffer = 57540608

PASS => Database parameter LOG_BUFFER is set to recommended value

PRODD1.log_buffer = 134217728

fast_start_mttr_target should be greater than or equal to 300

DB 파라메터 중 fast_start_mttr_target 설정을 확인함

Exadata는 BP에 따라 write 및 redo 성능 최적화를 위해 fast_start_mttr_target 파라메터를 300으로 설정할 것을 권장함

#설정확인

SQL> show parameter fast_start_mttr_target;

#설정변경

SQL> alter system set fast_start_mttr_target=300 scope=both sid=’*’;

=================================================================

수행결과샘플: 확인 결과 해당 파라메터가 0로 지정됨. 상기의 절차에 따라 BP 설정으로 변경할 것을 권장함

Status on PROD1:

WARNING => fast_start_mttr_target should be greater than or equal to 300.

PROD1.fast_start_mttr_target = 0

Status on PRODD1:

WARNING => fast_start_mttr_target should be greater than or equal to 300.

PRODD1.fast_start_mttr_target = 0

The data files should be recoverable

Data file의 복구 가능여부 확인

Nologging 상태로 데이터 로딩 작업이 발생한 datafile이 있는지 확인함

# Datafile recoverable 여부 확인

SQL> select file#, unrecoverable_time, unrecoverable_change# from v$datafile where unrecoverable_time is not null;

=================================================================

# 확인결과: 하기와 같이 다수 데이터파일들이 unrecoverable 상태로 확인 됨. 복구시나 Standby 구성시에 문제가 발생 할 수 있으므로 Full backup을 수행하고 force logging등의 방법을 사용할 것을 권장함

Status on PROD:

FAIL => The data files should be recoverable

DATA FOR PROD FOR VERIFY DATA FILES ARE RECOVERABLE

11 28-JAN-15 0

12 28-JAN-15 0

13 28-JAN-15 0

14 28-JAN-15 0

15 28-JAN-15 0

16 28-JAN-15 0

17 28-JAN-15 0

24 23-FEB-15 1.4226E+13

25 23-FEB-15 1.4226E+13