전체 DB 폴더 사이즈 체크 하면 350MB 정도 밖에 안되는 데이타를 갖고 있는 DB 입니다.
기존에 DB에 문제가 생기면 UNLOAD 했다가 다시 CREATE DB 해서 LOAD 하면 잘 돌아갔었는데,
LOAD 하고 나서 각 테이블들을 삭제 쿼리를 날리는데 삭제가 도무지 끝이 안나서
DB 를 종료 했다가 다시 시작 하고 (이것도 잘 안됨)
다시 CREATE DB 해서 LOAD 한 후 최적화 (모든테이블) 해보니 잘 되서
검사를 해봤는데 마찬가지로 영 끝날 기미가 없습니다.
어디를 체크해 봐야 할까요????
CREATE DB -> LOAD -> DATABASE START -> CM CONNECT -> DELETE from table QUERY 실행
시간이 오래 걸려서 어떻게 멈추게 할지 고민하다가 AUTO COMMIT ON 되어 있는 BUTTON을 클릭 해보고 도무지 어떻게 멈추게 할지 몰라서 TRAY ICON에 DB STOP
다시 START 하는데 START가 잘 안됨.
PC 재부팅
다시 CUBRID STOP -> DATABASE 삭제 -> CREATE DB -> LOAD -> DATABASE START -> CM CONNECT -> 최적화 > 검사
도무지 끝나지 않아서 작업 관리자 프로세스 보니 cub_server.exe 가 두개가 실행중이어서 하나를 죽인 후 한 30분 정도 지나서 검사가
종료 됨. 오류 메세지 표시 없음
오류 로그 열어 보니깐 오류코드 -4, Has been interrupted 잔뜩 있음.
암튼 검사 끝나서 이제 정상인가 하고
Delete from table 쿼리 하나 날렸는데 흠...15분 째 실행중이네요..데이타 량도 그리 많지 않은 데;;
일단 이거 쿼리 멈추게 할려면 어떻게 해야 하나요? auto commit on 되어 있는 상태 입니다.
그냥 쭉 기달렸더니 끝이 났습니다.
실행 결과에 " 1번째 질의 197023 데이터가 삭제되었습니다.[1,510.766 초] " 이렇게 표시가 됐는데
저거 25분 정도 나온걸로 계산되네요.
이정도면 정상적인 작동의 범주에 속하는건지...문제가 있어서 더 늦게 나온건지 알수 있을까요?
정상적으로 보이지 않지만... 모든 상황이 다를 수 있으니...
truncate table을 이용하는 것이 좋았을 걸 그랬습니다. ^^
delete를 수행한 테이블에 있는 index 정보에 따라 delete가 느려질 수 있습니다. 특히, key의 중복도가 높은 non-unique index가 있으면 delete 성능에 많은 영향을 줍니다.
예를 들어, index (grade) 가 있고, delete * from tab where grade = 'M' 질의가 10만 건을 삭제한다고 하면, 삭제하려는 key의 중복도가 10만이나 되기 때문에 성능이 꽤 느려질 겁니다.
삭제 쿼리라 함은 데이터 삭제이신지요? 만약 데이터 삭제라면 다른 트랜잭션에서 lock 잡고 있지는 않았는지 확인이 필요합니다.
또한 DB의 연산 작업 중 강제 종료는 DB가 복구작업을 하게 되는 원인이 되며 지속적인 강제 종료는 복구 시간의 지연을 가져옵니다.
우선 삭제 작업을 어디(CM또는 콘솔)에서 진행하셨는지와 어떠한 순서대로 진행하셨는지 확인을 부탁드리며, 만약 CM(또는 쿼리 브라우져)에서 작업을 하셨다면 auto commit off상태인지도 확인 하시기 바랍니다.