cubrid checkdb -r 명령을 통해 db를 체크하고 있습니다.
db의 데이터는 2400만개 이구요..
지금 20시간째 진행중인데..
원래 이렇게 시간이 오래 걸리는 것인가요?..
라이브 된 서비스에서 19시간 이상씩 시간이 걸린다는 것은..
서비스를 하지 말라는 것과 같은 것인데..
큐브리드의 경우..
select 문을 제외한 모든 쿼리와 기능들의 처리 속도 문제가 심각한 것 같습니다..
100만개 데이터에 대한 간단한 쿼리문 하나도 처리 시간이 6시간 이상씩 걸리면..
DB를 어떻게 가공해서 서비스를 할 수 있나요..
마이그레이션만 하면 다른 것은 성능상 문제가 없다고 생각했었는데..
일주일째 답을 못 구하고 있습니다..
큐브리드의 적정 데이터 수는 얼마나 되는 것인지 궁금합니다..
그리고 한 가지 건의를 드리자면,
모든 쿼리에 대해서 처리 예상 시간과 처리 진행상황에 대해 확인이 가능했으면 좋겠습니다.
예를들면 load 시에 -v 옵션 같은 것들이 기본 옵션이면 좋겠네요..
무한정 기다리는 것이 너무 지칩니다..
# cubrid checkdb -r 은 21시간째에서 종료했습니다..
db를 언로드하여 다시 로드시키는 중입니다.
적정 데이터 건수는 응용 성격, row 사이즈 등 다양한 조건에 따라 달라 지므로 답변 드리기는 어렵습니다.
일단 질문하신 100만건에서의 질의 수행이 6시간 걸렸다는 것은 뭔가 비정상적인 것 같습니다.(질의 가 잘못되었거나, DB가 손상되었거나 등)
unload/load를 통한 재구성 작업 중이시라고 하니 재구성 완료후 결과를 보는 것이 좋을 것 같습니다.
checkdb의 경우 인덱스 손상 등의 확인 및 복구에 사용되는 유틸로 각 인덱스와 관련된 데이터 유효성을 체크하기 위해 데이터 스캔작업이 이루어지므로 건수에 따라, 손상 여부에 따라 많은 시간이 걸리기도 합니다.
위에 질문하신 경우는 아마 인덱스 손상 정도가 checkdb의 정상 수행이 힘든 상태의 손상으로 보여집니다.
아래 질문에도 답변을 드렸는데 손상된 인덱스가 어떤 것인지 확인이 가능하다면 인덱스을 삭제하고 재생성하는 방법으로 복구해보시는 것이 좋을 것 같은데, 진행 중이라는 unload/load를 수행하는 것도 한 방법입니다.