FirebirdSQL 쿼리가 12:00에 중단되었습니다.

Question

Windows에서 Firebird 2.5를 실행 중이고 이전 버전을 사용해 왔습니다. 매일 12:00 PM 이후에 하나의 특정 테이블에서 삽입/업데이트 쿼리를 실행하면 중단되지만 시작된 시점과 상관없이 12:35 정도까지 성공적으로 완료됩니다. 파이어 버드가 테이블에서 어떤 종류의 유지 보수를하고있는 것으로 보이며, 완료하는 데 30 분이 걸리는 것 같습니다. 그 시간 동안 테이블에 쓸 수 없습니다 (그러나 읽기는 빠릅니다). 테이블 자체는 실제로 작고, 약 10000 개의 행을 가지고 있습니다. 다른 테이블에있는 수백만 개의 행과 비교하면, 다른 테이블은 붙어 있지 않습니다.

이유 또는 해결 방법을 찾을 수 없었습니다. 나는 테이블을 덤핑하고 복원하는 데 도움을주지 못했다. 나는 슈퍼 서버와 클래식 서버 사이를 전환하려고 시도했지만 성공하지 못했다.

누구나 이와 같은 문제가 발생 했습니까?

Answer 1

아니오. Firebird에는 내부 유지 관리 절차가 특정 시간대에 바인딩되어 있지 않습니다. 서버에 12:00 PM에 실행되도록 예약 된 작업이 있습니다. 또는 오후 12시에 무거운 액세스를 시작하는 서버의 네트워크 사용자가 있습니다.

Answer 2

유지 보수 FB는 "가비지 수집"(이전 레코드 버전 제거)이며 "필요할 때"기준으로 수행됩니다 (일반적으로 레코드를 선택하면 firebird.conf의 GCPolicy 참조). 미리 정의 된 시간.

이러한 특정 시간에만이 중단이 발생합니까 아니면 항상 해당 테이블에 삽입하는 속도가 느립니까? 느려지는 동안 서버로드를 확인 했습니까 (예 : 작업 관리자에서 CPU가 초과되었습니다)? 어쨌든 다음과 같은 몇 가지 아이디어를 확인하십시오.

• 테이블에 어떤 제약 조건/트리거가 있습니까? 수백만 개의 행을 포함하는 다른 테이블과 같은 광범위한 검사를 수행하는 경우 삽입이 오래 걸리는 이유가 될 수 있습니다.

• 아마도 그 당시에 실행 된 다른 서비스가 있습니까? 즉 그 당시 DB를 백업하는 cron 작업이 있습니까? 아니면 우선 순위가 더 높은 다른 시스템 서비스가 서버 속도를 늦 춥니 다.

• 테이블에 대해 추적 서비스가 활성화되어 있습니까? Firebird 루트 디렉토리의 fbtrace.conf를 참조하십시오. 활성 상태 인 경우 광범위한 로깅이 속도 저하의 원인 일 수 있으며, 활성 상태가 아니면 원인을 찾을 수 있습니다.

• ForcedWrites/UnflushedWrites (firebird.conf 참조)에 대한 설정은 무엇입니까? 그것들을 바꾸는 것이 달라 지나요?

• firebird.log에서 문제가되는 시간대에 기록 된 것이 있습니까? 12:00에서 시작하여 전체 테이블을 잠그는 일을 수행하는 과정을 가지고있는 것처럼 나에게

Answer 3

것 같습니다. 모니터링 테이블 또는 추적 관리자를 사용하여 의심스러운 연결 또는 활성 트랜잭션이 있는지 확인하십시오.
또한 자신의 트랜잭션이 LOCK TIMEOUT없이 WAIT 절로 시작되었다고 생각하면 LOCK TIMEOUT으로 NO WAIT 또는 WAIT로 변경하여 트랜잭션이 즉시 실패하거나 시간 초과 후에 실패 할 수 있습니다.

Answer 4

내 제안은 2.5에서 TRACE API를 사용하여 그 시간의 주변이나 주변에서 일어나는 일을 추적하는 것입니다. 그게 무슨 일이 일어나고 있는지 더 많은 정보를 얻는 데 도움이 될 것입니다. 디버깅을 위해 http://upscene.com/products.misc.fbtm.php 버그 버젼을 사용하지만, 작동 중일 때는 신이 전송됩니다.

Answer 5

일부 클라이언트 연결은 오후 12시에 종료됩니까? 나는 70.000 레코드 크기의 테이블에서 비슷한 문제를 겪었다 :

클라이언트 "A"는 "select * from TABLE"과 같이 영구적으로 열린 DB 연결을 가지고있다. 이것은 "읽기 전용 트랜잭션"이지만 서버가 레코드 버전을 생성하기에 충분한 이유입니다. 왜? 클라이언트 "B"가이 테이블을 대대적으로 업데이트 한 경우 서버는 "A"가 "선택"을 시작한 것처럼 전세계를 보존하려고 시도합니다. 이는 트랜잭션 가능한 DB 서버에 대해서는 정상이며 갱신되기 전에 레코드 데이터의 레코드 사본을 작성하여 구현됩니다. 필자의 경우이 테이블 170.000 레코드 버전이 존재했습니다. 이것을 측정 할 수 있습니다.

gstat -r -t TABLE db.fdb | grep versions

클라이언트 "B"가 다운되면 더 이상 레코드 버전 수가 증가하지 않습니다. 클라이언트 "A"는이 모든 버전을 동결시키는 유죄이며, 서버에 강제로 보관합니다. 마지막으로 클라이언트 "A"가 다운되면 (예를 들어, 방화벽 규칙이 보류중인 모든 연결을 끊는 경우) Firebird는 이제 쓸모없는 레코드 버전을 제거하는 프로세스를 시작하게되어 기쁩니다. 이 "청소"! 프로그램이 잘못됨 (2.5.2조차) cpu가 3 % 인 경우에만 < 10.000 Versions/Minute이므로이 테이블의 성능은 약 2 %입니다.