問題產生實際情況：
資料庫被強制乾掉，空間漲到100%。
分析：經觀察發現是由於pg_log目錄增長過快導致磁碟空間被爆。
pg_log是如何產生的？
記錄資料庫執行日誌， 內容可讀，預設關閉，需要設定引數啟動。
1. error資訊。
2. 定位慢查詢sql。
3. 資料庫的啟動關閉資訊。
4. pg系統相關警告資訊等。
根據以上幾點，眼前一亮， 慢查詢sql， 我們定的是記錄條件是什麼呢？
log_min_duration_statement ：# -1 is disabled, 0 logs all statements
# and their durations, > 0 logs only
# statements running at least this number
# of milliseconds
-1 ： 關閉。
0： 記錄所有語句。
>0 : 記錄大於此引數設定值。
此引數單位毫秒。
了解到這些資訊後， 去看了日誌記錄， 幾乎全部是sql，並驗證此引數的設定為0.
已找到案件的真兇了， 處理方案如下：
1. 修改此引數設定，大於300s的語句就記錄（此系統為olap）。
2. 手動刪除pg_log下的檔案。
3. 啟動資料庫。
後記：1. 監控很重要。
2. 引數設定要謹慎。
乙個ID引起的血案
最近用asp寫程式時，剛開始支援的資料庫是access，程式裡有一段 是往資料庫裡新添一條記錄，方法為先建立乙個recordset，然後用addnew和update方法來實現資料新增。addnew之後便能取得新增記錄的id號。後來程式移植到伺服器上時，由於伺服器安裝的是sql server 2000...
乙個引數引起的mysql從庫宕機血案
max binlog cache size 表示的是binlog 能夠使用的最大cache 記憶體大小 當我們執行多語句事務的時候 所有session的使用的記憶體超過max binlog cache size的值時 就會報錯 multi statement transaction required...
乙個引數引起的mysql從庫宕機血案
part1 max binlog cache size max binlog cache size 表示的是binlog 能夠使用的最大cache 記憶體大小 當我們執行多語句事務的時候 所有session的使用的記憶體超過max binlog cache size的值時 就會報錯 multi st...