반응형
테이블 안의 데이터를 삭제 하는 방법으로는 SQL의 DELETE 문을 들 수 있다.
일반적으로 모든 사람들이 이 SQL을 이용하여 테이블 내의 일부 데이터를 삭제할 것이다.
그러나 지금의 테이블은 그 사이즈가 점점 커지고 있는 상황이며, 이로 인하여 테이블 내의 데이터가 대량으로 들어가 있어서 이를 삭제시 문제가 발생할 수 있다.
문제라 한다면 대량의 데이터를 삭제 할때 , 중간중간 Commit문을 넣어 주지 않게 된다면 트랜잭션 로그의 양이 증가 하게 되어 데이터 베이스 로그가 Full 나는 상황이 발생 할 수도 있다.
(테이블 파티션을 잘 지정해서 운영 중이였다면 , 파티션 별로 Detach 명령어를 이용하여 해당 파티션만 날려 주면 되지만 )
그래서 이때 테이블의 데이터 변화에 대해서 그 쌓이는 로그의 양을 최소화 시키기 위하여 UOW 단위에서 로그의 사용 발생량을 최소화 하기 위하여 사용할 수 있는 명령이 있다.
ALTER TABLE ..... ACTIVATE NOT LOGGED INITIALLY 명령문을 수행하면 된다.
이 명령을 수행하게 되면 명령을 수행한 Application의 UOW 안에서 이루어 지는 해당 테이블에 대한 변경에 대해서 로그의 발생량이 최소화 된다.
위의 명령은 UOW 내에서만 유효하다. 만약에 CLP에서 테스트를 하고자 한다면 db2 +c 옵션을 이용하여 자동으로 Commit이 수행되지 않도록 해야 한다.
우선 일반적인 테이블에 대한 DML 상황과 ACTIVATE NOT LOGGED INITIALLY 옵션을 준 후의 로그 사용량에 대해서 확인해 보자
테스트를 위해서 LOGGED_TABLE / N_LOGGED_TABLE 이라는 두개의 테이블을 만들었으며 동일 데이터를 넣어 놓았다.
테스트를 시작하기 전에 트랜잭션 로그의 사용량을 보기 위하여 다음 명령을 이용하여 지금 현재 트랜잭션당 사용하고 있는 로그가 있는지 체크해 보자
사용명령어는 간단하게 db2pd의 Agent , Transaction 옵션을 이용하였다.
데이터 베이스 Connection을 맺고 있으며 , db2clp를 이용하여 테스트를 진행 할 것이기 때문에 Client Name은 db2bp로 나온다.
위의 값을 보면 LogSpace 사용량이 하나도 없음을 확인 할 수 있다.
그럼 이제 logged_table의 데이터를 모두 삭제 후 로그 사용량을 확인해 보자
logged_table의 데이터를 모두 삭제 하는데 로그를 697,634 Byte 사용하였다.
그럼 이번에는 n_logged_table에 대하여 ACTIVATE NOT LOGGED INITIALLY 옵션을 지정한 후에 똑같이 전체 데이터를 삭제해 보자.
옵션을 주고 삭제시는 로그 사용량이 168byte 정도 밖에 되질 않았다. 로그사용량이 확연하게 줄어드는것을 확인 할 수 있다.
테이블에 대하여 ACTIVATE NOT LOGGED INITIALLY 옵션을 주었다가 Rollback을 수행하게 되면 해당 테이블에 대하여 접근이 불가능 하게 되는경우도 존재를 한다. (SQL1477N 또는 SQL1476N)
ACTIVATE NOT LOGGED INITIALLY 옵션자체가 생긴 이유를 생각해 보면 , 마이그레이션을 하거나 , 테스트 서버를 구성 후 테스트 데이터를 옮겨와서 테스트를 하고자 할때 DBA 가 로그를 관리해줘야 하는 불편함을 줄이기 위해서 나온 옵션인 것이다.
즉, Temporary성 데이터들에 대하여 불필요하게 로그를 남기지 않고, 작업을 빠르게 진행하고자 하는 목적으로 태어났기 때문에 위와 같은 문제(SQL1477N 또는 SQL1476N)를 내포하고 있는것 같다.
또 한가지 테이블에 대하여 ACTIVATE NOT LOGGED INITIALLY 옵션을 수행하게 되면, 해당 UOW가 종료 되기 전까지 SYSIBM.SYSTABLES 카탈로그 테이블에 대하여 TABLE LOCK(IS) , ROW LOCK(NS) 락을 획득하며 , INTERNALP_LOCK, INTERNALC_LOCK 두 종류의 Internal Lock을 획득한다.
INTERNALP_LOCK 는 Package Cache에 잡는 Lock 이며 , INTERNALC_LOCK 은 Catalog Cache에 잡는 Lock이다.
이로 인하여 테이블에 ACTIVATE NOT LOGGED INITIALLY 옵션을 준 이후에 해당 UOW가 종료 되기 전까지는 해당 테이블에 대한 다른 Application의 접근이 제한된다.(SELECT , DML)
첨부파일 -->
첨부 파일은 logged_table에 대하여 ACTIVATE NOT LOGGED INITIALLY 옵션을 주어 놓고서(Appl Handle 19) , 다른 유저를 데이터베이스에 하나 접속 시킨 후 logged_table에 대하여 SELECT문을 수행하게 하였다(Appl Handle 65).
단순히 테이블에 대한 대량의 데이터를 삭제 하기 위하여 운영중인테이블에 ACTIVATE NOT LOGGED INITIALLY 옵션을 줄 경우, 해당 테이블에 대한 작업이 종료될 때 까지 다른 Application에서 접근이 되지 않을 수 있으므로 매우 주의 하여야 한다.
일반적으로 모든 사람들이 이 SQL을 이용하여 테이블 내의 일부 데이터를 삭제할 것이다.
그러나 지금의 테이블은 그 사이즈가 점점 커지고 있는 상황이며, 이로 인하여 테이블 내의 데이터가 대량으로 들어가 있어서 이를 삭제시 문제가 발생할 수 있다.
문제라 한다면 대량의 데이터를 삭제 할때 , 중간중간 Commit문을 넣어 주지 않게 된다면 트랜잭션 로그의 양이 증가 하게 되어 데이터 베이스 로그가 Full 나는 상황이 발생 할 수도 있다.
(테이블 파티션을 잘 지정해서 운영 중이였다면 , 파티션 별로 Detach 명령어를 이용하여 해당 파티션만 날려 주면 되지만 )
그래서 이때 테이블의 데이터 변화에 대해서 그 쌓이는 로그의 양을 최소화 시키기 위하여 UOW 단위에서 로그의 사용 발생량을 최소화 하기 위하여 사용할 수 있는 명령이 있다.
ALTER TABLE ..... ACTIVATE NOT LOGGED INITIALLY 명령문을 수행하면 된다.
이 명령을 수행하게 되면 명령을 수행한 Application의 UOW 안에서 이루어 지는 해당 테이블에 대한 변경에 대해서 로그의 발생량이 최소화 된다.
위의 명령은 UOW 내에서만 유효하다. 만약에 CLP에서 테스트를 하고자 한다면 db2 +c 옵션을 이용하여 자동으로 Commit이 수행되지 않도록 해야 한다.
우선 일반적인 테이블에 대한 DML 상황과 ACTIVATE NOT LOGGED INITIALLY 옵션을 준 후의 로그 사용량에 대해서 확인해 보자
테스트를 위해서 LOGGED_TABLE / N_LOGGED_TABLE 이라는 두개의 테이블을 만들었으며 동일 데이터를 넣어 놓았다.
테스트를 시작하기 전에 트랜잭션 로그의 사용량을 보기 위하여 다음 명령을 이용하여 지금 현재 트랜잭션당 사용하고 있는 로그가 있는지 체크해 보자
사용명령어는 간단하게 db2pd의 Agent , Transaction 옵션을 이용하였다.
데이터 베이스 Connection을 맺고 있으며 , db2clp를 이용하여 테스트를 진행 할 것이기 때문에 Client Name은 db2bp로 나온다.
위의 값을 보면 LogSpace 사용량이 하나도 없음을 확인 할 수 있다.
그럼 이제 logged_table의 데이터를 모두 삭제 후 로그 사용량을 확인해 보자
logged_table의 데이터를 모두 삭제 하는데 로그를 697,634 Byte 사용하였다.
그럼 이번에는 n_logged_table에 대하여 ACTIVATE NOT LOGGED INITIALLY 옵션을 지정한 후에 똑같이 전체 데이터를 삭제해 보자.
옵션을 주고 삭제시는 로그 사용량이 168byte 정도 밖에 되질 않았다. 로그사용량이 확연하게 줄어드는것을 확인 할 수 있다.
테이블에 대하여 ACTIVATE NOT LOGGED INITIALLY 옵션을 주었다가 Rollback을 수행하게 되면 해당 테이블에 대하여 접근이 불가능 하게 되는경우도 존재를 한다. (SQL1477N 또는 SQL1476N)
ACTIVATE NOT LOGGED INITIALLY 옵션자체가 생긴 이유를 생각해 보면 , 마이그레이션을 하거나 , 테스트 서버를 구성 후 테스트 데이터를 옮겨와서 테스트를 하고자 할때 DBA 가 로그를 관리해줘야 하는 불편함을 줄이기 위해서 나온 옵션인 것이다.
즉, Temporary성 데이터들에 대하여 불필요하게 로그를 남기지 않고, 작업을 빠르게 진행하고자 하는 목적으로 태어났기 때문에 위와 같은 문제(SQL1477N 또는 SQL1476N)를 내포하고 있는것 같다.
또 한가지 테이블에 대하여 ACTIVATE NOT LOGGED INITIALLY 옵션을 수행하게 되면, 해당 UOW가 종료 되기 전까지 SYSIBM.SYSTABLES 카탈로그 테이블에 대하여 TABLE LOCK(IS) , ROW LOCK(NS) 락을 획득하며 , INTERNALP_LOCK, INTERNALC_LOCK 두 종류의 Internal Lock을 획득한다.
INTERNALP_LOCK 는 Package Cache에 잡는 Lock 이며 , INTERNALC_LOCK 은 Catalog Cache에 잡는 Lock이다.
이로 인하여 테이블에 ACTIVATE NOT LOGGED INITIALLY 옵션을 준 이후에 해당 UOW가 종료 되기 전까지는 해당 테이블에 대한 다른 Application의 접근이 제한된다.(SELECT , DML)
첨부파일 -->
notloggedinitially.out첨부 파일은 logged_table에 대하여 ACTIVATE NOT LOGGED INITIALLY 옵션을 주어 놓고서(Appl Handle 19) , 다른 유저를 데이터베이스에 하나 접속 시킨 후 logged_table에 대하여 SELECT문을 수행하게 하였다(Appl Handle 65).
단순히 테이블에 대한 대량의 데이터를 삭제 하기 위하여 운영중인테이블에 ACTIVATE NOT LOGGED INITIALLY 옵션을 줄 경우, 해당 테이블에 대한 작업이 종료될 때 까지 다른 Application에서 접근이 되지 않을 수 있으므로 매우 주의 하여야 한다.
반응형