昨天在使用 pgadmin III 連上資料庫後, 查詢了幾筆資料後, 突然發現... 似乎有個不平常的訊息出現:

WARNING:  database "xxx" must be vacuumed within 107009986 transactions
HINT:  To avoid a database shutdown, execute a full-database VACUUM in "xxx".

看起來似乎很嚴重的樣子, 用 google 查了一下, 發現了這篇 postgresql 的文件, 說明是因為沒有做 vacuum 的關係. 只要做一次 vacuum 就可以了. (閱讀全文)

記得去年我們升級 PostgreSQL 之後, 造成在 Windows 上頭使用 ODBC 的程式無法連線, 雖然後來是另外建立一個使用者, 限定使用 LATIN1 來避開這個問題, 因為在這方面處理的都是數字, 所以這個方法也就一直用到了現在都沒什麼問題.

最近有另外的需求, 一樣是在 Windows 平台上頭, 使用 psqlODBC 來連線, 但是程式上頭會用到一些字串, 如果只使用 LATIN1 的話會有問題. 抓了目前最新的版本回來使用, 發現不管使用 PostgreSQL ANSI 或者是 PostgreSQL UNICODE 的 driver, 都不會出現 client encoding mismatch 的錯誤了. 目前使用上也一切正常了.

隨著資料量的增加, 通常資料庫的重要性也就跟著增加, 這時, 我們要如何確保資料庫可以正常運作呢? 使用比較好的機器? 使用高級的 RAID? 把資料備份好? 這些做的再好, 也都還是有風險. 也就是, 只要是硬體, 就可能會壞. 機器就是那一台, 出了問題, 就得找台機器, 重新開始安裝, 然後由備份的資料還原. 資料一多, 這些動作可以短到幾小時, 也可能是兩三天才能處理好. 也就是, 在這段時間內, 如果你的公司運作, 對資料庫有極大的依賴性, 可能這段時間的運作完全停擺, 損失不可說不小.  (閱讀全文)

我們大約是由 2003 年初開始使用 PostgreSQL 當做是公司內的資料庫系統. 當初在 ORACLE (9i), MySQL (3.x) 與 PostgreSQL (7.2) 之間選擇時, 先把當時還算很簡陋的 MySQL (那時應該還沒有支援 stored procedure, sub-query, transaction 等等的功能, 實在不適合商業使用,  不過因為快又小, 我們有些中介的資料庫, 還是使用 MySQL 來處理) 給排除掉. 在 ORACLE 與 PostgreSQL 的比較上, 在我們需要的功能上頭, 兩者都能提供, 當然, PostgreSQL 有絕對的價格優勢 (不過, 當初我們並沒有預算上的壓力, 雖然 ORALCE 不算便宜, 但我們決定要用時, 也不會說花不起這筆錢), 但是在複製, 備份與災難復原方面, 就遠遠比不上 ORACLE 了. 最後與老闆討論的結果, 是決定先用 PostgreSQL 試看看, 如果一年內有發生重大的當機或災難時, 我們就轉用 ORACLE. 結果... 當然 4 年多過去了... 我們還是在用 PostgreSQL. (閱讀全文)