Stories

List
Create Time

PostgreSQL中記錄SQL日誌/慢日誌參數

PostgreSQL記錄SQL日誌的參數有三個,如下,這三個參數都可以記錄某種日誌,也可以單獨設置,也可以相互設置,因此情況比較多,某些情況下會生成一些奇怪的日誌內容,需要弄清楚每一個參數的具體含義,有助於做出合理的配置 1,log_duration = on|off; 2,log_statement='none|ddl|mod|all'; 3,log_min_duration_sta

Create Time

Ubuntu 20下PostgreSQL 17.6 源碼編譯安裝,排除doc包

前些年寫了一個PostgreSQL自動化安裝的shell腳本,這幾年一直在用,中間有微調過但都可以正常一鍵安裝,今天嘗試安裝一個最新版的PostgreSQL 17.6(Aug. 11, 2025發佈的),發現編譯過程中死活過不去,遇到如下幾個錯誤 1,ERROR: `xmllint' is missing on your system.,安裝libxml2-utils依賴包後沒有出現了 sudo

Create Time

PostgreSQL中的work_mem參數

在SQLServer中有一個內存授予(Memory Grant)的概念,意思是一個執行一個查詢語句所需的內存大小,如果獲取不到這個內存,則查詢申請等待內存,因此就會受到影響。PostgreSQL有一個類似於此的work_mem參數,該參數也是執行跟查詢所使用的內存有關的,那麼work_mem的具體含義是什麼呢? work_mem參數 1,work_mem的定義   查詢操作(例如排序或哈

Create Time

PostgreSQL 17 pg_basebackup增量備份新特性測試,以及基於完整備份+增量備份+WAL日誌備份的恢復

PostgreSQL 17版本的pg_baseback開始支持增量備份,終於可以像大多數的數據庫物理備份工具一樣支持增量備份了,下班後抽空嘗試了一下,跟其他數據庫的物理備份類似,還是比較簡單的。 以下基於一個月前發佈的PostgreSQL 17.6為測試環境,利用pg_basebackup,基於full+incremental+wal日誌的備份,做一個基於時間點的恢復(Point-In-Ti

Create Time

PostgreSQL repmgr 高可用之故障轉移

PostgreSQL高可用之repmgr自動切換 之前寫過一個repmgr的高可用搭建的,https://www.cnblogs.com/wy123/p/18531710,repmgr的搭建過程還是比較簡單的,具體過程不再贅述。這裏為了簡化,做了1主2從的結構,之前一直沒空測試repmgr的手動和自動故障轉移,抽空找了個環境,做了個repmgr的故障轉移測試。 環境: ubuntu05:1

Create Time

PostgreSQL 18 源碼編譯安裝體驗

PostgreSQL 18 於前幾個小時剛剛發佈,來個一鍵安裝(Ubuntu 20.0) 一鍵安裝腳本,全自動編譯安裝,兩個實例的安裝pg1800和pg1900也只是1分鐘的事,自定義各級目錄,乾淨清晰。 前兩天羣裏竟然還有人推崇apt/yum安裝,説是統一規範,apt/yum安裝出來的目錄結構亂七八的,反規範吧,難道是那個人不會編譯安裝? 源碼包地址:https://ftp.po

Create Time

SQLServer中,大表的數據刪除操作,單次刪除和批量多次刪除產生的事務日誌的差別

1,應用場景 SQLServer中一個大表(測試環境千萬級,實際情況下會更多,達到10億級),刪除其中大部分數據。然後測試分批多次刪除和一次性全部刪除產生的transaction log的日誌大小的問題。 另:受限於相關的表做了複製分發,因此無法通過備份部分數據後truncate table的方式來實現,也無法通過新建一個表,通過rename的方式來交換實現,這兩種方式不

Create Time

SQLServer中,實測CPU主頻高低對計算密集型SQL執行速度的影響

從一個簡單的SQL來看,CPU主頻對計算密集型SQL執行速度影響的差別,測試語句有三個特點:簡單SQL,計算密集型SQL,循環多次執行來放大執行時間 1,構造一個簡單的插入語句SQL 2,通過隨機排序,來模擬計算密集型操作 3,通過循環來放大執行時間 完全一樣的SQL: 10年前的4代i7,老掉牙的PC級CPU了,但是主頻高,3.6GHz主頻的CPU,2秒鐘跑完 5年前的Xeon E5620,服

Create Time

SQLServer Always On環境的數據庫備份

SQL Server的Always on環境的備份規則設置比較混亂,加上一個copy_only備份,更是亂上加亂,copy_only備份實在極少的特殊情況下使用的備份,企業級日常備份,不可能用copy_only備份的,因此這裏不討論copy_only備份。 Backup preference有多重設置,企業級生產環境保持默認就可以,這裏以默認設置為例 1、不管怎麼設置,正常的數據庫備份(fu

Create Time

sqlserver系統表查出job的下一次運行時間異常現象

前兩天某SQLServer服務器斷斷續續出現性能問題,綜合排查之後懷疑是job定時任務引起的,於是查了一下job的schedule和最近一次執行情況。 大部分job的schedule都沒有問題,由於當前實例是啓用了複製分發,無意中喵到'Distribution clean up: distribution這個job的下一次執行時間明顯不正常,下一次運行時間跟上一次運行時間一樣??? 啓

Create Time

MySQL,SqlServer,PostgreSQL中,如何實現鎖定一張表

最近有個需要求,需要在SqlServer中鎖定一張表後,然後搞一些事情,完成後解鎖。 如何鎖定一張表,在MySQL和PostgreSQL中都比較好處理。有專用的語法來實現,在SqlServer中並沒有對於“直接鎖定一張表的語法”,如何來處理? 變通一下也比較簡單,甚至比MySQL和postgresql都更簡單。 1,如何在MySQL中鎖定一張表 MySQL語法:lock tables t2

Create Time

SqlServer 事務複製的兩個參數immediate_sync,allow_anonymous

SqlServer的事務複製中,immediate_sync和allow_anonymous兩個參數會影響到複製的後台行為和分發庫(distribution)的數據保留方式,這兩個參數單從名字上看,可能有些模稜兩可甚至雲裏霧裏,以下是個人結合複製的運維,對兩個參數的理解。 1,immediate_sync 參數含義:是否執行“立即同步”,立即同步啥?誰來同步?有啥作用?表面含義跟沒説一樣,完全看不

Create Time

SqlServer 事務複製(transaction replication)的複製位點信息

在邏輯複製中,正如MySQL的show slave status,或者postgresql的邏輯複製pg_stat_replication的sent_lsn,來觀察複製進度的座標位點,其複製進度座標位置都存儲在複製的源(source)端。 SqlServer的事務複製則有一些不一樣,在發佈端和訂閲端分別有一個記錄複製信息的系統表, 1,在源端,有一個MSdistribution_hist