기술노트 49 회 SQL PLAN MANAGEMENT Author 윤병길과장 Creation Date Last Updated Version 1.0 Copyright(C) 2009 Goodus Inc. All Rights Reserved

Size: px

Start display at page:

건 채
5 years ago
Views:

2 Contents 1. SQL PLAN MANAGEMENT OVERVIEW INTRODUCTION SQL PLAN MANAGEMENT 주요구성요소 SQL PLAN MANAGEMENT SPM 동작원리 AUTOMATIC PLAN CAPTURE MANUAL PLAN CAPTURE EVOLVING SQL PLAN BASELINES STEP BY STEP EXAMPLE SQL PLAN BASELINE MANAGEMENT BASELINE 속성값변경 BASELINE MANAGEMENT TRANSFERING BASELINE BASELINE 삭제

3 1. SQL Plan Management Overview 1.1. Introduction 데이터베이스를운영하면서성능저하의원인이라고하면쉽게아래와같은원인을꼽을수있다. - 비즈니스확장과사용량의증가로인한자원부족 - 잘못된데이터베이스및스토리지구성 - Heavy SQL 들로인한응답속도지원 - 데이터베이스버그 이중 SQL 의성능저하는데이터베이스성능저하의직접적인영향을주고있어, DBA 들은데이터베이 스를관리하며, 필요시마다 SQL 을튜닝하고, 옵티마이져가정확한예측을하도록통계정보를갱신하 는등의작업을하고있다. 특히 SQL 의실행계획은옵티마이져라는인공지능에의해계산되고만들어지는데, 불행히도그기능이 100% 퍼펙트하지않기때문에여러가지원인으로인해 SQL 의실행계획이변경되어혼란을초래하기도한다. 그원인은여러가지가있으나, 간단하게아래와같다. - 통계정보의갱신 - 옵티마이져파라미터의변경 - 스키마나테이블데이터의급격한변경 - 시스템환경과설정값변경 - 옵티마이져버전변경 이러한이유로오라클은예측하기어려운실행계획의변경을막기위해 Stored outlines 이나통계정보 수집을막거나, 특정테이블에대해통계정보갱신을잠금 (Lock) 하는기법들이도입되었다. 어쨌든오라클버전이올라가면서, 옵티마이져는진화하고발전하였고, 11g 에서는 9i 때도입된바인 드옅보기 (Bind Peeking) 기능의단점을커버하기위해어댑티브커서 (adaptive cursor) 와 SQL 의성능 을유지하기위해 SPM(SQL PLAN MANAGEMENT) 기능을제공한다. 특히 SPM 기능으로인해옵티마이져는자동으로변경되는 SQL 의실행계획을관리하고, 새로운실행 계획이만들어지더라고, 검증 (VERIFY) 이끝날때까지새로운실행계획을사용하지않으며, 현재의실행 계획보다성능이비슷하거나향상될경우에만사용할수있도록한다. 금번기술노트에서는 SPM 의기능과방법에대해예제를통해소개하고자한다 SQL PLAN MANAGEMENT 주요구성요소 SPM 은 SQL 의성능 (Runtime-performance) 이실행계획의변경으로인해저하되는것을방지하기위해 개발된기능이다

4 SPM 은 SQL 의실행계획이변경되더라도바로적용시키지않고, 검증을확인된 (VERIFY) 실행계획만받아들이도록되어있다. SPM 의 3 가지주요구성요소는아래와같다. 아래의구성요소에대한예제는 2 장에서살펴보도록한다. q q q SQL PLAN BASELINE CAPTURE ð 현재 SPM에의해수락되어검증된실행계획에대한 SQL Baseline을생성하고, PLAN History 정보는 SYSAUX 테이블스페이스에저장됨 SQL PLAN BASELINE SELECTION ð PLAN History 에는수락된 (accepted) 된실행계획과수락되기전의 (unaccepted) 실행계획을모두포함함. ð 수락되기전의 (unaccepted) 실행계획은아직검증 (verified) 이되기전의실행계획이며, 거부된 (rejected) 실행계획은검증 (verified) 을통해적용할수없는실행계획을의미한다. SQL PLAN BASELINE EVOLUTION ð PLAN History안의검증이되지않은 (all unverified) 실행계획은이단계에서검증을통해수락 (accept) 되거나거부 (reject) 된다. 위의그림은 SPM 이 Statement log 안에반복되는 SQL 에대한 Plan History 를가지고있음을보여주고 있다. 2. SQL PLAN MANAGEMENT - 4 -

5 2.1. SPM 동작원리 SQL 이하드파싱되면, CBO(COSE BASED OPTIMIZER) 환경에서옵티마이져는여러개의실행계획을만들고, 그중가장 COST 가적은실행계획을선택한다. 만약 SQL 베이스라인 (BASELINE) 이존재하면, 옵티마이져는 flag-accepted 꼬리말을달고있는실행계획을찾으려고하고, 이미수락된, 즉 accepted flag 상태의실행계획이발견되면해당실행계획을사용한다. 만약 SQL 베이스라인에매칭되는실행계획을찾지못하면, 옵티마이져는 SQL 베이스라인의수락된실행계획들에대해평가작업을시작하여그중에 COST 가가장적은실행계획을사용한다. 옵티마이져에의해새로만들어진실행계획이 SQL 베이스라인의존재하는실행계획보다 COST 가작은경우에는, 일단 SQL 베이스라인에수락되기전상태 (unaccepted) 로저장되며, 검증 (verified) 되기전까지사용할수없다. 또한시스템업그레이드나마이그레이션과같은시스템상의변경이일어날경우, SQL 베이스라인의모든수락된 (accepted) 실행계획을새로검토하여가장 COST 가작은실행계획을받아들이고 Flagaccepted 한상태로변경한다 Automatic Plan Capture OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES 파라미터는기본값이 FALSE, 이값을 TRUE 로변경하게되면, 시스템은자동으로모든 SQL 에대해 SQL 베이스라인을수집하며, 각각의 SQL 에대한 PLAN Hisotry 정보를저장한다. 가장최초로파싱되어사용되는실행계획은자동으로 flag-accepted 한상태로 SQL 베이스라인에저장된다. ( 자동으로실행계획을저장하는이기능은부하를줄수있으니, 적용전테스트할것을권고함.) SQL> SHOW PARAMETER OPTIMIZER_CAPTURE_SQL_PLAN_BASELI NES NAME TYPE VALUE optimizer_capture_sql_plan_baselines boolean FALSE SQL> ALTER SYSTEM SET OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES=TRUE; System altered Manual Plan Capture 이번단락에서는수동으로실행계획을저장하는방법을소개한다. 이작업은 DBMS_SPM 패키지를사용하며, 수동으로실행계획을 SQL 베이스라인에저장하는경우에는 DEFAULT 로 accepted 한상태로저장된다. SQL tuning set 을추가하는방법과 cursor 에저장된특정 SQL 의실행계획을추가하는방법 2 가지가있다. SQL 베이스라인이없다면베이스라인이새로생성되며, 베이스라인이존재하면실행계획은베이스라 - 5 -

6 인에추가된다. n LOAD_PLAN_FROM_SQLSET DECLARE l_plans_loaded PLS_INTEGER; BEGIN l_plans_loaded := DBMS_SPM.load_plans_from_sqlset( sqlset_name => 'my_sqlset'); END; / n LOAD_PLAN_FROM_CURSOR_CACHE DECLARE l_plans_loaded PLS_INTEGER; BEGIN l_plans_loaded := DBMS_SPM.load_plans_from_cursor_cache( sql_id => '1ghe87md0917n'); END; / 2.4. Evolving SQL PLAN Baselines 이단계는옵티마이져가 SQL 베이스라인에있는수락되지않은실행계획에대해수락 (accepted) 혹은거부 (rejected) 를결정한다. 자동수집환경에서는 EVOLVE_SQL_PLAN_BASELINE 함수에의해계산된며, 그결과를 CLOB 형태의보고서로보여준다 SET LONG SELECT DBMS_SPM.evolve_sql_plan_baseline(sql_handle => 'SYS_SQL_7b76323ad90440b9') FROM dual; 2.5. Step by Step Example 예제에서는수동수집을통해 SPM 을사용하는예를보여준다. 따라서 OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES 파라미터는 FALSE 로변경하고시작한다. CONN sys/oracle@test11g AS SYSDBA ALTER SYSTEM SET OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES=FALSE; 예제에서는수동수집을통해 SPM 을사용하는예를보여준다. 따라서 OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES 파라미터는 FALSE 로변경하고시작한다

7 --테스트를위한테이블생성및통계정보생성 SQL> CREATE TABLE spm_test ( 2 id NUMBER, 3 description VARCHAR2(50) 4 ); 테이블이생성되었습니다. SQL> DECLARE 2 TYPE t_tab IS TABLE OF spm_test%rowtype; 3 l_tab t_tab := t_tab(); 4 BEGIN 5 FOR i IN LOOP 6 l_tab.extend; 7 l_tab(l_tab.last).id := i; 8 l_tab(l_tab.last).description := 'Description for ' i; 9 END LOOP; FORALL i IN l_tab.first.. l_tab.last 12 INSERT INTO spm_test VALUES l_tab(i); COMMIT; 15 END; 16 / SQL> EXEC DBMS_STATS.gather_table_stats(USER, 'SPM_TEST', cascade=>true); --인덱스가없으므로 TABLE FULL SCAN 이이루어짐. SQL> SET AUTOTRACE TRACE SQL> SQL> SELECT description 2 FROM spm_test 3 WHERE id = 99; Execution Plan - 7 -

8 Plan hash value: Id Operation Name Rows Bytes Cost (%CPU) Time SELECT STATEMENT (0) 00:00:01 * 1 TABLE ACCESS FULL SPM_TEST (0) 00:00: Predicate Information (identified by operation id): filter("id"=99) Statistics recursive calls 0 db block gets 47 consistent gets 0 physical reads 0 redo size 454 bytes sent via SQL*Net to client 415 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1 rows processed --V$SQL 로부터 SQL_ID 값을찾아냄. SQL> SELECT sql_id 2 FROM v$sql 3 WHERE sql_text LIKE '%spm_test%' 4 AND sql_text NOT LIKE '%dba_sql_plan_baselines%' 5 AND sql_text NOT LIKE '%EXPLAIN%'; SQL_ID ffpxkrfmwu2nw - 8 -

9 --수동으로 SQL PLAN 베이스라인생성 SQL> SET SERVEROUTPUT ON SQL> DECLARE 2 l_plans_loaded PLS_INTEGER; 3 BEGIN 4 l_plans_loaded := DBMS_SP M.load_plans_from_cursor_cache( 5 sql_id => 'ffpxkrfmwu2nw'); 6 7 DBMS_OUTPUT.put_line('Plans Loaded: ' l_plans_loaded); 8 END; 9 / Plans Loaded: 1 -- DBA_SQL_PLAN_BASELINES 뷰로부터베이스라인정보를조회함. --현재베이스라인에는하나의실행계획이있으며, ENABLED 와 ACCEPTED 칼럼값이 YES 임을확인가능하다. SQL> SELECT sql_handle, plan_name, enabled, accepted 2 FROM dba_sql_plan_baselines 3 WHERE sql_text LIKE '%spm_test%' 4 AND sql_text NOT LIKE '%dba_sql_plan_baselines%'; SQL_HANDLE PLAN_NAME ENA ACC SYS_SQL_7a5adea0a1422e62 SQL_PLAN_7nqqyn2hn4bm2f2fc655a YES YES -- 테스트를위해현재 SHARE POOL 을 FLUSH 함. SQL> ALTER SYSTEM FLUSH SHARED_POOL; 시스템이변경되었습니다. --테스트테이블에인덱스와통계정보를생성함. SQL> conn test/test@test11g 연결되었습니다. SQL> CREATE INDEX spm_test_idx ON spm_test(id); 인덱스가생성되었습니다

10 SQL> EXEC DBMS_STATS.gather_table_stats(USER, 'SPM_TEST', cascade=>true); --인덱스를만들고 SHARED POOL 을 FLUSH 하여 SQL 이하드파싱하도록했지만실행계획은여전히이전실행계획인테이블 FULL SCAN 을하고있음 SQL> SET AUTOTRACE TRACE SQL> SQL> SELECT description 2 FROM spm_test 3 WHERE id = 99; Execution Plan Plan hash value: Id Operation Name Rows Bytes Cost (%CPU) Time SELECT STATEMENT (0) 00:00:01 * 1 TABLE ACCESS FULL SPM_TEST (0) 00:00: Predicate Information (identified by operation id): filter("id"=99) Note SQL plan baseline "SQL_PLAN_7nqqyn2hn4bm2f2fc655a" used for this statement Statistics recursive calls 0 db block gets

11 47 consistent gets 0 physical reads 0 redo size 454 bytes sent via SQL*Net to client 415 bytes received via SQL *Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1 rows processed -- DBA_SQL_PLAN_BASELINES 을보면하드파싱했음에도불구하고옵티마이져가이전실행계획을사용한이유를알수있다. 2 번째실행계획이 SQL 베이스라인에추가됨을확인할수있다. SQL 베이스라인에추가는되었으나 accepted 는 NO 상태임을알수있다. SQL> SELECT sql_handle, plan_name, enabled, accepted 2 FROM dba_sql_plan_baselines 3 WHERE sql_handle = 'SYS_SQL_7a5adea0a1422e62'; SQL_HANDLE PLAN_NAME ENA ACC SYS_SQL_7a5adea0a1422e62 SQL_PLAN_7nqqyn2hn4bm23034dc33 YES NO SYS_SQL_7a5adea0a1422e62 SQL_PLAN_7nqqyn2hn4bm2f2fc655a YES YES --EVOLVE_SQL_PLAN_BASELINE 함수를사용하여새로운실행계획에대한 EVOLVING 하고보고서를출력한다. --노란색으로표시한부분을살펴보면새로운실행계획이이전에비래수행시간도빠르고 IO 블록도적게읽는것을알수있다. SQL> SET LONG SQL> SELECT DBMS_SPM.evolve_sql_plan_baseline(sql_handle => 'SYS_SQL_7a5adea0a1422e62') 2 FROM dual; DBMS_SPM.EVOLVE_SQL_PLAN_BASELINE(SQL_HANDLE=>'SYS_SQL_7A5ADEA0A1422E62') Evolve SQL Plan Baseline Report Inputs:

12 SQL_HANDLE = SYS_SQL_7a5adea0a1422e62 PLAN_NAME = TIME_LIMIT = DBMS_SPM.AUTO_LIMIT VERIFY = YES DBMS_SPM.EVOLVE_SQL_PLAN_BASELINE(S QL_HANDLE=>'SYS_SQL_7A5ADEA0A1422E62') COMMIT = YES Plan: SQL_PLAN_7nqqyn2hn4bm23034dc Plan was verified: Time used.172 second s. Plan passed performance criterion: times better than baseline plan. Plan was changed to an accepted plan. Baseline Plan Test Plan Stats Ratio Execution Status: COMPLETE COMPLETE DBMS_SPM.EVOLVE_SQL_PLAN_BASELINE(SQL_HANDLE=>'SYS_SQL_7A5ADEA0A1422E62') Rows Processed: 1 1 Elapsed Time(ms): CPU Time(ms): 0 0 Buffer Gets: Physical Read Requests: 0 0 Physical Write Requests: 0 0 Physical Read Bytes: 0 0 Physical Write Bytes: 0 0 Executions: DBMS_SPM.EVOLVE_SQL_PLAN_BASELINE(SQL_HANDLE=>'SYS_SQL_7A5ADEA0A1422E62') Report Summary Number of plans verified:

13 Number of plans accepted: 1 --Evolving 후새로운실행계획이 accepted 되었음을확인한다. SQL> SELECT sql_handle, plan_name, en abled, accepted 2 FROM dba_sql_plan_baselines 3 WHERE sql_handle = 'SYS_SQL_7a5adea0a1422e62' ; SQL_HANDLE PLAN_NAME ENA ACC SYS_SQL_7a5adea0a1422e62 SQL_PLAN_7nqqyn2hn4bm23034dc33 YES YES SYS_SQL_7a5adea0a1422e62 SQL_PLAN_7nqqyn2hn4bm2f2fc655a YES YES --새로운실행계획이 SQL PLAN 베이스라인에서수락 (accepted) 된후옵티마이져는 COST 가적은새로운실행계획을사용한다. SQL> CONN test/test@test11g SQL> SET AUTOTRACE TRACE SQL> SQL> SELECT description 2 FROM spm_test 3 WHERE id = 99; Execution Plan Plan hash value: Id Operation Name Rows Bytes Cost (%CPU) Time SELECT STATEMENT (0) 00:00:01 1 TABLE ACCESS BY INDEX ROWID SPM_TEST (0) 00:00:01 * 2 INDEX RANGE SCAN SPM_TEST_IDX 1 1 (0) 00:00: Predicate Information (identified by operation id):

14 2 - access("id"=99) Note SQL plan baseline "SQL_PLAN _7nqqyn2hn4bm23034dc33" used for this statement Statistics recursive calls 0 db block gets 4 consistent gets 0 physical reads 0 redo size 461 bytes sent via SQL*Net to client 416 bytes received via SQL*Net from client 2 SQL*Net roundtrips to/from client 0 sorts (memory) 0 sorts (disk) 1 rows processed 3. SQL Plan Baseline Management Baseline 속성값변경 ALTER_SQL_PLAN_BASELINE 함수를사용하여 SQL PLAN 베이스라인의설정된속성에대한값을변경할수있다. 설정할수있는속성값의종류는아래와같다. n Enabled (YES/NO): 옵티마이져에의해베이스라인의실행계획이 accepted 일경우사용할지안할지결정. Yes 일경우옵티마이져는 accepted 인경우새로운실행계획을사용할수있음. n fixed (YES/NO): 플랜을 fix 할것인지아닌지결정, yes 일경우새로운실행계획이들어와도 EVILVING 하지않음. n autopurge (YES/NO): YES 이면, 일정기간동안사용하지않은베이스라인은자동으로 purge 됨. n plan_name: SQL plan 이름을대체할경우사용, 최대문자 30 자리 n description: SQL Plan 설명을넣고싶을경우사용, 최대문자 30 자리. -- 위에테스트로사용한실행계획에대해 fixed 를 yes 로설정하는예제 SQL> SET SERVEROUTPUT ON

15 SQL> DECLARE 2 l_plans_altered PLS_INTEGER; 3 BEGIN 4 l_plans_altered := DBMS_SPM.alter_sql_plan_baseline( 5 sql_handle => 'SYS_SQL_7a5adea0a1422e62', 6 plan_name => 'SQL_PLAN_7nqqyn2hn4bm23034dc33', 7 attribute_name => 'fixed', 8 attribute_value => 'YES'); 9 10 DBMS_OUTPUT.put_line('Plans Altered: ' l_plans_altered); 11 END; 12 / Plans Altered: 1 --위에서 fiexed 속성값을 yes 로변경한후아래와같이확인가능함. SQL> SET LONG SQL> SQL> SELECT * 2 FROM TABLE(DBMS_XPLAN.display_sql_plan_baseline(plan_name=>'SQL_PLAN_7nqqyn2hn4bm23034dc33')); PLAN_TABLE_OUTPUT SQL handle: SYS_SQL_7a5adea0a1422e62 SQL text: SELECT description FROM spm_test WHERE id = 99 Plan name: SQL_PLAN_7nqqyn2hn4bm23034dc33 Plan id: Enabled: YES Fixed: YES Accepted: YES Origin: AUTO -CAPTURE PLAN_TABLE_OUTPUT

16 Plan hash value: Id Operation Name Rows Bytes Cost (% CPU) Time PLAN_TABLE_OUTPUT SELECT STATEMENT (0) 00:00:01 1 TABLE ACCESS BY INDEX ROWID SPM_TEST (0) 00:00:01 * 2 INDEX RANGE SCAN SPM_TEST_TAB_ IDX 1 1 (0) 00:00:01 PLAN_TABLE_OUTPUT Predicate Information (iden tified by operation id): access("id"=99) 25 개의행이선택되었습니다 Baseline Management SQL PLAN 베이스라인, SQL statement log, plan History, SQL Profile 정보들은모두기본적으로 SYSAUX 테이블스페이스에저장된다. 아래의두가지속성값을통해저장되는 space 와보존기간을조절할수있다. n space_budget_percent (default 10): SYSAUX 테이블스페이스에최대로저장될수있는최대값. % 로나타내며 1-50 까지설정가능하다. n plan_retention_weeks (default 53): 사용하지않는 (Unused) 실행계획에대한보존주기

17 5-523 주까지설정가능. -- DBA_SQL_MANAGEMENT_CONFIG 뷰를통해현재설정값을확인한다 SQL> SELECT parameter_name, parameter_value 2 FROM dba_sql_management_config; PARAMETER_NAME PARAMETER_VALUE SPACE_BUDGET_PERCENT 10 PLAN_RETENTION_WEEKS 53 --DBMS_SPM.configure 를통해설정한다,. SQL> BEGIN 2 DBMS_SPM.configure('space_budget_percent', 11); 3 DBMS_SPM.configure('plan_retention_weeks', 54); 4 END; 5 / SQL> SQL> SELECT parameter_name, parameter _value 2 FROM dba_sql_management_config; PARAMETER_NAME PARAMETER_VALUE SPACE_BUDGET_PERCENT 11 PLAN_RETENTION_WEEKS Transfering Baseline DBMS_SPM 패키지는데이터베이스간에 BASELINE 을전송하는기능을제공한다. 아래는그절차를예제로보여준다. --먼저소스데이터베이스에 Staging 테이블을생성한다 SQL> BEGIN 2 DBMS_SPM.CREATE_STGTAB_BASELINE( 3 table_name => 'spm_stageing_tab', 4 table_owner => 'TEST', 5 tablespace_name => 'USERS'); 6 END;

18 7 / -- PACK_STGTAB_BASELINE 기능을통해 SQL PLAN 베이스라인을 staging 테이블로 export 한다 SQL> SET SERVEROUTPUT ON SQL> DECLARE 2 l_plans_packed PLS_INTEGER; 3 BEGIN 4 l_plans_packed := DBMS_SP M.pack_stgtab_baseline( 5 table_name => 'spm_stageing_tab', 6 table_owner => 'TEST'); 7 8 DBMS_OUTPUT.put_line('Plans Packed: ' l_plans_packed); 9 END; 10 / Plans Packed: 2 --위의작업이끝난후소스데이터베이스의 staging 을 datapump 를사용하여 export 한후 target 데이터베이스로 pump 를사용하여 import 한다. --import 가끝나면, UNPACK_STGTAB_BASELINE 기능을통해 SQL PLAN 베이스라인을특정사용 자로 import 한다. SQL> SET SERVEROUTPUT ON SQL> DECLARE 2 l_plans_unpacked PLS_INTEGER; 3 BEGIN 4 l_plans_unpacked := DBMS_SPM.unpack_stgtab_baseline( 5 table_name => 'spm_stageing_tab', 6 table_owner => 'TEST', 7 creator => 'TEST'); 8 9 DBMS_OUTPUT.put_line('Plans Unpacked: ' l_plans_unpacked); 10 END; 11 / Plans Unpacked:

19 3.4. Baseline 삭제. DROP_SQL_PLAN_BASELINE 기능을통해베이스라인을삭제할수있다. SQL> SET SERVEROUTPUT ON SQL> DECLARE 2 l_plans_dropped PLS_INTEGER; 3 BEGIN 4 l_plans_dropped := DBMS_SPM.drop_sql_plan_base line ( 5 sql_handle => 'SYS_SQL_7a5adea0a1422e62', 6 plan_name => NULL); 7 8 DBMS_OUTPUT.put_line(l_plans_dropped); 9 END; 10 / 2 SQL> SELECT sql_handle, plan_name, enabled, accepted 2 FROM dba_sql_plan_baselines 3 WHERE sql_handle = 'SYS_SQL_7a5adea0a1422e62'; 선택된레코드가없습니다

SQL PLAN MANAGEMENT 활용 엑셈컨설팅본부 /DB 컨설팅팀장정민 개요 오라클은비롯한많은관계형 DBMS 에서는사용자의 SQL 질의를효율적으로처리하기위해옵티마이저를사용하고있다. 옵티마이저는유저가수행하는 SQL 을받아실행계획을생성하고, 실제 SQL 은이실행계획을

SQL PLAN MANAGEMENT 활용 엑셈컨설팅본부 /DB 컨설팅팀장정민 개요 오라클은비롯한많은관계형 DBMS 에서는사용자의 SQL 질의를효율적으로처리하기위해옵티마이저를사용하고있다. 옵티마이저는유저가수행하는 SQL 을받아실행계획을생성하고, 실제 SQL 은이실행계획을통해서수행된다. 데이터베이스운영시평소잘수행되던 SQL 이성능이슈를발생시키는때가있는데, 그원인이