파이어버드는 트랜잭션 로그를 사용하지 않기 때문에 그것 때문일 리는 없을 거구요.
말씀하신 것을 보면, 제 상황하고는 다른 것이 UPDATE입니다. 저는 순수하게 INSERT밖에 없었습니다.

아마 UPDATE를 하고 나면, 파이어버드의 특성상 이전의 레코드를 업데이트하는 것이 아니라 새로운 레코드를 만들게 될 겁니다. 버저닝(versioning)을 한다고 하죠. 내부적으로는 새로운 레코드를 인서트하고 기존 레코드를 안보이게 하는 겁니다(DELETE와는 좀 다를 듯).

그런데, 이런 버저닝 결과로 가비지가 생긴다고 해도, 그것때문에 심각하게 느려진다는 것은 좀 상식적으로 안맞는 거 같고... 인서트나 업데이트에서 단순 쿼리문이 아닌 특이한 쿼리를 쓴다든지 그렇지는 않은가요? 예를 들면.. select count(*) 이런 식으로 count를 세고 있다든지요. 파이어버드에서 레코드가 많을 때 count는 많이 느립니다.

혹은, 하드디스크의 남은 용량이 적을 경우 단편화로 인해서 디스크 액세스 타임이 떨어지고, 그 결과로 속도가 극도로 떨어질 수도 있을 겁니다. 전반적인 상황을 다 봐야 문제가 뭔지 짚을 수가 있을 거 같은데..

그럼...


바람 님이 쓰신 글 :
: 예, 말씀하신 대로 의심을 해보았으나 시스템을 리부팅하고 다시시작해도 마찬가지로 데이터 초기화시 시간이 엄청 걸립니다.
:
: 그래서 디비가 깨지거나 손상인 것 같아 점검 해 보아도 아무 이상이 없습니다.
: 그러나 백업 & 리스토어만 해주면 정상적으로 다시 살아납니다.
:
: 사이즈도 훨씬 줄어들은걸 보면 트랜잭션 로그나 그밖의 것들이 쌓이면 그렇게 되지않나 의심스럽습니다.
: 초기화 작업때를 빼놓곤 자료 삭제는 없이 100% Insert 와 UPDATE Query뿐입니다.
: (단편화가 그리 심하지 않다는 생각)
: 그런데 백업,  리스토어시 1기가 파일이 350메가가 된다는게 뭔가 미심쩍습니다.
:
: 혹시 그러한 현상에 대한 정확한 이유를 알고계시는지요.
:
: 바쁘시더라도 한번더 부탁립니다..