f 四月 2019 ~ 迪貝之家

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.

RMAN archivelog 在備份保留天數的誤解

這其實是一個10.2.0.5透過rman restore 升級到12.1.0.2 過程中所發生的一個狀況


用NBU備份是因為它是公司既有的備份Infrastructure,就直接用它來做為升級來源,也就不用再耗系統資源及時間做一份disk 備份image,這套營業系統本身就很繁忙了,我也不想自找麻煩,在營業時間下full backup 指令,兩個資料庫加起來,所耗的時間大該一個工作天就不見了。


10.2.0.5 升級到12.1.0.2 是Oracle db 直接upgrade path的兩個端點極限了,所以不要問我,為甚麼不直接升級到18或19c。


既然是用NBU的備份,相關環境變數當然就得去詢問NBU的負責人,其實在類似我的工作環境,因為分工,DBA通常步做資料庫的日常備份工作。


你應該會覺得restore有甚麼好講的,就是出了問題,才會想記錄下來,底下是我進行restore的語法

12c upgrade


下列是跑到最後的錯誤


RMAN-06025
奇怪了!!不是當天的備份嗎?? 怎會倒不回去哩??居然找不到archive log,真是腦袋三條線。只好去查看control file內的archive log,ㄝ....怎麼會沒有22號的記錄,難怪rman 回應找不到相關訊息。後來備份負責人跟我一起看他們的archive log 備份script,哇哇哇.......哩!!看了之後才覺得,怎麼會有一個好大的mis....understanding.......哈哈哈!!來吧...我們看看script


archivelog backup script


看到了backup archivelog until time 'sysdate-1' 了嗎 ??
這個系統是有建置DataGuard,當時備份負責人應該是被特別提醒至少要保留一天的archive log,所以他才透過這個語法來達成,但是它的真正的含意是,要rman 指備份前一天的archive log,然後執行清檔。這就難怪了,controlfile 的archivelog備份記錄只有前一天的。該怎麼解決?? 就拿隔天的controlfile來進行前一天的備份還原


至於升級要進行哪些pre 及post task,Internet 找一找就有相關資料了




































Nagios Core 監控MSSQL Server

我自己對監控的定義為,以一定的頻率,對標的進行某個動作,再來判斷標的給的回應狀況。

在這裡我要我想談的是,我怎麼在Nagios
 Core 裏,實施上述動作,也就是我怎麼寫
我的plugin。



首先來看我的service定義,也就是對標的物進行的動作
nagios service



紅色框框所示就是定義針對SQL Server所要進行的動作,以Nagios的術語來說,check_command是所謂的directive,check_mssql_slow_query 就是你要求Nagios Core幫你執行的動作。


check_mssql_slow_query這個動作在Nagios 裡頭,是被定義出來的,也就是你在作業系統裡要執行的命令列,接下來我們來看command的設定檔
Nagios Command cfg






如圖所示,它所對應的是/usr/lib/nagios/plugins/check_mssql_slow_query.sh這隻shell script。它是透過sqlcmd進到sql server 查詢request DMV 來抓取slow query。但為了彈性,你就得去想,要怎麼把在Nagios 裡的設定,帶成不同的參數值,丟進sqlcmd 所執行的sql file裡。

其實坦白說,除了sqlcmd是由微軟所提供的binary,沒辦法變更,命令列其他的都是參數,sqlcmd 本身的參數我就只提,要執行的sql file怎麼在Nagios裡做指定,我是定義在我的service template裡頭,請見下圖
Nagios Service Template




如紅色框框所示,sqlcmd 要執行的sql file的位置為 /home/dbaadmin/plugin_sql/mssql/slow_query.sql。
那在Nagios裡頭,針對標的所要執行的動作會變成甚麼? 
我們回頭看一下Nagios Command的設定
Nagios Plugin Variable




前後兩個$,是Nagios自身的設計。
如果您有仔細看這篇文章的話,您應該會留
意到,我定義了兩個slow query的門檻,一
是10分鐘,一是15分鐘。為了t-sql程式的撰
寫彈性,我總不能讓sqlcmd 去執行不同的
sql file吧!!那我又得生出不同的shell
script,當你的服務監控越來越多時,就會
造成未來在管理上的不便。所以接下來我要
給各位看的是,相關參數的設定。

我們也回頭看一下對標的本身的設定
Nagios Plugin Variable




藍色與紫色框框分別表示兩個不同的參數,elapsed_time及wait_time。我們再次回頭看一下Nagios Command的設定



圖示裡,藍色框框ARG2是elapsed_time的值,ARG3是wait_time的值。這樣就OK了嗎?? 當然不是!! 相應的shell script及t-sql要做出調整
Nagios Plugin

圖示是shell script所做的調整。
t-sql variable


圖示是T-SQL要進行的修改

你如果真的想了解這中間怎麼串起來的,那就得去研究Nagios Plugin的撰寫、SQLCMD怎麼用、Linux Shell 變數怎麼帶入T-SQL 等。

有人一定會講說,屁那麼多,是真的可行嗎?
來我們來看看透過mail發出來的alert
Nagios Core


Postgresql 9.6 的lock 源頭好找多了

postgresql 9.6 開始多了個有趣的系統函式pg_blocking_pids,以後要砍lock session,可方便多了,不用再去執行一長串的sql 語句,真是一大福音,非常大的進步,我們來做個小測試吧!!

我們來執行一段叫ttt.sql,內容如下
pg_blocking_pids

因為跑了pg_sleep,所以transaction open 直到兩分鐘後才會commit,因此你會看到session 暫時pending
pg_blocking_pids


我們再叫起一個psql 的連線來下update 指令,你會看到它也pending,因為被前一個session給卡住了
pg_blocking_pids


接下我們找上面兩個session的process id 吧~~
pg_blocking_pids












紅色框框是該系統函式執行結果,藍色框框是兩個session的資訊,PID 4134 被8120給卡住了