OfficeTutor 365

지금으로부터 약 2년 전의 일입니다. 어떤 분이 액세스 데이터베이스를 두 대의 컴퓨터에서 공유하여 사용하고 있는데 언젠가부터 액세스가 자꾸 죽는다고 하여 좀 살펴봐 달라는 요청이 들어왔습니다. 그래서 제가 살펴 보니, 정말로 이유 없이 데이터베이스가 자꾸 죽는 것이었습니다. 두 대의 컴퓨터 사이의 네트워크 연결, 액세스 설치의 이상유무 등을 모두 체크해 보았지만 별다른 문제는 찾아볼 수 없었지요.

그러던 중 데이터베이스 파일을 조사하다가 우연히 그 크기가 대략 500메가 정도 되는 것을 발견할 수 있었습니다. 500메가라는 용량은 그 분이 사용하는 데이터 규모를 훨씬 초과하는 것이었기에 테이블을 일일이 열어서 데이터를 살펴보았습니다. 테이블에 들어 있는 데이터는 얼핏 보아도 3메가도 되지 않는 용량이었습니다. 그래서 저는 ‘데이터베이스 압축 및 복구’를 실행하였고, 데이터베이스 파일 용량은 채 1메가도 되지 않은 용량으로 줄어들었습니다. 물론 이유 없이 자꾸 죽는 이유도 해결 되었습니다.

이 사례에서는 ‘데이터베이스를 압축하지 않으면 이유 없이 데이터베이스가 죽는다’ 라는 다소 우스꽝스런 결론을 내릴 수도 있겠습니다. 왜 이러한 현상이 발생할까요? 그 이유는 오늘 데일리 팁 마지막 부분에 설명드리도록 하겠습니다.

이전 데일리 팁에 ‘데이터베이스 압축하기’라는 제목으로 데이터베이스 압축하는 방법에 대한 것이 자세히 실렸습니다. 그런데 데이터베이스 압축은 왜 하는 것일까요? 우리가 일반적으로 사용하는 오피스 파일의 경우 압축할 필요가 전혀 없습니다. 하지만 데이터베이스 파일은 왜 압축을 해 주어야 하는 것일까요?
 
오늘은 데이터베이스 압축 및 복구를 왜 수행해야 하는지, 그리고 언제 수행해야 하는지 알아보도록 하겠습니다.

액세스를 사용해 보신 분들이라면 데이터베이스 공유 시 속도 저하 현상, 일련번호 생성시 빈 번호 할당 불가능 등의 상식적으로 이해되지 않는 문제점이 있었을 것입니다. 이러한 것은 모두 액세스 데이터베이스 파일이 ‘여러 사람이 동시에 읽고 쓸 수 있도록 만들어져 있기’ 때문에 발생하는 문제들입니다. 이 중 데이터베이스 압축 및 복구도 ‘여러 사람이 동시에 읽고 쓸 수 있도록’ 하기 위해 액세스가 취한 몇 가지 방법들 중 하나입니다.

우리가 일반적인 워드 파일을 편집한다고 가정해 보겠습니다. 다음의 그림에서 네모 칸은 파일의 크기를 의미합니다.

일반적인 문서 파일의 경우 우리가 파일을 편집하면 그만큼 파일의 크기가 늘어나거나 줄어 듭니다. 따라서 일반적인 문서파일은 항상 최소한의 공간만을 보유하게 되겠지요? 그 말은 일반적인 문서 파일의 경우 파일을 저장할 때 항상 파일의 처음부터 끝까지 ‘다시’ 디스크에 기록한다는 의미를 가지고 있습니다. 물론 여러 알고리즘을 통해 무조건 다 저장하지는 않겠지만 기본적인 동작방식은 파일을 통째로 기록하는 것입니다.

반면, 데이터베이스 파일도 이와 같이 동작한다면 어떻게 될까요? 10명의 사용자가 사용하는 데이터베이스의 경우, 파일에 저장해야 할 경우가 아주 많아집니다. 그 때마다 파일을 처음부터 끝까지 디스크에 기록해야 한다면 어떻게 될까요? 데이터베이스의 성능이 많이 저하될 것은 불 보듯 뻔한 일 일겁니다. 그래서 데이터베이스 파일의 경우 다음과 같이 동작하게 되어 있습니다.

데이터베이스 파일은 동시에 여러 사람이 읽고 쓸 수 있어야 하기 때문에 기록할 때는 필요한 부분만 저장하게 됩니다. 따라서 항상 파일의 맨 뒷부분에 데이터를 추가하게 되지요. 그리고 데이터를 삭제하였을 경우에는 실제 파일의 내용을 삭제하는 것이 아니라 해당 부분에 ‘삭제’라는 표시만 해 놓습니다. 따라서 데이터베이스에서는 파일을 처음부터 끝까지 다시 쓰는 것이 아니라 새로 추가된 부분만을 기록하게 됩니다. 그렇기 때문에 여러 사람이 동시에 데이터베이스 파일에 접근하더라도 성능에 문제가 없는 것이지요. 다음을 기억해 두세요.

‘데이터베이스 파일은 사용하면 사용할 수록 커지기만 한다!’ 

그래서 데이터베이스를 많이 사용하다 보면 데이터베이스 파일 중간 중간에 ‘삭제’된 공간이 많이 남아 있게 됩니다. 이처럼 ‘삭제’된 공간이 많이 남아 있게 되면 아무래도 데이터 검색 속도가 많이 느려지겠지요? 다음 그림을 살펴보기 바랍니다.

위의 그림은 사용 중이던 데이터베이스 파일입니다. 그리고 밑의 그림은 데이터베이스 압축을 하고 난 후의 그림입니다. 군데 군데 ‘삭제’ 공간이 많이 있던 데이터베이스 파일을 최적화하여 꼭 필요한 공간으로 만들어 놓았지요? 이렇게 데이터베이스를 압축하게 되면 데이터 검색 속도도 빨라지고, 전체적인 데이터베이스 성능이 향샹되게 됩니다. 

앞서 말한 사례의 경우 정확히 왜 데이터베이스가 죽는지 지금 명확히 밝힐 수는 없지만, 한 가지는 분명합니다. 데이터베이스 파일 내부에 ‘삭제’된 공간이 너무 많아져서(500메가에서 1메가로 축소되었었지요?) 데이터 검색하는 시간이 너무 길어진 것이 아닌가 하고 생각됩니다. 데이터 검색하는 시간이 너무 길어져서 사용자 입장에서는 데이터베이스가 죽은 것처럼 보인 것이 아닌가 하는 생각이 드네요. 그 밖에 다른 많은 이유가 있겠지만 말이죠. 

지금까지 데이터베이스 압축 및 복구를 해야 하는 이유에 대해서 알아보았습니다. 그렇다면 데이터베이스 압축 및 복구를 언제 해야 할까요? 매일 해야 하는지, 일주일에 한 번 정도 하면 되는지, 일년에 한 번 하면 되는지..
데이터베이스 압축 및 복구 주기는 데이터베이스에 데이터가 쌓이고 삭제되는 정도를 고려해서 수행해야 합니다. 그래서 데이터베이스 압축 및 복구 주기를 정확히 말씀드릴 수는 없습니다. 보통 액세스의 경우 개인용 혹은 소규모 워크그룹용으로 사용하기 때문에 1개월 정도마다 한 번씩만 압축 및 복구 작업을 수행해 주어도 큰 문제는 없을 것입니다. 하지만 데이터 추가 및 삭제가 매우 빈번하다면 그보다는 자주 해 주어야 할 것입니다. 데이터베이스를 사용하다가 데이터베이스가 갑자기 느려지거나 이상 증세를 보이면 제일 먼저 수행해야 할것이 바로 ‘데이터베이스 압축 및 복구’ 라는 것을 머릿속에 담아두면 큰 문제는 없을 듯 합니다. 

참고적으로, 데이터베이스 압축 및 복구의 경우 데이터베이스 파일을 새로 처음부터 끝까지 다시 디스크에 기록하는 것이기 때문에 압축 및 복구 시점에 다른 사용자가 데이터베이스에 접속해 있으면 정상적으로 수행되지 않습니다.