'2010/05'에 해당되는 글 3건

  1. 2010.05.27 Partition Exchange의 함정 (13)
  2. 2010.05.20 튜닝 프로젝트 시 이슈 극복 사례 (15)
  3. 2010.05.07 PL/SQL-면접문제 (8)

Partition Exchange(이하 PE)는 특정 파티션과 다른 테이블의 데이터를 바꿔 치기 하는 기능이다. 많은 사람들이 PE를 실행 할 때 성능향상을 위하여 Without Validation 옵션을 자주 사용한다. 이 옵션은 ConstraintValidation Check를 하지 않기 때문에 성능이 향상된다. 그렇지만 조건에 맞지 않는 값이 파티션에 들어갈 수 있다는 단점도 있다. 그래서 많은 사람들이 PE를 실행 하기 전에 NOT NULL 이나 FK등의 제약조건을 검사한 후에 PE를 실행한다.

 

하지만.......

그러한 검사를 하여도 여전히 오류는 존재할 수 있다는 걸 아는 사람은 많지 않다. 이 내용을 모른다면 데이터를 찾을 수 없는 심각한 상황을 맞게 된다. 2009 4월에 발생한 장애 상황을 보자.

 

박대리 : 현재 파티션이 2009 3월 까지 만들어져 있고 이후로 파티션을 Split 하지 않아서 20094월 데이터가 MAX 파티션에 들어가 있습니다. 파티션을 Split 하여 4월 파티션을 만들고 거기에 데이터를 옮기고 싶습니다. 어떻게 하면 되나요?

 

김과장 : 빈 테이블을 하나 만들고 MAX 파티션과 PE를 실행하면 됩니다. 그 후에 파티션을 Split 하여 4월 파티션을 만든 후에 다시 PE를 실행한다면 해결됩니다. 단 데이터의 건수가 많으므로 Without Validation 옵션을 주면 성능이 향상됩니다.

 

박대리 : 알겠습니다.

 

대화를 끝낸 A씨는 김과장이 알려준 대로 하였다. 작업은 밤 늦게 시작하여 정상적으로 끝났지만 문제는 다음날 아침에 발생하였다.

 

사용자 : 데이터 중에 한 건이 조회되지 않습니다. 어제는 조회가 되었는데 갑자기 오늘부터 안되네요.

 

박대리: 그럴리가요?

 

이상하지 않은가?
데이터를 두 번 바꿔 치기 했을 뿐 데이터를 조작(Update)하거나 삭제한적이 없다. 그런데 조회가 되질 않는다니.....

 

이제 위의 장애 상황을 직접 만들어보자.

 

--테스트 환경 Oracle 11.1.0.6


--파티션 테이블과 인덱스 그리고 Constraint 생성

CREATE TABLE TB_EX_TEST

( VAL1        NUMBER,

 TR_DT       CHAR(8)     NOT NULL )

PARTITION BY RANGE (TR_DT)

(

    PARTITION PT_R200902 VALUES LESS THAN ('20090301') , --2월 파티션

    PARTITION PT_R200903 VALUES LESS THAN ('20090401') , --3월 파티션

    PARTITION PT_RMAX VALUES LESS THAN (MAXVALUE)    --max 파티션

);

 

CREATE UNIQUE INDEX PK_EX_TEST ON TB_EX_TEST (VAL1, TR_DT ) LOCAL;

 

ALTER TABLE TB_EX_TEST

ADD CONSTRAINT PK_EX_TEST PRIMARY KEY (VAL1, TR_DT);

 

-- 데이터 입력

 

INSERT INTO TB_EX_TEST VALUES(1 ,'20090201'); --2월 데이터

INSERT INTO TB_EX_TEST VALUES(2 ,'20090202'); --2월 데이터

INSERT INTO TB_EX_TEST VALUES(3 ,'20090203'); --2월 데이터

...중간생략

INSERT INTO TB_EX_TEST VALUES(11,'20090301'); --3월 데이터

INSERT INTO TB_EX_TEST VALUES(12,'20090302'); --3월 데이터

INSERT INTO TB_EX_TEST VALUES(13,'20090303'); --3월 데이터

...중간생략           

INSERT INTO TB_EX_TEST VALUES(21,'20090401'); --4월 데이터

INSERT INTO TB_EX_TEST VALUES(22,'20090402'); --4월 데이터

INSERT INTO TB_EX_TEST VALUES(23,'20090403'); --4월 데이터

INSERT INTO TB_EX_TEST VALUES(24,'30090404');  --잘못된 데이터 입력.

 

COMMIT;

 

--PE를 실행하기 위한 Temp 테이블 생성

CREATE TABLE TMP_TB_EX_TEST

( VAL1        NUMBER,

 TR_DT       CHAR(8)     NOT NULL ) ;

 

CREATE UNIQUE INDEX PK_TMP_TB_EX_TEST ON TMP_TB_EX_TEST (VAL1, TR_DT);

 

ALTER TABLE TMP_TB_EX_TEST

ADD CONSTRAINT PK_TMP_TB_EX_TEST PRIMARY KEY (VAL1, TR_DT);

 

이제 모든 준비가 끝났으므로 PE를 실행해보자.

 

ALTER TABLE TB_EX_TEST EXCHANGE PARTITION

PT_RMAX  WITH TABLE TMP_TB_EX_TEST WITHOUT VALIDATION;

 

SELECT * FROM TMP_TB_EX_TEST;

 

VAL1       TR_DT  
---------- --------
        21 20090401
        22 20090402
        23 20090403
        24 30090404  -->원래는 '20090404' 이나 업무팀에서 잘못된 데이터를 넣은 건임.
 
 

4 rows selected

 

 

PE를 성공적으로 수행하여 잘못된 데이터를 포함한 모든 데이터가 TEMP 테이블로 들어갔다 . 이제 MAX 파티션을 Split 하여 4월 파티션을 만들고 그 파티션과 TEMP 테이블을 이용하여 PE를 실행하면 모든 작업이 완료된다.

 

--MAX 파티션을 Split 하여 4월달 파티션 생성

ALTER TABLE TB_EX_TEST SPLIT PARTITION 

PT_RMAX AT ('20090501') INTO (PARTITION PT_R200904, PARTITION PT_RMAX);

 

Table altered.

 

--TEMP 테이블의 데이터를 이용하여 4월 파티션에 PE 수행

ALTER TABLE TB_EX_TEST EXCHANGE PARTITION 

PT_R200904  WITH TABLE TMP_TB_EX_TEST WITHOUT VALIDATION;

 

Table altered.

 

-- 2009년 파티션의 인덱스를 REBUILD 해준다.

ALTER INDEX PK_EX_TEST REBUILD PARTITION PT_R200904;

 

Index altered.


 

이제 모든 작업이 끝났으므로 2009 4월 데이터를 조회해보자.

 

SELECT *

  FROM TB_EX_TEST

 WHERE TR_DT LIKE ‘200904%’;

 

VAL1       TR_DT  

---------- --------

        21 20090401

        22 20090402

        23 20090403

 

3 rows selected.

 

3건이 조회되었고 여기까지는 정상적이다. 2009 4월을 지정하였으므로 잘못된 데이터가 조회되지 않음은 당연한 것이다. 하지만 충격적이게도 잘못된 데이터를 where 조건에 직접 입력해도 전혀 조회되지 않는다. 아래 SQL의 결과를 보라.

 

SELECT *

  FROM TB_EX_TEST

 WHERE TR_DT='30090404';

 

no rows selected.

 

단 한 건도 나오지 않는다

이상하지 않은가? 데이터는 존재하는데 조회되지는 않는다니.... 버그인가?

전혀 아니다. Partition Pruning이라는 기능 때문이다. 2009 4월 보다 큰 값을 where 조건에 주게 되면 MAX 파티션을 가리키게 되므로 조회가 되지 않는 것이다. 다시 말하면 잘못된 데이터는 2009 4월 파티션에 존재하지만 WHERE 조건은 MAX 파티션을 지정하였으므로 데이터가 조회되지 않는 것이다.  

 

그럼 어떻게 조회해야 하나?

조회가 되어야 잘못된 값을 수정할 것이 아닌가? 이때는 아래처럼 FROM 절에서 특정 파티션을 지정하면 된다.


SELECT ROWID, VAL1, TR_DT
  FROM TB_EX_TEST PARTITION (PT_R200904);


 

ROWID                    VAL1 TR_DT  

------------------ ---------- --------

AAASWxAAEAAAYf+AAA         21 20090401

AAASWxAAEAAAYf+AAB         22 20090402

AAASWxAAEAAAYf+AAC         23 20090403

AAASWxAAEAAAYf+AAD         24 20090404

 

4 rows selected.

 

박대리는 MAX 파티션에 4월 데이터만 있을 것으로 예상하였고 3009 4월 데이터가 있을 줄은 꿈에도 생각하지 못한 것이다. 하지만 현실의 데이터는 언제나 지저분하게 마련이다.

 

그렇다면 잘못된 데이터를 어떻게 수정해야 하나?

UPDATE 시에 3009 4 4일을 WHERE절에 지정하면 데이터가 없으므로 수정에 실패한다. 따라서 ROWID를 찾아서 UPDATE 해야 한다.

UPDATE TB_EX_TEST
   SET TR_DT = '20090404'
 WHERE ROWID =  CHARTOROWID('AAASWxAAEAAAYf+AAD');

1 row updated.
COMMIT;
Commit complete.

  

 

결론

Partition Exchange 시에 Without Validation을 지정하게 되면 Constraint 뿐만 아니라 파티션의 경계도 무시된다. 따라서 Exchange 할 소스테이블의 파티션 key 값에 대한 검증을 하여 잘못된 값을 바로잡아야 한다. 그렇지 않으면 데이터가 사라진 것처럼 보일 것이다.

지금 주위에 있는 사람에게 질문해 보라. WHERE 절에 특정월을 지정하는 것과 FROM 절에 특정월의 파티션명을 지정하는 것의 결과가 다를 수 있는지 없는지를. 아마 많은 사람들이 결과는 다를 수 없다라고 이야기 할 것인데 정답은 다를 수 있다는 것이다. 여러분이 위에서 본 것처럼....



신고
Posted by extremedb

댓글을 달아 주세요

  1. 질문 2010.05.27 17:05 신고  댓글주소  수정/삭제  댓글쓰기

    split 바로 하면 되는데 temp table 만들어서 exchange까지 하는 이유가 어떻게 되나요?

  2. 질문 2010.05.27 17:29 신고  댓글주소  수정/삭제  댓글쓰기

    제시된 시나리오 대로라면 조금 게으른 회사네요 데이터가 10억 건 될 동안 방치...
    그리고 성능때문에 Without Validation 까지 쓰면서 여러 번 작업하고 나중에 잘못된 data 찾아 update하고 그럴거면 그냥 split바로 하는게 효율적으로 보입니다~

    • Favicon of http://scidb.tistory.com BlogIcon extremedb 2010.05.27 17:40 신고  댓글주소  수정/삭제

      그 회사 전체를 게으르다고 하는 건 옿지 않습니다. 10억건을 SPLIT.... 한번 해보시기 바랍니다. downtime 이 얼마나 될지.....
      그리고 10억건이 아니라 천만건이라 해도 다운타임을 최소화 해야되는 곳에서는 데이터 검증후 PE하는 것이 옿겠지요.

  3. 질문 2010.05.27 17:47 신고  댓글주소  수정/삭제  댓글쓰기

    네 죄송, 게으른 박대리와 김과장으로 수정
    시나리오에서는 잘못된 data가 있는걸 미리 알고있고 그것이 한건인 경우인데, 만약 잘못된 데이터가 있는지 몰랐고 그 양이 많다면 알려주신 방법이 훨씬 복잡해지지 않을까 합니다

  4. 왕만두 2010.05.28 18:20 신고  댓글주소  수정/삭제  댓글쓰기

    얼마전 이런 비슷한 경험을 했습니다.
    5월 31일 파티션을 안만들어서 5월 31일 데이터가 9월 1일 파티션에 들어간거죠.
    파티션 이름을 가지고 substring 해서 데이터를 이관하는데
    Total 건수가 달라서 찾느라 아주 애먹었습니다.

  5. 주의사항 2010.05.29 11:04 신고  댓글주소  수정/삭제  댓글쓰기

    문제의 본질은 'DBA 작업의 실수'이지 'Partition Exchange의 함정'에 있지 않습니다. Without Validation 옵션을 잘못 사용한 DBA의 과실일 뿐입니다.
    'WITHOUT VALIDATION' 옵션의 의미는 "사용자(대개 DBA)가 정합성 체크를 다 했으니 값 체크 없이 파티션을 변경하라"고 오라클에게 지시하는 것입니다. 그리고 MAXVALUE 파티션에는 입력될 파티션을 찾지 못한 그 어떤 값도 입력될 수 있습니다. 이 두 사실을 안다면 Without Validation 옵션과 함께 Partition Exchange 명령으로 다시 밀어 넣기 전에 값을 체크하는 것이 당연합니다. 그럼에도 TEMP(TMP_TB_EX_TEST) 테이블에 2009년 4월 데이터만 입력돼 있을 것이라고 "강하게 믿고" 위와 같이 작업했다면 이것은 명백한 DBA의 과실입니다.

    서두에 "그러한 검사를 하여도 여전히 오류는 존재할 수 있다는 걸 아는 사람은 많지 않다."라고 했기에 이 기능을 유용하게 사용하는 DBA로서 깜짝 놀라지 않을 수 없었습니다. 끝까지 읽어 봤는데, 테스트 시나리오를 살펴보면 어디에도 '2009년 4월' 파티션과 Exchange 해도 되는지를 검사하지 않았습니다.
    이 아티클 제목으로는 "Without Validation 옵션 사용 시 주의사항" 정도가 적당한 거 같습니다. 제목이 무시무시할 뿐만 아니라, 결론 마지막 문단에도 오해의 소지가 있습니다. 파티션 기능은 불안하니 쓰지 말라는 건 아니실 거라고 생각합니다.
    놀란 가슴을 쓸어 담으며, 몇자 적어 봅니다.

  6. 눈팅독자 2010.05.30 05:31 신고  댓글주소  수정/삭제  댓글쓰기

    오호~
    WITHOUT VALIDATION 옵션을 쓰면 Constraint 뿐만 아니라 파티션의 경계도 무시되네여.
    함정에 빠지지 안으려면 익스체인지 하기전에 파티션 키값을 체크해야 되네여. 몰랐습니다. 거기에 플러스로 이미 함정에 빠진 사람들을 위하여 문제해결의 방법까지.
    고맙습니다.

처음에 이 글을 블로그에 올릴지 말지 고민을 많이 하였다. 왜냐하면 튜닝이나 모델링의 기술적인 문제가 아니고 튜닝 프로젝트 시 이슈의 해결 과정이기 때문이다. 하지만 의외로 이런 사례를 알고 싶어하는 사람이 많이 있을 것으로 생각한다. 오래된 자료이긴 하지만.....

 

이 글을 보기 전 고려사항

이 글은 튜닝 프로젝트 시 발생한 문제이다. 개인이 급한 불을 끄기 위해 소방수로 들어가서 튜닝을 하는 것과 튜닝프로젝트를 하는 것은 전혀 다르다. 이점을 알고 글을 보기 바란다. 또한 튜닝 프로젝트마다 이슈는 다를 수도 있고 아래의 이슈가 전혀 문제가 되지 않고 쉽게 해결되는 경우도 있다. 아래의 이슈들은 철저히 필자의 관점임을 밝혀둔다. 이슈는 다음과 같다.   

 

1. 뱅킹 시스템 RDBMS 경험자 전무(AS-IS Network DB)

2. DBMS 설치후 성능관련 파라미터 튜닝이슈

3. 업무변경 시 SQL튜닝 반영의 문제

4. CPU 사용율 60% 미만에서 초당 4700 TPS 를 확보하라

 

이제 각각의 이슈 사항을 자세히 알아보기 위해 타임머신을 타고 그때 그 시각으로 돌아가 보자.

그림을 클릭하면 크게 볼수 있다.
 

사용자 삽입 이미지

1. 뱅킹 시스템 RDBMS 경험자 전무(AS-IS Network DB) 상황:

AS-IS DB Network DB 이므로 RDBMS 경험이 없음.

RDBMS 를 사용하는 다른시스템 및 Legacy 시스템의 DBA 및 개발자들은 기존 시스템의 유지보수 관계로 차세대 뱅킹 프로젝트에 참여하지 못함.

외부업체의 개발자의 경우 상대적으로 RDBMS 에서 개발경험이 많으나 시스템 OPEN 직후부터의 유지보수는 은행직원들이 수행함으로 개발 시 직원의 적극적인 참여가 필수적으로 요구되는 상황임.

과연 시스템을 제대로 개발할 수 있을 것인가에 관한 의구심이 증폭됨.

 



사용자 삽입 이미지
2. DBMS 설치 후 성능관련 파라미터 튜닝이슈 상황:

개발 DB 가 설치된 지 한달 이 지났지만 성능관련 파라미터의 세팅을 완료하지 못함.

지연된 가장 큰 이유는 일반적인 가이드는 존재하지만 그 사이트에 맞는 정확한 파라미터값은 어디에도 존재하지 않음.

DBMS 밴더사 조차 초기값을 제시하지 못함. 개발이 진행되고 있는 상황에서 계속 지연될 경우 개발후기에는 실행계획이 대폭 바뀔 수 있으므로 빠른 시일 내에 최적의 성능관련 파라미터의 세팅이 필요함.

잘못되었을 경우 전체시스템에 악영향을 끼치므로 책임이 막중하여 DBMS 밴더사, DBA, 인프라팀 누구도 나서지 못함.

 



사용자 삽입 이미지
3. 업무변경 시 SQL튜닝 반영시 문제의 상황:

개발자가 작성한 SQL DA 팀에서 품질점검 및 튜닝을 수행할 경우 SQL을 수정해야만 하는 경우가 발생한다. 그런 다음 튜닝 된 SQL 은 개발자에게 전달되어 SQL 이 수정되게 된다. 이때 개발자가 수정을 잘못하여 SQL 의 결과가 틀릴 수 있다.

 

또 하나의 경우는 DA 팀에서 원본 SQL 을 튜닝하고 개발자에게 전달하는데 이틀이 걸렸다. 하지만 그 이틀 사이에 업무가 수정되어 원본 SQL 이 수정되는 경우가 있다.  하지만 DA 팀에서는 업무가 바뀐 것을 알지 못하므로 무조건 개발자에게 수정을 요청하는데 이때 해당 개발자가 업무가 바뀐 것을 확인하지 않고 DA 팀에서 수정한 SQL 로 바꿔버리는 경우가 있다. 이 경우에도 SQL의 결과가 틀리게 된다.

 

이런 일이 자주 발생될 경우 SQL 의 결과가 틀린 건이 많아지며 개발자는 DA팀에게 SQL 튜닝신청을 꺼리게 된다. 실제로 4000 여개의 SQL 중에서 약 100 개정도가 답이 틀리며 업무 팀에서는 앞으로 상황이 더욱 악화될 것으로 예상함. 

 

튜닝을 하면 값이 잘못 나온다는 소문이 돌기 시작하면서 DA 팀에서 SQL 을 튜닝 해도 개발자가 반영을 하지 않는 심각한 상황이 발생됨.

SQL 의 결과 값이 틀릴 경우 개발자는 SQL의 수정을 DA 팀에서 하였으므로 개발자 자신은 잘못이 없음을 강조함.

 



사용자 삽입 이미지
4. CPU 사용율 60% 미만에서 초당 4700 TPS 를 확보하라

상황:

성능목표 달성기준 : CPU소모량이 60% 미만에서 초당 4700 TPS 를 확보한다.

A은행의 초당 최대 TPS 2100 정도임을 감안할 때 이것은 매우 높은 목표임을 인식함.

이를 확보하려면 평균처리시간은 건당 0.12 초를 확보하여야 한다. 참고로 AS-IS 에서는 초당 최대 TPS 1800 이었음.

 

-OPEN 6개월 전 단위성능 테스트 :

   1) 건당 0.12 초가 목표였으나 평균 2.5초가 나왔음.

   2) DA 팀이 4월부터 품질점검 및 SQL 튜닝을 하였으므로 이것은 매우 실망스러운 결과임

   3) 단말로부터 수신한 전문의 해석과 로깅을 하고 본 서비스를 Forward 시키는 서비스는 모든 거래 시작 시 사용하는 아주 중요한 서비스이므로 집중 튜닝을 실시함(이 서비스에서 사용하는 테이블에 파티션 정책반영, 불필요한 인덱스 제거, 업무팀의 주요거래테이블도 파티션 정책 반영)

 

-OPEN 4개월 전 1차 통합 성능 테스트:

  1)성능이 초당 2000 TPS 정도밖에 나오지 않고 CPU 사용율도 매우높음.

  2)모든거래에서 사용하는 고객,상품,공통쪽 SQL 에 대하여 집중 튜닝 실시

 

-OPEN 3개월 전 2차 통합 성능 테스트:

  1)목표 달성율이 64% 에 그침으로써 OPEN3달밖에 남지 않은 상황이었으므로 매우 급박한 상황이었음.

  2)성능튜닝은 DB 튜닝만으로는 해결하기 어려워 OS 의 패치적용, OS 의 커널 파라미터 튜닝, 개발 프레임워크의 성정파일 수정등을 통하여 1차 실거래 테스트에 대비함.

  3)지속적인 튜닝에도 불구하고 전체적인 Apllication 의 성능이 나오지 않는 원인에 대한 규명이 필요해짐.

여기까지가 4가지 문제의 이슈들을 요약한것이다.
글이 길어지므로 문의의 해결과정은 아래의 파일을 참조하기 바란다.
단순히 슬라이드만 보지말고 Note의 내용을 같이 보야야 이해가 빠를것이다.


튜닝시_이슈극복_사례.ppt

튜닝시_이슈극복_사례



PS
이것들 외에 여러분이 격었던 이슈들 있었다면 필자에게도 공유해 주기 바란다.
공유할 수록 세상은 살기 편해지지 않을까?

저작자 표시 비영리 동일 조건 변경 허락
신고
Posted by extremedb

댓글을 달아 주세요

  1. hyun 2010.05.20 14:16 신고  댓글주소  수정/삭제  댓글쓰기

    생각을 하게 만드는 글이군요..
    좋은 글 감사합니다.

    값이 잘못나오는 경우는 명확하지만,
    튜닝을 했는데도, 개발자가 적용을 잘못하는 바람에 별로 개선되지 못하는 경우도 많이 봤습니다.

    개인적으로는,
    튜닝을 해서 개발팀에게 전달이 되면 개발자는 무조건 적용을 하는 것 보다는,
    왜 이렇게 튜닝이 되었는지, 본인이 구현한 sql과 무엇이 어떻게 다른지 이해를 하고 적용을 한다면 결과가 잘못되거나,
    튜너의 생각을 잘못반영하여 성능개선이 되지 않는 일은 없을꺼라 생각됩니다.

    • Favicon of http://scidb.tistory.com BlogIcon extremedb 2010.05.20 15:22 신고  댓글주소  수정/삭제

      이현석 책임님 오랜만 입니다.
      말씀하신것처럼 SQL을 받아서 튜닝의도를 파악 한다면
      성능개선 뿐 아니라 실력도 향상되겠네요. 우리가 원하는 것이죠.
      저번에 댓글이 너무 간단하다고 불평하셔서 좀 길게 적어봤습니다.^^

  2. 2010.05.21 04:48  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

    • Favicon of http://scidb.tistory.com BlogIcon extremedb 2010.05.24 09:07 신고  댓글주소  수정/삭제

      그렇네요.
      초당 TPS 라는 말은 중복된 거네요.
      TPS 자체가 초당 트랜잭션 수이니 초당 이라는 말은 필요없습니다.
      감사합니다.

  3. 타락천사 2010.05.25 10:03 신고  댓글주소  수정/삭제  댓글쓰기

    2번 사항까지 신경쓰는 DA / 튜너는 거의 못봤습니다.
    그냥 디폴트를 원하더군요...
    보통 소프트웨어 설치 후에 동종 업계를 참조해서
    버그나 추천 받는 파라미터는 검토해서 최소(NOT Default)한만 반영하게 되더군요.
    영향도가 큰 만큼 아무도 나서지 않더라구요...

    • Favicon of http://scidb.tistory.com BlogIcon extremedb 2010.05.25 10:55 신고  댓글주소  수정/삭제

      말씀하신대로 영향도가 크기 때문에 보통은 나서질 않습니다. 그래서 Default인 상태에서 Open하는 경우가 많이 있습니다. 위의 글도 그런 상황 이었습니다.

      감사합니다.

  4. 로또 2010.06.06 18:57 신고  댓글주소  수정/삭제  댓글쓰기

    2번, 3번은 의레히 있어왔던 일이고 별 문제가 없었는데
    왜 튜닝 프로젝에서만 갑자기 이슈가 되었을까요. ppt 에서도 특이한 해결책은 발견을 못했습니다.
    왜냐하면 대부분 상황에선 거의 문제가 안되는 이슈이고 당연한(??) 사항이기 때문이죠.

    2번 파라미터 관련 내용 :

    우선 설치후에 바로 최적화값을 찾겠다는 시도가 좀 이상합니다.
    실 운영에 가깝게 데이타도 그럴듯하게 쌓이고 애플리케이션도 돌아가서
    트래픽이 있는 상태에서 찾는다면 몰라도,
    달랑 DB 만 있는 상태에서는 뭘 수정할지 막막하기도 하고 한계가 있을건데요.

    또한 이론상은 성능관련 파라미터를 조정하면 물론 성능이 나아질수는 있겠지만
    수정한다는 시도 (수정값) 이 버그가 있는경우가 있어서
    플랫폼과 버전사이 교묘한 함수들의 지뢰밭을 전부 다 피해다녀야하는 리스크가 새롭게 발생하고,
    (이미 검증이된 디폴트가 세상에서 가장 안전한 값일수도)

    무사히 수정해도 드라마틱한 효과를 보기는 어렵고, 그 개선효과라는것이
    시시각각 바뀌는 시스템 트래픽의 오차범위내에 있다고 보여지는데,
    그래서 겨우겨우 찾는다고 한들 유저가 그 효과를 체감을 할수 있을지도 의문이고요.

    즉 찾는 과정도 매우 어렵지만, 찾는다고 한들 효과 보기도 어렵다는거죠.
    파라메터 몇개 바꿨더니 시스템이 확 빨라졌더라 이런거는 없다는겁니다.
    (개선효과를 구체적으로 수치화해서 제시하기도 어려울것임)
    그래서 대부분은 그냥 디폴트로 해도 큰 문제가 없으리라 보여지는데요.
    대부분의 문제는 SQL 이지 파라미터가 아니라는것이죠.

    파라미터가 이슈가 되는 경우는 좀 더 나은 성능찾기 상황이 아니라,
    특정버전에서 히든 파라미터와 버그가 결합되어 DB 가 사망하는 경우는 봤습니다.

    이때는 최적화 개념이 아니라 당장 죽고 사는 문제이기때문에
    누가 나서기를 기다리고 있는것이 아니고, 누군가에의해 곧바로 해결이됩니다.
    따라서 파라미터 자체가 이슈가 되어 장시간 늘어지는 경우는 못봤다는것입니다.


    3번 반영의 문제는 좀 어이없는 경우인데요.

    튜닝하는 사람이 튜닝후에 개발자가 받아봤을때 자신이 그 사이에 바뀌었는지를
    전혀 모른다는것은 버전관리가 안되었다는 뜻입니다.

    변경된것을 알고도 무시하고 반영했다는건 말이 안되고,
    변경되었는지 확인안했다는것도 말이 안되고. 어느경우든 어불성설입니다.

    튜닝 요청 제출하고 나서 소스가 변경되었다면, DBA 에게 알려줘야겠죠.
    하지만 이런 친절한 금자씨는 실제론 드물고 튜닝 다 끝난거 받아보고 나서 그때는 변경되었는데
    말 못해줘서 미안하다, DBA는 그말듣고 뒤집어진다 대충 이런 스토리로 흘러가게되죠.

    따라서 반영쪽은 개발쪽에서 개발자 본인 또는 PL급이 관리를 해줘야 하는데
    개발파트에서 당연히 관리가 되어야 하는 부분이 관리가 안되었다는뜻입니다.

    반대로, DBA (튜닝한사람) 가 꼭 해줘야 하는부분이 있는데,
    만약 튜닝과정에서 SQL 을 변경했을때는 원본과 결과값이 똑같다는것을
    튜닝한 사람이 직접 검증하고 나서 개발쪽에 넘겨주는것이 맞다고 생각합니다.(도의적으로도)

    원본과 비교 검증 책임을 DBA 가 안하고 개발자에게 알아서 하라고
    떠넘기는 경우를 봤는데 이건 심하게 말하면 무책임한 처사라고 보여집니다.

    수정을 했다면 검증까지 완벽히 해서 개발쪽에 넘겨주는것이 맞죠.
    대량 배치라면 검증 과정 자체가 또다른 튜닝기술이나
    DBA 권한이 필요할수도 있는것이기때문에.

    때로는 나는 너무나도 당연하다고 생각하지만 그것이 안되는경우가 있을순 있겠습니다.
    그 "당연하다"는 기준이 사람마다 약간씩 다를수도 있겠고 바빠서 깜빡할수도 있으니까요.
    하지만, 정규군이 아닌 특수병 (튜닝)에 추가비용을 쏟는 상황에서 이런 커뮤니케이션쪽의 문제를
    방치하는 PM 은 없으리라 보여집니다.

    • Favicon of http://scidb.tistory.com BlogIcon extremedb 2010.06.07 10:06 신고  댓글주소  수정/삭제

      글의 처음에 나오는 고려사항을 언급하였음에도 많은 분들이 2,3번이 왜 문제가 되는지 이해할 수 없다고 하시는 군요. 이해가 갑니다. 그래서 글을 올릴 지 말지 고민 하였습니다.

      로또님의 말씀을 요약하면 2번은 '조정해도 별 이득이 없으므로 괜한 고생을 하지 말라'
      3번은 '너무나 기본적인것이 이슈가 되다니 어이가 없다" 혹은 "그런사항을 방치하는 PM이나 PL은 있을 수 없기 때문에 이슈가 될 수 없다."
      등이 되겠네요. 그런데 설치후에 바로 최적화 하겠다는 내용은 어디서 발견하셨죠? 그런 내용은 없는것 같습니다.

      2번에 대해서 말씀드리겠습니다. DB 만 달랑있는 상태는 아니었습니다. 기본적인 테스트 데이터가 들어오고 APPLICATION이 테스트로 돌아가는 상태였습니다. 그리고 파라미터는 9i 시스템의 것을 기초로 하여 에서 10g에 적용을 해놓은 상태였습니다. 예를 들면 ALL_ROWS가 아닌 first_rows 로 되어 있었지요. 그리고 SESSION_CACHED_CURSOR 는 30 으로 매우 낮은 상태였습니다. 다른 파라미터도 많지만 여기서는 두가지만 언급하겠습니다. 문제는 9i에 익숙한 DBA들도 10g 로 갈때는 많은 것을 고려해야 한다는 것입니다. 아마 다 아시는 내용일 것입니다. 앞으로 10g-> 11g 도 마찬가지라고 생각합니다.

      3번에 대해서 말씀드리겠습니다.
      살다보면... 그런사람도 있고 저런 사람도 있습니다.
      만약 그런상황을 닥쳤을때 "좀 어이가 없다" 라는 반응을 보인다면 서로 싸움이 일어날 가능성이 큽니다. 즉 어이가 없다고 생각할 수 있지만 개발자에게 이야기 할때는 감정을 가라 않히고 당연한 것도 차분히 이야기 해주어야 합니다. 서로 신뢰를 주는것이 중요합니다.

      대규모 튜닝프로젝트에서는 3번 이슈가 자주 일어납니다. 예를 들면 SQL의 답이 틀렸는데 PM 이 '그 SQL을 작성한 사람을 불러오라' 고 했는데 해당 개발자는 DBA가 최종적으로 SQL을 튜닝(재작성) 하였으므로 DBA에게 출석을 요구하는 경우도 있었습니다. 그래서 DBA는 튜닝하기전의 SQL을 꼭 저장둔다고 하네요. DBA는 죄가 없다는 것을 증명하기 위해 증거를 남기는 경우인데 심한 경우죠.

      이 경우많은 수의 튜너들은 냉정한 대처 대신에 개발자에게 화를 내는것을 많이 보았습니다. 왜냐하면 너무나 당연한 것이므로 개발자를 어이없이(개념없이) 보기 때문입니다. 이때 튜닝 프로젝트를 처음하는 튜너가 이런 일이 발생할 수 있다고 알고 있다면 침착하게 대처 할 수 있겠지요.

      '알고 했으면 유죄 모르고 했으면 무죄' 라는 말이 있듯이 대규모 프로젝트를 처음하는 초급 개발자의 경우 대부분 무죄였습니다. 다른말로 하면 한번 이야기 했더니 바뀐 SQL은 반영하지 않는 것은 물론이고 미래에 바뀔 SQL도 튜닝 하지 말라고 DBA 에게 통보해 주더군요. ^^

      내공이 많은 분들은 "너무나 당연한거 아니냐?"라고 말씀 하실 수 있지만 이 글을 읽고 도움을 받는 사람이 단 한명이라도 있을 것이라고 생각하여 쓴 것 입니다. 다시말 하면 의외로 프로젝트 막바지의 소방수는 많이 있었지만 대규모 튜닝 프로젝트는 안해본 사람이들이 많았습니다.

  5. 로또 2010.06.08 06:46 신고  댓글주소  수정/삭제  댓글쓰기

    친절하신 답변에 먼저 감사드립니다.

    구체적으로 물어보시니, 오해를 풀기 위하여 추가 올립니다.(말꼬리 잡는것은 아닙니다)

    설치후에 바로 최적화 하겠다는 내용은 어디서 발견하셨죠? 라고 문의하신 부분.
    => "개발 DB 가 설치된 지 한달 이 지났지만 성능관련 파라미터의 세팅을 완료하지 못함."

    여기서 "설치된지 한달이 지났지만" 이라는 부분을 그렇게 이해했습니다.
    => 한달이 지나도록 못했다. => 처음부터 시도는 하고 있었다.
    이렇게 유추가 된것입니다.
    테스트 데이타나 appl 은 본문엔 없고 저의 답글로 최초 언급하신것이고요.

    난독증인지 설명이 부족한건지 모르겠네요. 전자일지도 ^^

    또한, 저의 글을 나름 요약을 하셨는데 둘다 잘못 짚으셨습니다.

    괸한 고생만하지 별 이득이 없다는것이 아니고 저의 진의는,
    즉 +10% 향상을 바라다가 버그에 빠지는 리스크가 있다는걸 말씀드리고 싶었습니다.

    이득이 아니라 리스크에요.
    님과 저는 보는 관점이 많이 다릅니다. (성능 위주 vs 안정성 위주)
    블로그 일부글은 히든 파라미터 조정하는것이 일부 있더군요. 글쎄요.

    DB는 안정성(정합성) > 성능 > 운영편리성 이렇게 생각하기때문에
    그 어떤 경우에라도 안정을 먼저 고려하고, 오라클을 쓰면서도 100% 믿지는 않습니다.
    오라클 자체도 소프트웨어에 지나지 않고 언젠가는 버그로 배신해서 내 뒤통수를 때릴 놈이기에.

    예를 들자면 index 관련 파라미터도 온라인용이면 디폴트를 수정해서 몇개 수정하는것이
    좋다는걸 어디선가 본적이 있는데 현장에 적용해보려고 하니 10g 는 버그가 있더군요.
    그런뜻입니다.

    이런것까지 버그 문서를 미리 전부 뒤져가면서 확인후 적용한다면 이부분도 역시 할말 없습니다.
    버그는 보통 문제 터진다음에 찾으니까요.

    하지만 저에게 하라고 한다면 그렇게는 당연히 안하고 10% 향상을 다른쪽으로 찾을겁니다.
    모든것은 결국 고객의 만족도라고 생각하고 그것엔 온오프적 많은점을 시사합니다.

    조금 확장하면 튜닝 불가상황을 디자인만 바꾸면 OK 가 됩니다.
    좀더 확장하면 전혀 다른것이 나옵니다.

    이것은 과연 튜닝이란것이 고객이냐 튜닝하는 사람 자신이냐
    누가 더 궁극적으로 만족해야 할까요.

    만족도라는것의 개념은 기술적으로 포장하거나 속이자는것은 물론 아닙니다.
    고객사측에서도 DBA 가 나와서 검증시키고 이해시키면 됩니다. 스스로의 양심도 있을것이고.


    3번 관련한것은 아주 소소하지만 중대한 커뮤니케이션 문제입니다.

    3번은 있을수 없다가 아니고,
    의사소통은 사람이 사는곳엔 어디서나 생기는 기본적인 문제이기때문에
    같이 풀어가면 된다는것이죠.

    죽마고우나 친한 사람끼리는 표정만 보면 압니까 ?
    처음 보는 사람은 그 속마음 아는데 얼마나 걸립니까.
    프로젝 험한 상황에서 마주친 사람끼리 상대방 마음을 얼마나 알겠습니까.

    사람간의 문제는 결국 디지털이 아니라 아날로그인것입니다.

    이런 문제는 혼자나 팀단위로 끌어안고 고민 안하고 PM 또는 이슈제기해서 같이 해결합니다.
    제 3자의 냉정한 관점과 리더십이 필요하기도하고,
    개발자는 눈앞의 개발과 디버깅이 중요하지 튜닝 이런거 신경 안쓰기때문이죠.

    나의 입장이 절대적으로 옳고, 중요하고, 반드시 그렇게 가야할것 같지만
    상대방 입장도 똑같습니다. 그래서 중재자가 필요합니다.

    튜닝전의 원본은 증거개념이 아니라 백업개념으로 당연히 남겨두는건줄 알았는데
    그게 아닌가보죠.
    원본을 덮어 쓰나요 ? 하긴 사람마다 습관이 다르니까요.

    대규모 프로젝 경험을 유난히도 강조하시는데,
    사실 커뮤니케이션 문제는 사람이 사는곳이면 대규모든 아니든 어디서나
    항상 발생될수 있는 문제입니다.
    쥐꼬리 만한 일을해도 옆자리 동료랑 말이 안통하는 문제가 생길수도 있는것이고요.

    결국 이런 소소한 사람간의 문제가 대규모이기때문에 더 큰것처럼,
    다른 문제처럼 보이는 착시현상일 뿐입니다.
    파라미터도 꼭 대규모 튜닝프로젝트여야만 문제가 된다는 논리도 좀 이상하게 들리네요.

    • Favicon of http://scidb.tistory.com BlogIcon extremedb 2010.06.08 09:28 신고  댓글주소  수정/삭제

      말씀하신대로 리스크는 항상 있습니다. 또한 소규모 프로젝트도 문제가 될 수 있지요. 생각하신대로 하시면 됩니다. 장문의 댓글 감사합니다.

    • 로또님 2010.06.08 19:07 신고  댓글주소  수정/삭제

      로또님의 글은 반대를 위한 반대가 아닌가요?
      최소한 저에게는 그렇게 보여지는 군요.

      3번에 대하여
      "의사소통은 사람이 사는곳엔 어디서나 생기는 기본적인 문제이기때문에
      같이 풀어가면 된다는것이죠." 라고 하셨는데 위에서 로또님은 그런 이야기를 하지도 않았습니다. 오히려 개발자와 소통해야 한다는것은 extremedba 님이 하셨구요.

      로또님이 이야기 하신것은 "너무나 당연한것이다. 그래서 이슈가 됬다는 것이 어이가 없다"는 것이 로또님이 하신말씀 맞는것 같습니다.

  6. 로또 2010.06.11 07:47 신고  댓글주소  수정/삭제  댓글쓰기

    새로운 글이 있네요.

    반대를 위한 반대인지 아닌지는 하늘이 내려보고있고 저도 양심이란것이 있습니다.

    전체적으로 무엇을 말하는지 진의를 보지 않고,

    세세한 문장 하나 하나 잡고 다 따진다면 참으로 피곤한 일입니다. .

    • 로또님의 글도 이슈 2010.06.20 23:35 신고  댓글주소  수정/삭제

      "전체적으로 무엇을 말하는지 진의를 보지 않고,
      세세한 문장 하나 하나 잡고 다 따진다면 참으로 피곤한 일입니다."

      라고 하셨는데 로또님의 글을 읽고 제가 요약을 해도 동규님의 요약과 다르지 않은데요? 다만 동규님의 요약에 리스크를 추가하면 더욱 완벽한 요약일 것입니다. 여러사람이 동규님과 비슷하게 요약한다면 그것은 말꼬리 잡는것이 아니라 윗분이 언급하신 반대를 위한 반대가 맞습니다. 의심이 가시면 옆의 분들에게 로또님의 글을 요약해보라고 해보세요. 어떻게 요약하는지. 전체적으로 로또님의 글이 그렇게 되어 있습니다. 본인의 글을 한번 읽어 보세요.

      2번 '조정해도 별 이득이 없으므로 괜한 고생을 하지 말라. 리스크만 커진다'
      3번 '너무나 기본적인것이 이슈가 되다니 어이가 없다" 혹은 "이슈가 될수 없다"

      이런 댓글은 블로그를 작성한 주인장이 기분 나쁘게 생각할 수 있다는것 입니다. 물론 아닐 수도 있습니다.

      이 블로그의 다른글에서 파라미터를 수정하는 이유는 그 파라미터가 어떤일을 하는지 보여주려고 하기 때문일것 같습니다. 토마스 카이트의 이펙티브 오라클 이란 책을 보면 성능관련 파라미터를 이리저리 수정해서 테스트 하지요. 또한 조나단 루이스의 책과 동규님의 책도 마찬가지 입니다.

      이런 사람들은 안정성을 고려하지 않는 것이 아니라 글을 성능관점에서 쓰기 때문입니다. 하지만 로또님의 말처럼 "성능 파라미터를 default가 아닌값으로 수정하라" 라고 느낄 수 는 있습니다. 하지만 그러한 유추에 의한 잘못된 결과(버그등)를 저자들에게 책임을 돌릴 수는 없을것입니다.

      동규님 글의 매력은 여러가지 유추가 가능하다는 것입니다. 왜냐하면 글을 읽고 사람마다 여러가지 다른 생각이 나올 수 있기 때문이지요. 제가 생각하는 동규님의 진의는

      "성능 파라미터는 벤더사와 협력하고 여러가지 조사를 통하여 파라미터의 초기값을 정하고 미세조정 단계를 거쳐 확정하는 단계가 있어야 한다"

      인것 같습니다. 다시말하면 파라미터의 값을 따지는 것이 아니라 성능파라미터의 확정 절차(프로세스)를 이야기 하는 것이 동규님의 진의 인것 같습니다. 이런글을 쓰는 분은 한국에 별로 없습니다. 제겐 도움이 되느데요? 미세조정 단계라...

  7. ExtraOdinary 2010.10.07 13:46 신고  댓글주소  수정/삭제  댓글쓰기

    안녕하세요 ^^ 이제 막 고객사에서 컨설팅 업무를 하고 있는 튜너 입니다.
    길지 않은 경력이지만 위에 언급하신 내용들이 와닿네요..ㅋ 특히 4번의 경우는 참 해결하기도 어렵고 어떻게 접근해야 할 지도 말 꺼내기가 쉽지 않은 경우가 많았습니다.
    아마 저같은 사람들을 위해 글을 올리신 것 같습니다. 앞으로 많은 도움이 되는 좋은 정리였던 것 같습니다.
    종종 여기와서 많은 걸 배우고 가다가 이글에는 왠지 댓글이 달고 싶더라구요...ㅋ
    앞으로도 부탁드리겠습니다!

    • Favicon of http://scidb.tistory.com BlogIcon extremedb 2010.10.07 14:59 신고  댓글주소  수정/삭제

      ExtraOdinar님 반갑습니다. 4번의 경우는 저도 고생을 하였습니다. 목표 수준이 워낙 높게 잡혀 있어서 DB 튜닝 만으로는 불가능 한 경우 였습니다. 이 글에 대해 좋게 생각해 주시니 고맙습니다.

작년에 회사에서 기술면접에 필요한 문제를 여러 개 만들었는데 그 중에 하나를 소개한다. PL/SQL의 예외처리에 관련된 것이고 개념문제이므로 응시자들이 어렵지 않게 풀 수 있을 거라 생각하였다. 하지만 결과는 예상 밖이었다.

 

오라클 내부구조, OWI, AWR, Query Transformation 등 어려운 개념은 맞추는 사람이 있는 반면 PL/SQL의 기본에 속하는 예외처리에 대해서는 아무도 정답을 맞추지 못했다. 정답에 근접한 사람도 아무도 없었다. 도대체 얼마나 어려운 문제이길래? 여러분도 아래의 문제를 풀어보기 바란다.

 

문제3)

1. Built In Exceptions

2. User-Defined Exceptions

3. RAISE_APPLICATION_ERROR  

4. EXCEPTION_INIT Pragma


위의 네 가지는 오라클 PL/SQL 상에서 예외처리방법을 나열한 것이다.
이 네 가지의 차이점을 설명하시오.

 

 

이 네 가지의 차이점을 정확히 알고 있는 사람은 아래의 파일을 다운받을 필요가 없다. 하지만 차이점을 정확히 설명할 수 없다면 이 기회에 정리하기 바란다. 4(8 페이지) 이므로 10분만에 볼 수 있을 것이다. 정답은 마지막 페이지에 있다.

 

모든 분야에는 기본이라고 불리는 것이 있다. 오라클의 세계에서도 예외는 아닌것 같다. 필자 또한 기본을 놓치지 않으려고 노력하는 사람중의 하나이다.


Oracle PLSQL - Exceptions.pdf

Oracle PL/SQL - Exceptions 정리

신고
Posted by extremedb

댓글을 달아 주세요

  1. 마늘장아찌 2010.05.07 16:04 신고  댓글주소  수정/삭제  댓글쓰기

    두루뭉실하게는 알고있었지만 막상 비교를 하려니 막막하면서 가슴이 답답한 이느낌 아,,,

    다시한번 Back to the Basic 하는 계기가 됬습니다.

    Logical Optimizer도 틈틈히 읽고는 있는데 꼼꼼히 보느라 진도가 느리네요
    이제 2장의 중간정도 보고있습니다.

    • Favicon of http://scidb.tistory.com BlogIcon extremedb 2010.05.07 16:46 신고  댓글주소  수정/삭제

      면접 응시자도 비슷한 말을 했다고 하네요.
      책은 이제 조금만 더 보시면 반을 보시는 거네요.
      어렵더라도 힘 네시기 바랍니다.

  2. 2010.05.09 23:10  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

  3. 마린일병 2010.05.17 17:31 신고  댓글주소  수정/삭제  댓글쓰기

    간간히 들어와서 눈팅하고 가는데 정말 탁월하시네요... 매번 스스로를 돌아보게 되네요...
    출간 축하드리구요, 곧 도전해보겠습니다... ^^

  4. Alvin 2010.06.17 16:03 신고  댓글주소  수정/삭제  댓글쓰기

    블로그 처음 와보았는데 많은 지식을 얻고 갑니다.

    즐찾해놧어여 ㅋㅋ

    글쓴이유는요...의견을 듣고 싶어서요...

    위의 Exception 4개가 제가 보기엔 아래의 3가지 측면에서

    내용이 서로 갈릴거 같아요.

    1. Exception의 정의.
    2. Exception의 발생.
    3. Exception의 사용.

    3가지 갈림의 논제를 1가지의 문제로 본다면, 응답자들은 많이들 헤깔리지 않을까요? ^^

    어디까지나 저의 생각이지만 extremedb님의 생각은 어떠신지요 ㅎㅎ;;

    • Favicon of http://scidb.tistory.com BlogIcon extremedb 2010.06.20 20:59 신고  댓글주소  수정/삭제

      좋은 지적입니다.
      실전에서는 "네 가지의 차이점을 설명하시오." 대신에 "pl-sql 블럭을 4 가지 형태로 각각 작성하시오" 로 되어 있기 때문에 별 문제가 없었습니다. 위의 글에서는 한번더 생각하도록 유도하기 위해 그런것 입니다.
      감사합니다.