FirebirdSQL查詢在12:00下午卡住

我在Windows上運行的是Firebird 2.5（也嘗試過早期版本）。每天中午12:00之後，在一個特定表上運行插入/更新查詢掛起，但在12:35左右成功完成，無論何時啓動。似乎Firebird在桌面上進行某種維護，並且需要半個小時才能完成，在此期間無法寫入表（但讀取速度很快）。該表本身非常小，大約10000行，而我們在其他表中有數百萬行 - 而其他表不會卡住。FirebirdSQL查詢在12:00下午卡住

我一直未能找到任何理由或解決方案。我試圖傾倒桌子並恢復它，這沒有幫助，我嘗試在超級服務器和經典版本之間切換，但沒有成功更改版本。

有沒有人遇到過這樣的問題？

來源

2011-09-23 Rytis

編號火鳥沒有任何內部維護程序綁定到某一特定時間的一天。看起來，您的服務器上有一些任務計劃在中午12點運行。或者服務器的網絡用戶在下午12:00開始進行大量訪問。

來源

2011-09-23 11:45:18

唯一的維護FB是「垃圾收集」（geting擺脫舊的記錄版本），這是在「需要時」的基礎上完成的（通常在選擇記錄時，請參閱firebird.conf中的GCPolicy）預定義時間。

您是否僅在這些特定時間內感受到這種情況，或者在插入該表時總是很慢？你是否在減速過程中檢查了服務器的負載（例如，在任務管理器中，CPU是否被最大化）？無論如何，這裏有一些想法來檢查：

你有什麼限制/觸發器在桌子上？如果它們涉及一些廣泛的檢查（即針對其他包含數百萬行的表），這可能是插入時間過長的原因。
也許還有一些其他的服務在當時被觸發？即你當時是否有cron作業來備份數據庫？或者，當時以更高優先級運行的其他系統服務會降低服務器的性能？
您是否對錶格有跟蹤服務？請參閱FireBird根目錄中的fbtrace.conf。如果它處於活動狀態，則廣泛的日誌記錄可能是導致速度放慢的原因，如果它不活躍，使用它可能會幫助您找到原因。
ForcedWrites/UnflushedWrites（請參閱firebird.conf）的註冊是什麼？改變它們會不會改變？
在firebird.log中是否有這種麻煩的時間表記錄？

來源

2011-09-23 11:50:04 ain

對我來說，它看起來像你有一個過程，開始於12:00，並做了一些鎖定整個表的東西。使用監控表或跟蹤管理器查看是否有任何看起來可疑的連接或活動事務。
我也認爲你自己的事務是在沒有LOCK TIMEOUT的情況下以WAIT子句開始的，你可能想用LOCK TIMEOUT將其更改爲NO WAIT或WAIT，這樣你的事務就會立即失敗或者在超時之後失敗。

來源

2011-09-24 08:04:24

我的建議是使用2.5中的TRACE API來追蹤當時或附近發生的事情。這應該有助於讓你瞭解正在發生的事情。我用它來調試http://upscene.com/products.misc.fbtm.php有點兒車本身，但是當它工作時它是一個神派。

來源

2012-03-29 18:24:33

是一些客戶端連接在12:00 PM下去？我曾在一個70.000記錄尺寸表了類似的問題：

客戶「A」具有像「SELECT * FROM表」永久開放的DB連接。這是一個「只讀事務」，但足以讓服務器生成記錄版本。爲什麼？客戶端「B」對此表進行了大規模更新，服務器試圖保持與「A」啓動她的「選擇」時一樣的世界。這對於事務處理能力強的數據庫服務器來說是正常的，並且通過在其更新之前創建記錄數據的記錄副本來實現。所以在我的情況下這個TABLE 170.000記錄版本存在。您可以通過

gstat -r -t表db.fdb衡量這個| grep的版本

如果客戶端「B」出現故障，記錄的版本的數量沒有任何更多的增長。客戶端「A」是有罪的，凍結所有這些版本，強制服務器持有它。最後，如果客戶端「A」出現故障（或者例如防火牆規則切斷了所有掛起的連接），Firebird很樂意開始擺脫現在無用的記錄版本。這「掃」？？編程不良（甚至2.5.2）cpu僅爲3％< 10.000版本/分鐘，因此該表的性能約爲2％。

來源

2014-01-28 20:50:57

FirebirdSQL查詢在12:00下午卡住

回答

相關問題