오랜만에 볼포에 글을 쓰네요

firebird의 경우 멀티코어에서 문제가 있다는 이야기가 예전부터 있었습니다.  버젼2에서도 아직 해결되지 않은 것으로 아는데 확인해 보시기를 바랍니다.


바람 님이 쓰신 글 :
: 항상 성실한 답변 주셔서 너무너무 감사합니다.
:
: 먼저 알려주신 점검사항 중 디스크 용량이나 시스템 사양은 문제가 없습니다.
: 시스템 사양은
:    - CPU       : 제온 쿼드코어 2.0 GHz (64bit)
:    - Memory : 2 GByte
:    - OS         : 윈도 2003 서버(32 bit)
:    - HDD       : 500기가
:    - Firebird  : Version 2.1 - SuperServer(32bit)  입니다.
: 디비가 있는 디스크용량은 500기가중 200 기가를 파티션해서 쓰고 1.1기가 사용중입니다.(DB가 1기가일때)
:
: 그리고 복잡한 쿼리는 쓰지않습니다.
: 단순한 쿼리에 수집된 데이터값의 임계치를 설정해두고 그 로그기록과 분단위, 시단위, 일일단위의
: 누적값 기록을 위해 트리거를 쓰고 있습니다.  
:
:  그리고 어플 시작시 초기화 쿼리도 WHERE 조건도없는 단순한
: DELETE FROM TBL_AAAA      // Record 수 : 대략 10~100 여개내외
: DELETE FROM TBL_BBBB     // Record 수 : 대략 100~1000 여개 내외
: 딱 두 라인 입니다.
:
: 트랜잭션 페어에대해선 수십번 점검하였고 예전에 그렇게 문제가생겨 Excepption로그를 남겨 확인 해보니
: 명확히 Deadlock 관계라고 오류를 밷어내더군요.
:
: 다들 의아하게 생각하는 부분은 백업 & 리스토어시 1기가가 350메가로 줄어들수 있는지입니다 .
: (저 말고 다른 분들도 백업 & 리스토어를 했을때  줄어드는 정도의 차이는 있지만 분명 의아하게 생각하는 부부입니다)
: 이부분에 대한 참고가 될만한 자료가 있는지요.
:
: 참으로 내공이 부족한 제탓을 하고 있자니 답답 할 따름입니다.
:
: 다시한번 항상 성실한 답변 주셔서 너무 감사합니다.
: 그럼......
:
:
: ==================================================================================================
: 박지훈.임프 님이 쓰신 글 :
: : 파이어버드는 트랜잭션 로그를 사용하지 않기 때문에 그것 때문일 리는 없을 거구요.
: : 말씀하신 것을 보면, 제 상황하고는 다른 것이 UPDATE입니다. 저는 순수하게 INSERT밖에 없었습니다.
: :
: : 아마 UPDATE를 하고 나면, 파이어버드의 특성상 이전의 레코드를 업데이트하는 것이 아니라 새로운 레코드를 만들게 될 겁니다. 버저닝(versioning)을 한다고 하죠. 내부적으로는 새로운 레코드를 인서트하고 기존 레코드를 안보이게 하는 겁니다(DELETE와는 좀 다를 듯).
: :
: : 그런데, 이런 버저닝 결과로 가비지가 생긴다고 해도, 그것때문에 심각하게 느려진다는 것은 좀 상식적으로 안맞는 거 같고... 인서트나 업데이트에서 단순 쿼리문이 아닌 특이한 쿼리를 쓴다든지 그렇지는 않은가요? 예를 들면.. select count(*) 이런 식으로 count를 세고 있다든지요. 파이어버드에서 레코드가 많을 때 count는 많이 느립니다.
: :
: : 혹은, 하드디스크의 남은 용량이 적을 경우 단편화로 인해서 디스크 액세스 타임이 떨어지고, 그 결과로 속도가 극도로 떨어질 수도 있을 겁니다. 전반적인 상황을 다 봐야 문제가 뭔지 짚을 수가 있을 거 같은데..
: :
: : 그럼...