태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

[오라클 만화] latch:library cache


[오라클 만화] latch:library cache

  • Favicon of https://1ststreet.tistory.com SITD 2011.05.18 11:26 신고 ADDR 수정/삭제 답글

    쿼리에서 호출하는 함수의 경우, 함수호출 때마다(패치때마다) 래치를 경유해서 함수 및 실행계획을 읽어오지만

    스칼라 서브쿼리는 래치를 한번만 읽고 해결한다는 거죠?

[오라클 질문] from dual 도 최적화 할 수 있을까요?

기술이야기/Ask 엑셈 2010. 5. 19. 09:52

2010-04-26 19:25:38 에 등록된 질문입니다.  김창두 님께서 질문해 주셨습니다

아래와 같은 SQL입니다.

select to_char(((((to_date(:b0, 'yyyymmddhh24miss')-to_date(:b1, 'yyyymmddhh24miss'))* 24)* 60)* 60)) into :b2 from dual ;

이 SQL이 데몬에서 무한로프 돌면서 로그를 찍습니다.

그러다보니 30분에 400만번 정도 돌면서 CPU를 5-10% 잡아 먹습니다.

이련 from dual SQL도 최적화 할 방법이 있을까요?



A:                                        엑셈 답변 보기

위 글은 (주) 엑셈 온라인 서비스 ASK EXEM 에서 발췌한 것임을 알려 드립니다.

[오라클 질문] RAC에서 글로벌 lock 해석방법

기술이야기/Ask 엑셈 2010. 5. 19. 09:49

2010-05-12 10:50:12 에 등록된 질문입니다. 예맥 님께서 질문해 주셨습니다.

아래와 같이 트레이스 발생했는데 blocker부분을 어떻게 해석해야하나요?
current는 lock을 유발한 sql인가요?

user session for deadlock lock c000000170cb4f90
  pid=87 serial=51403 audsid=198528653 user: 140/GROUPWARE
  O/S info: user: handy, term: unknown, ospid: 1234, machine: komappi2.kowaco.or.kr
            program: JDBC Thin Client
  application name: JDBC Thin Client, hash value=0
  Current SQL Statement:
  UPDATE mail_usr SET last_list_f = '0' WHERE user_id = :1  AND ( box_id = '000000001' ) 
AND last_list_f = '1
'
Global Wait-For-Graph(WFG) at ddTS[0.73] :
BLOCKED c000000170cb4f90 5 [0x5a001b][0x4594d],[TX] [1005-0057-00021692] 0
BLOCKER c00000017d19cb28 5 [0x5a001b][0x4594d],[TX] [200D-00D2-00027D5C] 1
BLOCKED c00000017f9e1c90 5 [0x310024][0xa22d1],[TX] [200D-00D2-00027D5C] 1
BLOCKER c00000017e64ec98 5 [0x310024][0xa22d1],[TX] [1005-0057-00021692] 0
 
A:                         엑셈 답변 보기

위 글은 (주) 엑셈 온라인 서비스 ASK EXEM 에서 발췌한 것임을 알려 드립니다.

[오라클 만화] Enq: TX - index contention


[오라클 만화] Enq: TX - index contention

  • Eddy 2010.04.21 23:24 ADDR 수정/삭제 답글

    날이 갈수록 노련한 설명과 유머를 사용하시네요. ^^/
    벌써 다음 편이 기다려집니다. 수고하세요.

  • Favicon of https://blog.ex-em.com EXEM 2010.04.22 09:35 신고 ADDR 수정/삭제 답글

    많은 관심 감사드립니다^^

  • Favicon of http://sensui.tistory.com sensui 2010.05.17 14:24 ADDR 수정/삭제 답글

    재미있게 보고 있습니다~!
    수고하세요!

[오라클 질문] SQL*Net message from client 이벤트를 보면...

기술이야기/Ask 엑셈 2010. 4. 20. 10:07
2009-04-16 20:46:37 에 등록된 질문입니다.  Bruce Lee 님께서 질문해 주셨습니다.

안녕하세요.
고생 많으시네요. 세미나도 하시고 ask.엑셈의 답변도 하시고. 대단하십니다.
질문이 3가지가 있는데요.
SQL*Net message from client 이벤트가 많이 발생하고 있습니다.
이 이벤트는 sql문을 수행하면 무조건 발생하는 idle 이벤트로 알고 있습니다.
우리가 sql문 실행과 동시에 SQL*Net message from client 이벤트가 발생하고 실행이 되는게 맞나요?
그리고 한가지 더 질문이 있습니다.
맥스게이지 로그를 보다가 Active Session이 증가하는 구간이 있는데요, 대부분의 이벤트가 SQL*Net message from client입니다. 그외 대기이벤트는 없구요, stat 지표를 보면 그 시점의 execution count가 증가하는 것을 볼 수 있습니다. 그렇다면 execution count가 많이 발생한 sql문, 즉 recursive query가 많이 발생한 sql문으로 인해 active session이 증가하였고, 그 이유로 SQL*Net message from client 이벤트가 많이 발생하였다고 봐도 무방한지요?
마지막 질문입니다.
이벤트 중에(v$event_name 조회시에)

SQL*Net message to client
SQL*Net more data to client
SQL*Net message from client
SQL*Net more data from client
SQL*Net message to dblink
SQL*Net more data to dblink
SQL*Net message from dblink
SQL*Net more data from dblink
SQL*Net break/reset to dblink


이런 것들이 있는데요, 간략하게나마 정확하게 이런 이벤트들이 왜 발생하는지 알고 싶네요.
미리 감사드려요.


A:                                        엑셈 답변 보기


위 글은 (주) 엑셈 온라인 서비스 ASK EXEM 에서 발췌한 것임을 알려 드립니다.

[오라클 질문] Dummy Table과 Single Row Table과 Join시 성능 차이

기술이야기/Ask 엑셈 2010. 4. 20. 10:03
2010-04-08 14:54:21 에 등록된 질문입니다.  bookman 님께서 질문해 주셨습니다.


Q:
안녕하세요.
제목처럼 Dual을 사용한 것과 Single Row Table을 Join하였을 때 엄청난 속도의 차이가 나는 SQL이 있어 이렇게 여쭤 보게 되었습니다.

일단, 문제의 Query는
1.
SELECT a.SALE_DATE, a.item_no, a.sale_qty
  FROM t_sale A, t_calendar B,
       t_temp C
 WHERE a.SALE_DATE IN (
          SELECT   MAX (SALE_DATE)
              FROM t_sale x
             WHERE SALE_DATE >= b.basis_date - 1
               AND SALE_DATE < b.basis_date + 1)
   AND B.basis_yyyymmdd = c.temp_yyyymmdd


2.
SELECT a.SALE_DATE, a.item_no, a.sale_qty
  FROM t_sale A, t_calendar B,
       (select '20100408' temp_yyyymmdd from dual) C
 WHERE a.SALE_DATE IN (
          SELECT   MAX (SALE_DATE)
              FROM t_sale x
             WHERE SALE_DATE >= b.basis_date - 1
               AND SALE_DATE < b.basis_date + 1)
   AND B.basis_yyyymmdd = c.temp_yyyymmdd


이 두문장의 차이는 t_temp 와 Dual 입니다.
Dummy Table의 어떤 특별한 기능이 있다 하더라도 Single Row Table을 Join 했을 때 너무나도 다른 성능을 보이고 있습니다.
꼭, t_temp Table을 사용해야만 하는 상황인데 그 이유와 해결방법을 부탁드립니다.

실행계획은
1.
------------------------------------------------------------------------------------------

| Id  | Operation                | Name          | Rows  | Bytes | Cost (%CPU)| Time     
|
------------------------------------------------------------------------------------------

|   0 | SELECT STATEMENT         |               |  8862 |   519K|   112  (55)| 00:00:02 
|
|*  1 |  HASH JOIN               |               |  8862 |   519K|   112  (55)| 00:00:02 
|
|*  2 |   HASH JOIN              |               |    90 |  4230 |    85  (66)| 00:00:02 
|
|   3 |    NESTED LOOPS          |               |     1 |    26 |     4   (0)| 00:00:01 
|
|   4 |     TABLE ACCESS FULL    | T_TEMP        |     1 |     9 |     3   (0)| 00:00:01 
|
|*  5 |     INDEX RANGE SCAN     | PK_T_CALENDAR |     1 |    17 |     1   (0)| 00:00:01 
|
|   6 |    VIEW                  | VW_SQ_1       | 32822 |   673K|    79  (69)| 00:00:01 
|
|   7 |     SORT GROUP BY        |               | 32822 |   801K|    79  (69)| 00:00:01 
|
|   8 |      MERGE JOIN          |               | 32822 |   801K|    68  (64)| 00:00:01 
|
|   9 |       SORT JOIN          |               |   365 |  6205 |     4  (25)| 00:00:01 
|
|  10 |        TABLE ACCESS FULL | T_CALENDAR    |   365 |  6205 |     3   (0)| 00:00:01 
|
|* 11 |       FILTER             |               |       |       |            |          
|
|* 12 |        SORT JOIN         |               | 35969 |   281K|    37  (41)| 00:00:01 
|
|  13 |         TABLE ACCESS FULL| T_SALE        | 35969 |   281K|    25  (12)| 00:00:01 
|
|  14 |   TABLE ACCESS FULL      | T_SALE        | 35969 |   456K|    25  (12)| 00:00:01 
|
------------------------------------------------------------------------------------------

2.
------------------------------------------------------------------------------------------
--------
| Id  | Operation                        | Name          | Rows  | Bytes | Cost (%CPU)| 
Time     |
------------------------------------------------------------------------------------------
--------
|   0 | SELECT STATEMENT                 |               |    24 |  1224 |    10  (20)| 
00:00:01 |
|   1 |  NESTED LOOPS                    |               |    24 |  1224 |    10  (20)| 
00:00:01 |
|*  2 |   HASH JOIN                      |               |     1 |    38 |     8  (25)| 
00:00:01 |
|   3 |    NESTED LOOPS                  |               |     1 |    17 |     3   (0)| 
00:00:01 |
|   4 |     FAST DUAL                    |               |     1 |       |     2   (0)| 
00:00:01 |
|*  5 |     INDEX RANGE SCAN             | PK_T_CALENDAR |     1 |    17 |     1   (0)| 
00:00:01 |
|   6 |    VIEW                          | VW_SQ_1       |    90 |  1890 |     4  (25)| 
00:00:01 |
|   7 |     SORT GROUP BY                |               |    90 |  2250 |     4  (25)| 
00:00:01 |
|   8 |      NESTED LOOPS                |               |    90 |  2250 |     3   (0)| 
00:00:01 |
|   9 |       TABLE ACCESS BY INDEX ROWID| T_CALENDAR    |     1 |    17 |     2   (0)| 
00:00:01 |
|* 10 |        INDEX RANGE SCAN          | PK_T_CALENDAR |     1 |       |     1   (0)| 
00:00:01 |
|* 11 |       INDEX RANGE SCAN           | IDX_T_SALE_1  |    90 |   720 |     1   (0)| 
00:00:01 |
|  12 |   TABLE ACCESS BY INDEX ROWID    | T_SALE        |    99 |  1287 |     2   (0)| 
00:00:01 |
|* 13 |    INDEX RANGE SCAN              | IDX_T_SALE_1  |   100 |       |     1   (0)| 
00:00:01 |
------------------------------------------------------------------------------------------
--------

=============
* TEST 환경
1. Table 생성
create table t_sale (
  item_no number,
  sale_date date,
  sale_qty number
 )


create table t_calendar (
  basis_yyyymmdd varchar2(8),
  basis_date date
 )


create table t_temp (
  temp_yyyymmdd varchar2(8)
 )


2. Data 생성
insert into t_calendar
select to_char(t_col, 'yyyymmdd'), t_col
  from ( select to_date('20100101', 'yyyymmdd') + level - 1 t_col from dual
          connect by level <= 365)

     
insert into t_sale
select b.lvl, a.t_col, 0
  from (select to_char(t_col, 'yyyymmdd'), t_col
          from ( select to_date('20100101', 'yyyymmdd') + level - 1 t_col from dual
         connect by level <= 365)) a,
       (select level lvl from dual
         connect by level <= 100) b

     
insert into t_temp
values ('20100408')


3. Index 생성
create index pk_t_calendar on t_calendar (basis_yyyymmdd)


create index idx_t_sale_1 on t_sale(sale_date)


4. 통계정보 생성
exec dbms_stats.gather_table_stats(username, 't_sale', no_invalidate=>false);

exec dbms_stats.gather_table_stats(username, 't_calendar', no_invalidate=>false);

exec dbms_stats.gather_table_stats(username, 't_temp', no_invalidate=>false);
 
A:                      엑셈 답변 보기

위 글은 (주) 엑셈 온라인 서비스 ASK EXEM 에서 발췌한 것임을 알려 드립니다.

[오라클 질문] sql profiler 적용여부

기술이야기/Ask 엑셈 2010. 4. 20. 09:58
2010-04-08 13:16:54 에 등록된 질문입니다.  이신구 님께서 질문해 주셨습니다.

Q:

안녕 하세요? ^^

현재 DW로 구축한 DB가 있고 OLAP툴에서 이 DB를 이용하여

정형/비정형 레포트를 생성 하고 있습니다.

헌데 OLAP툴이 레포트 쿼리를 할때 생성되는 SQL을 임의로

원하는대로 수정 할 수는 없더군요.

그래서 문제가 있는 쿼리들은 sql profiler를 이용하면 어떨까 하는데,

정형레포트일 경우 쿼리는 동일 하지만 날짜부분만 매일 틀립니다.

이 날짜변수를 상수로 해서 profiler를 적용해도 다음날 이 부분이 틀려질텐데 그래도

sql profiler 가 적용될수 있나요? 정확히 모든 문장이 동일해야 작동되는지

아닌지가 궁금 합니다 ^^



A:                                        엑셈 답변 보기


위 글은 (주) 엑셈 온라인 서비스 ASK EXEM 에서 발췌한 것임을 알려 드립니다.

[오라클 만화] latch: Shared Pool (Bind Mismatch)


[오라클 만화] latch: Shared Pool (Bind Mismatch)
  • Eddy 2010.04.01 18:36 ADDR 수정/삭제 답글

    곰돌이 귀여운데요. 이름이 있나요? ^^

  • Favicon of https://blog.ex-em.com EXEM 2010.04.06 15:00 신고 ADDR 수정/삭제 답글

    이름은 없는데, 하나 지어주세요~ㅋㅋ

  • Favicon of https://1ststreet.tistory.com SITD 2011.05.18 11:21 신고 ADDR 수정/삭제 답글

    곰돌이 남자인가요 여자인가요 ㅋㅋ

    말투는 여잔데 ㅋ

[오라클 질문] HASH JOIN에서 Parallel 처리 시 이상(?) 현상

기술이야기/Ask 엑셈 2010. 3. 22. 10:41
2010-03-10 15:01:14 에 등록된 질문입니다. (홍인훈 님께서 질문해 주셨습니다.)


Q:

안녕하세요^^ 항상 정성스런 답변에 감사드립니다.

아래와 같은 상황에서 이해가 안되어 질문을 드립니다.

Compile Time    : 2010/03/10 16:01:37
Trace File Name : /db/trace/admin/PIHFDB/udump/pihfdb_ora_13680.trc
Trace Version   : Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bit 
Production
Environment     : Array Size = 10
                  Long  Size = 80

********************************************************************************

select /*+ USE_HASH(t2) no_merge(t1) no_merge(t2)
           ordered swap_join_inputs(t1)
           pq_distribute(t2 broadcast none)
        */
       t1.c1, t2.*
  from (select 1 c1 from ar_cash_flow where rownum < 1) t1 --> 드라이빙(build)는 0건.
      ,(select /*+
                   parallel(t1 4) parallel(t2 4)
                   full(t1) full(t2)
               */
               1 c1, t1.*
          from ar_cash_flow t1,
               trs          t2
         where t1.TRS_NR = t2.TRS_NR
       ) t2
 where t1.c1 = t2.c1

Call     Count CPU Time Elapsed Time       Disk      Query    Current       Rows
------- ------ -------- ------------ ---------- ---------- ---------- ----------
Parse        1    0.010        0.038          0          2          3          0
Execute      1    0.080        1.043          0       1805          0          0
Fetch        1    0.020       41.787          0          0          0          0
------- ------ -------- ------------ ---------- ---------- ---------- ----------
Total        3    0.110       42.869          0       1807          3          0

Misses in library cache during parse: 1
Optimizer goal: ALL_ROWS
Parsing user: FSDMS (ID=165)

Rows     Row Source Operation
-------  ---------------------------------------------------
      0  STATEMENT
      0   PX COORDINATOR  (cr=1805 pr=0 pw=0 time=42830766 us)
      0    PX SEND QC (RANDOM) :TQ10002 (cr=0 pr=0 pw=0 time=0 us)
      0     HASH JOIN  (cr=0 pr=0 pw=0 time=0 us)
      0      BUFFER SORT (cr=0 pr=0 pw=0 time=0 us)
      0       PX RECEIVE  (cr=0 pr=0 pw=0 time=0 us)
      0        PX SEND BROADCAST :TQ10000 (cr=0 pr=0 pw=0 time=0 us)
      0         VIEW  (cr=0 pr=0 pw=0 time=69 us)
      0          COUNT STOPKEY (cr=0 pr=0 pw=0 time=62 us)
      0           PARTITION HASH ALL PARTITION: 1 64 (cr=0 pr=0 pw=0 time=21 us)
      0            INDEX FAST FULL SCAN AR_CASH_FLOW_I PARTITION: 1 64 (cr=0 pr=0 pw=0 
time=9 us)OF AR_CASH_FLOW_I (UNIQUE)
      0      VIEW  (cr=0 pr=0 pw=0 time=0 us)
      0       HASH JOIN  (cr=0 pr=0 pw=0 time=0 us)
      0        PX RECEIVE  (cr=0 pr=0 pw=0 time=0 us)
      0         PX SEND BROADCAST :TQ10001 (cr=0 pr=0 pw=0 time=0 us)
      0          PX BLOCK ITERATOR (cr=0 pr=0 pw=0 time=0 us)
      0           TABLE ACCESS FULL TRS (cr=0 pr=0 pw=0 time=0 us)
      0        PX BLOCK ITERATOR PARTITION: 1 128 (cr=0 pr=0 pw=0 time=0 us)
      0         TABLE ACCESS FULL AR_CASH_FLOW PARTITION: 1 128 (cr=0 pr=0 pw=0 time=0 
us)

Wait Event Name                                      Count Wait(sec)  Max Wait
-------------------------------------------------- ------- ---------- --------
PX Deq: Parse Reply                                       7      0.039    0.031
PX Deq: Join ACK                                          7      0.010    0.005
PX Deq: Signal ACK                                        5      0.032    0.002
PX Deq: Execute Reply                                   228     41.704    0.000
SQL*Net message to client                                 1      0.000    0.000
SQL*Net message from client                               1      0.006    0.006
os thread startup                                         8      0.743    0.106
reliable message                                          3      0.025    0.022
PX Deq: Table Q Normal                                    2      0.038    0.000
enq: KO - fast object checkpoint                          1      0.053    0.053
SQL*Net more data to client                               1      0.000    0.000
--------------------------------------------------- ------- --------- --------
Total                                                   264     42.65




드라이빙(build) t1에서 이미 0건이 나왔음에도 불구하고 t2 인라인 뷰의 테이블을 액세스 합니다. 위 트레이스에서 PX Deq: Execute Reply 대기이벤트 및 실제 direct path read가 관찰됩니다. 왜 I/O가 발생할까요?

parallel 힌트를 제거하면 제가 의도하는 대로 드라이빙에서 멈춥니다.

select /*+ USE_HASH(t2) no_merge(t1) no_merge(t2)
           ordered swap_join_inputs(t1)
           pq_distribute(t2 broadcast none)
        */
       t1.c1, t2.*
  from (select 1 c1 from ar_cash_flow where rownum < 1) t1
      ,(select /*+
--                   parallel(t1 4) parallel(t2 4)
                   full(t1) full(t2)
               */
               1 c1, t1.*
          from ar_cash_flow t1,
               trs          t2
         where t1.TRS_NR = t2.TRS_NR
       ) t2
 where t1.c1 = t2.c1

Call     Count CPU Time Elapsed Time       Disk      Query    Current       Rows
------- ------ -------- ------------ ---------- ---------- ---------- ----------
Parse        1    0.010        0.011          0          0          0          0
Execute      1    0.000        0.000          0          0          0          0
Fetch        1    0.020        0.035          0          0          0          0
------- ------ -------- ------------ ---------- ---------- ---------- ----------
Total        3    0.030        0.046          0          0          0          0

Misses in library cache during parse: 1
Optimizer goal: ALL_ROWS
Parsing user: FSDMS (ID=165)

Rows     Row Source Operation
-------  ---------------------------------------------------
      0  STATEMENT
      0   HASH JOIN  (cr=0 pr=0 pw=0 time=34589 us)
      0    VIEW  (cr=0 pr=0 pw=0 time=80 us)
      0     COUNT STOPKEY (cr=0 pr=0 pw=0 time=74 us)
      0      PARTITION HASH ALL PARTITION: 1 64 (cr=0 pr=0 pw=0 time=42 us)
      0       INDEX FAST FULL SCAN AR_CASH_FLOW_I PARTITION: 1 64 (cr=0 pr=0 pw=0 time=30 
us)OF AR_CASH_FLOW_I (UNIQUE)
      0    VIEW  (cr=0 pr=0 pw=0 time=0 us)
      0     HASH JOIN  (cr=0 pr=0 pw=0 time=0 us)
      0      TABLE ACCESS FULL TRS (cr=0 pr=0 pw=0 time=0 us)
      0      PARTITION HASH ALL PARTITION: 1 128 (cr=0 pr=0 pw=0 time=0 us)
      0       TABLE ACCESS FULL AR_CASH_FLOW PARTITION: 1 128 (cr=0 pr=0 pw=0 time=0 us)

Wait Event Name                                      Count Wait(sec)  Max Wait
-------------------------------------------------- ------- ---------- --------
SQL*Net message to client                                 1      0.000    0.000
SQL*Net message from client                               1      0.092    0.092
SQL*Net more data to client                               1      0.000    0.000
--------------------------------------------------- ------- --------- --------
Total                                                     3      0.09



선행집합을 serial로 처리하고 후행집합을 parallel처리하려고 하는데 위 현상이 발생합니다.

pq_distribute(t2 broadcast none)를 pq_distribute(t2 hash hash)로 변경하니 답이 안 나옵니다. 테이블이 워낙 커서...AR_CASH_FLOW(375G), TRS(6G)정도 되네요~

A:                                        엑셈 답변 보기


위 글은 (주) 엑셈 온라인 서비스 ASK EXEM 에서 발췌한 것임을 알려 드립니다.
  • 정민혁 2014.11.21 09:44 ADDR 수정/삭제 답글

    엑셈 답변을 볼 수가 없네요...

[오라클 질문] table_name을 이용한 사용된 SQL 추출 및 실행계획 생성

기술이야기/Ask 엑셈 2010. 3. 22. 10:40
2010-03-09 09:20:33 에 등록된 질문입니다. 유수익 님께서 질문해 주셨습니다.

특정 계정에 특정 테이블이 있을경우
이 테이블이 사용하는 SQL을 추출해서 실행계획등을 만들고 인덱스 상태등을
확인하고자 할때 어떻게 해야하나요?

1. 특정 테이블에대한 사용된 SQL 추출
2. 추출된 SQL을 이용한 실행계획 조회 또는 생성

감사합니다.




A:                                        엑셈 답변 보기

위 글은 (주) 엑셈 온라인 서비스 ASK EXEM 에서 발췌한 것임을 알려 드립니다.