오늘은 정신없이 Error수정을 하다가 강의를 들으러 왔습니다. 고객사에 문제가 터졌는데 전에 원활하게 해결이 되지 않았는지 외근나간 다른 직원에게 확인을 하지 못하여 내일 업무를 바로 처리하는 것을 예정으로 하고 급하게 강의를 들으러 왔습니다.

늦게 온 만큼 자리를 잘 잡지 못하여 내일부터는 가능하면 laptop을 들고 와서 강의를 수강할 수 있도록 하는것이 좋을 것 같습니다.

강의 전 다른 일행분들을 위해 자리를 옮겨서 내일부터는 노트북을 들고오도록 해야겠습니다.

첫날 첫시간은 DB backup 및 Recovery에 관한 내용으로 교재의 내용을 앞부분부터 차근차근 진행하셨습니다.

각종 DB 실패의 원인 및 해결 방법에 관한 내용이었습니다. 그리고 DB실습을 위한 환경구축을 위해 VM ware설치 및 리눅스 시작까지 마쳤습니다.

=======================================    2    =====================================

리눅스 안에서 터미널을 열어서 DB를 시작하였습니다.

그 후에는 접속 프로그램으로 사용할 Putty 설정을 하였습니다. 이번 시간에는 처음으로 접속기의 색을 변경하는 방법도 가르쳐주셨습니다.

위의 화면에서 블럭처리 한 부분은 스크롤을 내릴수있는 출의 최대치라고 생각하시면 됩니다. 기본값이 200으로 되어있었는데 그정도 양으로는 부족할 수 있다고 하셨습니다.

이번에는 저도 하늘색 바탕의 설정하나와 기본 흰색 설정 2가지를 미리 저장을 해 두었습니다.

VM 내부의 Linux의 터미널로 작업을 하는 경우는 터미널에서 . .bash_profile을 입력하여 주어 환경변수를 수동으로 컴파일 해 줘야 한다고 설명을 해 주셨습니다.

위 작업은 편리한 사용을 위함이라고 설명을 해 주셨습니다.

저의 경우는 커리큘럼에 맞게 벌써 4번째 DB수업을 듣는 것이지만 다른 수강생 특히 이번 DB강의가 처음인 분들도 계셔서 이 강의에 맞는 부분으로만 이론 기초 설명을 진행한다고 하셨습니다.

DB관리 계정은 SYS 와 SYSTEM 이 있습니다.

sys계정으로 접속하는 것은 조금 특이한 방법이 있는것을 알고는 있었지만 conn / as sysdba로 바로 로긴이 가능 한 것은 오늘에서야 알게 되었습니다.

DB구조를 나타내는 그림에서 이번 DB백업과 복구에 관련이 깊은 Redo log buffer에 관해 책 내용을 설명 해 주셨습니다.

select * from v$datafile;

SQL> select name from v$datafile;

NAME
--------------------------------------------------------------------------------
/u01/app/oracle/oradata/orcl/system01.dbf
/u01/app/oracle/oradata/orcl/sysaux01.dbf
/u01/app/oracle/oradata/orcl/undotbs01.dbf
/u01/app/oracle/oradata/orcl/users01.dbf
/u01/app/oracle/oradata/orcl/example01.dbf

조회를 해 보니 아까 VM ware에서 확인한 Datafile이 있는것을 확인할 수 있습니다.

SQL> select * from v$logfile;

    GROUP# STATUS  TYPE
---------- ------- -------
MEMBER
--------------------------------------------------------------------------------
IS_
---
         3         ONLINE
/u01/app/oracle/oradata/orcl/redo03.log
NO

         2         ONLINE
/u01/app/oracle/oradata/orcl/redo02.log
NO

         1         ONLINE
/u01/app/oracle/oradata/orcl/redo01.log
NO

위의 결과는 Redo log파일을 조회한 결과입니다.

이번에는 실습을 하는 파일을 Text파일로 주시지는 않으시고 인쇄만 해서 주셨습니다. 직접 타자를 쳐서 실습을 하게 만드신 것 같은데 4번의 강의를 들으면서 계속 다른 방식으로 강의를 하시는 것이 흥미롭기도 하고 개인적으로는 직접 손으로 실습을 해 보는것이 더 도움이 된다고 생각을 하지만 지난 실습을 txt파일에서 복사 붙여넣기만 하는것이 많이 편해진 것인지 직접 타자를 치는게 달갑지만은 않지만 더 기억에 남을 것 같습니다.

쉬는시간 2장의 실습을 진행해보겠습니다.

1. DB에서 모든 DBfile의 이름을 찾는데 사용하는 v$뷰를 질의하시오.

SQL>

Select name FROM v$datafile;

현장감 있는 실습 1의 결과입니다. 결과가 깔끔한 경우에는 추후에는 text형식으로 붙여넣도록 하겠습니다.

2. 현재 온라인 Redo log 그룹과 데이터베이스에 있는 모든 redo log 파일의 이름을 찾는데 사용하는 V$뷰를 질의하시오.

SQL> SELECT group#, status FROM v$log;

    GROUP# STATUS
---------- ----------------
         1 INACTIVE
         2 INACTIVE
         3 CURRENT

3. DB에 있는 모든 컨트롤파일의 이름을 찾는데 사용하는 V$뷰를 질의하십시오.

SQL> SELECT name FROM v$controlfile;

NAME
--------------------------------------------------------------------------------
/u01/app/oracle/oradata/orcl/control01.ctl
/u01/app/oracle/flash_recovery_area/orcl/control02.ctl

4. DB이름을 찾는데 사용하는 V$뷰를 질의하시오

SQL> SELECT name FROM v$database;

NAME
---------
ORCL

5. 디스크에 쓰여지기 전에 메모리에 복구정보를 버퍼링하는 SGA의 메모리영역을 구성하는 초기화 매매개변수는 무엇입니까?

LOG_BUFFER

6. 대용량 풀은 무엇이고 언제 사용되며, 이것을 구성하는 초기화 매개변수는 무엇입니까?

대용량 풀이란 IO 슬레이브가 필요한 경우나 Recovery Manager를 위해 정보를 버퍼링하는데 사용될 수 있는 SGA의 한 영역입니다. 대용량 풀은 RMAN을 사용할 때 백업 및 복원 속도와 효율성을 향상시킵니다.

LARGE_POOL_SIZE 매개변수는 SGA에서 할당되는 바이트수를 지정합니다.

======================================    3    ======================================

실습을 확인하셨고 V$LOG에 대한 설명을 추가로 해주셨습니다.

SQL> SELECT *  FROM v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES  BLOCKSIZE    MEMBERS ARC
---------- ---------- ---------- ---------- ---------- ---------- ---
STATUS           FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME
---------------- ------------- --------- ------------ ---------
         1          1          4   52428800        512          1 NO
INACTIVE                821270 29-JAN-14       841850 29-JAN-14

         2          1          5   52428800        512          1 NO
INACTIVE                841850 29-JAN-14       867857 15-FEB-16

         3          1          6   52428800        512          1 NO
CURRENT                 867857 15-FEB-16   2.8147E+14

책 21페이지와 함께 보아야 할 것 같습니다. 현재 실습환경을 그림으로 표현해 준 그림이 있으며 그 내용은 위의 SQL을 조회한 내용과 같습니다.

RAC는 instance별로 Redo log 그룹을 관리해야 한다고 설명을 해 주셨습니다. 그것을 Thread를 만들어 관리합니다.  위의 조회 내용에 THREAD#가 1만 있습니다. 그 이유는 RAC와 같지 않기 때문입니다.

Log writer가 redo log파일에 기록을 합니다. 다 기록을 하면 다른 그룹에 자동적으로 기록을 합니다. 이 과정을 Log switch라고 합니다.

SQL> alter system switch logfile;

System altered.

SQL> SELECT *  FROM v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES  BLOCKSIZE    MEMBERS ARC
---------- ---------- ---------- ---------- ---------- ---------- ---
STATUS           FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME
---------------- ------------- --------- ------------ ---------
         1          1          7   52428800        512          1 NO
CURRENT                 871704 15-FEB-16   2.8147E+14

         2          1          5   52428800        512          1 NO
INACTIVE                841850 29-JAN-14       867857 15-FEB-16

         3          1          6   52428800        512          1 NO
ACTIVE                  867857 15-FEB-16       871704 15-FEB-16

한 그룹을 쓰고 다음 정보를 쓸 때 Log 그룹이 생기고 위의 작업은 수동으로 Log Switch를 시킨 경우입니다.

크기는 50MB정도 되 보입니다. memeber가 전부 1개씩 있습니다.

 FIRST_CHANGE#     FIRST_TIM

871704                     15-FEB-16 

SQL> SELECT current_scn FROM v$database;

CURRENT_SCN
-----------
     871900

시간이라는 개념과 SCN(System Change Number)중 SCN이 더 정확합니다. 시간을 정확하게 표현하는 것 보다는 SCN을 정확하게 표현하기 쉽습니다. 이것은 인터넷 쇼핑의 주문시간과 주문번호에 비유하여 생각하시면 더 이해하기 쉬울 것 같습니다. SCN은 DB에서는 시간과 같은 개념입니다. DB의 시간은 OS의 시간을 따라갑니다. 따라서 OS의 시간을 변경하는 경우 DB에 시간이 중복되는 값이 생길 수 있습니다. 하지만 SCN은 중복될 경우가 없기 때문에 시간보다 더 정확하게 각각을 구분할 수 있습니다.

FIRST CHANGE와 NEXTCHANGE를 비교하여 시간의경과를 확인할 수 있습니다.

2장 실습 계속

실습 8.

이중화를 할 때

SQL> alter database add logfile member
  2  '/u01/app/oracle/oradata/orcl/redo01b.log' to group 1;

Database altered.

SQL> alter database add logfile member
  2  '/u01/app/oracle/oradata/orcl/redo02b.log' to group 2;

Database altered.

SQL> alter database add logfile member
  2  '/u01/app/oracle/oradata/orcl/redo03b.log' to group 3;

Database altered.

책에서와 달리 하나하나 적용을 하였습니다. 책과 같이 쉼표로 구분하여 member를 처리할 수 있습니다.

실습 9.

다시 조회를 해 보면 아래와 같습니다

SQL> SELECT member FROM v$logfile;

MEMBER
--------------------------------------------------------------------------------
/u01/app/oracle/oradata/orcl/redo03.log
/u01/app/oracle/oradata/orcl/redo02.log
/u01/app/oracle/oradata/orcl/redo01.log
/u01/app/oracle/oradata/orcl/redo01b.log
/u01/app/oracle/oradata/orcl/redo02b.log
/u01/app/oracle/oradata/orcl/redo03b.log

6 rows selected.

굵게 처리를 한 부분이 이중화를 하여 생성한 것입니다.

SQL> SELECT * FROM v$log;

    GROUP#    THREAD#  SEQUENCE#      BYTES  BLOCKSIZE    MEMBERS ARC
---------- ---------- ---------- ---------- ---------- ---------- ---
STATUS           FIRST_CHANGE# FIRST_TIM NEXT_CHANGE# NEXT_TIME
---------------- ------------- --------- ------------ ---------
         1          1          7   52428800        512          2 NO
CURRENT                 871704 15-FEB-16   2.8147E+14

         2          1          5   52428800        512          2 NO
INACTIVE                841850 29-JAN-14       867857 15-FEB-16

         3          1          6   52428800        512          2 NO
INACTIVE                867857 15-FEB-16       871704 15-FEB-16

다중화가 된 것을 위의 붉은색 부분을 통해 확인할 수 있습니다.

실습 7번의 내용은 추후에 나오면 설명을 해 준다고 하셨습니다.

----------실습은 이상으로 마치고 계속 이론 내용수업을 진행하셨습니다 ----------

다중화된 Control file을 설명해 주셨습니다.

SQL> SELECT * FROM v$controlfile;

STATUS
-------
NAME
--------------------------------------------------------------------------------
IS_ BLOCK_SIZE FILE_SIZE_BLKS
--- ---------- --------------

/u01/app/oracle/oradata/orcl/control01.ctl
NO       16384            594

/u01/app/oracle/flash_recovery_area/orcl/control02.ctl
NO       16384            594

control file을 조회해보면 위와 같습니다.

다중화는 2개정도가 적당합니다.

실습을 위해 2번째의 control file을 없애고 다시 다중화 해 보겠습니다.

SQL> show parameter control_files

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
control_files                        string      /u01/app/oracle/oradata/orcl/c
                                                 ontrol01.ctl, /u01/app/oracle/
                                                 flash_recovery_area/orcl/contr
                                                 ol02.ctl

아래의 SQL은 경로명이 틀리지 않도록 해야합니다.

SQL> ALTER SYSTEM SET
  2  control_files='/u01/app/oracle/oradata/orcl/control01.ctl'
  3  scope=spfile;

System altered.

그리고  DB를 내립니다.

SQL> shutdown immediate
Database closed.
Database dismounted.

그리고 다시 DB를 올리면

SQL> startup
ORACLE instance started.

Total System Global Area  849530880 bytes
Fixed Size                  1339824 bytes
Variable Size             511708752 bytes
Database Buffers          331350016 bytes
Redo Buffers                5132288 bytes
Database mounted.

Database opened.

SQL> show parameter control_files

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
control_files                        string      /u01/app/oracle/oradata/orcl/c
                                                 ontrol01.ctl

조회해보면 1개로 줄어든 것을 확인할 수 있습니다

다중화는 다른 디스크에 다른 경로면에 해 주는것이 좋습니다. 아래에서는 실습을 편하게 하기 위해서 동일한 경로에 진행을 할 예정입니다.

SQL> ALTER SYSTEM SET
  2  control_files='/u01/app/oracle/oradata/orcl/control01.ctl',
  3  '/u01/app/oracle/oradata/orcl/control02.ctl'
  4  scope=spfile;

System altered.

(실습중 DB를 내리기 전에 위의 문장이 잘못되있을 경우 다시 실행하시면 됩니다.)

Control  파일은 자동으로 복사가 되지 않아 OS명령어로 복사를 해 줘야합니다.

exit하여

[oracle@ocpdba ~]$ cd /u01/app/oracle/oradata/orcl/

경로를 옮겨 아래의 명령을 실행하여 복사를 하고

[oracle@ocpdba orcl]$ cp control01.ctl control02.ctl
[oracle@ocpdba orcl]$ ls
control01.ctl  redo01b.log  redo02.log   sysaux01.dbf  undotbs01.dbf
control02.ctl  redo01.log   redo03b.log  system01.dbf  users01.dbf
example01.dbf  redo02b.log  redo03.log   temp01.dbf
[oracle@ocpdba orcl]$

확인 후 DB를 시작합니다.

SQL> startup
ORACLE instance started.

Total System Global Area  849530880 bytes
Fixed Size                  1339824 bytes
Variable Size             511708752 bytes
Database Buffers          331350016 bytes
Redo Buffers                5132288 bytes

Database mounted.
Database opened.

다시 조회를 해 보면 아래의 02번 파일 이 생성된 것을 확인할 수 있습니다.

SQL> SELECT name FROM v$controlfile;

NAME
--------------------------------------------------------------------------------
/u01/app/oracle/oradata/orcl/control01.ctl
/u01/app/oracle/oradata/orcl/control02.ctl

 백업과 복구에서 안정하게 유지를 하기 위해 하는 작업 4가지 중 2가지를 오늘 해 보았습니다. 그 2가지는 Redo log의 다중화와 Control file의 다중화를 하였습니다.

scope은 Memory, both, spfile이 있습니다.

Q&A

Q . spfile은 무엇입니까?

A.

Alter system set p_name=values scope=both;

는

Alter system set p_name=values;

와 같습니다.

both는 Memory와 spfile을 같이 바꾸는 것 입니다.

Alter system set p_name=values scope=memory;
위는 동적인 변경이고 Control file은 동적으로 변경을 할 수 없어서 scope을 spfile로 주고 DB를 내렸다가 올려야 합니다.

Alter system set p_name=values scope=spfile;

오늘은 정말 여유있게 식사를 해서 기분좋게 강의를 들으러 왔습니다.

설 연휴 준비를 위해 다들 일찍 들어가는 모습을 보았지만 불굴의 의지로 강의를 들으러 왔습니다.

EM으로 메모리 어드바이져 PGA확인

PGA의 세부정보를 더 보면 아래와 같습니다. 위에서는 적중률이 100%로 상당히 이상적인 수치임을 확인할 수 있습니다.

지금 권고사항을 확인하면 넉넉한 상황입니다.

<<실습>>

SQL> show parameter pga

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
pga_aggregate_target                 big integer 284M
SQL>

pga_aggregate_target이 설정되었으면 자동!!!

그럼 수동은 뭔가 하면...?

SQL> show parameter area_size

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
bitmap_merge_area_size               integer     1048576
create_bitmap_area_size              integer     8388608
hash_area_size                       integer     131072
sort_area_size                       integer     65536
workarea_size_policy                 string      AUTO
SQL>
 

위에는 지금 자동으로 되고 있지만 수동으로 바꾸면 위의 값이 아닌 sort_area_size                       integer     65536 로 잡히게 됩니다. (64K)

따라서 64K이상이면 Multipass가 발생할 수 있습니다. 그러면 성능이 저하되겠네요.

AUTO로 할 때의 장점은 위의 수동설정보다 훨씬 많은 값을 사용할 수 있습니다. 예를들어 64K를 위와 같이 쓴다고 할 때 PGA에 여유가 있으면 64K이상의 값을 사용할 수 있습니다. 수동으로 하는 것 보다 Temp ~ 에 가는것이 적어서 성능이 더 좋습니다.

PGA의 히스토그램도 볼 수 있습니다. 위의 통계정보를 계속 보면 아래와 같습니다.

위의 붉은 부분 이상이 되면 성능이 더 개선되지 않으므로 최적의 성능을 원한다면 저정도로 설정을 하면 되는것을 알 수 있습니다.

위의 보고서에서 Direct path read/write temp가 있는지 확인을 하여 튜닝을 할 수 있습니다.

WITH로 시작하는 SQL를 사용하는 것인 서브쿼리 펙토링을 설명해주셨습니다. 성능을 좋게하기 위해서 사용한다고 하셨습니다. 좋은 예제를 찾는데 시간이 좀 걸리셨고 Oracle문서에서도 바로 찾지 못하셨습니다.

subquery factoring 으로 구글에 검색을 하셔서 몇분동안 예제를 찾아보셨습니다.

 subquery factoring 은 깊게 봐야 더 좋다고 하셨습니다.

한번 읽어온 자료를 다시 활용하려면 Sub query를 사용하거나 in line view를 만들어 주어야 하지만 WIth문을 써서 하면 또 읽는것을 막고 Temp Table Space에 있는것을 읽어서 성능을 높이는 방법을 써서 성능을 높일 수 있습니다.

Create Index를 하면 PGA WA(work area)에서 작업을 합니다.

이번에는 Table Space를 보겠습니다. 보통은 자동으로 계속 늘어나게 설정이 되어있고 자동으로 늘어나는 것이 위험할 수 있는데 작업을 하다가 잘못하여 자동으로 계속 늘어나 Full나게 되면 DB가 죽을 수 있습니다. (100%이해는 안되지만 강사님의 설명을 직접 옮겼습니다.)

 그래서 Temp Table space를 생성해보겠습니다.

Temp table space를 여러개 성성하여 그룹으로 묶으면 한 사용자가 사용할 때 IO가 분산되어 좋은 성능을 발휘할 수 있습니다.

===================================== 2 ===========================================

오늘은 9시 이후에 개인 사정으로 10시까지 강의를 듣지 못할 수 있을 것 같습니다.

명절에 무엇을 할 지..... 흠.... 명절에는 TV 보고 자고 먹고.... 그럴 것 같군요.... 강사님께서도 비슷하신 것 같습니다.

SQL> show parameter memory_target

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
memory_target                        big integer 0

0인걸 보니 수동인 것 같습니다.

SQL> show parameter db_cache_size

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_cache_size                        big integer 0
SQL> alter system set db_cache_size=250m;

System altered.

SQL> show parameter db_cache_size

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
db_cache_size                        big integer 252M

EM에서 메모리권고자()를 다시한번 보겠습니다. 자동관리는 위의 파이그래프에 있는 항목들만 가능합니다. 다 더한값은 SGA 의 최대 사이즈를 초과할 수 없습니다.

위의 구성요소를 제외한 것들은 자동으로 늘거나 줄지 않습니다. 그 중에는 리두로그버퍼가 있습니다.

DB성능관리와튜닝_데모스크립트.txt

alter system set sga_target=0;   -> 수동으로 설정함

SQL>  show parameter sga_target;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
sga_target                           big integer 528M

2. 반자동 (script)

반자동은 하한값을 설정하되 서로 조절이 가능 하도록 정말 최저로 낮게 설정을 하여 변화가 유동적으로 되도록 하되 최 하한 밑으로는 내려가지 않도록 할 때 유용합니다.

ASMM을 사용하고 있는것을 확인할 수 있습니다.

SELECT component, current_size/1024/1024
FROM V$SGA_DYNAMIC_COMPONENTS;

COMPONENT
----------------------------------------------------------------
CURRENT_SIZE/1024/1024
----------------------
shared pool
                   152

large pool
                     4

java pool
                     4

streams pool
                     4

DEFAULT buffer cache
                   252

KEEP buffer cache
                     0

RECYCLE buffer cache
                     0

DEFAULT 2K buffer cache
                     0

DEFAULT 4K buffer cache
                     0

DEFAULT 8K buffer cache
                     0

DEFAULT 16K buffer cache
                     0

DEFAULT 32K buffer cache
                     0

Shared IO Pool
                     0

ASM Buffer Cache
                     0

14 rows selected.

SQL>
SQL> show parameter memory_target

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
memory_target                        big integer 0

SQL> show parameter memory_max_target
NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
memory_max_target                    big integer 812M

SQL> show parameter sga_target

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
sga_target                           big integer 424M

//설정값을 변경해보겠습니다.

SQL> alter system set memory_target = 812m;

System altered.

SQL> show parameter memory_max_target

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
memory_max_target                    big integer 812M
SQL> show parameter memory_target

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
memory_target                        big integer 812M

재시작을 해야 바뀌는 값들을 확인하기 위해 강사님께서 DB를 재시작하는 것을 보여주셨습니다.

예를들면 

동기들의 배려로 불짬뽕 곱배기를 정말 맛있게 콧물 질질 흘리면서 먹고(완뽕은 못했네요) 올라와서 강의를 듣습니다. 오늘도 열심히 듣고싶지만 회사일의 여파가 가시지를 않는 상황입니다. 흠.... 하소연은 그만하고 힘내서 수강을 시작합니다.

오늘은 어제에 이어 ADDM권장사항에 대한 이론내용부터 수강을 시작합니다.

예전의 열악한 IT기업환경.... 군대문화와 비슷한 일들이 많았다는 이야기도 전설처럼 이야기 해 주셨습니다.

https://192.168.0.200:1158/em/ -> EM에 들어가서 sys/oracle SYSDBA로 접속을 하시면 오늘도 EM을 활용하실 수 있습니다.

보고서 실행을 하는데 EM이 죽어서 결국은 스크립트로 확인을 해 보겠습니다.

스크립트도 보기 힘들어 VM ware에서 확인하였습니다. Putty에서 vi편집기로 열어도 HTML형식이기 때문에 보기 몹시 불편했습니다.

CMD창에서 DB정보 보는법?

[oracle@ocpdba ~]$ df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/sda1              18G   12G  5.8G  67% /
none                 1014M  529M  486M  53% /dev/shm

이후에는 내일 수업을 나오지 못하는 사람들을 위해 빨리 빨리 넘어가면서 이론 수업 위주로 진행을 하셨습니다.

=====================================   2   =========================================

강사님께서 피곤해하는 수강생을 위해 재미있는 이야기를 해주셨습니다.

"국수와 국시?  그 둘의 차이를 아세요?"

국수는 밀가루로... 국시는 밀가리로 만드는거라는...... 으,...춥다....

국수는 아주머니가 파시고 국시는 아지매가 파는것이라네요.....

국수는 봉지에 국시는 봉다리에 담아 준다고 합니다....... ( 겨울이 다시 오려나봐요.. )

표준어와 사투리의 차이에 관한 농담인것 같지만 더 옮기는것은 얘의가 아닌거 같아서 이만 하겠습니다.  위의 것 외에도 엄청난 콤보들이 계속 이어지는

아이와 얼라 학교와 핵교, 선생님과 선상님 등........ 허허허허허허허헣

결국 국수와 국시의 차이는 사투리였다는....

간단한 이론설명을 조금 하시고 그 후에는 또 Oracle문서에 대해서 설명을 해 주셨습니다.

Database 2 Day + Performance Tuning Guide

http://docs.oracle.com/cd/E11882_01/server.112/e10822/toc.htm

Oracle의 문서는 ORACLE에서 제공하는 중요한 문서라고 강조를 재차 하셨습니다.

우리나라의 문제점의 시작이라는 영어에 대한 거부감... 영어권 국가는 훨씬 더 빠르게 읽을 수 있어서 또한 있는줄도 모르는 경우도 많아서 영어권 국가에 피해 훨씬 적응이 느리고 습득이 느릴 수 밖에 없다고 하셨습니다.

전에는 이런 문서들이 많지 않았고 번역을 하여 책으로 만들어서 제품의 안내책자를 주는 경우가 많았는데 요즘 그런것들이 줄어들면서 점점 더 문서를 보지 않게되는 문제들이 생겼다고 하셨습니다.

문서를 보기는 보되 빠르게 읽는것을 강조하셨습니다. 속독을 하고 눈에띄는 부분에 대해 정독을 하는 방법을 권하셨습니다. 도움이 되는 서적도 많지만 Oracle의 문서가 가장 정확한 부분이 있을 수 있으므로 Oracle의 문서의 중요성을 3차로 강조하셨습니다.

그 후로는 My oracle support site에 대해 소개해주셨습니다. Oracle과 support계약이 체결된 회사에만 제공이 된다고 합니다.....

SQL> show sga

Total System Global Area      849530880 bytes
Fixed Size                            1339824 bytes
Variable Size                     461377104 bytes
Database Buffers                381681664 bytes
Redo Buffers                        5132288 bytes

SYSDBA계정으로 위의 문장을 실행하면 위의 결과를 얻을 수 있습니다.

====================================    3    ========================================

커서의 공유여부(115page)부터 이론수업을 이어가셨습니다.

내일(금)업무가 끝나면 본격적으로 설 연휴가 시작되기 때문에 강사님께서도 선덕선덕하신 것 같습니다.

Shared pool의 크기를 조정하는 가장 좋은 방법은 자동 공유 메모리 관리를 활용하는 것입니다.

 EM의 서버 tab으로 이동하셔서 데이터 베이스 구성의 첫번째 항목인 메모리 권고자를 누르면 아래의 화면을 확인하실 수 있습니다.

휠을 내려 아래로 내려보면 자동으로 관리가 되어 변경되는 것을 확인할 수 있습니다.

위의 화면은 EM 이전에 보던 page에서 메모리 권고사항 버튼을 클릭 한 화면입니다.

SQL> show parameter memory_target

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
memory_target                        big integer 812M

SQL> show parameter pga

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
pga_aggregate_target                 big integer 284M
SQL> show parameter sga

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
lock_sga                             boolean     FALSE
pre_page_sga                         boolean     FALSE
sga_max_size                         big integer 812M
sga_target                           big integer 528M
SQL>

아래 화면에서 볼 수 있듯이 메모리 자동관리를 사용하지 않음으로 설정을 하고 그 다음에 SGA의 권고사항을 살펴보겠습니다. 

SGA는 지금 크기가 부족한 것을 위의 권고사항을 보고 확인할 수 있습니다.

수동으로 관리를 하면 크기를 적정하게 직접 설정을 해 주어야 하고 그 적정한 값을 찾는것 또한 관리자가 스스로 해야한다는 것입니다.

물론 권고자(Advisor)의 정보를 확인하여 할 수 있지만 가능하면 자동 공유 메모리 관리를 사용하는 것이 좋습니다.

위의 화면은 리포트를 분석해 왜 buffer gets가 많은지 분석하고 SQL문장을 확인한 결과 SQL튜닝이 필요하다는 결론을 얻을 수 있었습니다.

또한 강사님께서 강의를 정리하시면서 자신만의 환경을 구축하여 실습 및 분석을 하는것이 DB를 관리하고 정보분석 튜닝등에 많은 도움이 될 수 있다고 하셨습니다.

script -> ** Private pool에 대한 설명을 하셨습니다. -> 이것은 Buffer cache에 쓰지않아 Buffer cache에 성능을 올릴 수 있고 Private pool또한 성능이 뛰어납니다.

오늘은  일찍나오지는 못했지만 비빔밥을 동기들과 먹고 와규(?) 선물세트를 챙겨서 강의를 들으러 왔습니다.

오늘 강의의 시작은 2일간의 강의 전반적인 응답을 수강생들에게 들어보시면서 간단하게 수강 느낌을 물어보시고 시작을 하였습니다.

DBMS에 대한 선행지식이 필요하다는 것, DB관련 통계를 보고 그 내용을 분석하여 성능적인 부분에 대해 비교를 할 수 있어야 한다고 하셨습니다.

'단순히 사무적으로 관리를 잘해서 성능이 좋아졌다'라는것이 형식적인 내용이 아니라 사람의 이야기와 비교하여 "건강하고 숨잘쉬고 하면 된다."는 그런 추상적이로 일반적인 내용이 아니라 구체적으로 성능 개선을 위한 과정의 일부를 확인하시는 것이 이 과정에 대한 도움을 줄 수 있다고 하셨습니다.

경력과 배경 지식에 따라 이해하기 어려울 수 있지만 이 과정을 뒤로 갈 수록 강의를 듣는데에 수월할 수 있다고 이야기하셨습니다.

설명은 Statspack 설명을 하셨습니다.

*** STATSPACK <<실습 계속>>

 "PERFSTAT" user로 작업을 하기위해 해당 user로 로그인을 합니다.

리포트를 생성하고 확인하는 실습입니다.

conn perfstat/oracle

exec statspack.snap;

variable snap number;

begin
:snap := statspack.snap;
end;
/

print snap

alter session set nls_date_format = 'yyyy-mm-dd hh24:mi:ss';

select SNAP_ID, SNAP_TIME, SNAP_LEVEL
from STATS$SNAPSHOT
order by SNAP_ID ;

@?/rdbms/admin/spreport

그리고  exit하여 ls로 파일을 조회하면 "sp_1_2.lst"라는 파일이 생성되어 있습니다. vi편집기로 확인한 화면은 아래와 같습니다.

강사님께서는 VM안의 Linux에서 메모장을 열어서 보여주셨습니다.

Snapshot       Snap Id     Snap Time      Sessions Curs/Sess Comment
~~~~~~~~    ---------- ------------------ -------- --------- ------------------
Begin Snap:          1 03-Feb-16 19:17:35       35       3.3
  End Snap:          2 03-Feb-16 19:18:32       35       3.3
   Elapsed:       0.95 (mins) Av Act Sess:       0.1
   DB time:       0.05 (mins)      DB CPU:       0.02 (mins)

위와같이 snapshot의 생성시점 및 각종 정보들이 보이는 것을 확인할 수 있습니다.

내용을 vi편집기에서 계속 확인하면 첫날 다루었던 top5의 대기시간 정보도 있습니다.

아래화면은 CPU 사용을 많이 한 SQL문에대한 보고 내용입니다.

이 외에도 statspack의 리포트는 많은 정보들을 확인할 수 있습니다.

메모리 구성요소 및 변화, Data buffet cache관련 정보, wait정보, PGA에 관한 통계정보, PGA에 대한 Memory advise, Latch 관련 내용, Data dictionary Cache, shared pool에대한 advise정보, memory 사용량, 초기화 Parameter값에 대한 정보까지 포함하고 있습니다.

리포트를 확인하고

CMD창에서 exp perfstat/oracle file=orcldb.dmp를 입력하여 Export를 할 수 있습니다.

다음은 리포트를 보기위해 하나찍고 다른 계정에서 일정 작업을 해서 부하를 주고 그 후에 스냅샷을 찍어 그 사이의 변화량을 리포트로 확인해보겠습니다.

두개의 창에서 왼쪽은 SYSDBA , 오른쪽 하늘색 창은SCOTT 사용자입니다.

Load Profile  Section을 확인하시면 됩니다.

redo size는 작업이 많을수록 늘어나는 통계값.

=====================================    2    =======================================

건강검진 결과를 하나 검색을 하셔서 보여주시는 비유를 보여주시면서 두번째시간의 강의를 시작하셨습니다. 그 이유는 BaseLine에 대한 설명을 하기 위해서였고, 건강검진의 결과만 보고도 오랜 경험이 있으면 알 수 있을지 모르지만 비교의 기준이 될만한 정보를 알 수 있어야 하고 그러한 것을 BaseLine이라고 합니다.

DB의 통계정보도 더 의미있는 정보와 비교를 통해 성능분석을 하기 위해서 baseline을 즉, 정상적인 범위의 수치에 대한 정보가 필요합니다.

DB튜닝도 건강관리처럼 부하를 없애는 것이 목표가 아니라 정상범위로 만드는 것이 목표라고 생각하시면 이해하기가 쉽다는 설명을 해 주셨습니다. 예로는 고혈압인 사람의 혈압을 없애는(?)것이 아니라 정상 혈압으로 낮추는 처방을 하는 것입니다.

Report를 확인하여 top에 있는 것들을 튜닝의 대상인지 고려해 볼 필요가 있습니다. 튜닝이 이미 완료가 되있거나 더이상 성능개선의 여지가 없는 문장도 top에 등장할 수 있습니다.

====================================     3     =======================================

AWR에 관한 이론내용부터 강의를 시작하셨습니다. 이번주 금요일은 설 연휴의 전날로 지난번 못지 않게 많은 수강생들이 결석할 것을 고려하여 간단하게 수강생들의 출석의지를 확인하셨습니다.

EM에 접속하여 정보를 확인해보겠습니다.

홈 성능 가용성 서버 스키마 ...

서버 탭을 보시면....

위의 화면에서 스냅샷 번호를 누르면 아래의 화면이 나옵니다.

강의 시간 일정에 맞게 스냅샷이 찍힌 것을 확인할 수 있습니다.

스냅샷은 X-ray와 비슷한 느낌으로 DB의 정보를 쭉 읽어서 저장하는 느낌입니다.

EM에서도 스냅샷을 생성할 수 있습니다.

EM을 통해서 statspack report처럼 보고서를 만들어보도록 하겠습니다.

AWR reoprt는 Text형식과 HTML형식으로 만들 수 있습니다.

실습을 또 진행하겠습니다 어제 예고하셨던 어제것을 보기 힘들어 새로 만들겠습니다.

위의 화면은 부하를 준 후의 성능분석 화면입니다. 실시간 tool의 장점을 확인할 수 있습니다.

VM안에서 생성한 보고서를 확인하는 화면입니다. Applications -> file browser로 열어서 보고서 파일을 열면 위와같은 화면을 볼 수 있습니다.

 스냅샷을 2개 더 찍고

@?/rdbms/admin/awrddrpt.sql
<< 비교 리포트를 만드는것>>

위의 문장을 실행하여 리포트를 만들고 VM화면에서 확인을 해 보겠습니다. 그 화면은 아래와 같습니다.

Load Profile 부분을 비교리포트를 보면 위와 같습니다.

아래 화면은 EM 메인화면의 하단 관련링크 파트의 중앙권고자를 눌러 확인한 화면입니다.

@?/rdbms/admin/addmrpt

수동분석을 위해 작업을 하고 화면을 보았는데

강사님 화면에서는 ADDM이 결과를 찾았지만  제 환경에서는 찾지 못했습니다.

태어난지 9800일!!!!! 째가 되는 날입니다.....ㅎㅎㅎㅎ

오늘은 구로 어드벤쳐라고 할 만큼 회사에서 업무를 마치고 강의장까지 역동적인 길을 걸어왔습니다. 힘겹게 버거를 먹고 오늘도 수강을 시작합니다.

사용자 접속을 통해 Black 관련 실습을 진행하였는데 이해를 하지 못했습니다.

로긴을 2개의 사용자로 해야 하는데 그것을 하지 못했습니다.

DB성능관리와튜닝_데모스크립트.txt

오늘은 위의 파일을 받았습니다. 스크립트입니다. 실습 과정을 적어둔 파일입니다.

** V$SYSSTAT

select name, VALUE from v$sysstat order by 2;

통계 정보를 조회한 화면입니다.

위의 화면에서 확인할 수 있는 것 처럼 604건의 항목이 있습니다. 이런 정보들은 DB를 사용하는동안 계속 변합니다. 예를 들면 Session connect time 등도 계속 늘어나기 마련입니다.

DB시작 이후로 누적되는 정보이기 때문입니다. 누적된 정보를 조회하는 것은 사실상 큰 의미가 없습니다.

v$sesstat을 조회하면 알아먹기 힘든 ..... 그런 상황입니다. 뭔가 이해할 수 있는 정보로 만들기 위해서는 V$SYSSTAT 과 조인해야합니다.

select a.*, b.name
from V$SESSTAT a, V$STATNAME b
where a.STATISTIC# = b.STATISTIC#
and a.sid=28;

HR 접속자의 DB사용 통계를 조회하면 아래와 같습니다.

뭔가 역시나 알아볼 수 없는 내용들입니다.

스크립트 <<** Oracle Wait Event>> 부분을 설명해주셨습니다.

===================================   2   ===========================================

Oracle의 Graphical tool을 이용할 준비를 하겠습니다.

바로 위의 두번째 화면의 명령은 시간이 조금은 오래 걸리는 편입니다.

첫 화면은 리스너를 실행하는 것입니다.

https://192.168.0.200:1158/em 을 Chrome 브라우저의 주소창에 입력을 하시면

사용자 계정은 sys, 비밀번호는 Oracle

SYSDBA로 접속을 하시면 됩니다.

비밀번호 만료에 대한 화면이 나오면 과감하게 확인을 누르고 넘어가시면 됩니다.

위의 화면은 EM(Enterprise Manager)화면입니다. oracle의 tool로 다양한 작업을 할 수 있습니다.

위의 화면은 이전 화면의 orcl을 클릭하여 해당 DB사용을 확인 한 화면입니다.

위의 화면은 이 전전 화면의 orcl대신 기타를 눌러서 호스트의 정보를 확인하는 화면입니다.

Graphical tool을 이용하면 편리한 부분이 있습니다.

CMD창에서 cd /u01/app/oracle/diag/rdbms/orcl/orcl/trace/  로 이동하여 ls *log 를 입력하면 alert_orcl.log라는 로그파일이 있습니다. 성능에 관한 정보를 볼 수 있습니다.

alert_orcl.log파일을 vi 편집기로 확인한 내용은 위와 같습니다. 약 3000여 라인으로 저는 확인했고 강사님께서는 계속 내용이 추가된다고 하셨습니다.

실시간 모니터링을 하는 기법인 tail을 걸어두도록 하겠습니다.

** Incomplete checkpoints

select EVENT, TOTAL_WAITS from v$system_event where event like '%log file switch%';

5M redo group 4, 5번 생성 후 기존 1, 2, 3번 group 삭제

select * from v$log;

alter database add logfile group 4 '/u01/app/oracle/oradata/orcl/redo04.log' size 5M;

alter database add logfile group 5 '/u01/app/oracle/oradata/orcl/redo05.log' size 5M;

alter system switch logfile;
<< 강제적으로 Log switch를 일으키는 문장 >>

select * from v$log;

current는 현재 쓰는 redo Log file 입니다.

alter system checkpoint;

alter database drop logfile group 1;

alter database drop logfile group 2;

alter database drop logfile group 3;

후에
select * from v$log; 로 조회를 해 보면

tail 걸어 두었던 화면을 확인하면 아래와 같습니다.

걸어두기 전과 달리 추가되는 내용들이 계속 확인이 되고 있습니다.

====================================   3   ========================================= 

위의 화면은 이전시간에 폭풍확인 후에 남은 화면에서 대기를 작업들이 어떻게 일어났는지를 볼 수 있습니다.

** SQL_TRACE

지난 SQL 튜닝 과정에서 자세하게 다루었습니다.

** V$뷰의 한계

select NAME, value
from v$sysstat where name like '%physical reads%';

델타값을 알 수 있도록 누적된 정보에서 의미있는 결과를 추출하기 위해서는 특정 기간을 두고 위의 조회를 두번 하여 해당 변화량을 확인하는 것이 의미있는 결과를 확인할 수 있는 방법입니다.

*** STATSPACK

** Install statspack
conn / as sysdba
@?/rdbms/admin/spcreate.sql
- perfstat password: oracle
- perfstat default TS : sysaux
- perfstat temp TS : temp

2월 1일... DB 성능관리와 튜닝 3번째 강의 첫시간입니다.

3주째 같은 강사님께 수업을 듣기 때문에 이제는 반갑게 인사를 할 수도 있습니다. 워낙 성격이 나긋나긋하지는 못한 편이지만요... 

쓸데없는 소리는 저기까지만 하고 오늘도 강의 , 수강을 시작하겠습니다.

과정에 대한 특징 설명으로 강의를 시작하셨습니다.

DB 서버에 대한 성능관리를 주로 다룰 예정입니다. 다른말로는 인스턴트 튜닝 혹은 서버튜닝 이라고 합니다.  Oracle DB를 사용할 예정입니다. 환경설정이 지난주에 거의 갖춰져있어서 걱정은 없고 Oracle 11g를 가지고 실습을 진행할 예정입니다.

튜닝이라는 것은 관련 문서를 보여드릴 예정이지만 튜닝은 크게 3가지로 나뉩니다.

 1) 성능계획. 성능관리 -> HW선정과 DB 설계 및 객체생성을 어떻게 효율적으로 할 것인지를 튜닝하는 부분입니다.

 2) SQL (app) 튜닝 -> SQL에 대한 내용입니다.

 3) DB 서버 (인스턴트) 튜닝

위의 2)와 3)을 비유를 하면 2가 자동차라면 3은 도로라고 비유할 수 있습니다. 물론 이 비유는 지난 강의때 나왔던거 보셨으면 기억 하실 수 있을 것이라고 생각합니다.

둘다 우열을 가릴 수 없을 정도로 중요합니다.

오늘도 수강생의 현황을 한번 파악을 해 주시면서 다양한 경험과 실력을 가진 수강생들이 모여있는 것을 알려주셨습니다.

이 DB성능관리와 튜닝이라는 과정은 어디가서 쉽게 들을수는 없는 과정입니다.

교제 내용으로 수업을 진행하셨습니다.

책 내용을 살펴보면 튜닝을 야기하는?? 10가지 실수에 대해 소개가 되어있습니다.

1. 잘못된 접속 관리

2. 커서와 Shared Pool의 잘못된 사용

3. 잘못된 SQL

4. 비 표준화 파라미터 사용

5. 잘못된 DB의 I/O구성

6. 온라인 리두 설정문제

7. 프리 리스트, 프리 리스트 그룹, 트렌잭션 슬롯의 부족 또는 언두 세그먼트의 부족으로 인한 버퍼 케시 내의 데이터 블록 직렬화

8. Long Full Table Scan -> 커다란 테이블을 통으로 읽는 것입니다.

9. 대량의 재귀 SQL -> Recursive SQL

10. 배포 및 이전 오류

위의 내용에 대한 자세한 설명은 책에 적어두었습니다.

===================================    2    ========================================

두 번째 시간은 실습환경을 구축하는 것으로 시작하였습니다. D 드라이브로 옮기면서 저도 다시 설치를 진행하였습니다.

이번에도 리눅스에서 터미널을 열고 SQL PLUS를 실행하여 sysdba계정으로 접속하여 DB를 시작(startup)하였습니다.

그리고 책에 이어지는 부분을 계속 설명해 주셨습니다.

DB 성능관리와 튜닝 개요라는 주제로 설명을 하셨습니다.

===================================    3    ========================================

튜닝 도구 ~ 

위의 범위에 해당하는 내용을 책을 가지고 내용설명을 진행하셨습니다.

수업 중 License관련 이야기를 하며 불법 S/W에 대한 이야기... 농담 반 진담 반이지만 개발자인 나 조차도 돈을 주고 S/W를 쓰지 않으려고 하는걸 보면.... 뭔가 이해가 가지 않는 아니러니 한 상황입니다.

Dynamic View까지 설명을 하시고 그 이후에는 실습을 진행하셨습니다.

V$ view

위의 블록 처리한 문장을 수행한 결과입니다.

책에 등장하는 예제입니다.

Oracle site에 또 왔습니다.

이번에는 http://docs.oracle.com/en/database/database.html 를 아예 즐겨찾기(북마크) 하였습니다.

11.2  ( 11g)로 확인을 하시기로 하셨습니다.
이 과정에서는 Reference를 많이 사용할 예정이라고 하였습니다.

 다운 받을 수 있다고 하셨는데 1306 페이지라서 포기하였습니다.

 사이트에 접속해서 위의 내용을 확인할 수 있습니다.

위의 두 화면은 분홍색 화면의 scott이라는 사용자가 사용한 SQL문을 SYS관리자 계정에서 몇번 사용되었는지를 조회해 보는 화면입니다.

11. 조인

SQL> conn system/oracle
conn / as sysdba
<<  Error 나면 sys계정에서 다시 해볼것 >>

SQL> grant plustrace to hr;

SQL> conn hr/hr

SQL> password
hr
hr
hr
<<  비밀번호가 변경되지 않는다면 !!
alter user hr identified by hr;
>>

SQL> @?/rdbms/admin/utlxplan

SQL> create table emp as select * from employees;

SQL> create table dept as select * from departments;

SQL> create table loc as select * from locations;

SQL> exec dbms_stats.gather_table_stats('HR', 'EMP');

SQL> exec dbms_stats.gather_table_stats('HR', 'DEPT');

SQL> exec dbms_stats.gather_table_stats('HR', 'LOC');

SQL> set autot trace

SQL> SELECT /*+ rule */ e.last_name, d.department_name, l.city
FROM emp e, dept d, loc l
WHERE e.department_id = d.department_id
AND d.location_id = l.location_id;

위 화면은 그 위의 SQL문장을 수행했을 때 나오는 실행계획입니다.

위화면의 내용은 Table 하나를 읽고 다른 Table을 반복적으로 읽는 실행계획입니다.

SELECT /*+ all_rows */ e.last_name, d.department_name, l.city
FROM emp e, dept d, loc l
WHERE e.department_id = d.department_id
AND d.location_id = l.location_id;

힌트를 주지 않아도 기본값(defualt)로 들어가는 all rows는 Hash join을 사용합니다.

위의 세 경우 모두 서로 다르지만 조인을 사용하였습니다.

위의 예제를 제시한 이유는 현실적인 것과 비 현실적인 것을 비교하기 위함입니다. Table을 여러개 join하면 위에서 비 현실적이라고 가정했던 것이 일어날 수도 있습니다.

 dept 테이블 PK(인덱스) 추가
SQL> alter table dept add constraint dept_deptid_pk primary key(department_id);

후 위의 과정을 다시 해 보면....

 table읽고 index읽고.... 반복.....

실행계획만을 보고 알 수 없음.

일반적으로 RBO와 CBO를 비교하면 CBO쪽이 좋고 CBO쪽에서도 All rows가 더 나은 실행계획을 생성하는 것을 확인할 수 있고 first row같은 경우는 인덱스 유무에 따라 성능저하를 가져올 수 있습니다.

Table이 엄청 크더라도 조회에 시간이 오래 걸리지 않을 수 있습니다.

사용자들이 오해하고 있는 것 중의 하나가 무조건 Hash조인을 선호하는 것입니다.

기본값을 All rows로 둔 이유는 Data를 상대적으로 많이 처리할 경우에 성능이 저하되기 때문입니다. 비유를 하자면 정말 가까운 거리는 차를 타고가나 걸어가나 뛰어가나 별 차이가 없을 수 있지만 서울에서 부산을 가는 정도의 거리라면 교통 수간에 따라 엄청난 시간차이가 날 수 있습니다. 이와 유사하게 생각하시면 될 것 같습니다.

====================================     2     =======================================

RBO의 경우는 조건이 비기면 From절의 뒤의 Table부터 읽음.

이론 위주로 교제 수업을 하시다가 Oracle의 문서를 보여주셨습니다.

Oracle Database Online Documentation 11g Release 2 (11.2)

Performance

http://docs.oracle.com/cd/E11882_01/nav/portal_17.htm 

===================================    3     =========================================

sqldeveloper-4.1.2.20.64-x64를 소개해주는 Demo로 마지막날 마지막시간의 강의를 시작하셨습니다.

M _ View작업

 5) Materialized View

SQL> conn / as sysdba

SQL> grant create view, create materialized view to scott;

SQL> conn scott/tiger

SQL> set autot on

SQL> set timing on
<< 위의 것은 시간정보 보게 >>

SQL> drop table test purge;

SQL> create table test
as
select * from emp;

SQL> begin
for i in 1..20 loop
insert /*+ append*/ into test
nologging
select * from test;
commit;
end loop;
end;
/
  -- 바로 위의 SQL문을 수행했을 때 5분여의 시간이 소요되었습니다.

16. 자동 SQL 튜닝

-- SQL Tuing Advisor (10g 이상)
SQL> drop table test purge;

SQL> create table test
as
select * from emp;

SQL> exec dbms_stats.gather_table_stats('SCOTT','TEST');

SQL> begin
for i in 1..20 loop
insert /*+ append*/ into test
nologging
select * from test;
commit;
end loop;
end;
/

SQL> select count(*)
from test;

SQL> insert into test(empno) values(4444);

SQL> commit;

SQL> select *
from test
where empno=4444;

SQL> create index test_empno_ix on test(empno);

SQL> select *
from test
where empno=4444;

SQL> select /*+ index(test test_empno_ix) */ *
from test
where empno=4444;

SQL> conn / as sysdba
-- ALTER SYSTEM SET control_management_pack_access='DIAGNOSTIC+TUNING';

SQL> declare
my_task_name VARCHAR2(30);
my_sqltext CLOB;
begin
my_sqltext := 'select * from test where empno=4444';
my_task_name := DBMS_SQLTUNE.CREATE_TUNING_TASK(
sql_text => my_sqltext,
user_name => 'SCOTT',
scope => 'COMPREHENSIVE',
time_limit => 300,
task_name => 'my_sql_tuning_task_1',
description => 'Task to tune a query on a specified table');
end;
/

SQL> begin
DBMS_SQLTUNE.EXECUTE_TUNING_TASK(task_name => 'my_sql_tuning_task_1');
end;
/

SQL> set long 10000

SQL> set longchunksize 1000

SQL> set linesize 100

SQL> set heading off

<< 리포트 결과를 조회하는 SQL문장 >>
SQL> select dbms_sqltune.report_tuning_task('my_sql_tuning_task_1')
from dual;

2가지 결과를 찾았습니다.

1. Optimizer통계가 오래 됬다는 내용입니다.

2. 더 나은 방법을 찾았다는 내용입니다.

SQL튜닝실습자료.txt

정리

CBO연구, 자동화된 SQL튜닝기법. Access adviser는 M view만드는거 index 추가 삭제까지 조언을 해줌.

활용할 수 있으면 하는것이 성능상에 도움을 줌.

<< 강사님의 들어가는말 >>

튜닝의 경우에는 여러 사람의 이야기를 들어보는 것이 좋습니다. 그 이유는 제테크와 비슷 한데 각각의 상황에 맞게 튜닝을 해야하기 때문입니다.

기본적으로 해야하는 것들도 있지만 개개인에 맞는 튜닝또한 존재하기 때문입니다.

튜닝은 정답이 있는것이 아닙니다. 

100점을 맞는 그러한 것이 거의 불가능 하다고 볼 수 있습니다. 그 이유는 한 부분을 고치면 다른 부분이 상대적으로 성능이 저하될 수 있기 때문입니다.

튜닝은 80점 정도 맞으면 합격점이라고 생각합니다.

튜닝의 목표!?

모니터링을 매일 하는것과 튜닝을 매일 하는것은 다르다. 계속해서 튜닝만을 할 수 없기 때문입니다. 그래서 목표를 설정하고 얼마만큼 튜닝을 할 것인지가 중요합니다. 

4) RBO 동작의 조정

(1) FROM 절에서 테이블 순서 변경

SQL> select /*+rule */ e.ename, d.dname
from emp e, dept d
where e.deptno=d.deptno
and e.empno=7788
and d.deptno=10;

Rule의 경우에는 조건이 동일한 경우 즉, Table을 접근하여 찾는 조건이 동일한 경우에만 뒷쪽의 Table을 먼저 읽습니다.

select /*+rule */ e.ename, d.dname
from dept d, emp e
where e.deptno=d.deptno
and e.empno=7788
and d.deptno=10;

위의 경우는 반대로 뒤에있는 emp table을 먼저 읽습니다.

AND는 앞에서부터 , OR의 경우는 뒤에서부터 읽습니다.

 (2) WHERE 절에서 술어 순서 변경

SQL> select /*+ rule */ * from dept
where deptno=10 and deptno=20;

SQL> select /*+ rule */ * from dept
where deptno=10 or deptno=20;

rule에서는 driven table이 될 뒤쪽 테이블에 좋은 조건의 Table을 써주는것이 좋습니다.

(3) syntax 트릭의 사용

SQL> select /*+rule */ e.ename, d.dname
from emp e, dept d
where e.deptno=d.deptno;

SQL> select /*+rule */ e.ename, d.dname
from emp e, dept d
where e.deptno=d.deptno + 0;

위의 것과 아래의 것을 비교해보면 아래것이 consistent gets는 줄고 Memory sort는 늘었습니다.

select /*+ index_join(emp pk_emp emp_mgr_ix ) */ empno, mgr
from emp
where empno=7900 and mgr=7698;

위의 화면을 보면 View가 보이지만 그것은 아래 2번에서 hash Join을 하여 만든 결과값을 보는 것입니다.

(11) NATIVE_FULL_OUTER_JOIN (11g)

SQL> conn scott/tiger

SQL> set autot on

SQL> select *
from emp e full outer join dept d
on e.deptno=d.deptno;

양쪽 다 만족하지 않는 결과를 볼 때 사용합니다. hint를 사용하지 않아도 아래와 같습니다. 하지만 그 아래의 No_NATIVE_FULL_OUTER_JOIN 은 이전의 방식으로 table을 1번 초과하여 읽을 수도 있습니다.

SQL> select /*+ NATIVE_FULL_OUTER_JOIN */ *
from emp e full outer join dept d
on e.deptno=d.deptno;

SQL> select /*+ NO_NATIVE_FULL_OUTER_JOIN */ *
from emp e full outer join dept d
on e.deptno=d.deptno;


outer join은 Ansi 것을 사용하시기를 권장합니다. 그 이유는 oracle은 검색 조건에도 +기호를 붙여야해서 실수를 유발할 수 있습니다.

FULL_OUTER_JOIN 은 ansi것을 사용해야 table을 여러번 읽는것을 막을 수 있습니다.

======================================  2  =========================================

9. CBO 통계 수집

1) 테이블 통계

SQL> conn scott/tiger

SQL> set autot off

SQL> create table test2
as
select * from emp;

SQL> select count(*) from test2;

SQL> desc user_table;

SQL> select table_name, num_rows, blocks
from user_tables;

optimizer 통계 정보가 실시간으로 업데이트 되는것이 아닙니다. 매일 10시에 해당 정보를 수집합니다. 스케쥴러가 돌아가서 작업을 수행합니다.

SQL> exec dbms_stats.gather_table_stats('SCOTT','TEST2')

SQL> select table_name, num_rows, blocks
from user_tables;

SQL> insert into test2 select * from test2;

SQL> commit;

SQL> select count(*) from test2;

SQL> select table_name, num_rows, blocks
from user_tables;

위의 문장들을 수행하고 다시 확인을 하면

28행이 있는것을 확인을 했음에도 불구하고 통계정보는 14건으로만 조회되는 것을 확인할 수 있습니다.

optimizer정보는 실시간 교통정보와 유사한데 실시간으로 업데이트가 되지 않아서 문제가 생길 수 있습니다. 스케줄러를 비활성화 시키면 지속적으로 Optimizer 통계정보를 관리 해 주어야합니다.

꿀팁!!!!  SQL>에서  '/'를 입력하면 이전 query를 재 수행함...

index는 필요 악이라고 하셨습니다. 항상 좋은 성능을 내는것은 아니지만 필요할 때도 분명 있기 때문입니다.

====================================    3    ========================================

히스토그램, 통계정보 수집. ANALYZE와 DBMS_STATS

통계수집은 중요하다!!!! 통계수집이 SQL 튜닝에서 가장 중요하다.

통계를 다 지우고 새로 수집을 할 수도 있습니다. 통계정보를 모두 지워버리면 오히려 성능이 안좋았던 DB에서 성능이 나아지는 경우도 있습니다.

그 이유는 잘못된 통계정보가 DB의 성능을 저하시킬 수 있기 때문입니다.

table의 경우에는 삭제된 공간을 바로 재사용을 하지만 Index의 경우는 그러지 못하므로 rebuilding을 하는 경우가 있습니다.

통계수집은 1차적으로 DBA, 2차적으로는 개발자에게 책임이 있고 매우 매우매우 중요합니다.

index의 경우는 생성을 할 때 통계정보를 모아줍니다.

원칙은 10%이상 바뀌면 통계정보를 수집을 해주는 것을 권장합니다.

통계정보를 수집하게 되면 DB Level로 수집을 하게되면, auto로 수집을 하면 통계정보가 없거나 10%이상 변경된 것들만 통계정보를 모읍니다. ANALYZE는 위의 조건같은 것을 구분하지 않고 모으기 때문에 성능이 떨어질 수 있습니다.

버전에 따라서 주의를 할 필요는 있습니다. 통계정보를 모으는 것은 귀찮고 번거롭고 부하도 많이 발생하지만 꼭 필요한 작업입니다.

압축!!

내일은 그동안 수업내용을 꿰는 시간. 구슬이 서말이라도 꿰어야 보배라고 했으니까요...

오늘 허겁지겁 뛰어오고 볼팬도 없고 옆에는 여전히...

열악한 환경에도 불구하고 오늘도 강의를 수강하러 가산까지 왔습니다.

오늘은 Optimizer에 대해서 먼저 수업이 진행되겠습니다.

표현식 : 사칙연한이나 함수들이 표현된 식. 표현식에 대한 연산을 먼저 처리합니다.

select * from emp where sal=30000/10;

위와 같은 식에서 30000/10을 3000으로 먼저 계산을 하고 Select문을 수행하게 됩니다.

view를 참조하여도 위의 화면과 같이 실행계획은 보면 Optimizer가 더 효율적으로 수행을 하기 위해 직접 Table을 참조하는 것을 확인 할 수 있습니다.

 CREATE TABLE emp2 AS select * from emp;

CTAS라고 테이블을  테이블 조회해서 만드는 문장. 자주 쓸 것이라고 설명을 해 주셨습니다.

table 처럼 사용할 수 없으면 결과의 view를 만들고 처리합니다. ??

<서브쿼리의 사용>

SELECT *
FROM dept
WHERE deptno IN ( SELECT deptno FROM emp );

위의 화면은 서브쿼리를 사용했음에도 불구하고 Optimizer가 더 효율적인 작업을 위해서 JOIN을 실시한 실행계획 화면입니다.

"인위적으로 실행 계획을 바꾸려고 하지 말라"는 말씀을 지난번에 이어 강조하셨습니다. 즉, 위에서 본 30000/10 과 같은 처리를 명시적으로 지시하지 않아도 Optimizer는 알아서 효율적으로 동작을 한다는 것을 강조하셨습니다.

실행계획은 위에서 아래로, 왼쪽에서 오른쪽으로 보는게 좋습니다.

들여쓰기가 되어있고 위에서부터 실행이 되지만 자식이 있으면 자식 먼저 수행이 됩니다.

각 단계를 row source라고 하고 각 단계에서는 row set을 반환합니다.

[ RBO Access path ]

CBO를 사용하는 것을 권장하지만 타산지석으로 RBO를 보고 CBO의 장점을 찾고 다른점을 비교하여 볼 수 있도록 살펴보는 것이라는 안내로 시작하셨습니다.

상식적이지만 융통성이 없음.

Ex> 비행기가 빠른 운송수단임은 참이다. 하지만 태풍이 김포공항에 닥쳐오는데 비행기를 타러 가는 것은 현명하다고 할 수 있는가?

ex> Index가 있으면 사용함.  -> Table의 크기나 효율등을 무시함.

RBO 우선순위 결정 방식 (56page -> 2,3,5,6,7번은 볼 필요가 없음)

  Cluster table -> Oracle에서는 사용하지 않음. 취지는 좋습니다.

  table space를 만드는 경우에 Table Space 위에 Cluster를 만들어 미리 공간을 할당하는 느낌입니다. 즉. 섹션을 분할하는 것과 같은 개념입니다.

장점도 있지만 단점도 있습니다. 먼저 공간 설정을 잘못하면 확장되면서 더 성능이 떨어지고 DATA의 입력이 잘못 된 경우 값만 update하면 되는 것이 아니라 실제로 cluster에서 이동을 시켜야 함.

rowID(행의 주소)는 명시적으로 조회해야 나옵니다.

위의 화면은 RowID를 조회한 결과화면입니다.

table과 Index는 따로 존제하는 객체입니다. Index는 RowID를 갖고 있습니다. 따라서 인덱스로 찾아서 해당 RowID를 확인하여 table을 찾아 갈 수 있습니다.

빠르게 Data를 조회하려면 rowID를 조회하면 되지만 직접적으로 이용하기는 쉽지않다.

직접적으로 RowID를 주면 빠르지만 불편하기 때문에 간접적으로 효과를 보기 위해서 Index를 사용하는 것입니다.

Oracle의 5대 제약조건

<기본키(PK) 유니크 낫널(Not NULL) 외래키(FK) ??>

위의 화면은 RBO순위결정방식 4번에 있는 PK로 조회한 것을 실행계획으로 확인 한 화면입니다. 즉, 조건을 사용할 때 PK, UK column을 사용하면 효율이 뛰어나고 따라서 위와같은 것을 활용 할 필요가 있습니다.

====================================2========================================================

 4) Path 9: Single-Column Indexes

SQL> drop index emp_job_deptno_ix ;

SQL> create index emp_job_ix on emp(job);

SQL> SELECT *
FROM emp
WHERE job = 'ANALYST';

결과 화면입니다. index를 100건읽고 99건 버리고 1건만 읽는 경우를 설명 해 주셨습니다.

EX> 사원번로가 PK이면 사원번호로 조회를 하여 바로 찾을 수 있습니다.

하지만 사원번호를 모른다고 할 때 이름으로 먼저 검색을 하고 부서 번호 조건도 같은 사람이 있을 경우 즉, PK를 못쓰고 해당 조건에 맞는 행을 조회하기 위해서는 테이블을 다 읽고나서 걸러내는 작업입니다. 어제 설명과 같이 Data는 읽지 않을수록 좋습니다.(성능의 면에서) 하지만 Composite Index가 단일 Column index보다 좋다는 것 입니다.

7) Path 12: Sort Merge Join

SQL> SELECT *
FROM emp, dept
WHERE emp.deptno = dept.deptno;

위의 조인 한 결과 화면입니다. 마지막 Where문을 WHERE emp.deptno = dept.deptno+0; 과 같이 약간의 트릭을 써서 수행을 할 수도 있습니다.

10) Path 15: Full Table Scan
SQL> SELECT *
FROM emp;

위의 경우는 어느 조건도 주지 않아서 Table의 모든 행을 조회한 화면입니다.

[ CBO Access path ]

 Oracle 7에서부터 도입, 지속적으로 향상되어 일반적으로 RBO보다 우수합니다.

CBO는 데이터에 대한 각종 통계를 사용합니다. 이 통계는 Table과 Index에 관한 통계정보입니다.

1) SELECT 문장에서의 SAMPLE 절

-- EMP 테이블 5% 질의

SELECT * FROM emp SAMPLE (5);

위의 화면을 보면 CBO를 사용한 실행계획은 RBO와 달리 cost정보가 더 보입니다.

2) BY GLOBAL INDEX ROWID

SQL> CREATE TABLE SALES
(ID NUMBER(5),
NAME VARCHAR2(10))
PARTITION BY RANGE (ID)
(PARTITION SALES_P1 VALUES LESS THAN (101),
PARTITION SALES_P2 VALUES LESS THAN (201),
PARTITION SALES_P3 VALUES LESS THAN (301),
PARTITION SALES_P4 VALUES LESS THAN (MAXVALUE));

SQL> CREATE INDEX sales_id_ix ON sales(id)
GLOBAL PARTITION BY RANGE (id)
(PARTITION p1 VALUES LESS THAN (201),
PARTITION p3 VALUES LESS THAN (MAXVALUE));

3) BY LOCAL INDEX ROWID
SQL> drop index sales_id_ix;
SQL> CREATE INDEX sales_id_ix ON sales(id) LOCAL;
SQL> select /*+ index(sales) */ * from sales where id = 1;

5) INDEX FAST FULL SCAN

SQL> conn / as sysdba

SQL> alter user sh identified by sh account unlock;

SQL> conn sh/sh

SQL> set autot trace exp

SQL> select CUST_id from CUSTOMERS;

full scan과 fast full scan은 약간의 차이가 있고 추후에 설명 예정이라고 하셨습니다.

====================================  3   ==========================================

교육에 관하여... 60%정도 아는 상태에서 듣는 것이 가장 좋다고 생각하셨습니다.

튜닝같은 경우는 특히 다른 강의를 들어볼 수 있다면 비교를 하면서 들어보면 또 다른 Style을 배울 수 있습니다.

강사님께서는 본인을 담백하게 튜닝을 하는 사람이라고 예를 들어주셨습니다. 원칙을 지키면서 담백하게 하는 것이 장기적으로 볼 때에는 도움이 많이 될 것이라 하셨습니다. 설탕같은 조미료를 많이 넣은 음식을 먹으면 늙어 고생한다는 것이 튜닝과도 유사하다고 하셨습니다.

7) Bitmap Operation

SQL> conn scott/tiger

SQL> drop index emp_job_ix;

SQL> create index emp_job_ix on emp(job);

SQL> create index emp_mgr_ix on emp(mgr);

SQL> set autot on

SQL> select /*+ index_combine(emp emp_job_ix emp_mgr_ix ) */ *
from emp
where job='CLERK' and mgr=7788;

SQL> select /*+ index_combine(emp emp_job_ix emp_mgr_ix ) */ *
from emp
where job='CLERK' or mgr=7788;

미리 Index가 conversion 되있는 경우가 더 빠릅니다. 위의 경우가 그러한 경우입니다. 각각의 RowID를 추출하여 bit값으로 바꾸고 Bit And연산을 하여 그 행을 찾을 수 있는 고유 값이 나오는데 그것을 RowID로 바꾸어 해당 행을 찾아갑니다. 위의 결과는 힌트를 주어 인위적으로 만든 실행계획입니다. 힌트를 주지 않는 경우에는 Index를 하나만 사용하는 것을 확인 할 수 있습니다.

Minus 연산

SQL> select /*+ index(emp emp_job_bix emp_mgr_bix ) */ *
from emp
where job='CLERK' and mgr<>7788;

위의 화면은 두가지 조건이 아닌 것을 검색하는 내용으로 해당 비트를 빼는것을 실행계획에서 확인할 수 있습니다.

3번째 시간.txt

3번째 시간에는 거의 실습 화면을 보면서 설명을 해 주셔서 실습

환경 설정에 대한 문제 , 물리적으로는 노트북이 부족해서 불평을 표하는 사람들이 많아서 조금은 불쾌하게 강의를 시작한 느낌이 있지만 될수 있으면 좋은 강의를 긍정적으로 들을 수 있도록 .... 오늘도 시작합니다.

Read consistent?

읽기의 일관성을 위해 Update등을 하면 update를 실시 한 사용자는 변경한 값을 볼 수 있지만 다를 사용자는 Commit을 하기 전까지는 볼 수 없는 내용을 확인하기 위해서 Undo Table에 있는 값을 읽어 와 update되기 전의 값을 읽어오는 것을 읽기 일관성(Read consistent)이라고 합니다.

위 내용은 제가 들은 설명을 정리한 것이라 정확하지 않을 수 있습니다. 조금 더 정리를 하여 수정하고 다듬도록 할 예정입니다.

"다른것은 다 잊으셔도 되니 DML을 쓸 때 DB Block계층이 나타납니다."  라는 말씀을 강하게 하셨습니다.

삽입, 수정, 삭제 를 빨리할 수 있는 방법은 뭐가 있을까요??

insert -> 딱히 없네요 방법이 느려지는 이유를 찾으려면 다른 것을 확인해야 합니다.

Update -> 한건정도만 하면? 찾아야 하는데... 찾는데 조건을 잘 줘서, 예를들면 인덱스를 주고 찾을 수 있겠습니다.

Delete -> 한 행을 지운다고 가정할 때 위와 같이 한 행을 인덱스를 통해 빨리 찾으면 됩니다.

sort(memory) 통계값과 sort(disk)값은 각각의 장치에 정렬을 한 횟수로 메모리에서의 정렬은 PGA에서 처리를 합니다. 위 정렬 작업을 간단히 비유하면 암산을 하다가 양이 많아지면(숫자가 커지면) 손으로 써서 계산을 하는 것과 유사합니다.

통계값중 값이 나올 경우 가장 성능저하를 가져 올 수 있는것은 무엇일까요?

1. consistent gets

2. physical read

3. sort(memory)

4. sort(disk)

답은......

4번.... 이유는 뭘까요?? 우선 1번과 3번은 작업하는 HW가 메모리입니다. 속도가 훨씬 빠릅니다. 물리적인 디스크를 사용하는 2번과 4번을 비교해야 하는데 2번의 경우에는 물리적인 읽기를 할 경우에는 해당 내용을 메모리로 caching 하므로 다시 활용을 할 수도 있습니다. 모든 data는 한번은 Caching해야하기 때문이죠... 하지만 4번의 경우는 정말 좋지 않습니다. 그 이유는 disk에서 정렬을 하여 쓰고, 그러므로 메모리보다 속도가 느립니다. 게다가 재활용이 불가능 하기 때문입니다.

따라서 2번과 4번 특히 4번의 경우는 수치가 0이거나 0에 가까울 수록 좋습니다. 특히 서버의 성능이 나쁠수록 해당 수치들에 민감한 편입니다.

위의 붉은 상자로 처리 한 부분은 실행 계획만을 보는 것으로 파싱을 한 후 실행계획을 만들었다라는 의미의 확인 메시지로 생각하면 될 것 같습니다.

-------------------------------------------------------2---------------------------

실행계획 보기 다른방법

V관련된 것을 보려면 일반사용자는 권한이 없어서 Error이 발생합니다.

권한을 부여하는 아래의 SQL문을 수행하면

SQL> conn / as sysdba

SQL> grant select on v_$session to scott;

SQL> grant select on v_$sql_plan_statistics_all to scott;

SQL> grant select on v_$sql_plan to scott;

SQL> grant select on v_$sql to scott;

SQL> conn scott/tiger

SQL> SELECT * FROM dept WHERE deptno=10;

SQL> SELECT * FROM table(DBMS_XPLAN.DISPLAY_CURSOR);

바로 위의 SQL문을 수행했을 때 아까와 달리 결과가 정상적으로 보입니다.

trace결과를 보기 위에 위의 화면 위에 있는 이전의 파일을 tkprof를 사용하여 보기 좋은 양식으로 정리 된 결과라고 생각하시면 됩니다.

위 화면은 TKPROF만 입력하여 해당 툴을 사용하는 방법을 안내해주는 화면을 캡쳐한 것이고 옵션들을 접두어에 따라 분류 해 표시하였습니다.

위의 옵션들은 여러개를 동시에 사용할 수 있습니다.

========================================================3============================

두가지 실행계획을 비교할 수 있습니다. 그 두가지는 이전에 실행 항 것과 지금 다시 실행 한 것을 비교하는 것입니다.

위의 화면을 보면 Row Source Operation과 Excution Plan을 비교하여 볼 수 있는 것 입니다. Row Source Operation 가 실제로 실행된 것입니다.

위의 화면은 대기시간이 발생한 화면을 캡쳐 한 것입니다. 정상적인(?) 범위를 넘어서는 대기시간입니다.

위의 화면은 대기시간이 발생한 이유를 캡쳐한 화면으로 해당 화면을 분석을 하면 LOCK때문에 발생한 대기임을 확인할 수 있습니다.

위와 같은 대기시간이 배치작업이 아닐경우 문제가 됨.

배치작업 또한 오래 걸리지 않는 작업이지만 lock에 걸려서 대기하는 시간이 대부분이고 그 때문에 배치작업이 사간을 많이 소요하게 됩니다.

3~5초 소요되면 퇴근????????????????????????????????????????????????????!!!!!!!!!!

실행 계획만을 보면 되는 것이 아니라 실제로 사용된 것과 대기시간도 확인을 해야 성능저하 문제를 해결할 수 있는 경우가 있습니다.

아기의 울음에 비유하셔서 설명.... 아기가 우는것과 DB의 성능저하를 같다고 보면 아이가 운다고 모두 한가지 원인인 것은 아니라는 느낌!! 배고파서 울 수 있고 아파서 울 수 있으므로 그렇습니다.