제품 : ORACLE SERVER 작성날짜 : 2002-05-09 SNAPSHOT LOG의 데이타가 지워지지 않는 이유와 강제로 지우는 방법 (V7 ~ V8I) ==================================================== PURPOSE 사용하고 있는 snapshot의 refresh에는 이상이 없는데 master table의 sanpshot log가 지워지지 않고 계속 늘어만 가는 경우가 있을 수 있다. 이러한
제품 : ORACLE SERVER
작성날짜 : 2002-05-09
SNAPSHOT LOG의 데이타가 지워지지 않는 이유와 강제로 지우는 방법
(V7 ~ V8I)
====================================================
PURPOSE
사용하고 있는 snapshot의 refresh에는 이상이 없는데 master table의
sanpshot log가 지워지지 않고 계속 늘어만 가는 경우가 있을 수 있다.
이러한 경우 master site의 snapshot log가 증가하면서 space문제를
발생시킬 수도 있고, log의 내용을 refresh해가는 속도도 문제가 될 수
있으므로 여기에서는 그 원인과 조치 사항을 정리한다.
Explanation
1. snapshot log의 데이타가 지워지는 원리
snapshot log의 데이타가 지워지는 순간은 snapshot의 refresh time 때,
refresh 후, 해당 데이타에 대해서 MLOG$_<table_name>내의 SNAPTIME과
SYS.SLOG$의 해당 master table에 대한 snapshot들의 SNAPTIME을 비교해 보아
SYS.SLOG$.SNAPTIME이 MLOG$_<table_name>.SNAPTIME보다 미래이거나 같으면
그때 해당 데이타를 지우게 되는 것이다.
즉 다음 조건을 만족하는 때이다.
SYS.SLOG$.SNAPTIME >= MLOG$_<table_name>.SNAPTIME
그 이유는 snapshot log의 각 데이타는 master table에 연결된 여러 snapshot 중
첫 snapshot의 refresh시에만 refresh해당 시간이 SNAPTIME에 설정되고,
그 이후에 같은 데이타를 다른 snapshot 이 refresh해가도 값이 변경되지
않는다.
아무도 refresh하지 않은 경우는 default로 Oracle7의 경우 null이고,
Oracle8의 경우는 4000년 1월 1일로 설정된다.
SYS.SLOG$의 경우는 master table에 대해 연결된 모든 fast refresh로
refresh해가는 snapshot의 정보가 포함되어 있는데 각 snasphot이 refresh해
갈때마다 해당 snapshot에 대한 SNAPEIME이 변경된다.
그러므로 모든 snapshot이 snapshot log의 해당 레코드를 refresh해가는 경우
SYS.SLOG$의 SNAPTIME은 해당 MLOG$_<table_name>의 해당 레코드의 SNAPTIME
보다 미래이거나 같게 된다.
만약 SYS.SLOG$의 특정 snapshot의 SNAPTIME이 과거인채로 계속 refresh를
안해간다면 그래서 이 값이 snapshot log의 SNAPTIME보다 더 과거라면,
결국 해당 데이타를 refresh해가지 않은 snapshot이 존재하지 않는다는
것이므로 snapshot log의 데이타는 지워질 수 없는 것이다.
이러한 현상이 발생하는 경우는 master table에 연결되어 있는 하나의
snapshot site가 snapshot을 drop하지 않은 상태에서 장기간 데이타베이스
자체를 down시켜 둔 채 사용하지 않거나 아예 database를 remove시킨 경우이다.
그외에도 해당 master table에 snapshot을 test하다가 지우지 않고
그대로 둔 경우 등 이러한 문제는 실제 자주 발생하는 편이다.
2. snapshot log의 데이타를 강제로 지우는 방법
이렇게 사용하지 않는 snapshot으로 인해 비정상적으로 snapshot log의 크기가
커지는 경우, 가장 쉽게는 해당 snapshot을 찾아 drop해주면 문제는 바로
해결된다.
(1) snapshot 확인하는 방법
많은 경우 이러한 방치된 snapshot이 존재하는지 자체를 몰라 snapshot log가
계속 증가하게 되는데 이때는 다음과 같이 master site에서 snapshot 정보들을
확인할 수 있다.
- Oracle7의 경우:
Oracle7에서는 해당 master table에 걸려있는 모든 fast refresh의 snapshot의
정보를 확인할 수 있는 view는 SYS.SLOG$뿐이었다. 예를 들어 master table
이름이 DEPT인 경우 조회 방법은 다음과 같다.
SQL>connect sys/manager
SQL>select * from sys.slog$ where master = 'DEPT';
이 경우 snapshot을 나타내는 column은 SNAPSHOT으로 날짜로 표시된다.
이 snapshot을 실제 snapshot site에서 확인하려면 예상되는 snapshot
site에서 다음과 같이 조회하여 확인할 수 있다.
SQL>select * from sys.snap$ where master = 'DEPT';
- Oracle8의 경우
Oracle7에서는 위와 같이 snapshot의 정보를 master site에서 확인하는
것이 번거로운 문제점이 있어서 Oracle8부터는 snapshot을 나타내기 위한
snapshot id라는 개념이 추가되었고,
DBA_REGISTERED_SNAPSHOTS view가 생성되어 이 view를 통해 쉽게 snapshot를
찾는것이 가능해 졌다.
SQL>select snapid from sys.slog$ where master = 'DEPT';
SQL>select * from dba_registered_snapshots
where snapshot_id=위에서 확인한 번호;
이렇게 확인하면 해당 snapsot이 어느 site에 존재하는지에 대한 master
site의 database link이름 등도 확인 가능하다.
(2) 강제로 snapshot정보를 master site에서 제거하는 방법
위와 같이 확인하였는데도 snapshot을 snapshot site에서 직접 drop할 수
없는 환경이라면, master site에서 해당 snapshot에 대한 정보를 아예 지워
과거의 SNAPTIME을 가지는 snapshot이 SYS.SLOG$에 남지 않게 하면 된다.
SLOG$는 dictionary table이므로 바로 delete문장을 이용하여 해당 정보를
지워서는 안되며 다음과 같은 package를 이용한다.
- Orcle7의 경우:
SQL>exec DBMS_SNAPSHOT.PURGE_LOG('DEPT',2);
해당 master table에 걸려 있는 snapshot중 가장 과거의 SNAPTIME을 가지는
몇개의 snapshot정보를 지울 것인가를 지정하는 방식이다.
이 예의 경우는 DEPT table에 걸려있는 snapshot중 가장 이전에 refresh해간
두개의 snapshot의 정보를 master site의 SYS.SLOG$ 에서 제거한다.
- Oracle8의 경우:
Oracle7에서도 앞에서 설명한 DBMS_SNAPSHOT.PURGE_LOG는 여전히
사용가능하다.
그 외에 Oracle8에서 새로 추가된 snapshot id를 이용한 다음과 같은
package를 사용가능하다.
PROCEDURE PURGE_SNAPSHOT_FROM_LOG
Argument Name Type In/Out Default?
SNAPSHOT_ID BINARY_INTEGER IN
SNAPOWNER VARCHAR2 IN
SNAPNAME VARCHAR2 IN
SNAPSITE VARCHAR2 IN
예를 들어 다음과 같이 사용하면 된다.
SQL>exec DBMS_SNAPSHOT.PURGE_SNAPSHOT_FROM_LOG
(10, 'SCOTT', 'DEPT_SNAP', 'SNP8I.WORLD');
작성날짜 : 2002-05-09
SNAPSHOT LOG의 데이타가 지워지지 않는 이유와 강제로 지우는 방법
(V7 ~ V8I)
====================================================
PURPOSE
사용하고 있는 snapshot의 refresh에는 이상이 없는데 master table의
sanpshot log가 지워지지 않고 계속 늘어만 가는 경우가 있을 수 있다.
이러한 경우 master site의 snapshot log가 증가하면서 space문제를
발생시킬 수도 있고, log의 내용을 refresh해가는 속도도 문제가 될 수
있으므로 여기에서는 그 원인과 조치 사항을 정리한다.
Explanation
1. snapshot log의 데이타가 지워지는 원리
snapshot log의 데이타가 지워지는 순간은 snapshot의 refresh time 때,
refresh 후, 해당 데이타에 대해서 MLOG$_<table_name>내의 SNAPTIME과
SYS.SLOG$의 해당 master table에 대한 snapshot들의 SNAPTIME을 비교해 보아
SYS.SLOG$.SNAPTIME이 MLOG$_<table_name>.SNAPTIME보다 미래이거나 같으면
그때 해당 데이타를 지우게 되는 것이다.
즉 다음 조건을 만족하는 때이다.
SYS.SLOG$.SNAPTIME >= MLOG$_<table_name>.SNAPTIME
그 이유는 snapshot log의 각 데이타는 master table에 연결된 여러 snapshot 중
첫 snapshot의 refresh시에만 refresh해당 시간이 SNAPTIME에 설정되고,
그 이후에 같은 데이타를 다른 snapshot 이 refresh해가도 값이 변경되지
않는다.
아무도 refresh하지 않은 경우는 default로 Oracle7의 경우 null이고,
Oracle8의 경우는 4000년 1월 1일로 설정된다.
SYS.SLOG$의 경우는 master table에 대해 연결된 모든 fast refresh로
refresh해가는 snapshot의 정보가 포함되어 있는데 각 snasphot이 refresh해
갈때마다 해당 snapshot에 대한 SNAPEIME이 변경된다.
그러므로 모든 snapshot이 snapshot log의 해당 레코드를 refresh해가는 경우
SYS.SLOG$의 SNAPTIME은 해당 MLOG$_<table_name>의 해당 레코드의 SNAPTIME
보다 미래이거나 같게 된다.
만약 SYS.SLOG$의 특정 snapshot의 SNAPTIME이 과거인채로 계속 refresh를
안해간다면 그래서 이 값이 snapshot log의 SNAPTIME보다 더 과거라면,
결국 해당 데이타를 refresh해가지 않은 snapshot이 존재하지 않는다는
것이므로 snapshot log의 데이타는 지워질 수 없는 것이다.
이러한 현상이 발생하는 경우는 master table에 연결되어 있는 하나의
snapshot site가 snapshot을 drop하지 않은 상태에서 장기간 데이타베이스
자체를 down시켜 둔 채 사용하지 않거나 아예 database를 remove시킨 경우이다.
그외에도 해당 master table에 snapshot을 test하다가 지우지 않고
그대로 둔 경우 등 이러한 문제는 실제 자주 발생하는 편이다.
2. snapshot log의 데이타를 강제로 지우는 방법
이렇게 사용하지 않는 snapshot으로 인해 비정상적으로 snapshot log의 크기가
커지는 경우, 가장 쉽게는 해당 snapshot을 찾아 drop해주면 문제는 바로
해결된다.
(1) snapshot 확인하는 방법
많은 경우 이러한 방치된 snapshot이 존재하는지 자체를 몰라 snapshot log가
계속 증가하게 되는데 이때는 다음과 같이 master site에서 snapshot 정보들을
확인할 수 있다.
- Oracle7의 경우:
Oracle7에서는 해당 master table에 걸려있는 모든 fast refresh의 snapshot의
정보를 확인할 수 있는 view는 SYS.SLOG$뿐이었다. 예를 들어 master table
이름이 DEPT인 경우 조회 방법은 다음과 같다.
SQL>connect sys/manager
SQL>select * from sys.slog$ where master = 'DEPT';
이 경우 snapshot을 나타내는 column은 SNAPSHOT으로 날짜로 표시된다.
이 snapshot을 실제 snapshot site에서 확인하려면 예상되는 snapshot
site에서 다음과 같이 조회하여 확인할 수 있다.
SQL>select * from sys.snap$ where master = 'DEPT';
- Oracle8의 경우
Oracle7에서는 위와 같이 snapshot의 정보를 master site에서 확인하는
것이 번거로운 문제점이 있어서 Oracle8부터는 snapshot을 나타내기 위한
snapshot id라는 개념이 추가되었고,
DBA_REGISTERED_SNAPSHOTS view가 생성되어 이 view를 통해 쉽게 snapshot를
찾는것이 가능해 졌다.
SQL>select snapid from sys.slog$ where master = 'DEPT';
SQL>select * from dba_registered_snapshots
where snapshot_id=위에서 확인한 번호;
이렇게 확인하면 해당 snapsot이 어느 site에 존재하는지에 대한 master
site의 database link이름 등도 확인 가능하다.
(2) 강제로 snapshot정보를 master site에서 제거하는 방법
위와 같이 확인하였는데도 snapshot을 snapshot site에서 직접 drop할 수
없는 환경이라면, master site에서 해당 snapshot에 대한 정보를 아예 지워
과거의 SNAPTIME을 가지는 snapshot이 SYS.SLOG$에 남지 않게 하면 된다.
SLOG$는 dictionary table이므로 바로 delete문장을 이용하여 해당 정보를
지워서는 안되며 다음과 같은 package를 이용한다.
- Orcle7의 경우:
SQL>exec DBMS_SNAPSHOT.PURGE_LOG('DEPT',2);
해당 master table에 걸려 있는 snapshot중 가장 과거의 SNAPTIME을 가지는
몇개의 snapshot정보를 지울 것인가를 지정하는 방식이다.
이 예의 경우는 DEPT table에 걸려있는 snapshot중 가장 이전에 refresh해간
두개의 snapshot의 정보를 master site의 SYS.SLOG$ 에서 제거한다.
- Oracle8의 경우:
Oracle7에서도 앞에서 설명한 DBMS_SNAPSHOT.PURGE_LOG는 여전히
사용가능하다.
그 외에 Oracle8에서 새로 추가된 snapshot id를 이용한 다음과 같은
package를 사용가능하다.
PROCEDURE PURGE_SNAPSHOT_FROM_LOG
Argument Name Type In/Out Default?
SNAPSHOT_ID BINARY_INTEGER IN
SNAPOWNER VARCHAR2 IN
SNAPNAME VARCHAR2 IN
SNAPSITE VARCHAR2 IN
예를 들어 다음과 같이 사용하면 된다.
SQL>exec DBMS_SNAPSHOT.PURGE_SNAPSHOT_FROM_LOG
(10, 'SCOTT', 'DEPT_SNAP', 'SNP8I.WORLD');
'Oracle > admin' 카테고리의 다른 글
UTL_MAIL (0) | 2017.02.26 |
---|---|
DBMS_SMTP (0) | 2017.02.26 |
RAC 클러스터 환경을 안정화하기 위한 주요 11가지 방안 (문서 ID 1575936.1) (0) | 2016.12.13 |
Enabling and Disabling Maintenance Tasks for all Maintenance Windows (0) | 2016.11.17 |
tablespace,datafile 생성 SQL (마이그레이션시 참고용) (0) | 2016.11.14 |