dbms_stats.gather_schema_stats 프로시저를 이용해서 통계 정보를 수집하는 경우 수행 시간이 너무 많이 걸린다는 불만이 종종 있다. 이런 현상은 대부분 다음과 같은 경우에 발생한다. 

- 특정 테이블들의 크기가 매우 크다.
- 일부 큰 테이블들은 Partitioning이 되어 있다. 

즉 큰 테이블들이 있고 더구나 Partitioning까지 되어 있으니(Global/Partiton Statistics모두 수집해야 하므로) 그만큼 통계 정보 수집에 시간이 걸리기 마련이다. 하지만 Oracle 10g에서는 estimate_percent 파라미터와 method_opt 파라미터의 값이 Oracle에 의해 적절하게 판단되어 통계 정보 생성 시간을 최적화한다. 그렇다면 왜 필요 이상 많은 시간이 걸리는 경우가 발생하는가? 

이것은 이 두 파라미터에 다음과 같은 결함이 있기 때문이다.

- estimate_percent 파라미터의 값이 AUTO이다. 즉, Oracle이 테이블의 크기에 따라 적절한 샘플 크기를 선택한다는 의미이다. 대부분의 경우 Oracle은 테이블의 크기에 따라 적절한 값을 찾지만, 간혹 아주 큰 테이블에 대해 100%의 값을 사용하는 경우가 있다. 
- method_opt 파라미터의 기본값이 FOR ALL COLUMNS SIZE AUTO이다. 즉 모든 컬럼에 대해 통계정보를 수집하면 히스토그램의 생성 여부는 Oracle이 판단한다. 대부분의 경우 Oracle은 적절한 히스토그램 버킷 크기를 할당하지만, 간혹 불필요하게(가령 Unique Key에 대해) 히스토그램을 생성하는 경우가 있다.

위와 같은 상황이 발생하면 예상보다 지나치게 많은 시간이 걸리게 되는 셈이다. 

이런 상황을 해소할 수 있는 방법이 있을까? 가령 다음과 같이 하면...?

dbms_stats.gather_schema_stats(estimate_percent=>10, method_opt=>'FOR ALL INDEXED COLUMNS SIZE 1');

물론 위의 방법으로 수행 시간 문제는 해결하겠지만, 좋은 방법은 될 수 없다. 만일 크기가 작은 테이블들이 있다면 샘플 크기가 작으면 왜곡된 통계 정보가 수집될 수 있다. 만일 특정 테이블에 대해서는 모든 컬럼(ALL COLUMNS)에 대해 통계 정보를 수집해야 한다면? 또는 특정 테이블의 특정 컬럼에 대해서는 히스토그램 크기를 주고 싶다면? 

그렇다고 테이블 레벨로 일일이 dbms_stats.gather_table_stats를 호출하는 것은 너무나 지겨운 일이다. 

그래서 보통 다음과 같은 트릭을 종종 사용한다.(편의상 정확한 문법은 생략)

-- 특정 테이블 통계 정보 변경을 막음
dbms_stats.lock_table_stats(user, 'TABLE1');

-- 스키마 레벨로 통계 정보 수집
dbms_stats.gather_schema_stats(user);

-- 통계 정보 활성화 후 이 테이블만 다시 통계 정보 수집
dbms_stats.unlock_table_stats(user, 'TABLE1');
dbms_stats.gather_table_stats(user,'TABLE', estimate_percent=>10, method_opt=>'FOR ALL INDEXED COLUMNS SIZE AUTO');

위와 같이 하면 Schema 레벨로 대부분의 테이블에 대해 통계 정보를 수집한 후 특정 문제가 되는 테이블에 대해서만 별도로 통계 정보를 수집할 수 있다.

지저분한 트릭같지만 매우 유용한 방법이다.

Oracle 11g에서는 "Preference"라는 새로운 개념을 통해 위와 같은 불편을 일시에 해소하고 있다. Oracle 11g에서라면 다음과 같이 훨씬 직관적이고 깔끔한 방법을 쓸 수 있다.

-- 아래와 같이 한번만 설정
dbms_stats.set_table_prefs(user,'TABLE1', 'ESTIMATE_PERCENT', '10');
dbms_stats.set_table_prefs(user,'TABLE1','METHOD_OPT', 'FOR ALL INDEXED COLUMNS SIZE AUTO');

-- Schema 레벨에서 통계 정보 수집
dbms_stats.gather_schema_stats(user);

즉, 특정 테이블별로 Preference(선호도)를 저장할 수 있어서 10g에서와 같은 부자연스러운 트릭은 불필요한 것이다. 11g에서 가장 마음에 드는 New Feature중 하나이다.

출처: http://ukja.tistory.com/86

 
크리에이티브 커먼즈 라이선스
Creative Commons License
로컬DB에서 클라이언트 DB의 데이터를 DBLINK를 통해 바로 저장할 수 있다. 


1.로컬DB에 클라이언트DB에 접속가능한 DBLINK를 만든다.

CREATE DATABASE LINK <DBLINK이름>
 CONNECT TO SYSTEM IDENTIFIED BY <비번> 
 USING '(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=<IP나 호스트명>)(PORT=<포트주소>)) (CONNECT_DATA=(SERVICE_NAME=<SID명>)))';  



2. parfile 를 생성(안해도 되지만 편의를 위해)
-- filename.par
DIRECTORY=DATA_PUMP_DIR  -- DATA_PUMP_DIR은 당연 로컬DB에 생성된 DBLINK
job_name=impdp_pre.20111001  -- 수행되는 job의 이름 제약없음 
logfile=imppd_pre.20111001.log -- 생성될 log 파일 DATA_PUMP_DIR 의 위치에 저장된다.
remap_schema=<client의 schema>:<local의 schema> -- 스키마 변경이 필요할 경우 적는다, table만 import 할때는 fromuser touser 의 역활을 한다   
tables=<client의 schema>.<테이블명>    
remap_tablespace=<client의tablespace명>:<local의대체tablespace명>,<여러개일경우반복>:<여러개일경우반복>
network_link=<DBLINK명>
table_exists_action=<해당 옵션은 따로 찾아보기>
content=<해당옵션은 따로 찾아보기>

3.impdp user/password parfile=filename.par  로 수행
 
# 참조 http://www.keiis.co.kr/study/220.DB_Oracle/M910.Object&Utility/H100.Data_Pump_0.html
# table_exists_action

SKIP - 테이블을 있는 그대로 두고 다음 객체 생성으로 이동한다. CONTENT 파라미터를 DATA_ONLY로 지정할 경우
SKIP을 지정할 수 없다.
APPEND - 소스로 부터 row를 읽어 들여 테이블에 적재 시키고, 이미 존재하는 row는 그대로 둠
TRUNCATE - 이미 존재하는 row가 있다면 삭제시킨 후 새로 데이터를 적재 시킴
REPLACE - 이미 존재하는 테이블을 드롭 시킨 후, 테이블을 새로 만들고 데이터를 적재 시킴. CONTET 파라미터를
DATA_ONLY로 지정하느 경우 이 값을 지정할 수 없다.

다음은 옵션을 지정하는데 있어 고려해야 할 사항이다 :

TRUNCATE나 REPLACE를 지정할 경우, 영향을 바는 테이블이 참조 무결성에 의해 참조 되지 않는 지 여부를 확인한다.
SKIP, APPEND 또는 TRUCATE를 지정할 경우, 이미 존재하는 테이블에 대한 인덱스나, 권한 부여, 트리거, 제약 조건이
무시된다. REPLACE를 지정할 경우, 의존 관계에 있는 객체들이 먼저 drop 된 후, 재 생성된다. 이것을
피하기 위해서는 EXCLUDE를 사용하여, 명시적으로 제외를 시키거나 임포트 하고자 하는 덤프 파일에 해당 내용이
포함 되지 않아야 한다.
APPEND나 TRUNCATE를 사용할 경우에는,다른 모든 작업에 앞서 덤프 파일의 내용이 이미 존재하는 테이블에 들어갈 수
있는 형태의 데이터인지를 먼저 확인한다.

이미 존재하는 테이블에 대해서는 external 테이블을 사용하여 load 작업이 수행되는데 이것은, external table 이
constraint나 trigger가 제 기능을 하도록 하기 때문이다. 하지만, active constraint를 위반하는 row 가
하나라도 존재하면,load 작업은 취소되어 아무런 데이터도 load 되지 않는다는 점을 기억해 둘 필요가 있다.

만약 데이터를 반드시 load 시켜야 하는데, constraint voilation을 유발시킬 만한 내용이 있다면
constraint를 먼저 disable 시키고, 데이터를 적재 시킨 후, 문제가 되는 row를 삭제 하고 constraint를
다시 enable 시키는 방법을 사용해야 한다.

APPEND를 사용할 때는, 데이터가 언제나 새로운 공간에 load 된다. 기존에 사용중인 공간에 여유 공간이 있더라도
재 사용되지 않는다. 이와 같은 이유 때문에 데이터에 대한 compress를 별도로 수행할 필요가 있을 수도 있다.
 

# CONTENT 파라미터:

CONTENT 파라미터는 Export 또는 Import 세션에서 사용할 수 있다. 명백하게, export 값이 DATA_ONLY나
METADATA_ONLY였다면, 지정된 데이터만 덤프파일에 존재하여 import 시 사용할 수 있다.

기본값 : ALL

import 될 수 있는 내용을 제한하기 위해서는 다음과 같은 옵션을 사용할 수 있다 :

DATA_ONLY - 이미 존재하는 테이블에 대해서만 데이터를 load 시킨다. 없던 객체를 생성 시키지 않는다.
METADATA_ONLY - 데이터베이스 객체에 대한 정의만 load 시킨다. 테이블의 row 데이터를 load 시키지 않는다.
ALL - 소스의 데이터 및 메타데이터를 load 시킨다. 기본 값.
 


크리에이티브 커먼즈 라이선스
Creative Commons License