About DATABASE

logminer사용하기~!! 

1. 파라미터 파일에 dictionary file 이 생성될 위치를 지정한다.

    utl_file_dir="d:\oracle"    -->> spfile을 사용할 경우 alter system set utl_file_dir='c:\oracle\ora92\logminer') scope=sfpile; 을 사용하여 dict파일을 생성될 위치를 생성해주면 된다!!

 

2. db 를 restart 한다.

  SQL> shutdown immediate

  SQL> startup

 

4. dbms_logmnr_d.build 를 사용하여 dictionary file을 생성시킨다.

   SQL> execute dbms_logmnr_d.build('dir_file','c:\oracle\ora92\logminer);

 

   PL/SQL 처리가 정상적으로 완료되었습니다.

 

 

 

5. 분석할 아카이브 로그파일및 리두로그파일을 추가시킨다.

 

   SQL>  execute dbms_logmnr.add_logfile('d:\oracle\oradata\ocp\redo01.log',dbms_logmnr.new);

 

    PL/SQL 처리가 정상적으로 완료되었습니다.

 

 

 

 

 

< 참조문서: 분석을 위한 Redo log 지정하기 >

   dictionary file을 생성하였으면 이제 redo log를 분석할 수 있다.
   첫 단계로, 분석하고 싶은 log file을 ADD_LOGFILE procedure를 이용하여
   지정한다. procedure의 parameter로 NEW / ADDFILE / REMOVEFILE 등의 상수를
   이용한다. 값을 지정하지 않을 경우 default로 ADDFILE이 배정된다.

   각 상수의 값은 다음과 같다.

 - NEW : 1
 - ADDFILE : 3
 - REMOVEFILE : 2

 

   1. sqlplus를 사용해서 Oracle Instance를 기동한다.
  SQL> startup

 

   2. dbms_logmnr.add_logfile procedure에 NEW parameter를 지정함으로써
       log의 리스트를 만든다. log는 online redo log file이거나 archived
       log file 중에서 지정해야 하고 일반 filie을 지정할 경우 error가 발생한다.

      SQL> exec dbms_logmnr.add_logfile('/home2/o8ii/oradata/o8ii/redo01.log',1);

 

   3. log 리스트에 첨가하는 작업
      SQL> exec dbms_logmnr.add_logfile('/home2/o8ii/oradata/o8ii/redo02.log',3);

 

   4. log 리스트에서 삭제하는 방법
      SQL> exec dbms_logmnr.add_logfile('/home2/o8ii/oradata/o8ii/redo02.log',2);

 

6. 분석 시점을 지정한다.

    SQL> execute dbms_logmnr.start_logmnr(dictfilename=>'d:\oracle\dir_file',-
       starttime=>to_date('2005/08/09 15:55:10','RRRR/MM/DD HH24:MI:SS'),-
       endtime=>to_date('2005/08/09 16:05:10','RRRR/MM/DD HH24:MI:SS') );

 

    PL/SQL 처리가 정상적으로 완료되었습니다.

 

또는 파일 이름을 지정하면 된다!!~!! 시점을 지정해서 검색도 가능하다!!!

 

7. v$logmnr_contents  를 조회하여 원하는 정보를 추출한다.

     
   SQL> alter session set nls_date_format='RRRR/MM/DD:HH:MI:SS';

 

 

   SQL> col seg_owner for a10

   SQL> col username for a10

 

   SQL> col sql_redo for a30

                                                                                                                                                                                                                                       
                                                                                                                                                                                                                                                                                    
    SQL> select timestamp,seg_owner,username, sql_redo from v$logmnr_contents
             where sql_redo like '%drop%';

TIMESTAMP              SEG_OWNER     USERNAME                 SQL_REDO                                                                                                                                                                                                                                     
------------------- ---------          --------------------- ---------------                                                                                                                                                                                                               
2005/08/09:03:57:33 SYS                  SYS                          drop table emp900;

 

 

 

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

 

 

 

 

로그마이너를 통해 원하는 시점의 log정보를 검색해서 내가 어느 시점에 파일을 drop시켰는지 변경했는지를 알 수 있다!!

그 후 데이터베이스의 테이블을 불완전 복구하면 원하는 시점으로 테이블을 복구 할 수 있다!

예를 들어 내가 2008년 7월 22일 15:00:00 시에 scott의 emp테이블을 drop했을경우 나는 오프라인 백업데이터를 가져와 그 시점까지만 복구하면 drop하기 바로전까지 복구 할 수 있는 것이다

 

1.백업된 파일은 내 데이터 베이스로 복사해온다...

 

2.불완전 복구작업을 수행할 때 가장 중요한 포인트 중에 하나는 마지막 오프라인 백업된 모든 데이터 파일들을 현재 경로로 복사해야 한다는 것입니다.

이때 ctl파일이나 redo파일등은 복사할 필요 없고, 데이터 파일이 깨진 것이므로 모든 데이터 파일만 복사하면 된다.

 

불완전 복구 방법에서는 특정 파일만 재 설치해서는 모든 데이터를 과거 특정시점으로 되돌릴 수 없기 때문에 반드시 모든 데이터를 과거 시점으로 복구해야 하기 때문이다!!!

 

 

 

3.startup mount

 

4.SQL> set autorecovery on --->> recover database 실행하여 아카이브 적용시 자동으로 auto를 적용시켜줌

 

5.SQL> recover database until time '2008-07-22 15:33:00';

 

6.SQL> alter database open; until time을 사용하여 복구해서 datafile의 scn이 다르기 때문에 resetlogs를 사용하여 강제로 scn과 모든 상태정보값을 초기화 시킨 후 오픈하여야 한다~!

 

7.SQL> alter database open resetlogs;

 

 

 

ORACLE10G 에서 추가된 LOGMINER 의 기능
======================================

출처:한국오라클 불리틴

 

PURPOSE
-------
이 자료는 Oracle10g version에 추가된 LogMiner 기능에 대해 설명한다.

 

Explanation
-----------
Oracle10g LogMiner 에서는 아래의 기능들이 추가되었다.

1.  LogMiner in a Shared Server Environment

 

기존에는 Dedicated mode에서만 logminer실행이 가능했으나 Oracle10g 에서는 MTS 환경에서도 logminer의 실행이 가능하다.

2.  Support for Index Organized Tables

 

Logminer 는 IOT 에 대해서도 Logminer를 통해서 정확한 record 변화를 찾을 수 있다. Oracle9i 까지는 Logminer에서 IOT 를 지원하지 못했다.

3.  Support for new datatypes

 

LogMiner 10g 에서는 아래의 data type을 redo/undo transaction에서 정확히 반영하게 되었다.  즉, 아래의 parameter가 새로

지원된다.

 

  - LONG
  - Multibyte CLOB
  - NCLOB

4.   SQL_REDO/SQL_UNDO without rowids - NO_ROWID_IN_STMT

 

DBMS_LOGMNR.START_LOGMNR procedure실행시에 NO_ROWID_IN_STMT option을 추가할 수 있다. 이 기능은

v$logmnr_contents view의 SQL_REDO 와 SQL_UNDO column에서 rowid 를 나타내지 않도록 하는 option이다.

이 rowid 를 나타내지 않으면 이 sql들을 rowid 가 다른 환경에서도 사용할 수 있으므로 더 유용하다.  logminer 기능을  object가

원래 있는 db가 아닌 다른 db에서 실행할 때 이 기능을 이용하여 rowid 가 아닌 primary key 등에 의해 sql 을 적용할 수 있다.

 

[예제]

SQL> EXECUTE DBMS_LOGMNR.START_LOGMNR(-
         OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + -
         DBMS_LOGMNR.NO_ROWID_IN_STMT);

 

5.  Removing a logfile from the LogMiner session

 

Oracle9i 까지는 Logminer session을 실행하여 log file이나 archiving file을 add한 후에는 list 에서 삭제할 수가 없었다. 

Oracle10g 부터는 add한 file을 삭제할 수 있는 기능이 추가되었다.

이 기능은 다음과 같이 DBMS_LOGMNR.REMOVE_LOGFILE()를 이용하여 가능하다.

[예제]

SQL>  EXEC DBMS_LOGMNR.REMOVE_LOGFILE(LOGFILENAME => '/oracle/logs/log2.f');

만약 위와 같이 logfile을 삭제한 후에 바로 v$logmnr_contents view를 조회하면
아래와 같이 ora-1306 error가 발생한다. 그러므로 다시 DBMS_LOGMNR.START_LOGMNR 를
실행한 후 조회해야 한다.

SQL>  select count(*) from v$logmnr_contents;
 select count(*) from v$logmnr_contents
                      *
ERROR at line 1:
ORA-01306: dbms_logmnr.start_logmnr() must be invoked before selecting from
v$logmnr_contents

 

Reference Documents
-----------------
<Note:249001.1>

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

delete from t1 where c1 = 'GRACE';

이와 같은 방식으로 random으로 많은 양의 데이터가 삭제될 경우,
인덱스의 leaf block이 드문드문하게 채워져 있게 된다. (Index Fragmentaion)

물론, 장기적으로는 삭제된 공간은 재활용 될 수 있지만
인덱스는 sorting 되어야 한다는 특징에 의하여
Key 값이 들어갈 수 있는 자리가 정해져 있으므로 삭제된 공간을 재활용하지 못할 수 있다.

[Oracle Virus] - 왜 Index가 불필요하게 커지는가? 를 참조하면, 위 내용을 이해할 수 있다.

이 경우,
INDEX OFFLINE REBUILD
INDEX ONLINE REBUILD
INDEX SHRINK
INDEX COALESCE
를 통해 fragmentation 된 leaf 블록들을 정리한다.

이중, coalesce와 shrink는 Oracle 10g부터 동일한 방법(delete + insert)으로 수행되고,
Leaf block 간의 key 값을 compact 하는 것이므로 index의 높이에는 변화가 없다.

단, coalesce는 compact를 통해 확보된 index의 Free block들을 반환하지 않으므로,
Index의 fragmentation을 정리하지만 Index의 크기는 변하지 않는다. 

반면, Shrink는 compact를 통해 확보된 index의 Free Block들을 반환하고 HWM를 조정하므로
Index의 Fragmentation을 정리함과 동시에 Index의 크기를 줄인다.

# Coalesce TEST 

# Shrink TEST 

이 문서는 REDO log buffer 캐쉬의 아키텍쳐의 이해, 및 SGA 구조에 관련해 튜닝 해야 할 문제를 찾아내 해결하는 방법에 대해 설명하고 있습니다.

 

◆ 1.REDO로그 버퍼란 무엇인가???

REDO log buffer는 SGA내에 존재하며 데이타베이스에 대한 변경에 관한 정보를 보관 유지하는 버퍼입니다. 이 정보는 REDO 엔트리에 격납됩니다. REDO 엔트리는 데이타베이스에 대해서 행해진 변경을 재실행하기 위해서 필요한 정보를 포함하고 있습니다. 필요에 따라서 개개의 REDO 엔트리는 데이타베이스의 복구에 사용됩니다.   REDO엔트리는 Oracle 서버 프로세스에 의해 유저의 메모리 영역으로부터 SGA에 있어서의 REDO log buffer에 카피됩니다. 이 때 REDO 로그 엔트리는 버퍼내의 영역에 차례로 써집니다. 백그라운드 프로세스의 LGWR는, REDO log buffer의 내용을 디스크상의 액티브한 온라인 REDO 로그 파일 (온라인 REDO 로그 파일 그룹)에 씁니다. 초기화 파라미터 LOG_BUFFER는 REDO log buffer의 사이즈를 바이트 단위로 지정한 것입니다. 1개의 트랜잭션(transaction), 혹은 다중의 트랜잭션(transaction)에서 대량의 REDO log buffer에의 기입이 발생하는 환경에서는 일반적으로는 이 값을 크게 해 로그 파일에 대한 I/O수를 줄일 수가 있습니다. LOG_BUFFER 사이즈의 설정에 관해서는 KROWN#18227을 확인해 주세요.

 

◆ 2.REDO 로그 Latch

데이터 블록에 대한 변경이 필요할 때 이하의 순서에 의해 REDO log buffer내에 REDO 레코드가 작성됩니다. 다른 프로세스가 해당 프로세스보다 높은 COMMIT SCN(System Change Number)를 생성하고 있지 않는 것을 확인한다.   ■ REDO를 쓸 수 있는 스페이스가 있는지를 확인한다. 충분한 스페이스가 없는 경우는 LGWR가    REDO log buffer의 내용을 디스크상의 REDO 로그 파일에 쓰거나 로그 스윗치를 실시한다. ■ REDO log buffer내에 필요한 스페이스를 할당한다. ■ REDO log buffer에 REDO 레코드를 카피하고, 리커버리 시에 사용 가능하도록 관련성 실시 데이타베이스에는 이 처리를 실행하기 위해 3개의 REDO Latch가 있습니다. ・redo copy latch redo copy latch는 상기 순서를 실행하는 동안 보관 유지되고 있습니다. 빈 공간을작성하기 위해서 로그 스윗치가 실행되었을 때에 해방되어 로그 스윗치가 종료하면 다시 취득합니다.   ・redo allocation latch SGA내의 REDO log buffer에 대한 REDO 엔트리의 기입을 직렬화하기 위해서 사용됩니다. 트랜잭션(transaction)량이 적은 혹은 1 CPU의 서버인 경우에는 redo allocation latch는 redo copy latch를 획득하지 않고  REDO를 REDO log buffer에 씁니다.빈 스페이스를 획득하기 위해서 로그 스윗치가 필요하게 되는 경우는 이 Latch는 redo copy latch와 함께 해방됩니다. 이 Latch는 데이타베이스에 1개 밖에 없습니다.   ・redo writing latch LGWR 프로세스에 대해서 동시에 복수 프로세스에 의한 로그 스윗치의 요구가 발생하는 일을 막습니다. 빈 공간이 필요한 프로세스는 LGWR에 REDO 로그 버퍼로부터 REDO 로그 파일에의 쓰거나  혹은 로그 스윗치의 실행을 요구 하거나 단지 대기할까를 판단하기 이전에 이 latch을 취득해야 합니다.

 

◆ 3.REDO Latch에 관한 인스턴스 파라메터

REDO log buffer에 있어서의 Latch 할당의 동작에 관련하는 2개의 파라미터가 있습니다.   ・LOG_SIMULTANEOUS_COPIES   시스템이 복수CPU를 가질 때 redo copy latch의 수를 제어   ・LOG_SMALL_ENTRY_MAX_SIZE   REDO log buffer에 REDO를 쓸 때 redo allocation latch를 취득할지 아닐지를 결정하는 기준

 

◆ 4.REDO로그 버퍼의 퍼포먼스 튜닝

REDO log buffer에 있어서의 경합은 모든 DML 및 DDL문은 실행전에 REDO 엔트리를 작성 할 필요가 있기 때문에 퍼포먼스상 중요합니다. 경합은 Latch 경합 혹은 REDO 로그 버퍼에 대한 빈 공간의 과도의 요구가 있는 것으로 확인할 수 있습니다. 이하에 열거한 2 종류의 경합이 발생하고 있는 일을 검출하는 것이 가능합니다.   ・Latch 경합 다음의 SQL는 REDO 로그에 있어서의 Latch의 사용율을 표시하는 것입니다.         SELECT  substr(ln.name, 1, 20) "latch type",                   100*(misses + immediate_misses)/(gets +                   immediate_gets + immediate_misses) "latch utilization(%)"        FROM v$latch l, v$latchname ln      WHERE  ln.name in ('redo allocation', 'redo copy')    　　 and ln.latch# = l.latch#;   이 결과 latch utilization가 1%를 넘는 경우 Latch 경합이 발생하고 있다란것을 의미합니다. redo copy latch의 전에 redo allocation latch의 튜닝을 실시하는 일을 추천합니다.redo allocation latch는 인스턴스에 1개 밖에 없기 때문에 redo allocation latch의 경합은 퍼포먼스상 영향도가 높기 때문입니다.   Oracle7,8i에서는 redo alocation latch의 경합이 발생하는 경우 LOG_SMALL_ENTRY_MAX_SIZE의 값을 낮추고 redo copy latch가 획득되기 쉽게 조정하는 것이 좋다. 추천치는 평균의 REDO 사이즈이며 이하의 SQL의 결과의 'redo size'를 'redo entries'의 값으로 나눈 값이 됩니다.       SELECT value        FROM v$sysstat     WHERE name in ('redo size','redo entries');   다만 이 SQL를 실행할 때는 실전 환경과 같은 조건이 아니면 적절한 결과를 얻을수 없습니다. redo copy latch 경합이 발생하고 있는 경우는 LOG_SIMULTANEOUS_COPIES 파라미터를 증가시키는 것으로 새로운 redo copy latch를 추가시킬 수가 있습니다.이 파라미터의 추천치는 CPU수*2 가 됩니다.   Oracle8i에서는 redo allocation latch 경합이 발생하고 있는 경우, 특정의 처리에 대해서는  NOLOGGING 옵션을 사용하면 생성되는 REDO를 감소시킬수  있습니다 혹은 LOG_BUFFER 파라미터를 증가시키는 것으로 latch의 부하를 낮추는 것이 가능합니다. LOG_BUFFER 파라미터의 튜닝에 관해서는 KROWN#18227 로 소개있습니다.redo copy latch 경합이 발생하고 있는 경우 Oracle8 이전과 같이 LOG_SIMULTANEOUS_COPIES를 증가 시킨다. ・영역 할당의 리퀘스트의 경합 REDO log buffer의 영역 할당을 대기한 회수는 "redo buffer allocation retries"라는 통계로 카운트 됩니다. 다음의 SQL를 사용하고, 어플리케이션이 동작중의 통계치를 감시해야 합니다.          SELECT name,valus 　    FROM v$sysstat 　　WHERE name = 'redo buffer allocation retries';   "redo buffer allocation retries"의 값은 0인 것이 이상적입니다. 이 값이 증가 경향에 있는 경우에는 LOG_BUFFER 파라미터의 값이 너무 작을 가능성이 있습니다. LOG_BUFFER의 튜닝 방법에 대해서는 Krown:18227을 참조하십시오.

CTAS 를 통한 테이블 복제시 제약 조건

 

	Local	Remote
Column Name, Type, Length		그대로 Copy 됨
Column Default Value		No
Index		No
Constraint		No
Not Null ( PK 에 의한 Not Null 포함 )		그대로 Copy 됨그대로 Copy 됨
Grant		No
Synonym		No
Trigger		No

 

테스트 결과는 첨부 화일 참조 바랍니다.

 

1. CTAS 의 경우 Parallel Hint 는
   CT(Create Table) 에서는 사용하여도 의미가 없고(ORACLE 이 무시함),
   AS 에서만 Parallel Hint 를 사용한다.
   (As Select /*+ paralllel(a) parallel(b) */ * from tab1 a, tab2 b)
   식으로 사용한다.

2. 캐릭터셋의 다른 DBMS 간의 CTAS 사용시 Column Size 가 달리 될수 있다.
   [ 참고 - http://cafe.naver.com/prodba/2014 ]
   이 경우 _keep_remote_column_size=true 로 설정 후 DB Restart 후에 CTAS 를 사용하면 된다고함
   _keep_remote_column_size 파라미터의 의미 : remote column size does not get modified
   Default 값은 False 임  

3. 그럼 가장 빠르게 테이블 복제 [ Export / Import 제외 ]
  
  3.1 Create Table COPY_Table as select * from Source_Table@remote where 1=2
   를 통해서 테이블 껍데기만 Copy 후에
  3.2 alter session enable parallel dml;
  3.3 insert /*+ parallel(Copy_Table, 10) */ into Copy_Table nologging
      select /*+ parallel(Source_table, 10) */ * from Source_Table@remote ;
  3.4 Creae index ... Nologging PARALLEL ;
      CREATE INDEX XAK_COPY_Table ... NOLOGGING PARALLEL ;
  3.5 ALTER index ... LOGGING NOPARALLEL ;
      ALTER index XAK_COPY_Table logging noparallel ;
  3.6 통계정보 수집
     exec dbms_stats.gather_table_stats(ownname=>user, tabname=>'COPY_Table ');
  3.7 기타 추가 작업
     Column Default Value, Index, Constraint, Grant, Synonym, Trigger 

4. CTAS 를 쓸것인가 ? Export/Import 를 쓸것인가 ?
   CTAS - Parallel 처리가 가능하다는 강점이 있다.
          단. DB Link 를 통해서 통신 하기 때문에, Network 로 근거리(한국 내 정도 ^^;)어야 하고,
              양쪽 DB 의 Characterset 이 동일 해야 한다. 기타 DB LInk 사용에 따른 제약이 없어야 한다.
   Export/Import - Dump 화일 생성을 위한 저장할 공간이 필요하다.
                   양쪽 DB 의 Characterset 이 다르더라도, Sub Set 에서 Super Set 으로 이관시 아무런
                   문제가 되지 않는다. 비교적 먼거리 시에는 Remote 에서 Dump 화일 생성, ftp 전송,
                   Local Import 수행이 가능하다.

1.해당하는 PK를 삭제한다
: ALTER TABLE TABLE명 DROP CONSTRAINT PK명;

 

2.변경하고자 하는 COLUMN으로 Unique Index를 생성한다.
: CREATE UNIQUE INDEX PK명 ON TABLE명(COLUMN명) TABLESPACE TABLESPACE명;

 

3.PK에 속성을 추가한다.
: ALTER TABLE TABLE명 ADD CONSTRAINT PK명 PRIMARY KEY(COLUMN명);

 

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

 

 

-- PK 제거하기

Alter TABLE 테이블이름 drop primary key cascade

 

--PK추가 하기

ALTER TABLE 테이블이름 ADD CONSTRAINT 인덱스 이름 PRIMARY KEY(field1, field2)


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

1. PK INDEX Create

 

ALTER TABLE TABLE_NAME
        ADD CONSTRAINTS PK_INDEX_NAME
            PRIMARY KEY (PK_1, PK_2, PK_3)
            USING INDEX
            TABLESPACE TABLESPACE_NAME
            STORAGE(    INITIAL     1280K
                        NEXT        1280K
                        PCTINCREASE 0   );

2. INDEX Create

 

CREATE UNIQUE INDEX INDEX_NAME ON TABLE_NAME(PK_1, PK_2, PK_3)

TABLESPACE TABLESPACE_NAME

STORAGE ( INITIAL 5M NEXT 5M PCTINCREASE 0 );

 

3. PK_INDEX Drop

 

ALTER TABLE TABLE_NAME DROP CONSTRAINT INDEX_NAME;

 

4. INDEX Drop

 

DROP INDEX INDEX_NAME;

기존에는 테이블을 새로 작성(reorg)  작업을 통해

커진 테이블 스페이스 크기를 복구 가능하였으나

10g 부터는 shrink 기능을 이용하여 손쉽게 테이블을 줄일수 있게 되었다.

Shrink 기능은 HWM(High Water Mark)를 줄일수 있는 기능이다.


- 사전 확인 사항

init.ora 파일내에 compatible = 10.2 이상인것을 확인

ASSM (Automatic Segment Space Management) 테이블 스페이스여만 가능

각 테이블 조회 방법은

SELECT obj.owner
,obj.table_name
,(CASE WHEN NVL(idx.cnt, 0) < 1 THEN 'YES' ELSE 'NO' END) shrinkable
FROM dba_tables obj,
(SELECT table_name, COUNT(rownum) cnt
FROM dba_indexes
WHERE index_type LIKE 'FUN%'
GROUP BY table_name) idx
WHERE obj.table_name = idx.table_name(+)
AND obj.tablespace_name = upper('&1')

쿼리를 통해 (테이블 스페이스 명을 인자값으로)

확인 가능하다.

1. 테이블 검색 방법

SELECT * FROM TABLE(DBMS_SPACE.ASA_RECOMMENDATIONS());

아래와 같이 테이블의 DBA_SEGMENTS에서 볼수 있는 크기와

축소 가능 크기가 조회된다.

SEGMENT_OWNER	SEGMENT_NAME	SEGMENT_TYPE	PARTITION_NAME	ALLOCATED_SPACE	USED_SPACE	RECLAIMABLE_SPACE
MAX_TI	SMR_IF_LOG	TABLE		6761793074	5910149080	851643994
MAX_TI	SMR_IF_LOG_I01	INDEX		478455081	420139142	58315939
MAX_TI	SMR_IF_LOG_I02	INDEX		411921243	398204079	13717164

2. 축소하기

가장 먼저 행들을 이동 가능하도록 변경한다.

위의 SMR_IF_LOG 테이블을 기준으로 설명하겠다.

ALTER TABLE SMR_IF_LOG ENABLE ROW MOVEMENT;

--> 반대로는 ALTER TABLE SMR_IF_LOG DISABLE ROW MOVEMENT; 이다..

이제 SHRINK 기능을 수행할수 있으며

다음 3가지 형태로 가능하다

① ALTER TABLE SMR_IF_LOG SHRINK SPACE; 
    -- SMR_IF_LOG 테이블의 공간만 TABLESPACE로 환원

② ALTER TABLE SMR_IF_LOG SHRINK SPACE CASCADE;
    -- 모든 관련 OBJECT까지 TABLESPACE으로 공간 환원

③ ALTER TABLE SMR_IF_LOG SHRINK SPACE COMPACT;
   -- 행들만 이동시킴.



※ SHRINK 를 적용 시킬  없는 테이블
UNDO segments
temporary segments
clustered tables
tables with a column of datatype LONG
LOB indexes
IOT mapping tables and IOT overflow segmnets
tables with MVIEWS with ON COMMIT
tables with MVIEWS which are based on ROWIDs.

SELECT --*
       'ALTER TABLE '||SEGMENT_NAME||' ENABLE ROW MOVEMENT;   '||CHR(10)||CHR(13)||
       'ALTER TABLE '||SEGMENT_NAME||' SHRINK SPACE COMPACT;  '||CHR(10)||CHR(13)||
       'ALTER TABLE '||SEGMENT_NAME||' SHRINK SPACE ;         '||CHR(10)||CHR(13)||
       'ALTER TABLE '||SEGMENT_NAME||' SHRINK SPACE CASCADE;  '||CHR(10)||CHR(13)||
       'ALTER TABLE '||SEGMENT_NAME||' DISABLE ROW MOVEMENT;  '||CHR(10)||CHR(13)
  FROM USER_SEGMENTS a
 WHERE 1=1
   AND a.segment_type = 'TABLE'


select * from table(dbms_space.asa_recommendations());

select job_name, program_name
from dba_scheduler_jobs
where job_name like '%SPACE%';

select program_name, program_action
from dba_scheduler_programs
where program_name = 'AUTO_SPACE_ADVISOR_PROG';

1. REDO
 - 모든 변경사항을 REDO로그에 기록한다.
 - REDO로그는 Online REDO와 Archuved REDO로그로 구성된다.
    Online REDO 로그는 2개 이상의 파일로 구성되어 있어,
    현재 사용중인 로그 파일이 꽉 차면 다음 로그 파일로 스위칭
    이때 꽉 차여진 로그 파일을 다른 위치로 백업래 준 파일을 Archived REDO로그 이다.
 - 목적 3가지
  - 데이타 복구 : Archived REDO이용
  - 버퍼캐시복구 : 인스턴스가 비정상적종료시 그떄까지 작업내용이 잃어버리게 됨.
                          재기동 되면 Online REDO로그에 저장된 기록사항을 읽어와 마지막
                          채크포인트와 사고발생직전까지 수행한 트랜젹션을 재현
  - Fast Commit(IO속도 차 극복) : 데이타 버퍼 블록을 디스크에 기록하는 작업은 Random엑세스 방식,
                                              Append방식 Append방식이 상대적으로 빠르게 때문에 우선 변경사항을
                                              Append방식으로 기록하고 동기화는 후에 배치방식으로 일괄수행.
 - REDO로그 버퍼를 REDO로그에 기록하는 시점
  - 3초마다 DBWR프로세스부터 신호흫 받을때
  - 로그 버퍼의 1/3이 차거나 기록된 REDO레코드량이 1MB를 넘을떄
  - 사용자 커킷 또는 롤백 명령이 날릴때
  
2. UNDO
 - 각 트랜지션별로 UNDO세그먼트를 할당해주고 그 트랜지션이 발생시킨 테이블과 인댁스에
    대한 변경사항을 UNDO레코드 단위로 UNDO세그먼트 블록에 기록.
 - 목적 3가지
  - 트랜지션 롤백
  - 트랜지션 리커버리(인스턴스 리커버리시 롤백단계)
  - READ Consistency(읽기 일관성)
  타 DBMS는 Lock를 통해 일기 일관성을 구현하지만,
  오라클에서는 UNDO데이타를 이용해서 읽기 일관성을 구현한다.  
             읽기 일관성이란 Transaction이 진행되는 동안 Database의 다른 사용자는 이 Consistent Read에 의해
             Commit되지 않은 변경 사항을 볼 수 없는 기능 입니다.  
 - UNDO레코드에 기록되는 내용
  - Insert : 추가된 레코드의 rowid
  - Update : 변경되는 컬럼에 대한 before image
  - Delete : 지워지는 로우의 모든 컬럼의 대한 before image
------------------------------------------------------------------------------------
REDO 와 UNDO를 차이점에서 바라본 관점.
------------------------------------------------------------------------------------
REDO 는 UNDO를 포함 합니다.
REDO 는 시스템 장애시 복구를 위해 사용 합니다.
복구시에 UNDO 데이터도 같이 복구하구요. Commit 되지 않은 데이터를 Rollback 하게 됩니다.
UNDO 는 Rollback 시에도 사용 되지만 Read Consistency(읽기 일관성) 을 위해서 도 사용 됩니다.
REDO 는 모든 변경사항(UNDO 포함)을 기록 합니다.
복구는 UNDO 를 통해서 복구를 하게 됩니다. 즉, ROLLBACK을 한다는 말이죠.
시스템 장애가 발생하게 되면 UNDO 데이터도 모두 날아가게 되겠죠.
결국 시스템 장애시 REDO 데이터를 이용해서 마지막 CHECK POINT 부터 장애까지의 DB BUFFER CACHE 를 복구하게 됩니다.
이게 완료가 되면 UNDO DATA 를 이용하여 COMMIT 되지 않은 데이터를 모두 ROLLBACK 함으로써 복구를 완료하게 됩니다.
결국 REDO 가 UNDO 를 복구하고 최종적으로 UNDO가 복구를 하게 됩니다.
UNDO(안한것 처럼)는 되돌리는 것 이라고 보시면 될거에요.
어떤 세션에서 DML을 발생시키면 commit이나 rollback을 날리기 전까지 이전 정보를 저장하기 위해서
UNDO 블럭에 해당 정보를 기록하죠.. 해당 세션이 트렌젝션 중에 비정상적으로 종료가 되었다면,
안한것 처럼(UNDO) 다시 원복해야 되니까요.
REDO(다시 함)는 위에 설명에도 있듯이 인스턴스 실패시(DB가 내려감) 데이터 파일에 쓰여지지 않은 커밋된 데이터를 복구한다고 되어 있습니다.
좀 더 설명을 해드리자면 커밋을 날릴 경우 LGWR가 로그 파일에 변경된 정보를 기록하게 되고
그 다음에 DBWR이 버퍼캐쉬에 있는 변경 사항에 대해서 데이터 파일에 내려 쓰게 됩니다.
이는 복구 정보가 더 중요해서 그런 것이라고 이해하시면 됩니다(복구 정보가 있으면 재적용이나 되돌릴 수 있으므로).
DB가 비정상적으로 내려가면, 데이터 파일에 쓰여지지 않은 정보들이 리두로그에 기록되어 있으므로
리두로그에서 정보를 가져와 다시 적용(REDO)하는 것입니다.