PineTree/TRAVEL2010. 4. 26. 12:50
반응형

보너스 항공권 마일리지 공제표 (왕복기준)

구분 트래블 클래스(일반석) 비즈니스 클래스 퍼스트 클래스
국내선 10,000

한일/동북아 30,000 45,000 60,000
동남아 40,000 60,000 80,000
서남아 50,000 75,000 100,000
미주, 대양주 70,000 105,000 140,000
유럽 70,000 105,000 140,000
한국 경유 여정


일본 - 동북아 45,000 60,000 90,000
일본/동북아 - 동남아 55,000 70,000 100,000
일본/동북아 - 서남아 60,000 80,000 110,000
일본/동북아 - 미주,대양주 75,000 110,000 150,000
일본/동북아 - 유럽 75,000 110,000 150,000
동남아 - 유럽 85,000 125,000 170,000
동남아 - 서남아 70,000 105,000 140,000
동남아 - 미주/대양주 85,000 125,000 170,000
서남아 - 미주/대양주 95,000 140,000 190,000
대양주 - 미주 105,000 160,000 210,000
대양주 - 유럽 105,000 160,000 210,000

상황별 마일리지 공제

구분 노선 기간
2010년 국내선 1/1~1/3, 2/12~2/16, 7/16~8/22, 9/18~9/26, 12/30~12/31
국제선 - 미주지역에서 출발 시 : 5/15~6/30, 12/11~12/23
- 미주지역 이외 출발 시 : 1/1~1/15, 2/8~2/14, 7/17-8/18, 9/16~9/22, 12/27~12/31
2011년 국내선 1/1~1/2,2/1~2/7,2/26~3/1,5/5~5/10,6/4~6/6,7/16~8/28,9/10~9/14,10/1~10/3,12/30~12/31
국제선 - 미주지역에서 출발 시 : 5/14~6/30, 12/10~12/23
- 미주지역 이외 출발 시 : 1/1~1/20, 1/29~2/6, 7/25-8/26, 9/9~9/14, 12/24~12/31
반응형

'PineTree > TRAVEL' 카테고리의 다른 글

서울에서 가볼만한 곳 BEST 10  (0) 2010.06.02
아시아나 항공 구간별 마일리지 공제표  (0) 2007.04.02
Posted by [PineTree]
ORACLE/ADMIN2010. 4. 19. 10:45
반응형
EM Port 확인
  - $ORACLE_HOME\install\portlist.ini 파일을 열어보면 사용하는 port 정보를 볼수 있다.

=================vi portlist.ini==================
iSQL*Plus HTTP port number =5560
Enterprise Manager Console HTTP Port (orcl) = 1158
Enterprise Manager Agent Port (orcl) = 3938
Enterprise Manager Console HTTP Port (prod) = 5500
Enterprise Manager Agent Port (prod) = 1830
==================================================

원하는 Port로 변경을 원할시 
   - emca 란 명령어를 이용해서 port를 변경을 할 수 있다
   - emca -reconfig ports [파라미터] 값
   - emca -reconfig ports -DBCONTROL_HTTP_PORT 1740


=========================================================================================================
  1. 현재 사용중인 SID 값을 넣어준다
  2. em을 재시작을 한다
=========================================================================================================
 

  - emctl을 다시 시작해보면 변경된 포트를 확인할 수 있다




* emca 옵션 *

emca의 옵션은 emca -help로 확인 가능합니다.
예를 들면, 10.2.0.1 에서는 이하의 옵션이 준비되어 있습니다.


emca -help
/opt/ora10201/product/10201/bin/emca [조작] [모드] [데이타베이스타입] [플래그] [파라미터]

 

-h | --h | -help | --help: 이 헬프 메세지의 인쇄
-version: 버젼의 인쇄

 

-config dbcontrol db [-repos (create | recreate)] [-cluster] [-silent] [-backup] [파라미터]
: 데이타베이스에 사용하는 Database Control의 구성

 

-config centralAgent (db | asm) [-cluster] [-silent] [파라미터]
: 집중 에이전트 관리의 구성

 

-config all db [-repos (create | recreate)] [-cluster] [-silent] [-backup] [파라미터]
: Database Control 및 집중 에이전트 관리의 구성

 

-deconfig dbcontrol db [-repos drop] [-cluster] [-silent] [파라미터]
: Database Control의 구성 해제

 

-deconfig centralAgent (db | asm) [-cluster] [ -silent] [파라미터]
: 집중 에이전트 관리의 구성 해제

 

-deconfig all db [-repos drop] [-cluster] [-silent] [파라미터]
: Database Control와 집중 에이전트 관리의 구성 해제

 

-addInst (db | asm) [-silent] [파라미터]
: 신규 RAC 인스턴스에 사용하는 EM의 구성

 

-deleteInst (db | asm) [-silent] [파라미터]
: 지정한 RAC 인스턴스에 사용하는 EM의 구성 해제

 

-reconfig ports [-cluster] [파라미터]
: Database Control 포토의 명시적 재할당

 

-reconfig dbcontrol -cluster [-silent] [파라미터]
: RAC Database Control 디프로이먼트의 재구성

 

-displayConfig dbcontrol -cluster [-silent] [파라미터]
: RAC Database Control의 구성에 관한 정보를 표시

 

-upgrade (db | asm | db_asm) [-cluster] [-silent] [파라미터]
: 구버젼의 EM구성을 현행 버젼에 업그레이드

 

-restore (db | asm | db_asm) [-cluster] [-silent] [파라미터]
: 현행 버젼의 EM구성을 구버젼에 restore

 

파라미터 및 옵션 :
[파라미터]: [ -respFile fileName ] [ -paramName paramValue ]*
db: 데이타베이스(ASM를 사용하는 데이타베이스를 포함)에 대한 구성 조작의 실행
asm: ASM만의 인스턴스에 대한 구성 조작의 실행
db_asm: 데이타베이스와 ASM 인스턴스의 업그레이드/restore 조작을 실행
-repos create: 신규 Database Control 리포지터리(repository)의 작성
-repos drop: 현행의 Database Control 리포지터리(repository)의 삭제
-repos recreate: 현행의 Database Control 리포지터리(repository)의 삭제 및 신규 리포지
새의 재작성
-cluster: RAC 데이타베이스에 대한 구성 조작의 실행
-silent: 파라미터의 입력을 요구하지 않는 구성 조작의 실행
-backup: 데이타베이스의 자동 백업의 구성

 

싱글·인스턴스·데이타베이스의 파라미터
    HOST: 데이타베이스·호스트명 
    SID: 데이타베이스의 SID
    PORT: 리스너의 포토 번호 
    ORACLE_HOME: 데이타베이스의 ORACLE_HOME
    HOST_USER: 자동 백업의 호스트의 유저명 
    HOST_USER_PWD: 자동 백업의 호스트의 유저·패스워드 
    BACKUP_SCHEDULE: 자동 백업·스케줄(HH:MM) 
    EMAIL_ADDRESS: 통지용 메일주소 
    MAIL_SERVER_NAME: 통지용 송신 메일(SMTP) 서버 
    ASM_OH: ASM ORACLE_HOME
    ASM_SID: ASM SID
    ASM_PORT: ASM 포토 
    ASM_USER_ROLE: ASM 유저·롤 
    ASM_USER_NAME: ASM 유저명 
    ASM_USER_PWD: ASM 유저·패스워드 
    SRC_OH: 업그레이드 하는 데이타베이스의 ORACLE_HOME
    DBSNMP_PWD: DBSNMP 유저의 패스워드 
    SYSMAN_PWD: SYSMAN 유저의 패스워드 
    SYS_PWD: SYS 유저의 패스워드 
    DBCONTROL_HTTP_PORT: Database Control의 HTTP 포토 
    AGENT_PORT: EM에이전트·포토 
    RMI_PORT: Database Control의 RMI 포토 
    JMS_PORT: Database Control의 JMS 포토

 

클러스터·데이타베이스의 추가 파라미터 
    CLUSTER_NAME: 클러스터명 
    DB_UNIQUE_NAME: 유일 데이타베이스명 
    SERVICE_NAME: 서비스명 
    EM_NODE: Database Control의 노드명 
    EM_SID_LIST: 에이전트 SID 리스트[콤마 단락]

반응형
Posted by [PineTree]
ORACLE/SCRIPT2010. 4. 15. 20:24
반응형

col program for a20
col username for a10
col first_load_time  for a20
col module format a20
col sql_id format a16
col machine for a20;

 

 select /* ordered use_nl(a b) */ 
         b.sql_Id, substr(a.program,1,20) program, substr(b.module,1,20) module, a.machine,
         username, B.executions, buffer_gets, disk_reads,ROWS_PROCESSED,
         trunc(buffer_gets/DECODE(nvl(executions,0),0,1,executions) ) b_e,
         trunc((buffer_gets+disk_reads)/DECODE(nvl(executions,0),0,1,executions) ) b_d_e,
         trunc(buffer_gets/DECODE(nvl(ROWS_PROCESSED,0),0,1,ROWS_PROCESSED) ) b_r,
         first_load_time        
            from Gv$session a, Gv$sqlarea b
            where  a.status = 'ACTIVE'
             and  username not in ('SYS','SYSTEM')
             and a.sql_id=b.sql_id
             and a.inst_id = '1' and b.inst_id = a.inst_id
order by b_d_e;  


반응형
Posted by [PineTree]
ORACLE/RAC2010. 4. 14. 10:00
반응형

출 처: http://scidb.tistory.com/


지난번에 Range 파티션에서 maxvalue 진정한 의미 라 는 글에서 Multi-Column으로 Range 파 티션을 구성할 때 주의사항에 대하여 알아 보았다. 이 글을 쉽게 이해하려면 위의 글을 먼저 보기 바란다. 테스트용 스크립트도 위의 글에서 사용한 것을 그대로 사용한다.

 

RAC4 Node로 구성되어있는 환경에서 동일한 SQL이 모든 Instance에서 골고루 수행될 때 1 Instance 만 유독 느리다면 무엇을 의심해야 할까? 네트워크 등의 문제일 수 있지만 가장 먼저 조사해야 할 것은 gc_current_grant_busy 이벤트가 발생하느냐 이다.

테 스트 환경을 만들어 보자.

 

CREATE TABLE t (

  id NUMBER,

  d1 DATE,

  day_num VARCHAR2(2), 

  inst_id NUMBER(1),

  pad VARCHAR2(4000),

  CONSTRAINT t_pk PRIMARY KEY (id)

)

PARTITION BY RANGE (day_num,inst_id) (

  PARTITION pt_1_1 VALUES LESS THAN ('1', 2),

  PARTITION pt_1_2 VALUES LESS THAN ('1', 3),

  PARTITION pt_1_3 VALUES LESS THAN ('1', 4),

  PARTITION pt_1_4 VALUES LESS THAN ('1', 5),

  PARTITION pt_2_1 VALUES LESS THAN ('2', 2),

  PARTITION pt_2_2 VALUES LESS THAN ('2', 3),

PARTITION pt_2_3 VALUES LESS THAN ('2', 4),

PARTITION pt_2_3 VALUES LESS THAN ('2', 5),

  ...중간생략

  PARTITION pt_7_1 VALUES LESS THAN ('7', 2),

  PARTITION pt_7_2 VALUES LESS THAN ('7', 3),

  PARTITION pt_7_3 VALUES LESS THAN ('7', 4),

  PARTITION pt_7_4 VALUES LESS THAN ('7', 5)

);

 

Table created.

 

---> 여기서 이전 글에서 사용했던 Insert 문 과 dbms_stats.gather_table_stats 수행

 

 

상황 : 아래의 SQL 2개가 모든 Instance에서 동시에 여러 번 수행된다.

 

SELECT COUNT(*)

  FROM T

 WHERE DAY_NUM = '3';           --> 3번 파티션

 

UPDATE T

   SET pad = LPAD('A', 4000, 'B')

 WHERE DAY_NUM = '4'          --> 4번 파티션

   AND INST_ID = :V_INST_ID;      --> 현재 수행되고 있는 Instance 번 호 대입

 

이 상황에서 1 Instance Update문만 유독 느리게 수행된다. 아래는 개발자와 필자의 대화내용이다.

 

개발자 : Update문의 Bind 변수에 1번만 넣으면 느린가요?


필자    : 1 Instance에서 Update 하려면  다른 Instance에서 Exclusive Mode의 Lock 권한을 받아야 하기 때문으로 추측됩니다.


개발자 : 권한이라뇨?


필자    : SELECT 시에 DAY_NUM 4번에 해당하는 파티션을 5번 이상 Access 했 기 때문에 권한이 다른 INSTANCE로 넘어간 것 같습니다. 이 현상을 FDC(Fairness Down Convert) 라고 합니다. FDC가 발생한 후에 DAY_NUM 4번에 해당하는 첫번째 파티션(pt_4_1)의 해당 블록에 UPDATE문을 수행하려면 권한을 받는 작업(gc_current_grant_busy 이벤트)이 필요합니다.


개발자 : 그럴 리가요? Update 문은 DAY_NUM = '4' 조건이고 Select 문 은 DAY_NUM = '3' 조건이므로 서로 다른 파티션 입니다. 따라서 SELECT 문과 UPDATE문이 동일 파티션을 Access 할 이유가 없습니다.


필자   : SELECT 문이 실제로는 DAY_NUM = '4' 의 첫번째 파티션을 항상 Access 합니다. MAXVALUE를 지정하지 않았으므로 그런 것 입니다.


개발자 :  그렇군요. 어 쩐지 tracegc_current_grant_busy가 많이 보였습니다.

 

아래는 개발자가 제시한 Trace 내용 중 Wait Event 부분을 발췌한 것이다.

 

core1_ora_13638.trc

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

WAIT #11: nam='gc current grant busy' ela= 947 p1=28 p2=1672046 p3=33619969 obj#=12043270 tim=12372374088207

WAIT #11: nam='gc current grant busy' ela= 992 p1=29 p2=2310876 p3=33619969 obj#=12070599 tim=12372374089432

...중간생략

WAIT #11: nam='gc current grant busy' ela= 767 p1=28 p2=1673090 p3=33619969 obj#=12043272 tim=12372374096882

 


Fairness Down Convert란 무엇인가?
Exclusive mode의 lock이 Shared lock 모드로 Down Convert 된다는 뜻이다. 다른  Instance의 요청에 의해서 Exclusive mode의 lock 상태에서 블럭을 다른 INSTANCE로 전송하는 작업은 무거운 연산이므로 특정 횟수 이상 블럭을 요청할 경우 Shared lock 모드로 전환하겠다는 뜻이다.  FDC 발생 이후로는 블럭을 요청한 INSTANCE로는 블럭 전송이 불필요 하다. 따라서 성능이 향상된다.  하지만 반대로 원래의 Instance에서
그 블럭을 Update 하 려면 권한을 받아야만 하므로 성능이 느려지는 것이다.

FDC Control 할 수 있는 파라미터는 _FAIRNESS_THRESHOLD 이다. 이 파라미터는 Default 4 이다. 즉 특정 블록을 다른 Instance에서 5번 이상 Access 하는 경우 FDC가 발생하여 요청한 Instance로 권한이 넘어간다.

 

결론:

FDC 기능은 성능을 향상 시키기 위한 용도로 만들어 졌다. 하지만 위의 경우와 같이 오히려 느려지는 경우도 있다. Trade Off 특징이 잘 나타난다. 파티션의 특징을 잘 모르고 사용하였기 때문인데 해당 Select 문 뿐만 아니라 DML문까지 성능이 느려질 수 있으므로 주의해야 한다.
반응형
Posted by [PineTree]
PineTree/CAR2010. 4. 5. 19:17
반응형

자동차세금 이 자동체세금은 보통의 경우 일년에 두번을 내게 됩니다.
하지만, 자동차세금을 전반기, 후반기 각각 따로 내게 되면 자동차세금을 감면 받을 기회가 날아가 버리게 되는데요.
바로 자동차세금 1년분을 미리 납부하는 선납(연납)제도를 이용하게 되면 자동차세금의 10%를 할인 받을 수 있습니다.

제목에는 자동차세 연납으로 15%를 할인받자고 했는데 왜 10%일까 라고 의아애 하시는 분들도 계실텐데요.
그 비밀은 바로 승용차 요일제 참여로 추가적으로 자동차세 5%를 더 할인 받는 것입니다. 더 자세한 이야기는 뒤에 하도록 하겠습니다.

 


알고 계신분도 있고 알지만 잊어버린 분들도 있으실텐데요. 한푼이라도 아쉬운 때에 자동차세금 10%도 작지 않은 돈이 될 수 있습니다. 만약 자동차세금이 10만원이라면 자동차세 연납제도를 이용하면 10% 할인 받으면 9만원. 바로 만원을 할인 받을 수 있는 기회입니다.

이러한 자동차세 연납(선납이라고도 합니다.)을 위해서는 직접 자동차등록지 관할 지자체(시,군,구청)에 전화 또는 직접 방문해서 자동차세 연납(선납)고지서를 신청하면 됩니다.

 

 

자동차세금 연납(선납)신청을 하고 1월 16일 ~ 1월 31일 사이에 납부하면 됩니다.

하지만 전자정부라는 그럴싸한 시스템을 그나마 좀 갖추어 놓은 우리나라. 자동차세금 연납(선납)에 신청 및 납부 모두 인터넷으로 가능합니다.(전 따로 신청을 하지 않았는데 목록에 나와 있네요)

서울의 경우는 자동차세 연납(선납)을 etax 사이트(http://etax.seoul.go.kr)을 이용해서 신청 및 납부 하실 수 있습니다.
경기도나 기타 지방의 경우 자동차세 연납(선납)을  wetax 사이트(http://www.wetax.go.kr)을 이용해서 신청 및 납부 하실 수 있습니다.

또한 신용카드로도 납부가 가능한데요. 신용카드 납부의 경우 etax 사이트와 wetax 사이트가 서로 다를 수 있으므로 사이트에서 확인하셔야 합니다.

etax 사이트의 경우 우리카드/롯데카드/삼성카드/현대카드/신한카드/외환카드/BC카드/하나카드 를 통해 자동차세 연납  신용카드 납부가 가능합니다. (다만 카드 사용분의 경우 연말정산 때 신용카드공제에서는 제외됩니다)

wetax 사이트의 경우 신한카드/삼성카드/현대카드/롯데카드/BC카드 를 이용하여 자동차세 연납 가능합니다.

 


그리고 자동차세 연납(선납)을 통해 10% 할인 받고 추가적으로 자동차요일제(승용차요일제)에 참여하면 자동차세금 선납(연납) 외에 5%를 추가 할인해 주니 이번 기회에 자동차요일제(승용차요일제)도 함께 신청하시면 절세에 더 많은 도움이 될 듯 합니다. 자동차세 연납과 함께 승용차 요일제 참여로 5% 추가 할인 기회가 있는데요. 이 승용차 요일제의 경우 다른 지역자치단체도 해당되는지는 저도 확인해 보지 못했습니다.

한 푼이라도 아껴야죠! 자동차세 연납(선납)으로 한번 할인 받고 승용차요일제(자동차요일제)[http://no-driving.seoul.go.kr/index.jsp] 참여로 한번 더 할인 받고!

저도 신용카드로 자동차세 연납(선납) 할인 받고 승용차요일제 할인 받고 납부 완료했습니다.


반응형
Posted by [PineTree]
ORACLE/SQL2010. 4. 2. 16:58
반응형




이번달 퀴즈는 두가지 부정형 조인 NOT IN, NOT EXISTS 의 차이점을 설명하는것입니다.

문제를 명확히 하기 위해서 아래와 같은 상황을 고려하겠습니다.

테이블 : TEST1

     NO

Name

1

Lee

2

Kim

3

Park

<NULL>

Jang

<NULL>

<NULL>


테이블 : TEST2

NO

 

Name

 

1

Lee

2

Kim

3

Park

<NULL>

Jang

* <NULL>은 데이터가 NULL값인 경우입니다.


테스트 쿼리

1) NOT IN 의 경우

SELECT *
   FROM TEST1 A
  WHERE A.NO NOT IN (SELECT NO FROM TEST2)

2) NOT EXISTS 의 경우

SELECT *
   FROM TEST1 A
  WHERE NOT EXISTS (SELECT 1 FROM TEST2 B WHERE A.NO = B.NO)

위와 같은 상황에서 두 개의 테스트 쿼리를 실행하여 그 결과에 대해 왜 그렇게 나왔는지 설명하세요.



답안)

이번달 퀴즈의 문제는 NOT IN과 NOT EXISTS의 차이점이 무엇인가입니다.


1번, 2번의 경우에서 NO의 값 1,2,3은 모두 결과에 나오지 않습니다. 즉, TEST2에 속하지 않는것을 찾는것이므로 결과에 나오지 않게됩니다. 차이점은 NULL 값이 결과에 나오는가 아닌가에 있습니다.


NOT IN(1번)의 경우

where절의 조건이 맞는지 틀리는지를 찾는것입니다. 그런데 NULL은 조인에 참여하지 않기때문에 결과에서 빠집니다. 여기서 TEST1의 NULL값이 나오지 않은 이유는 IN 서브쿼리의 결과에 NULL유무에 영향을 받지 않습니다. 즉, TEST2의 NO컬럼에 NULL값이 없어도 TEST1의 NO컬럼의 NULL값은 결과에 나오지 않습니다.


NOT EXISTS(2번)의 경우

EXISTS는 서브쿼리가 TRUE인지 FALSE인지 체크하는 것이므로  NOT EXISTS는 서브쿼리가 FALSE이면 전체적으로 TRUE가 됩니다. 서브쿼리에서 TEST1과 TEST2의 조인시 NULL은 결과에서 빠지게 됩니다. 이것은 서브쿼리를 FALSE로 만들게 되고 전체적으로 TRUE가 되어 TEST1의 NULL값이 결과에 나오게 됩니다.


이번 퀴즈는 매우 쉬운것 같으나 자칫 잘못 생각할 수 있는 내용이기 때문에 퀴즈로 다루었습니다. 일반적으로 대용량을 처리할 때 성능상의 이유로 Hash Anti-Join, Merge Anti-Join으로 유도하기 위해 NOT EXISTS를 NOT IN으로 바꿔서 처리하기도 합니다. 이때 두 부정형 조인의 결과가 같다는 전제 조건이 있어야 합니다. 그러나 위에서와 같이 연결고리가 되는 컬럼의 값 중 NULL이 포함된 경우 결과가 다르다는것을 주의해야 합니다.



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



not in 과 not exists 차이점 / 부정형을 긍정으로 변경할때



일반적으로 대용량을 처리할때 성능상의 이유로 Not Exists로 되어 있는 것을


Not In으로 바꿔서 Hash나 Merge Anti Join으로 유도하는 경우가 있는데


이는 Not Exists와 Not In의 관계가 "="이 성립한다는 전제 조건에서 이루어 진다.


하지만 모든경우 Not Exists와 Not In의 관계가 "=" 성립하는지에 대한 의문에서


아래와 같이 테스트를 해보았습니다.


<결론>
   Not In 과 Not Exists는 다르다.
    + Not IN과 Not Exists의 차이점은 연결고리가 되는 컬럼의
      값중 null값을 처리하는 부분에서 차이가 난다.


<이유>
    + Not In 은 where 절의 조건이 만족하더라도
      연결고리 컬럼이 Null값을 가진 다면 결과에서 무조건 제외 된다.


    + Not Exists는 Not In과 달리 Null값을 가진 row들도 결과에 포함된다.


    + 간단히 생각해보면 in은 조건에 만족하는 row를 찾는 것이고
      exists는 exists이하 절이 true인지 아닌지를 체크하는 것이기 때문에
      연결고리 컬럼의 값이 null값을 가질때 null은 조인에 참여하지 못하기 때문에
      in은 조건에 만족하는 것을 찾을 수 없는 것이고
      exists는 false의 값을 return한다.
     
      따라서 연결고리 값이 null값을 가질때
      Not in은 조인 연산을 하지 않기 때문에 결과에서 제외되며
      Not Exists는 exists이하의 절이 false를 리턴하고 거기에 대한 Not이기 때문에
      결과적으로 true가 되어 결과에 포함된다.


<참고사항>


  1) 부정형을 긍정으로 변경할 때


    + Not In일 때는 상관 없지만 Not Exists일때는
      논리적으로 부정형을 긍정으로 변경 한 후 연결고리가 되는 컬럼이 null값 가질 경우에
      대해서 반드시 True가 되도록 처리해 줘야 된다.
    + 즉 null 값을 가지는 컬럼에 대해서도 결과에 포함 되도록 해야 된다.


  ex)
      SELECT :current_il,
             A.SNG_NO,
             A.SNG_SEQ,
             A.JI_HANDO,
             A.JI_HAN_BAL,
       FROM IRMS_SNG_MAS A
      WHERE A.WONJ_ST2 = '1'
        AND A.GAGIGONG_GB IN('2','3')
        AND NOT EXISTS(SELECT 'X'
                         FROM IRMS_SNG_MAS G
                        WHERE G.WONJ_ST2 = '1'
                          AND G.GAGIGONG_GB IN('2','3')
                          AND (G.MANGI_IL < :current_il AND NVL(G.SIL_BAL,0) = 0)
                          AND G.SNG_NO = A.SNG_NO
                          AND G.SNG_SEQ = A.SNG_SEQ)


   <부정형을 긍정형으로 변경>


     + MANGI_IL이 NULL값을 가질때 반드시 참이 되도록 해야 됨.
    
      SELECT :current_il,
             A.SNG_NO,
             A.SNG_SEQ,
             A.JI_HANDO,
             A.JI_HAN_BAL,
        FROM IRMS_SNG_MAS A
       WHERE A.WONJ_ST2 = '1'
         AND A.GAGIGONG_GB IN('2','3')
         AND NOT (NVL(A.MANGI_IL,'99991231') < :CURRENT_IL AND NVL(A.SIL_BAL,0) = 0)


<테스트 테이브>
TEST_AJ01
TEST_AJ02


<데이타>

TEST_AJ01
========================
NO        MARRY_DT
-------------------
1        20030405
2        20030405
3        20030405
<null>   <null>
<null>   20030408


TEST_AJ02
========================
NO        MARRY_DT
-------------------
1        20030405
2        20030405
3        20030405
<null>   20030408

# NULL값을 가진 컬럼의 값은 <null>이라고 표현하였음


<테스트 SQL문>
1)
    SELECT *
      FROM TEST_AJ01 A
     WHERE A.NO NOT IN (SELECT NO FROM TEST_AJ02)
  
   ==결과==  -- 0건
   No rows returned

2)
    SELECT *
      FROM TEST_AJ01 A
     WHERE NOT EXISTS (SELECT 'X' FROM TEST_AJ02 B WHERE A.NO = B.NO)

   ==결과==  -- 2건
   <null>    <null>
   <null>    20030408



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

TEST1 테이블의 데이터 중 TEST2에 속하지 않는 데이터만 가져오기 ( NOT IN, NOT EXISTS, JOIN, UNION 으로 해결 )

중복되지 않는 데이터만 가져와서 INSERT 하거나

중복되는 데이터만 가져와서 UPDATE 할 때 사용할 수도 있다.


CREATE TABLE TEST1 (
 IDX INTEGER,
 NAME VARCHAR(100)
)

CREATE TABLE TEST2 (
 IDX INTEGER,
 NAME VARCHAR(100)
)


INSERT INTO TEST1 VALUES (1, 'A')
INSERT INTO TEST1 VALUES (2, 'B')
INSERT INTO TEST1 VALUES (3, 'C')
INSERT INTO TEST1 VALUES (4, 'D')
INSERT INTO TEST1 VALUES (5, 'E')


INSERT INTO TEST2 VALUES (3, 'C')
INSERT INTO TEST2 VALUES (4, 'D')
INSERT INTO TEST2 VALUES (5, 'E')
INSERT INTO TEST2 VALUES (6, 'F')
INSERT INTO TEST2 VALUES (7, 'G')


SELECT * FROM TEST1
SELECT * FROM TEST2


-- NOT IN

SELECT *
  FROM TEST1
 WHERE IDX NOT IN (
SELECT IDX
  FROM TEST2 )


-- NOT EXISTS

SELECT *
  FROM TEST1 A
 WHERE NOT EXISTS (
SELECT *
  FROM TEST2 B
 WHERE A.IDX = B.IDX )


-- SYBASE JOIN
SELECT *
  FROM (
 SELECT A.*
   , B.IDX B_IDX
   FROM TEST1 A
      , TEST2 B
  WHERE A.IDX *= B.IDX
    ) A
   WHERE B_IDX IS NULL
 

-- ANSI JOIN

SELECT *
  FROM TEST1 A
  LEFT JOIN TEST2 B
    ON A.IDX = B.IDX
 WHERE B.IDX IS NULL
 

-- UNION ALL
SELECT A.IDX, A.NAME
  FROM (
  SELECT NAME
    , COUNT(*) CNT
    , COUNT(CASE WHEN GBN = 'A' THEN 1 END) A_CNT
    , IDX
    FROM (
    SELECT 'A' AS GBN
      , A.*
      FROM TEST1 A
    UNION ALL
    SELECT 'B'
      , B.*
      FROM TEST2 B
     ) A
   GROUP BY IDX, NAME
  ) A
 WHERE A.CNT < 2
   AND A_CNT = 1


출처 : http://blog.naver.com/tyboss?Redirect=Log&logNo=70051601411

반응형
Posted by [PineTree]
ORACLE/TroubleShooting2010. 4. 1. 15:10
반응형
문제 설명
Oracle은OPEN_CURSORS매개변수를 사용하여 세션이 동시에 취할 수 있는 최대 열린 커서 개수를 지정합니다. 최대 개수를 초과하면 Oracle은ORA-01000오류를 보고합니다. 이 오류가 WebLogic Server로 전송되면SQLException이 발생합니다.

java.sql.SQLException: ORA-01000: maximum open cursors exceeded


이 패턴은 WebLogic Server를 사용할 때 오류를 발생시키는 원인과 해결 방법에 대해 설명합니다.

문제 해결
다음 항목을 모두 수행해야 하는 것은 아닙니다. 어떤 경우에는 다음 중 일부만 수행하여도 해결할 수 있습니다.

항목 바로가기


진단 조회
다음 SQL 조회는ORA-01000문제를 진단하는 데 유용합니다. 이런 조회를 실행하려면 데이터베이스에 관리자로 로그인하거나 데이터베이스 관리자가 사용자에게v$뷰에서 SELECT 명령문을 실행할 수 있는 권한을 승인해야 합니다.

1. 데이터베이스의 OPEN_CURSORS 매개변수 값을 확인합니다.
Oracle 은OPEN_CURSORS초기 화 매개변수를init.ora에 사용하여 세션이 동시에 취할 수 있는 최대 커서 개수를 지정합니다. 디폴트값은 50이지만, WebLogic Server와 같은 시스템에는 너무 작습니다. 다음 조회를 사용하여 데이터베이스에서OPEN_CURSORS매개변수 값을 찾을 수 있습니다.
 
SQL> show parameter open_cursors;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
open_cursors                         integer     1000

 

OPEN_CURSORS값을 충분히 큰 값으로 설정하여 응용 프로그램에서 열린 커서가 부족하지 않도록 해야 합니다. 이 수는 응용 프로그램에 따라 다릅니다. 세션이OPEN_CURSORS에 지정된 커서 개수만큼 열지 않는 경우 이 값을 실제 필요한 값보다 크게 설정해도 오버헤드가 추가되지 않습니다.

2. 열린 커서의 수를 확인합니다.
아래 조회는 사용자 'SCOTT'가 각 세션에 대해 연 커서 개수를 내림차순으로 표시합니다.
 
SQL> select o.sid, osuser, machine, count(*) num_curs
  2  from v$open_cursor o, v$session s
  3  where user_name = 'SCOTT' and o.sid=s.sid
  4  group by o.sid, osuser, machine
  5 order by  num_curs desc;       SID OSUSER               MACHINE                                              NUM_CURS
---------- ---------------- ------------------------------------------------- ----------
       217                                m1                                                           1000
        96                                 m2                                                            10
       411                                m3                                                             10
        50                                test                                                              9


WebLogic Server에서 커넥션 풀을 사용할 때 커넥션을 커넥션 풀에서 가져온 경우 이 조회의user_name은 커넥션을 생성하는데 사용한user_name이 어야 합니다. 조회 결과는 시스템 이름도 출력합니다. 조회 결과를 통해 열린 커서의 개수가 큰SID와 WebLogic Server를 실행하는 시스템 이름을 식별할 수 있습니다.

v$open_cursordbms_sql.open_cursor()를 사용하여 연 동적 커서인PARSEDNOT CLOSED를 세션에 대해 추적할 수 있습니다. 구문 분석 하지 않은 열린 동적 커서는 추적하지 않습니다. 응용 프로그램에서 동적 커서의 사용은 흔하지 않습니다. 이 패턴은 동적 커서가 사용되지 않는 것으로 간주합니다.

3. 커서에 대해 실행 중인 SQL을 확인합니다.
위의 조회 결과에서 식별한 SID를 취하고 다음 조회를 실행합니다.

SQL> select q.sql_text
  2  from v$open_cursor o, v$sql q
  3  where q.hash_value=o.hash_value and o.sid = 217;

SQL_TEXT
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
select * from empdemo where empid='212'
select * from empdemo where empid='321'
select * from empdemo where empid='947'
select * from empdemo where empid='527'
...

 

결과는 커넥션 상에서 실행 중인 조회를 표시합니다. 이를 기준으로 열린 커서의 출처를 역추적할 수 있습니다.

페 이지 맨 위

일 반적인 원인과 문제 해결
다음 단계는 문제의 원인을 파악하고 가능한 해결 방법을 모색하는 절차입니다.

코드 연습
이 문제의 가장 일반적인 원인은 JDBC Object가 정상적으로 닫히지 않은 경우입니다. 모든 JDBC Object가 정상적으로 닫혔는지 확인하기 위해 응용 프로그램 코드에서 역추적하려면진 단 조회에 타사의 조회 결과를 사용합니다. 모든 JDBC Object가 정상적인 상태나 예외 조건에서 닫히도록 하려면finally블록에서 Connections, Statements 및 ResultSets 같은 JDBC Object를 명시적으로 닫는 것이 좋습니다. 다음은 일반적인 예제입니다.
Connection conn = null;
Statement stmt = null;
ResultSet rs = null;

try {
    conn = getConnection(); //Method getConnection will return a JDBC Connection
    stmt = conn.createStatement();
    rs = stmt.executeQuery("select * from empdemo");
    // do work
} catch (Exception e) {
    // handle any exceptions
} finally {
    try {
        if(rs != null)
            rs.close();
    } catch (SQLException rse) {}
    try {
        if(stmt != null)
            stmt.close();
    } catch (SQLException sse) {}
    try {
        if(conn != null)
            conn.close();
    } catch (SQLException cse) {}
}

 

JDBC Object를 버리는 코딩 습관을 피하십시오. 다음 연습은 각 루프 반복에서 새 Connection, Statement 및 ResultSet를 얻지만 각 반복에 대해 JDBC Object를 닫지는 않습니다. 그러므로 JDBC Object leak이 발생합니다.

Connection conn = null;
Statement stmt = null;
ResultSet rs = null;
String[] queries = new String[10];
//Define queries

try {
    for(int i = 0; i < 10; i++) {
        conn = getConnection();
        stmt = conn.createStatement();
        rs = stmt.executeQuery(queries[i]);
        // do work
    }
} catch (Exception e) {
    // handle any exceptions
} finally {
    try {
        if(rs != null) 
            rs.close();
    } catch (SQLException rse) {}
    try {
        if(stmt != null) 
            stmt.close();
    } catch (SQLException sse) {}
    try {
        if(conn != null) 
            conn.close();
    } catch (SQLException cse) {}
}


Connection을 닫을 때 Statement와 ResultSet를 닫아야 하지만 JDBC 사양에 따라 하나의 Connection Object에 여러 Statement를 작성한 경우에는 사용한 직후 Statement와 ResultSet를 명시적으로 닫는 것이 좋습니다. Statement와 ResultSet를 명시적으로 즉시 닫지 않으면 커서가 누적되어 Connection이 닫히기 전에 데이터베이스에 허용된 최대 개수를 초과할 수 있습니다. 예를 들어, 아래 코드 부분에서는finally블록에 서 Connection을 닫을 때 ResultSet와 Statement도 닫아야 합니다. 그러나 이 코드 부분은 하나의 Connection에 여러 Statement와 ResultSet를 생성합니다. 루프가 끝나기 전에 "maximum open cursors exceeded(열린 최대 커서 개수 초과)" 문제가 발생했을 수 있습니다.


Connection conn = null;

try{
    conn = getConnection();

    for(int i = 0; i < NUM_STMT; i++) {
        Statement stmt = null;
        ResultSet rs = null;
 
         stmt = conn.createStatement();
         rs = stmt.executeQuery(/*some query*/);
        //do work
    }
} catch(SQLException e) {
     // handle any exceptions
} finally {
    try{
        if(conn != null)
            conn.close();
    } catch(SQLException ignor) {}
}


페 이지 맨 위

명령문 캐시
성능 향상을 위해 WebLogic Server는 커넥션 풀을 사용할 때 prepared statements와 callable statements를 캐시하는 기능을 제공합니다. WebLogic Server가 prepared statements나 callable statements를 캐시할 때 많은 경우에 DBMS는 열린 각 명령문에 대해 커서를 유지합니다. 그러므로 명령문 캐시 기능은 "maximum open cursors exceeded(열린 최대 커서 개수 초과)" 문제의 원인이 될 수 있습니다. 명령문 캐시 크기 속성은 커넥션 풀의 각 인스턴스에서 각 커넥션에 대해 캐시할 prepared statements와 callable statements의 전체 개수를 결정합니다. 명령문을 너무 많이 캐시하면 데이터베이스 서버의 열린 커서 개수가 최대 개수를 초과할 수 있습니다.

WebLogic Server에서 디폴트 명령문 캐시 크기는 버전마다 다를 수 있습니다. 예를 들면 다음과 같습니다. 

""maximum open cursors exceeded(열린 최대 커서 개수 초과)" 문제가 명령문 캐시와 관련이 있는지 확인하려면 명령문 캐시 크기를 0으로 설정하여 이 기능을 해제하거나 캐시 크기를 줄여 오류가 계속 발생하는지 확인할 수 있습니다. 캐시 크기를 줄여도 문제가 발생하지 않으면 커넥션 풀의 원래 명령문 캐시 크기가 너무 크거나 DBMS의 최대 열린 커서 개수 제한이 너무 적은 것이므로, 이 중 하나의 값을 조정해야 할 수 있습니다. 커넥션에 열린 커서의 개수가 계속 증가하다가 명령문 캐시 크기를 0으로 설정했을 때 이런 동작이 나타나지 않으면 커서 leak 문제일 수 있습니다. 사용 중인 JDBC 드라이버가 원인이거나 WebLogic Server 버그일 수도 있습니다. 다른 JDBC 드라이버를 사용해 보십시오. 다른 JDBC 드라이버를 사용할 때도 동일한 문제가 발생하면 기술 지원 엔지니어가 이 문제를 세부적으로 조사하여 WebLogic Server 버그인지 확인할 수 있도록 BEA에 보고하십시오.

페 이지 맨 위

데이터베이스 드라이버
""maximum open cursors exceeded(열린 최대 커서 개수 초과)" 문제는 JDBC 드라이버가 원인일 수 있습니다. 드라이버가 문제인지 WebLogic 커넥션 풀이 문제인지 파악하기 위해 재현 가능한 테스트 케이스가 있으면 다음을 시도해 볼 수 있습니다.

1. 드라이버에서 커넥션을 직접 가져옵니다.
테스트 케이스에서 JDBC 커넥션은 드라이버에서 직접 가져오고 WebLogic 커넥션 풀은 우회합니다. 커넥션을 닫지 말고 배열이나 일부 다른 구조에 열어 두고 커서 leak 문제가 계속 발생하는지 확인합니다. 커넥션을 닫지 않는 이유는 커넥션 풀을 사용할 때의 동작을 시뮬레이션하기 위해서 입니다. 커넥션 풀을 사용할 때connection.close()는 커넥션을 실제로 닫지는 않으나 대신에 커넥션을 풀로 반환합니다.

2. 다른 JDBC 드라이버로 시도합니다.
타사의 JDBC 드라이버나 드라이버의 업데이트 버전으로 시도하여 문제가 계속 발생하는지 확인합니다. 메타 데이터를 사용하여 올바른 드라이버가 사용되었는지 확인할 수 있습니다. 샘플 코드는 다음과 같습니다.

Connection conn = getConnection();
DatabaseMetaData dmd = conn.getMetaData();
System.out.println("JDBC Driver Name is " + dmd.getDriverName()); 
System.out.println("JDBC Driver Version is " + dmd.getDriverVersion());


3. XA 드라이버 버그.
Oracle XA 드라이버를 사용 중이고 데이터베이스에 "SELECT count (*) FROM SYS.DBA_PENDING_TRANSACTIONS" 같은 쿼리가 많은 경우 Oracle XA 드라이버에 커서 leak 문제가 발생할 수 있습니다. 이 문제는 MetaLink Case 3151681에 설명되어 있으며 버전 10.1.0.2에서 수정되었습니다.
또한 XA 드라이버를 사용할 때http://e-docs.bea.com/wls/docs81/jta/thirdpartytx.html#1075181에 설명된 대로 데이터베이스 서버에 XA 사용을 설정해야 합니다. 즉,grant select on dba_pending_transactions to public명 령을 실행해야 합니다.

JDBC 드라이버가 문제이고 이 드라이버를 사용해야 할 경우 커서 leak 문제의 해결 방법은 WebLogic 커넥션을 가끔씩 재설정하거나 커넥션 풀을 축소하는 것입니다. 재설정하는 방법이나 커넥션 풀을 축소하는 방법은 WebLogic 설명서를 참조하십시오. 버전 8.1의 경우http://e-docs.bea.com/wls/docs81/ConsoleHelp/domain_jdbcconnectionpool_control.html에 설명되어 있습니다.


페 이지 맨 위

알려진 문제
사용하고 있는 WLS 버전의 릴리스 정보를 주기적으로 검토하여 서비스 팩에서 알려진 문제나 해결된 문제를 확인하고 ORA-01000 / 커서 Leak 관련 문제를 검색할 수 있습니다.다음을 참조하십시오.
특별 정보의 경우, 각 버전의 서비스 팩 릴리스 정보에서 해결된 것으로 표시된 다음 CR를 참고하십시오. 

검색하면 릴리스 정보뿐 아니라추 가 도움말에서 언급된 기타 지원 솔루션 및 CR 관련 정보도 알 수 있습니다. 계약 고객은http://support.bea.com/에 로그인한 다음 Browse 포틀릿에서 Solutions 및 Bug Central을 검색하여 제품 버전별로 사용 가능한 최신 CR을 찾을 수 있습니다.

페 이지 맨 위

추 가 도움말이 필요하십니까?
패턴대로 작업했지만 추가 도움말이 필요한 경우 다음과 같이 할 수 있습니다.
  1. http://support.bea.com/의 AskBEA에서"ORA-01000: maximum open cursors exceeded" 등으로 문제를조회하여 게시된 다른 해결 방법을 찾아봅니다. 계약 지원 고객: 제공되는 CR 관련 정보에 액세스할 수 있는 권한으로 로그온합니다
  2. http://forums.bea.com에 서 BEA 뉴스그룹에 보다 자세한 내용을 질문합니다.
이렇게 해도 문제를 해결할 수 없는 경우 유효한 유지 보수 계약이 되어 있다면http://support.bea.com/에 로그인하여 지원요청할 수 있습니다.
반응형
Posted by [PineTree]
ORACLE/TUNING2010. 3. 31. 12:59
반응형

HWM(High Water Mark)란?

  1. HWM(High Water Mark)란 저장공간을 갖는 세그먼트 영역에서 사용한 적이 있는 Block과 사용한 적이 없는 Block 의 경계점을 의미한다.
    Block 은 위에서 부터 채워진다.
  2. 데이타파일은 HWM을 가지지 않으며, 세그먼트만이 HWM를 가진다.

특성

  1. High Water Mark는 증가하기만 한다.
  2. Truncate 명령을 사용하면 Header Block 위치로 돌아오게 된다.(0으로 set)
  3. Delete 명령은 HWM의 변화를 주지 않는다.
  4. 5 block 씩 증가한다. (초기 5 block이 될때까지는 1 block씩 증가한다.)
  5. Table의 Full Scan량과 동일하다.
  6. USER_TABLES.AVG_SPACE의 기준이 된다.

관련 Data Dictionary

USER_TABLES.BLOCKS HWM와 같은 값으로 단위는 block 이다.
segment에 의해 사용된 적이 있는 block 수
USER_TABLES.EMPTY_BLOCKS 할당된 블록 중에서 HWM 위에 미사용으로 남아있는 공간의 블록 수.
HWM 위의 block
USER_TABLES.AVG_SPACE 한 블록당 평균 FREE SPACE SIZE.
단위는 Byte 이다.
Header Block을 제외한 HWM 안에 있는 Block들에 대해서 평균을 구하므로 오차가 있을 가능성이 많다.
테이블 사이즈 계산 테이블 사이즈 = (blocks + empty_blocks + 1) = 사용블록 + 비어있는블록 + segment head block(1)

HWM 측정방법

  1. 특정테이블의 HWM를 알기 위해서는 ANALYZE TABLE 명령을 수행하여 통계정보를 수집한다.
     ANALYZE TABLE <tablename> ESTIMATE/COMPUTE STATISTICS; 
  2. 수집한 통계정보를 가지고 HWM를 측정한다.
    SELECT blocks, empty_blocks, num_rows
    FROM user_tables
    WHERE table_name = <tablename>;
  3. 레코드를 삭제하는 것은 HWM의 위치를 아래로 옮기지 않는다.
    그러므로, 레코드를 삭제하는 것은 EMPTY_BLOCKS 의 수치를 늘리지 않는다.

TUNING

  1. 계산된 테이블사이즈가 세그먼트의 크기(USER_SEGMENTS.BLOCKS)와 다르면 Analyze를 다시 해주어야 한다.
  2. EMPTY_BLOCKS가 BLOCKS에 비해 너무 크면, INITIAL_EXTENT나 NEXT_EXTENT를 줄여야 한다.
  3. 입력된 데이터 건수에 비해 HWM가 너무 높다면 segment를 재생성을 고려해야 한다.
    이유 는 실제 데이터 건수는 작은데 비해 Full Scan시에 HWM까지 검색해 Disk I/O가 많아져 부하가 증가하게 된다.
  4. USER_TABLES.AVG_SPACE가 너무 크면 테이블을 재생성해야 한다.
    PCT_USED 와 PCT_FREE 의 중간 이상
    DB_BLOCK_SIZE * (100 - PCT_USED + PCT_FREE) / 200 
반응형

'ORACLE > TUNING' 카테고리의 다른 글

DBMS_XPLAN - 2.포맷 설정하기  (0) 2010.05.24
DBMS_XPLAN - 1.실행계획  (0) 2010.05.24
AWR - Monitoring & Tuning  (0) 2010.03.23
AWR (Automatic Workload Repository)  (0) 2010.03.23
Statspack 생성/삭제/Sanpshot생성  (0) 2010.03.23
Posted by [PineTree]
ORACLE/TUNING2010. 3. 23. 13:47
반응형
AWR (Automatic Workload Repository)
- SYSAUX Tablespace (SYS소유) 에 존재하는 Tables
- Snapshot 을 저장
- 기본 7 일간 저장 (DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE을 통해 Baseline 화 하여 삭제안되게 할 수 있다.)
- MMON(기본 1시간단위 수집) 에 의해 생성된 Snapshot 을 DMA 방식으로 메모리의 내용을 저장한다
- 저장된 결과를 ADDM(분석) 또는 DBA 가 분석한다
- Performance(v$) 관련 Data들이 저장
- Infra Structure 역할을 한다.
- 문제확인과 자체튜닝을 가능케해준다

cf.
Baseline : Database 가 정상작동하고 있을때의 통계값 (문제발생시 비교를 위한값)


ADDM (Automatic Database Diagnostic Monitor)
- 분석 후, 기본적인 이상 발생시 알려주는 역할
- 분석에 관하여 핵심적이고 본질적인 역할 수행
- DBA 의 분석작업을 빠르게 제공 (분석, 도움)
- 다른 Advisory 와 달리 자동으로 실행된 다


ADDM 과 MMON
동작 : MMON 이 Snapshot 을 생성한 후 ADDM 에 알리면 ADDM 은 가장 최근의 Snapshot 과 비교하여 이상여부를 분석하여 화면으로 출력하고(EM) AWR 에 저장(ADDM Result) 한다


Alert 의 종류
1. Tool 이 발생시킨 Alert
2. DBA 가 설정한 값에 의해 발생한 Server Alert
1. Metric-Based Alert : DBA_OUTSTANDING_ALERTS 에 기록후 해결되면 지워진다. 모든 이전 기록은 DBA_ALERT_HISTORY 에 남는다
2. Event-Based Alert : 즉시 DBA_ALERT_HISTORY에 기록


Server Alerts
동작 : 문제 확인시 AWR 에 저장(ADDM Result) 하면서 Server Alerts Queue 에 작업을 넣고 화면으로 출력한다(EM)
- DBA 가 설정한 (Metrics 의 설정값) 특정상황 발생시 서버측에서 즉각적으로 경고
- EM 및 DBMS_SERVER_ALERTS Package 사용하여 수동 설정
- Resumable Session Suspended, Snapshot Too Old 같은 상황에 대해 미리 경고를 받을 수 있다.


Advisory Framework
<Advisory Framework>
- Performance 분석 및 Failure(11g) 에 대한 도움말 기능
- ADDM 만 자동으로 실행된다
- DBMS_ADVISOR Package 를 사용


Automated Tasks
- 주기적인 (B&R 과 같은) 작업을 자동화 하는 Job으로 생성하여 수행
- DBMS_SCHEDULER Package 사용


Data Warehouse of The Database
- Automatic Collection of Important Statistics
- Direct Memory Access : Oracle Engine 이 아닌 Memory 에 직접적으로 접근


Statistics
Optimizer Stats (일부 dba_)
- 관리자가 프로시저를 사용해 수동으로 통계를 집계해야 한다
- DBMS_STATS package 의 사용으로 통계 수집
   참조: http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14258/toc.htm

Performance Stats (v$)

- Server 의 수행 내역에 관한 통계들. 관리하지 않아도 자동으로 변경된다.
- 문제발생시 우선 확인해야하는 부분
- v$ 뷰를 기초로 하기에, Startup 이래로 누적된 값만을 볼 수 있으므로 특정상황에 대한 문제를 발견 할 수 없다
- Shutdown 시 정보가 없어진다
- (1)누적 (2)휘발의 위험을 위해 Snapshot 을 남긴다
Snapshot 을 만드는 방법
1. utlbstat.sql + utlestat.sql -> report.txt $ORACLE_HOME/rdbms/admin
2. statspack / sp*.sql
3. AWR (+MMON + ADDM)


Metric

- 측정단위. 통계값의 2차 가공한 정보
- 내부 Component 들이 어떤 결과를 내리기 위한 값 (기본적으로 관리자의 관리를 위한 Data 가 아니다)
- Ex] Statistic 가 총 Commit 이 발생한 횟수 라면 Metric 은 초(시간)당 Commit 의 횟수 일 수 있다.


Tuning
SQL Tuning
특정 SQL 이 처리되는 가장 좋은 경로를 알고 있는 상태에서
Optimizer 가 특정 SQL 의 최적의 실행계획을 선택하도록 유도하는 과정
유도 방법
- Optimizer Stats 관리
- Index 의 적절한 조절
- 대안적 저장구조
- Parameter 값 변경 (PGA 크기조정 etc...)
- SQL 변환
- Hint 의 사용
- Etc...

Server Tuning
진단 결과 해석할 능력이 있는 상태에서
목표에 맞는 Performance 가 발휘되도록 System 의 여러 요소를 조절해가는 과정


Statistic Levels
- BASIC : Snapshot 같은 정보는 수집하지 않는다
- TYPICAL : Default
- ALL : 시스템에 부담. Snapshot + SQL Tuning 정보까지도 포함
반응형

'ORACLE > TUNING' 카테고리의 다른 글

DBMS_XPLAN - 1.실행계획  (0) 2010.05.24
HWM(High Water Mark)란?  (0) 2010.03.31
AWR (Automatic Workload Repository)  (0) 2010.03.23
Statspack 생성/삭제/Sanpshot생성  (0) 2010.03.23
[Oracle 물리설계] 제5부 영역감시  (0) 2010.02.11
Posted by [PineTree]
ORACLE/TUNING2010. 3. 23. 13:41
반응형
출처 : http://www.urbantree.wo.tc/entry/6-Using-Automatic-Workload-Repository

AWR (Automatic Workload Repository)

- SYS 소유
- SYSAUX TS 에 존재
- MMON에 의해 자동으로 60분마다 수집 / 7일간 유지 (Default)
- MMON 에 의해 자동으로 삭제
- Snapshot : Set of performance statistics captured at a certain time
- Baseline : Set of Snapshots
AWR 수록 내용
- Base Statistics
- Metrics
- Active Session History
- Advisor Results
- Snapshot Statistics
- Database Feature Usage


Script
- awrrpt.sql : AWR 관련 Report 생성 Script. (분석은 사용자의 몫)
- awrddrpt.sql (기간비교) : AWR 관련 Report 생성 Script (분석은 사용자의 몫)
- ashrpt.sql : ASH 관련 Report 생성 Script (분석은 사용자의 몫)
- addmrpt.sql : ADDM 관련 Report 생성 Script 분석 및 권고안까지 포함


ADDM Attributes
- STATISTICS_LEVEL = TYPICAL or ALL (Basic으로 설정시 자동 실행 안된다)


ADDM Report
- 하나의 Report 생성

SQL> @?/rdbms/admin/addmrpt

Enter value for begin_snap: 8

Enter value for end_snap: 10

Enter value for report_name:

Generating the ADDM report for this analysis ...

- 기존의 작업물들을 바탕으로 Report 생성

SELECT dbms_advisor.GET_TASK_REPORT(task_name)

FROM   dba_advisor_tasks

WHERE  task_id = (

       SELECT max(t.task_id)

       FROM   dba_advisor_tasks t,

              dba_advisor_log l

       WHERE  t.task_id = l.task_id   AND

              t.advisor_name = 'ADDM' AND

              l.status = 'COMPLETED');



ASH (Active Session History)
- V$SESSION 의 내용중 Active Session 의 내용들을 1초 단위로 ASH Buffer로 복사
- ASH Buffer 는 Shared Pool 안에 존재
- ASH Buffer 에는 V$ACTIVE_SESSION_HISTORY View 가 존재
- CPU 당 2mb 의 크기 사용
- ASH 는 Lock 에 의한 보호 메커니즘이 없으므로 읽기 일관성 보장 안된다.
- V$ACTIVE_SESSION_HISTORY 의 내용은 일정크기를 순환해서 쓰는 Rollng Buffer 방식
- V$ACTIVE_SESSION_HISTORY 의 내용을 Direct Path 방식으로 AWR로 내려쓴다
- AWR 로 내려쓰여진 정보들은 DBA_HIST_ACTIVE_SESSION_HISTORY, WRH$_ACTIVE_SESSION_HISTORY 에서 확인가능
관련 Process
▒ MMON
- 시간이 다 되었을 경우(1시간) 1/10개 Sampling 하여 AWR 내려쓴다
▒ MMNL
- V$SESSION 의 내용을 ASH Buffer 로 채우는 역할
- ASH Buffer 의 내용이 1/3이상 찰 경우 1/10 Sampling 하여 AWR 로 내려쓴다


Oradebug 를 이용한 ASH Dump
SQL> oradebug setmypid
SQL> oradebug dump ashdump 10
SQL> oradebug tracefile_name


V$ACTIVE_SESSION_HISTORY 의 해석


SELECT   sql_id, count(*),
         round(count(*)/sum(count(*)) over (), 2)
pctload

FROM     v$active_session_history

WHERE    sample_time > sysdate -1/24/60 and

         session_type <> 'BACKGROUND'

GROUP BY sql_id

ORDER BY count(*) desc;


최근 1분안에 수행한 SQL 문중 가장많은 시간(n초)을 사용한 sql_id 와 count(*)[횟수, 시간]

ASH 에서 Count 한 값은 횟수이면서 동시에 시간(n초) 로 해석할 수 있다(Sampling의 단위가 1초이므로)


ASH Report Structure
- Top Events
- Load Profile
- Top SQL
- Top Session
- Top Objects/File/Latches
- Activity Over Time
▒ Slot Count : 1분간 Active Session
▒ Event Count : Sloct Count 별 상위 3지표
반응형

'ORACLE > TUNING' 카테고리의 다른 글

HWM(High Water Mark)란?  (0) 2010.03.31
AWR - Monitoring & Tuning  (0) 2010.03.23
Statspack 생성/삭제/Sanpshot생성  (0) 2010.03.23
[Oracle 물리설계] 제5부 영역감시  (0) 2010.02.11
Oracle Hidden Parameter 란  (0) 2010.01.26
Posted by [PineTree]