f 十二月 2021 ~ 迪貝之家

Microsoft SQL Server Log Shipping

SQL 7就有的技術,簡單的說就是資料庫複本資料同步的技術,而這份複本可以開放讀取的功能以分散營業資料庫的負載,也可純粹當成備援資料庫,不管是在本地還是異地。怎麼達成? 透過SQL Agent自動化排程進行備份、傳檔及復原等作業。

Oracle GolGateden

機房搬遷跨Site能即時同步資料庫利器

Nagios 資料庫維運自動化

一開始設計這架構時,就排除使用remote agent的想法因為在專業分工的組織下,要求安裝新軟體於既有系統是一件不太可行的方案,既然身為DBA就只能把資料庫instance當作是一個最大的agent 想辦法在資料庫內做到我想做的事情

This is default featured post 4 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

This is default featured post 5 title

Go to Blogger edit html and find these sentences.Now replace these sentences with your own descriptions.

Postgres sequence currval 效能問題及GCP Query Insight工具

 

最近在寫go 程式
把資料轉進GCP Cloud SQL Postgres 13
碰到sequence 物件叫用currval的效能問題
邏輯大概是這樣
塞到主表資料後
再用currval抓出主表該筆資料的json資料展開後
再塞到子表
可是主表已經把identity欄位設為主鍵
基本上應該不會有效能問題
結果170幾萬筆的資料
程式跑了一天半跑不完
而且從table size 的數字看起來
資料匯入連一半都不到
碰到這種狀況
只好改寫程式
在insert主表時,return identity欄位的數值
再用strconv package把數值轉為文字
大概3個半小時就能跑完所有的資料
此時當然就在想,為什麼呢?
以前管地端的postgres
auto_explain及pg_stat_statements
這兩個extension我一定會用
一個是看執行計畫
一個是sql的執行數據
可是現在用的是cloud managed service
難不成還用地端的思維來管理資料庫及調校程式效能??
其實GCP給了很好的工具...叫做query insight
我不得不說.....真的非常好用
首先我們來看執行計畫的部分

左下我用黃色圈起來的部分
就是currval的運作
掃表以及執行時間是195.56ms
我們再來看改寫後的計畫差異
index scan以及執行時間小於1 ms
上述是auto_explain的功能
那pg_stat_statements呢?
有啦~~query insight也有
這工具整合了不少好東西
我要特別強調
這是程式剛丟下跑的時候
currval 運作的時間
隨著逐筆塞入後
insert select 的速度只會越來越慢
我們再來看改寫程式後的數據
平均執行時間0.03 ms
其實實務上debug的順序
應該是先找到slow query
然後再來找執行計畫
只是因為程式是我寫的
我大概知道問題出在哪裡
就直接去point執行計畫的部分
總之~~ query insigth 就是好用