Oracle-튜닝-index , block

1. index 구조

  . B*tree 구조로 되어 있음. ( B : blance )

  . 균형이 잡힌 Blance Tree 구조

  . index block들이 모여 존재하는데  이 앞쪽에 B*tree구조가 존재 한다.

    그래서 검색 시 B*tree를 먼저 검색 하고 index block을 찾아 간다.

  . 

2. index를 생성하기 좋은 컬럼들

  . where절에 조건 컬럼

  . join절에 연결 컬럼

  . 분포가 고른 컬름

  . null을 많이 포함하고 있는 컬럼

  

3. index 컬럼선택  -  예)

  . 군인 테이블에서.성별 컬럼을 index잡아야 하는 경우

    - 군인중 남자는 60만명, 여자는2만명인데 분포도가 너무 않좋다.

    - 그래서 '여자'를 검색할 때는 빠르지만 '남자'를 검색하게 되면 index full scan후

      table검색하기 때문에 속도가 너무 느리다.

    - 그래서 오히려 남자를 검색할 때 full table scan이 빠른경우가 이런 경우이다.

    - 최종 : 성별컬럼에 '남자는 : null', '여자는 : 1' 로 저장 하면

              자연스럽게 남자검색시 full table scan을 하게 된다.

    - 추가 : 남자레코드가 많기 때문이 null을 포함한 컬럼을 index를 잡으면 index size도 작다.

3. index는 null컬럼을 포함하지 않음.

  . SELECT * FROM EMP WHERE ID is not null

    - ID에 index 존재 시

    - INDEX FULL SCAN ; 실행계획 처리.

    - is not null : 값이 존재 하는 id는 index에 모든 자료이므로 index full scan으로 처리 됨

3. index 목록 보기

   > SELECT INDEX_NAME , INDEX_TYPE, TABLE_NAME, UNIQUENESS FROM USER_INDEXES;

3. index order by

   . index가 존재 하는 자료를 조회 시 자료는 index기준으로 조회하기 때문에 정렬이 되어 조회됨

   . 만약 index key를 order by 해도 실행계획은 sort order by를 하지 않는다.

   . create index idx_emp_sal on emp(sal);

   . select * from emp where sal >= 3000 order by ename; 

      - empnm은 index가 없기 때문에 order by를 수행할 때 SORT ORDER BY 가 수행 됨

   . select * from emp where sal >= 3000 order by sal; 

     - sal에 index가 존재 하기 order by를 했지만 SORT ORDER BY 가 수행 되지 않음

   

   . select * from emp where sal >= 3000 order by sal desc; 

     - sal에 index가  asc 로 존재 하기 order by를할 경우 DESCENDING 으로 scan index range scan은 하고, SORT ORDER BY 가 수행 되지 않음

3. Block

   .  size

    > show parameter db_block_size;  --결과 : 8192 (8k)

      - db block size는 운영체제가 i/o를 읽을 수 있는 배수로 설정되어야 한다.

3. 테이블 Block

   . 저장구조

      [RH : 컬럼갯수 : 자리수 : 값 : 자리수 : 값 ....]  (RH : Row Header)

   . 실재 생성 구조 예1)

      -> 컬럼 : ID, NAME

      -> 값 : 1234, 'ABC'

          값 : NULL, 'DEF'

          값 : 4567, NULL   -> 일 경우 아래 Record가 저장되는 구조임.

      -> [RH : 2 : 4 : 1234 : 3 : ABC]

          [RH : 2 : 0 : 3 : DEF] -> 마지막 이전 컬럼값이 null이면 자릿수만 존재 '0'

                                      값에 대한 영역은 존재하지 않음

          [RH : 2 : 4 : 4567] -> 마지막 컬럼값이 null이면 자릿수와 값영역 둘다 존재하지 않음

      -> NULL이 들어가는 컬럼들은 마지막에 두면 더 좋다.     

   . 실재 생성 구조 예2)

     -> 컬럼 : ID, NAME

     -> 값 : 1234, A

     -> 값 : 1235, B

     -> 값 : 1236, C

     -> [RH : 2 : 1234 : 1 : A]

     -> [RH : 2 : 1235 : 1 : B]

     -> [RH : 2 : 1236 : 1 : C]

     -> 약 100만건 존재

     . 위 레코드에서 name 값을 아래 값으로 update한 경우 Row Migration 이 발생한다.

       처음 Insert시 block에 꽉 차게 된다. 그런데 update하므로써 block에 넘치므로

       다른 block을 하나 만들어서 현재 레코드를 빈 block으로 이주시킨다.

       이주 시킨후에는 기존 block에 이동한 block주소를 가지고 있어야 찾아갈 수 있다.

       만약, 계속 같은 레코드에 더 많은 문자를 UPDATE하게 되면 이주는 여러번 발생하고

       각 BLOCK에 체인처럼 이주 주소를 가지고 있어야 하는 경우가 발생할 수 있다.

        * 1차 해결방법 : PCT Free영역을 잘 관리하기

        * 2차 해결방법 : dba는 주시적으로 이 체인정보등을 관리해준다.

                           아래 BLOCK관리방법에 존재

     -> 값 : 1234, 'AAAA......약 3,000 개 문자'

     -> 값 : 1235, 'BBBB......약 3,000 개 문자'

     -> 값 : 1236, 'CCCC......약 3,000 개 문자' 

     -> 약 100만건 모두 update

     -> 기존 block에서 자료가 너무 많으므로 다른 block

     

     -> [RH : 2 : 1234 : 3000 : 'AAAA....']

    . PCT FREE

    . PCT USED

3. Block 관리방법

   SELECT TABLE_NAME, BLOCKS, EMPTY_BLOCKS, CHAIN_CNT, AVG_ROW_LEN

      FROM USER_TABLES

    WHERE TABLE_NAME= 'T2';

   - BLOCKS          : 테이블에서 사용된 block수

   - EMPTY_BLOCKS : 테이블에서 비어있는 block수

   - CHAIN_CNT      : 체인 수

   - AVG_ROW_LEN  : row별 평균 자리수

   - 위 SQL문장을 수행하면 Table_name은 나오지만 나머지 컬럼들은 나오지 않는다.

     아래 문장을 수행해줘야  위 sql문장을 수행했어야 자료가 조회 된다.

   - ANALYZE TABLE T2 COMPUTE STATISTICS;  --테이블별 전체 분석

     ANALYZE TABLE T2 ESTIMATE STATISTICS;   --테이블별 샘플로 일부 분석

   - 

   - ANALYZE 후 T2테이블결과 보기

   - CHAIN_CNT : 이 갯수가 많으면 SELECT속도가 너무 느려진다.

     이 CHAIN_CNT 갯수 없애주기

     * 방법1 : 저장장소(tablespace)이동하기

                . 저장장소를 이동하게 되면 이동한 tablespace에서 테이블 신규생성

                 , 하나의 레코드씩 insert 시키므로 chain이 없는 깨끗한 block으로 만들어 진다.

                . SELECT * FROM V$TABLESPACE;  --사용할 수 있는 저장장소 목록 조회

                . ALTER TABLE T2 MOVE TABLESPACE SAMPLE;

                . ALTER TABLE T2 MOVE TABLESPACE USERS;

       이동 후 분석결과 - chain-cnt가 0 으로 됐다.

      추가 : . 테이블이 이동 된 경우 테이블 레코드의 ROW_ID가 변경된다.

               이로인해 index 에서 가지고 있는 row_id와 table의 row_id가 서로 상이하게 된다.

             . 이 상태에서 where조건에 index column을 연결해도 db는 index의 상태를 확인하고 

               UNUSABLE 상태를 확인 후 table full scan을 수행하게 된다.

             . index 상태 확인 방법

               - SELECT index_name, status FROM user_indexes WHERE table_name = 'emp';

             . 그래서 index도 다시 생성 되어야 한다. 

               - drop index ..;

               - create index ...;

               - alter index .... rebuild;

                   --rebuild중 DML 문장(crud) 사용불가.

               - alter index index_name rebuild online;

                  --내부적으로 drop & create를 하게 됨.

                  --rebuild중 DML 문장(crud).

     * 방법2 : 신규테이블을 생성 후 INSERT하기

              . 이런방법도 가능하지만 내부적으로 이유는 모르지만 위 MOVE 사용방법을 더 권장

--관리 파일

remark '구','신' 이라는 라인 조회 되지 않음

set verify off

remark  모든 메세지가 조회되지 않음

remark set termout off

remark  첫줄에 컬럼 heading안보이게 처리

set heading off  

remark 처리 결과 레코드수 안보이게 처리

set feedback off  

set autotrace off 

SPOOL MOVET.SQL

SELECT 'ALTER TALE ' || TABLE_NAME || ' MOVE TABLESPACE EXAMPLE;'

   FROM USER_TABLES

UNION ALL

SELECT 'ALTER TABLE ' || TABLE_NAME || 'MOVE TABLESPACE USERS;'

  FROM USER_TABLES;

SPOOL OFF

@MOVET.sql

remark set heading on

remark set feedback on

remark set autotrace on

3. 테이블과 index 간 insert,update 구조

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

   테이블    : index

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

   INSERT    INSERT

   DELETE    DELETE

   UPDATE   DELETE & INSERT

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

   즉, 테이블에 update문장이 수행되면 index는 delete & insert가 수행 됨

3. Index Block

   . 특징

     - NULL값을 포함하지 않음 

     - B*Tree구조 (Blance)

     - 저장구조 : [RH : index컬럼갯수 : 자리수 : 값 : 자리수 : 값...] (RH : Row Header)

   . 저장구조 예

     -> 컬럼 : ID, NAME

     -> 컬럼 ID에 index 존재

     -> 값 : 1234, 'ABC'

         값 : NULL, 'DEF'

         값 : 4567, NULL   -> 일 경우 아래 index 형태로 저장됨

     -> [RH : 1 : 4 : 1234 : Rowid]

         [RH : 1 : 0 : Rowid]           <--하지만 이 자료는 만들어지지 않음.

                                                NULL은 index Block에 저장되지 않음

         [RH : 1 : 4 : 4567 : Rowid]

   . ROWID : OFBR : Object(6자리) + file(3자리) + block(6자리) + row(3자리)

   . index block생성 시 null은 생성하지 않음.

   . SELECT ....

     WHERE id is null ;  과 같이 검색할 때 id가 index를 존재 해도 'TABLE ACCESS FULL' scan하게 됨

                           null 값은 index block에 생성되지 않기 때문

   . index 재구성 시점

     - table을 다른 tablespace로 move했다 다시 원래 tablespace로 move했을 경우

     - 잦은 delete와 insert로 밸런스가 깨졌을 경우

   . 밸런스가 깨졌는지 확인 방법. index 구조를 분석.

     - ANALYZE INDEX idx_name VALIDATE STRUCTURE;

     - SELECT (DEL_LF_ROWS_LEN/LF_ROWS_LEN) * 100 AS Balancing FROM INDEX_STATS;

        . DEL_LF_ROWS_LEN : DELETE LEAF ROWS LENGTH : 삭제된 leaf row의 길이

        . LF_ROWS_LEN : 현재 총 leaf rows 의 길이

        . 이 숫치가 0 이면 최상이고, 클 수 록 조금씩 이슈가 발생한다.

        . oracle에서 20 이상이면 rebuild 하길 권장하고 있음.

   . 인덱스의 효율

     - 선택도가 낮을 수록 인덱스 효율이 좋다.

     - 선택도 범위:  0 <= selectivity <= 1

     - 선택도 값 : selectivity = 1 / distinct value;

       . 예) select 1/(distinct deptno) from emp;

     - SELECT column_name, num_distinct, density, num_nulls

         FROM USER_TAB_COL_STATISTICS

        WHERE table_name = 'EMP'

        ORDER BY 1;

        

        . NUM_DISTINCT : 각 컬럼별 distinct 한 수

        . DENSITY : 선택도 값

        . num_nulls : 숫자컬럼중이 null값 수

      - 인덱스 효율을 보는 script 파일 만들기

col owner for a10

col column_name for a25

store set saved_settings replace

set termout off

set verify off autotrace off

set feedback on termout on

prompt

prompt columns of table &1:

prompt

select column_name, num_distinct, density, num_nulls

  from user_tab_col_statistics

 where table_name = upper('&1')

 order by 1;

@saved_settings

set termout on

4. Reverse Index

   - 생성이유 :하나의 Block에 I/O가 너무 많이 집중 될 경우 index lock등이 발생한다.

      Index Block Header정보에 I/O가 발생하게 되면 기록을 하는데 무한대로 접근이 하닌

      Limit이 있기 때문에 index lock이 발생한다.

   - 예) 항공회사.항공권 테이블

         . 컬럼 : 항공권번호, 출발일, 도착일, 기종, 게이트번호, 도착지...

         . INDEX : 항공권번호  (규칙:201802031130G30S25 : 출발일 + 게이트번호 + 좌석)

         . 이때 출발일을 기준으로 모든검색이 이루어 지기에 몇개의 block에 I/O가 집중된다.

           만약, 거의 모든 BLOCK으로 I/O를 분산시킬 수 있다면 가장 좋을텐데..

           이 해법이 Reverse Index가 된다.

   - 예) CREATE INDEX IDX_EMP_ENAME_REV ON EMP(ENAME) REVERSE;

        . Reverse index : 52S03G031130208102 

   - Reverse Index를 db가 검색시 내부적으로는 정상index처럼 검색이 이루워진다.

     그래서 최종결과는 정상 index처럼 정렬되어 나온다.

4. Bitmap index

   - 예) 결혼정보 회사

        . 회원정보 : 이름, 나이, 성별, 연봉,직업, 거주지, 가족관계, 재산,자녀수,키,국적,취미,종교,...

        . index : 거의 모든컬럼이 index가 구성되어야 한다. 자주 검색조건에 포함 되므로

        . 이럴 경우 Bitmap index를 활용

   - 정의 : 컬럼값을 Bitmap (숫자 0 과1 의 조합)으로 mapping시킨다.

   - 속도 : 특별한 상황에서 일반 index보다 약 30배 속도가 더 빠르다.

   - 생성 ) CREATE BITMAP INDEX IDX_EMP_JOB_SAL ON EMP(JOB, SAL);

   - SQL : 개발자는 특별히 bitmap index라고 해서 다르게 sql문장을 작성할 필요는 없다.

   - 단점) 

      . 예) 성별컬럼 : 남,여  (1,0) 으로 Bitmap index가 존재 하고 있었는데

           법이 변경되어 성별에 종류가 추가 될 수 있다. (남,여,게이,트렌스젠더..  등)

           만약, 게이라는 성별을 가진 신입회원이 가입하게 되면

           전체 회원의 성별컬럼에 대한 Bitmap index가 전체 재 생성된다.

           (지금까지 1 자리 bitmap을 사용하다가 2자리 bitmap이 필요하기 때문)

           이런 회원이 첫 신규 가입하게 되면 속도가 어마어마하게 느려진다.

4. Index + Table 이 결합된 IOT

   - 정의 : Index와 Table이 결합된 구조

   - IOT 테이블 생성)

     CREATE TABLE IOTTEST

        ( NO NUMBER CONSTRAINT IOTEST_PK_NO PRIMARY KEY,

          TITLE VARCHAR2(50),

          CONTENTS VARCHAR2(500)

        )

       ORGANIZATION INDEX TABLESPACE USERS PCTTHRESHOLD 40

       INCLUDING TITLE

       OVERFLOW TABLESPACE USERS ;

      . ORGANIZATION INDEX TABLESPACE USERS  : 이 문장으로 IOT 가 된다

      . PCTTHRESHOLD 40

         : 전체 DATA를 저장하는 block에 40%를 찾이 할 경우 별도 block에 이동시킴

         : 

     INSERT INTO IOTTEST VALUES(1111, 'AAA', 'BBB');

     INSERT INTO IOTTEST VALUES(3333, 'AAA', 'BBB');

     INSERT INTO IOTTEST VALUES(9999, 'AAA', 'BBB');

     INSERT INTO IOTTEST VALUES(2222, 'AAA', 'BBB');

     SELECT * FROM IOTTEST;     

      . 조회결과 : 1111, 2222, 3333, 9999 순으로 조회 됨

     

     . INDEX FAST FULL SCAN : Index block을 한번에 여러게 읽어 옴

   - 보통 자료를 Insert 후 자료를 자료를 SELECT하면 insert한 순서대로 조회가 된다.

     하지만 IOTTEST 테이블은 PK를 기준으로 B*Tree를 만들고 최종 Leaf Node에 레코드가 존재 한다.

     그래서 자료를 조회 하면 정렬이 된 결과를 볼 수 있다.

  - IOT 단점

    . Index는 항상 정렬된 순서대로 구조를 만들게 된다.

     그래서 값들이 계속 추가 되면 속도가 느리다.

    . 값이 큰 자료가 들어 올 경우 자즌 split등이 발생하여 속도가 느려린다.

      그래서 PCTTHRESHOLD 속성을 이용해서 조정 할 수 는 있다.

4. Clustered Index

   - 

4. index 통계정보 만들기

  예제 : 부서에 index가 존재하고 있는데, 한 부서(A10)에 약 90%인력이 포함되어 있고,

  나머지 인력은 10%로 분산 되어있다고 가정할때..

  CBO가 정상적이지 않으면 A10 조건이 올 경우 INDEX SCAN을 해서 TABLE FULL SCAN보다 

  속도가 더 오래 수행 될 수 있다.

  해결방법 : ANALYZE를 해주면 CBO가 A10번 부서가 조건이 걸릴때 INDEX SCAN하지 안고 

  TABLE FULL SCAN하게 된다.

   - 통계정보 분석하기

     . ANALYZE TABLE emp ESTIMATE STATISTICS FOR TABLE 

        FOR COLUMNS DEPTNO SIZE 20  SAMPLE 10 PERCENT;

      . SIZE 20 : bucket 크기. 이 bucket을 이용해서 db는 자료를 담아 가면서 분석

      . SAMPLE 10 : 전체 크기에서 SAMPLE 10%를 가지고 analyze 하기.

    - 분석정보 만들기

      . DESC DBMS_STATS;  --package정보 보기

      . EXEC DBMS_STATS.GATHER_TABLE_STATS(OWNNAME=>'SCOTT', TABNAME=>'EMP',CASCADE=>TRUE,METHOD_OPT=>'FOR ALL COLUMNS SIZE 1');

      . 필수 argument값 만 기술해도 됨

      . cascade=true : 해당 테이블에 연관되어 있는 정보도 같이 조회.

      . ALL COLUMN SIZE 1 : 모든 컬럼들 다 분석 및 조회

    - 히스토 그램은 index가 있고 value의 분포가 불규칙한 컬럼에만 생성하자.

4. index 선택기준

   - 정의 : index가 여러개 존재할 때 어떤 index를 사용하지 선택 판단기준.

   - 선택기준 

     . 밸런싱 

     . 선택도

     . 조건절의 비교연산자 ( => 보단 =로 되어 있는 index)

   - CBO정보를 항상 최신정보로 유지시켜줘야 DB성능이 좋아진다.

   - 두개의 index를 동시에 찾아서 index scan을 할 수 도 있다.(hint 이용)

      . JOB에 index존재.  DEPTNO에 index존재 시 아래 sql문장 수행

      . 2개의 index를 동시에 사용할 수 있다.

      . SELECT /*+ AND_EQUAL(EMP, IDX_EMP_JOB, IDX_EMP_DEPTNO) */

                 EMPNO, ENAME, JOB, DEPTNO

          FROM EMP

         WHERE JOB = 'MANAGER' AND DEPTNO= 10;

      .  

              : 8i 도입 후 속도에 이슈 발생으로. 10g폐기. 11g 사용안됨  

      . SELECT /*+ INDEX_COMBINE(EMP, IDX_EMP_JOB, IDX_EMP_DEPTNO) */

                 EMPNO, ENAME, JOB, DEPTNO

          FROM EMP

         WHERE JOB = 'MANAGER'  AND DEPTNO= 10;

            : BITMAP CONVERSION FROM ROWIDS

              - ROWID를 BITMAP으로 변경  (0,1 구조)

4. 결합 INDEX

   - 고려사항

     . 분포도가 낮은 컬럼을 앞쪽에 위치

     . 

      

5. ORDER BY (sort, 정렬)

   - User가 접속하면 SESSION하나가 생성됨

     하나의 Session에 PGA 영역 존재

     PGA 영역에  Sort Area 존재

     Sort Area는 메모리 생성되는데 이 메모리가 부족하면 disk와 swapping한다.

     이러므로 속도가 느림

     추가로, 이 Sort Area는 각 session별로 관리 되기에 다른 session과 공유가 안된다.

     그래서 같은 정렬을 다른사용자가 해도 각각 sorting이 일어 난다.

   - 정렬 이유

     . Order by

     . Group by

     . distinct

     . minus

     . union

   - 예)

    SELECT * FROM EMP A

    MINUS

    SELECT * FROM EMP_HIS B;

    

     . 수학: A-B = A- (A교집합B)  (교집합:Intersection)

       이때 A교집합B는 항상  A정렬, B 정렬 후 서로 비교해 가면서 값을 추출한다.

       정렬 후 비교하므로 최종결과는 ORDER BY 된 순서로 조회 된다.

       

     SELECT * FROM EMP a 

      WHERE NOT EXISTS (SELECT 1 FROM EMP_HIS b WHERE a.empno = b.empno);

    

     SELECT * FROM EMP

      WHERE empno not in (SELECT empno FROM EMP_HIS); 

    

    SELECT A.*

      FROM EMP A LEFT OUTER JOIN EMP_HIS B

              ON (A.empno = B.empno)

     WHERE B.empno is null;

     

     SELECT * FROM EMP

     UNION ALL

     SELECT * FROM EMP_HIS;

     

        . UNION ALL 은 정렬이 발생하지 않아 빠르다.

     

4. Extent

   - 정의 : 여러개 block을 묶어서 관리하는 단위 

   - Blocks : 값이 존재하는 block

   - Empty block : 값이 비어있는 block

   - HWM(high water mark) : block과 empty block과의 경계선

     . 

5. 자료 조회 순서

   1. 먼저 index scan

   2. index의 row id를 기준으로 data block 읽기

   3. block을 읽어서 DBC(Data buffer cache)로 저장함.

6. index scan을 안하는 경우

   - index column을 변경시켰을 경우

   - null값 질의

   - 형변환 : 서로 다른 자료형을 일치 시킴

   - 부정연산자 : 대상의 범위가 넓어지므로 full table scan 을 함.

   - 예  (TABLE ACCESS FULL)

     where sal * 12 > 36000;                ->where sal > 36000/12;

     where sal + 0 = 3000;                  

     where year||month||day='20180127' ->where year = '2018' and month='01' and day='27'

     where name || '' = 'KIM'               ->일부러 name에 index scan안되게 하는 방법

     where upper(name) = 'HONG'

     where name is null;

     where deptno like '1%'           -> deptno가 number이므로 deptno를 형변환하기에 index scan안함

     where to_char(deptno) like '1%' -> deptno가 number이므로 deptno를 형변환하기에 index scan안함

     where deptno != 10;    -> != 부정연산자를 사용시 index scan을 안함

7. function-based normal index

   - 정의 : 컬럼값에 변형을 가해서 만들어진 index

   - CREATE INDEX IDX_EMP_SAL12 ON EMP(SAL*12);

   - SELECT * FROM EMP WHERE SALE*12 >= 36000;

8. Table Recycle

   - DROP TABLE table_name;

   - 수행했던 이력 보고 : C:\app\user\oradata\orcl\*.LOG 파일에 정보가 존재.

     . *.LOG파일은 Text파일이 아니고 binary파일 이여서 바로 볼 수 없다.

     . 이 파일들을 지우면 DB가 아에 수행되지 않는다.

   - 이전에 수행했던 명령어 삭제방법

     . alter system switch logfine;

     . 위 문장을 3번 쓰면 됨.

     . 3번 쓰는 이유 : *.LOG파일이 3개 존재 하는데 위 문장을 한번 수행할 때마다

       첫 번째 LOG파일이 두 번째 LOG파일로 이동된다. 그래서 3번 수행하면

       사라지게 되는 이유이다.

   - SHOW RECYCLEBIN;

      . DROP된 테이블 목록 보기

      . 특정시점에 레코드 정보도 볼 수 있다.(??)

   - FLASHBACK TABLE table_name TO BEFORE DROP;

      . drop이전으로 테이블을 복구 시킬 수 있다.

      . 단점, FLASHBACK 복구 후에 인덱스의 상태 확인하기

       >COL INDEX_NAME FORMAT A40

       >COL TABLE_NAME FORMAT A20

       >COL COLUMN_NAME FORMAT A20

       >SELECT INDEX_NAME, TABLE_NAME, COLUMN_NAME FROM USER_IND_COLUMNS;

       index_name이 깨진 현상을 볼 수 있다.         

       

      . 해결방법 : index rename

       - ALTER INDEX "BIN$2+6uQ8eVSFaZjrGsYdM3XQ==$0" RENAME TO IDX_EMP_SAL;

   - 복구 가능한 정보는 그리 오래 가지고 있지는 않다.

   - PURGE RECYCLEBIN ;   --휴지통 비우기