AWR 활용 Monitoring(DBA_HIST_* View)

    • Oracle AWR의 기능은 활용가치가 매우 높다. 기본적으로 특정 시점 별로 스냅샷을 찍어 보관하고 있어 쌓여 있는 정보들을 어떻게 가공하는지에 따라서 그래픽 한 형태로 추출해낼 수 있다.
    • 단순히 AWR Report나 ADDM Report로 추출하는 것보다 원하는 정보를 SQL문으로 질의하여 추출하는 것이 더 의미 있는 정보를 빨리 얻어 낼 수 있다.
    • 아래 내역들은 SQL문으로 핵심이 되는 Table을 Join하여 데이터를 추출하였으며 더 나아간다면 엑셀이나 Program을 통하여 S/W를 만들어 즉각적으로 분석 및 모니터링 하는 것이 가능하다.

         

  1. DBA_HIST_* View 활용

    • DBA_HIST_* View로 구성되어 있는 AWR은 다양한 DB 정보를 일정 기간 동안 보관하고 있어 과거의 데이터부터 현재까지의 연속된 데이터를 그래프로 사용자 편의에 좋게 그려낼 수 있으며 이상 증후 및 패턴을 분석하여 DB 관리에 있어 모니터링이 가능하다.
    • Statspack의 경우에도 stats$* Table들을 활용하여 많은 정보를 추출 할 수 있다.

       

         

  2. CPU & IO Wait Time, Load 등

- 기본적인 CPU, IO 사용량, Load와 같은 부하 정도를 아래 테이블(DBA_HIST_OSSTAT)을 통하여 측정할 수 있으며 DBA_HIST_SNAPSHOT 테이블의 경우에 해당 시점과 항상 Join하기 때문에 구조와 데이터를 잘 파악해두면 좋다.

   

   

  3.Buffer Busy waits, latch free 등

- Buffer Busy Waits, latch Free와 같은 성능적인 지표(DBA_HIST_SYSTEM_EVENT)에 대하여도 추출할 수 있으며 이슈가 되는 시점을 분석하여 집중적으로 Tuning을 진행할 수 있으며 대처에 대한 부분을 강구할 수 도 있다.

   

   

  4.Top 5 Wait Event

- AWR Report에 추출되는 Top5 Wait Events(DBA_HIST_SYS_TIME_MODEL)를 일자 별로 연결하여 봄으로써 빈번하게 발생되는 Event와 주요 이슈에 대하여 즉각적으로 확인하여 볼 수 있다.

   

  5. SQL 분석

- 기존의 SQL분석 시에 v$sql, v$sqlarea, v$sqlplan과 같은 휘발성 데이터를 이용하다 보니 폭넓은 SQL수집이 어려웠지만 AWR을 구성하는 테이블을 활용한다면 보관 주기 동안에 수집된 SQL문을 모두 확인하여 분석할 수 있다.


블로그 이미지

운명을바꾸는자

IT와 함께 살아가는 삶

,


Migration(데이터이관) EXP/IMP/Datapump 활용

   

  1. Migration EXP/IMP/Datapump 방법론

 

구분

장점

단점

비고

Exp/Imp

데이터베이스의 전부 또는 일부 마이그레이션

데이터 압축으로 마이그레이션 가능

오라클을 다른 플랫폼이나 운영체제에 마이그레이션하는 이용할 있음

업그레이드에 이용할 수 있음

압축하지 않으면 속도가 매우 느림

대량의 디스크 공간 요구

  

Named-Pipe Multi-thread

Exp/Imp

Migration 성능이 빠름(exp/imp10배 이상)

CTAS & DB Link와 다르게 Table 단위로 Manual하게 Script를 생성할 필요가 없음

Table별로 Migration Script를 생성해야 함

  

TTS

(Transportable

Tablespace)

이기종간 Data File 이 호환이 됨

Down-Time 을 최소화 할 수 있고 가장 빠른 Migration 방법

Raw-device, ASM, File-System 등 모든 File 에서 적용 가능함

양쪽 DB가 모두 10g 이상이어야 함.

10g이상

Datapump

EXP와 비교해서 20배 이상 정도 빠름

시간 예측 가능

일시 정비 & 이어 받기 가능

병렬 처리 가능

10g 이상 사용 가능

Exp와 호환 안됨

10g이상

   

  2. Migration Exp/Imp/Datapump 구성도

     1) Export, Import, Datapump

  • 기본 exp, imp로 진행 할 경우에 EXPORT-> 파일 전송 -> IMPORT -> 검증 진행
  • Datapump로 진행할 경우에 기존의 Exp/Imp와 동일한 방법과 Network Link를 통하여 바로 데이터 이관도 가능하다.

   

     2) Named-Pipe Multi-thread Exp/Imp

  • DB 버전이 낮은데 빠른 시간안에 데이터이관을 하고자 할 경우에 자주 사용되며 EXPORT와 동시에 IMPORT를 수행하여 데이터이관을 한다.

 

     3) TTS(Transportable Tablespace)

  • Datapump의 활용으로 transport_tablespaces 옵션을 통하여 TTS가 가능하며 동일 장비 및 이기종에 대한 부분도 Rman을 통하여 변환하여 데이터 이관이 가능하다.
  • Datapump TTS -> DataFile 변환 -> 이관 -> Import TTS 진행


블로그 이미지

운명을바꾸는자

IT와 함께 살아가는 삶

,

Oracle Backup & Recovery의 종류

   

 1. DB Backup 종류

구분

Backup Type

Archive log 상태

DB 상태

비 고

EXPORT

Backup

datafile, user, table

별로 Backup 가능

Archive log mode

OR Noarchive log mode

와는 무관

DB open 상태

논리적 Backup

HOT Backup

(Archive log

backup)

Full Backup,

Partial Backup 둘 다 가능

Archive log mode

설정 되어 있어야 함 .

DB open 상태

물리적 Backup

COLD

Backup

Full Backup,

Partial Backup 둘 다 가능

Archive log mode

OR Noarchive log mode 와는 무관

DB Shutdown

상태

물리적 Backup

RMAN

Data File, Control File, init Parameter file, Archive Redo Log Flile [Auto Backup]

Archive log mode

OR Noarchive log mode 백업 대상에 따라 다름

DB mount/open 상태

물리적 Backup

기타 정책

-Oracle golden gate / Active data Guard / Flashback

   

 2. DB Backup에 대한 기본 정책

 

Backup 정책

   

복합 백업 정책(DR)

   

   

 3. HA(High Availability)

- 중단 없는 서비스를 하기 위하여 HA구성의 다양한 정책을 세워 구성하고 있다.

   

HW적 HA구성 & Oracle RAC 기반의 자동 Failover

   

Oracle Golden Gate & Oracle Data Guard

   

   

4.Recovery 종류

구분

Recovery 방법

Recovery 범위

DB 상태

비 고

IMPORT

datafile, user, table 별로 Import를 통하여 Recovery가능

Table 단위, Object 단위 에서부터 전체 DATA 복구 가능

(백업이 수행된 시점)

DB open 상태

논리적 Recovery

HOT Backup

Recovery

(Archive log backup)

Full Backup, Partial Backup에 따른 Recovery 가능

Data file, Tablespace 단위 복구 가능

DB Shutdown / open 상태

물리적 Recovery

COLD Backup

Recovery

Full Backup, Partial Backup에 따른 Recovery가능

Data File, Control File, Redo log File, Archive log File

DB Shutdown

물리적 Recovery

RMAN

Recovery

Data File, Control File, init Parameter file, Archive Redo Log Flile Backup에 따른 Recovery 가능

Data file, Tablespace 단위 복구 가능

DB mount/open 상태

물리적 Recovery

 


블로그 이미지

운명을바꾸는자

IT와 함께 살아가는 삶

,


DBMS_CRYPTO Package를 이용한 단방향 암호화

   

  • 단방향 암호화란?
    • 고객의 Password와 같이 특정 컬럼에 암호화(ENCRYPTION)하며, 복호화(DESCRIPTION)이 필요 없는 단방향성 암호화 기법이다.
    • 고객의 Password는 암호화만 되며, 고객이 입력한 Password는 암호화 루틴을 거쳐 암호화된 값과 일치 여부를 판별한다. 복호화 과정은 필요 없으며, 있을 필요도 없다.
    • 고객의 Password의 분실 시 복호화 해서 알려주는 것이 아니라 RESET으로 임의의 초기값으로 설정하여 통보한다.

         

  • 단방향 암호화를 위해서는
    • Encryption의 Function은 볼 수 없어야 합니다. ==> wrap으로 처리
    • MASTER KEY는 보안담당자만이 알고 있거나, 한번 설정으로 알 필요가 없어야 한다.
    • 해당 특정 Application(AP서버에 있는 Application만)만 암/복호화를 할 수 있어야 한다. ==> Data Vault이용 (Option)
    • Password를 잊었을 경우는 DBMS_RANDOM을 이용하여 초기화 한 후 고객에게 초기화 Password를 알려 준다.

       

       DBMS_CRYPTO를 위한 암호화 Function

   

해당 Function Scriptwrap를 이용하여 Wrapping

   

Wrapping 된 단방향 암호화 Function – 암호화 로직 Master Key를 알 수 없다.

   

Wrapping 된 단방향 암호화 Function – 암호화 로직 Master Key를 알 수 없다.

블로그 이미지

운명을바꾸는자

IT와 함께 살아가는 삶

,


Fine Grained Auditing의 활용

  • 사용자 및 오브젝트의 액세스 패턴 에 관한 Auditing 이외에 보다 정교하고 세분화된 조건을 만족하기 위하여 Fine Grained Auditing 을 사용한다
  • Fine Grained Auditing을 사용하여 다음의 Policy를 구현할 수 있다.
    • 사전에 정의된 조건에 맞는 결과에 대해서만 Audit
    • 지정된 컬럼들 (Any or All) 이 사용된 경우에만 Audit
    • SQL 단위의 Audit ( Select 및 DML 포함)

         

  • 실행 계획

       ① 중요한 테이블과 컬럼의 목록을 작성한다.

② 정보 접근에 대한 감사 기준을 설정한다. (예: salary가 500 이하인 경우는 감사 조건에 포함시키지 않음).

③ 가능한 모든 기준을 감안하여 조건을 조합하며, 하나의 구문이 두 개 이상의 조건에 적용되지 않도록 한다.

④ 정의된 조건을 이용하여 FGA 정책을 구현한다. ( DBMS_FGA.ADD_POLICY)

⑤ FGA 정책을 활성화한다. (AUDIT_TRAIL = DB_EXTEND)

⑥ 일정 시간이 경과한 후 FGA 감사 로그 파일을 분석한다. (DBA_FGA_AUDIT_TRAIL)

⑦ 로그 파일의 삭제를 위한 스케줄을 설정하고 FGA 로그 테이블을 삭제한다.

   

  • 세부적인 Auditing조건을 쉽고 간단하게 Auditing 설정 예

       

       

  • TEST 작업 스크립트

exec dbms_fga.drop_policy(

object_schema => 'SCOTT',

object_name => 'EMP',

policy_name => 'CONA_ACCESS_FGA'

);

begin

dbms_fga.add_policy (

object_schema => 'SCOTT',

object_name => 'EMP',

policy_name => 'EMP_ACCESS_FGA',

audit_column => 'ENAME',

audit_condition => 'SYS_CONTEXT(''USERENV'',''IP_ADDRESS'') NOT IN (''127.0.0.1'',''10.103.90.1'',' ||

'''10.103.90.2'',''10.103.90.3'',''10.103.90.4''' ||

',''10.103.90.12'',''10.103.90.13'',''10.103.90.22'',''10.103.90.23''' ||

',''10.103.90.32'',''10.103.90.33'',''10.103.90.42'',''10.103.90.43'')' ,

statement_types => 'INSERT,UPDATE,DELETE,SELECT',

audit_trail => DBMS_FGA.DB + DBMS_FGA.EXTENDED );

end;

/

 

select ENAME from scott.emp;

select *from scott.emp;

select *from DBA_FGA_AUDIT_TRAIL;

   

블로그 이미지

운명을바꾸는자

IT와 함께 살아가는 삶

,


WRAP 유틸리티 활용

   

  • 내장 프로시저와 함수에 패스워드, 암호화 키와 같은 중요한 정보를 저장해 두는 경우가 있으며 해커는 코드 내에서 해당 부분을 쉽게 조회할 수 있다.
  • 이와 같은 위협을 차단하기 위한 최상의 대안은 wrap 유틸리티를 사용하는 것이다.

       

  • 실행 계획
    • 패스워드나 암호화 키 등이 포함되어 있는 procedure 나 함수를 wrap 유틸리티 혹은 PL/SQL (dbms_ddl.create_wrapped )를 이용하여 wrap 한다

       

       

  • TEST 작업 스크립트

SET SERVEROUTPUT ON SIZE UNLIMITED

DECLARE

l_source VARCHAR2(32767);

l_wrap VARCHAR2(32767);

BEGIN

l_source := 'CREATE OR REPLACE FUNCTION get_date_string RETURN VARCHAR2 AS' ||

'BEGIN ' ||

'RETURN TO_CHAR(SYSDATE, ''DD-MON-YYYY''); ' ||

'END get_date_string;';

l_wrap := SYS.DBMS_DDL.WRAP(ddl => l_source);

DBMS_OUTPUT.put_line(l_wrap);

END;

/

   

CREATE OR REPLACE FUNCTION get_date_string RETURN VARCHAR2 AS BEGIN RETURN TO_CHAR(SYSDATE, 'DD-MON-YYYY'); END get_date_string; /

   

wrap iname=get_date_string.sql oname=get_date_string_wrap.sql

   

블로그 이미지

운명을바꾸는자

IT와 함께 살아가는 삶

,


Corrupt Data Found During RMAN Backup Troubleshoot

   

1. 이슈사항

  • RMAN Full BACKUP을 수행 할 때, 특정 TBS에서 Block Corrupt 현상이 발견되는 상태
  • 운영 시에는 Block Corrupt현상이 없으며 RMAN FULL BACKUP이 수행되는 새벽시간에만 해당 에러가 발생되고 있는 상태
  • 현재 ASM Disk의 경우에 3중(HIGH)으로 Mirroring 되어 있는 상태

ORA-27061: waiting for async I/Os failed

Linux-x86_64 Error: 5: Input/output error

Additional information: -1

Additional information: 4194304

WARNING: Read Failed. group:1 disk:4 AU:626 offset:0 size:4194304

WARNING: failed to read mirror side 1 of virtual extent 1977 logical extent 0 of file 261 in group [1.103449180] from disk DATA_0004 allocation unit 626 reason error; if possible, will try another mirror side

NOTE: successfully read mirror side 2 of virtual extent 1977 logical extent 1 of file 261 in group [1.103449180] from disk HDD_E0_S01_975274559P1 allocation unit 4776

Tue Apr 28 03:10:41 2015

Hex dump of (file 4, block 1028608) in trace file /u01/app/oracle/diag/rdbms/SID/SID1/trace/SID1_ora_21436.trc

Corrupt block relative dba: 0x010fb200 (file 4, block 1028608)

Completely zero block found during backing up datafile

Trying mirror side HDD_E1_S06_1135637411P1.

Reread of blocknum=1028608, file=+DATA/datafile/undotbs2.261.794895089. found same corrupt data

Reread of blocknum=1028608, file=+DATA/datafile/undotbs2.261.794895089. found valid data

Hex dump of (file 4, block 1028609) in trace file /u01/app/oracle/diag/rdbms/SID/SID1/trace/SID_ora_21436.trc

Corrupt block relative dba: 0x010fb201 (file 4, block 1028609)

Completely zero block found during backing up datafile

….

..

Corrupt block relative dba: 0x00800201 (file 2, block 513)

Bad header found during backing up datafile

Data in bad block:

 type: 1 format: 2 rdba: 0x00003102

 last change scn: 0xb408.00000003 seq: 0x8 flg: 0x01

 spare1: 0x8 spare2: 0x1 spare3: 0x0

 consistency value in tail: 0x00000000

 check value in block header: 0x9

 block checksum disabled

ksfdrfms:Mirror Read file=+DATA/wind/datafile/sysaux.257.797856311 fob=0x3cb15a548 bufp=0x7f1f74501000 blkno=513 nbytes=8192

ksfdrfms: Read success from mirror side=1 logical extent number=0 disk=DATA_0002 path=/dev/asmdisks/oracle_ocr02p1

Mirror I/O done from ASM disk /dev/asmdisks/oracle_ocr02p1 

Trying mirror side DATA_0002.

Reread of blocknum=513, file=+DATA/wind/datafile/sysaux.257.797856311. found same corrupt data

ksfdrnms:Mirror Read file=+DATA/wind/datafile/sysaux.257.797856311 fob=0x3cb15a548 bufp=0x7f1f74501000 nbytes=8192

ksfdrnms: Read success from mirror side=2 logical extent number=1 disk=DATA_0003 path=/dev/asmdisks/oracle_recovery01p1

Mirror I/O done from ASM disk /dev/asmdisks/oracle_recovery01p1 

Reread of blocknum=513, file=+DATA/wind/datafile/sysaux.257.797856311. found valid data

   

2. 원인 분석

  • Corrupt Data Found During RMAN Backup (문서 ID 1610350.1) 오라클 공식 문서 참조

     


3. 분석 내용

  • RMAN Full Backup이 수행 될 때에 Corrupt Data를 확인하여 Alert log에 보여주는 것으로 판단되며 현재 3중으로

    Mirroring되어 있어 운영에는 큰 영향이 없는 상태(정상적인 Block을 확인하여 백업 진행)

  • 해당 되는 TBS를 확인하여 복구작업을 진행해야 함.

       

4. 해결

  • 공식 문서에 수행해야 하는 절차가 상세하게 나와있다.
  • Full Backup 후에 DB를 내리고 Mount 상태에서 복구를 진행하면 된다.

1) Take a full backup of the database and archivelogs

2) Shutdown the database and startup mount the database

3) Restore and recovery as follows:

   

RMAN > run

{

allocate channel c1 type disk;

allocate channel c2 type disk;

allocate channel c3 type disk;

allocate channel c4 type disk;

restore datafile < list all the affected files separated by commas >;

recover database;

sql 'alter database open';

}

   

Item 1 this will backup the database if the block is corrupt on the primary side RMAN will get the good block from the mirror. So once you have a good backup restoring the datafile will restore with good blocks. 

 


'1. IT Story > DB' 카테고리의 다른 글

Oracle Backup & Recovery의 종류  (0) 2015.09.15
DBMS_CRYPTO Package를 이용한 단방향 암호화  (0) 2015.09.08
Fine Grained Auditing의 활용  (0) 2015.09.08
WRAP Utility 활용  (0) 2015.09.08
DATABASE 암호화 기술들  (0) 2015.09.04
Oracle oradebug활용 Troubleshoot  (0) 2015.09.04
Oracle RAC 11gR2 주요 Command(명령어)  (0) 2015.09.04
Oracle Flashback  (0) 2015.09.04
블로그 이미지

운명을바꾸는자

IT와 함께 살아가는 삶

,


DATABASE 암호화 기술들

 

1. DB 암호화 기법

   

  

이름 

장점 

단점 

비고 

ECB모드

 전자부호표모드

(Electric Codebook mode)

* 간단

* 고속

* 병렬처리가능(암호화.복호화 양쪽)

* 평문속의 반복이 암호문에 반영된다.

* 암호문 블록의 삭제나 교체에 의한 평문의 조작이 가능

* 비트단위의 에러가 있는 암호문을 복호화하면 대응하는 블록이 에러가 된다.

* 재전송공격이 가능

사용해서는 안됨.

CBC모드

 암호블록 연쇄모드

(Cipher Block Chaining mode)

* 평문의 반복은 암호문에 반영되지 않는다.

* 병렬처리가능(복호화만)

* 임의의 암호문 블록을 복호화할 있다.

  

   

 권장

CFB모드

 암호피드백모드

(Cipher Feedback mode)

* 패딩이 필요 없다.

* 병렬처리가능(복호화만)

* 임의의 암호문 블록을 복호화할 있다.

  

현재는 사용 안함.

CTR모드를 사용하는 편이 나음.

 OFB모드

 출력피드백모드

(Output Feedback mode)

* 패딩이 필요 없다.

* 암호화/복호화의 사전 준비를 있다.

* 암호화와 복호화가 같은 구조를 하고 있다.

* 비트 단위의 에러가 있는 암호문을 복호화하면 평문의 대응하는 비트만 에러가 된다.

  

CTR모드를 사용하는 편이 나음.

CTR모드 

 카운터모드

(Counter mode)

* 패딩이 필요 없다.

* 암호화/복호화의 사전 준비를 있다.

* 암호화와 복호화가 같은 구조를 하고 있다.

* 비트 단위의 에러가 있는 암호문을 복호화하면 평문의 대응하는 비트만 에러가 된다.

* 병렬처리가능(암호화/복호화 양쪽)

  

권장

   

   

2. DB 암호화 알고리즘 종류

3. DB 암호화 제품의 유형

   

   

4. DB 암호화 제품의 비교

  • 추가적인 S/W의 변경 및 개선 사항이 있을 수 있음.

       

  

Oracle TDE (11g)

E사

P사

K사

암호화된 Index를 통한 색인검색 기능

지원

(Tablespace 암호화 시 Range 검색 가능)

지원

불가 (평문 Index 구축시는 지원) *

불가 (평문 Index 구축시는 지원)

무중단 암호화 기능 (리스너 재기동 및 Lock 없는 조건)

무중단

무중단

중단 (DB Restart)

중단(수초 ~ 수분 이내)

DB서버내의 키 기밀성

유지안됨.

(e-wallet 파일에 저장)

유지됨. (디스크에 저장되지 않고, 메모리로만 로딩 됨.)

유지(파일로 저장되지만 메모리로 로딩이 됨)

유지(키 서버를 통해 분리 구축)

국내 법정 알고리즘 지원 여부

불가

(ARIA, SEED 및 일방향 알고리즘 없음)

개인정보 용: ARIA, SEED

비밀번호 용: SHA-1, SHA-256/384/512 (일방향 알고리즘)

개인정보 용: SEED

비밀번호 용: SHA-1, SHA-256/384/512 (일방향 알고리즘)

개인정보 용: ARIA, SEED

비밀번호 용: SHA-1, SHA-256/384/512 (일방향 알고리즘

지원 알고리즘

AES, TDES

ARIA, SEED, AES, TDES, DES, SHA

SEED, ARIA, AES, TDES, SHA,, 3DE,

ARIA, SEED, AES, TDES, DES, SHA

공공기관 사용 가능 여부

부분 가능 (기존 Oracle DB 사용중인 국립병원이 TDE 암호화 사용)

가능

가능

가능

대용량 (파티션) 테이블 암호화 지원

지원

지원 (RANGE, LISH, HASH, SUB IOT)

지원

지원

접근통제 및 감사 기능

없음 (별도 설정 필요)

지원

지원

지원

권한 분리

불가(별도 설정 필요)

지원

지원

지원

HSM (FIPS-140 level2) 지원 여부

지원

지원

불가

불가

DB 재기동시 키 로딩 방법

파일 또는 테이블에서 읽어 로딩 (키 기밀성 유지 안됨)

RSA 방식으로 자동 로딩

(키 기밀성 유지)

파일 또는 테이블에서 읽어 로딩 (키 기밀성 유지 안됨)

키 서버에서 암호화 키 로딩

암호모듈검증기준 준수

준수 못함

준수

준수

준수

암호화 구성

TDE(Transparent Data Encryption)

API, Plug-in, Hybrid

API, Plug-in, Hybrid

API, Plug-in, Hybrid

 


블로그 이미지

운명을바꾸는자

IT와 함께 살아가는 삶

,