2017年12月5日 星期二

[SQL Server] 案例分析 : 用IF EXISTS來進行交易的判斷真的沒有問題嗎?

案例情境
近幾天檢查資料庫客戶資料時意外發現有客戶的帳戶餘額為負值,這對公司來說是一個非常致命的錯誤,事關到公司營收。
便開始檢查是否被鑽了漏洞或者程式有邏輯錯誤。







在逐筆確認了交易的Log後,發現客戶的提款動作在短時間內重覆了兩次





此時心中開始咒罵 : 一定是哪個傢伙沒確認餘額狀況,就讓客戶可以領錢
於是乎去檢查了提款的Stored Procedure,發現以下這段邏輯

IF EXISTS(
    SELECT 1
    FROM dbo.MemberAccount
    WHERE MemberID = @MemberID
          AND ActualBalance >= @TransferAmount
)
BEGIN
    UPDATE dbo.MemberAccount
    SET ActualBalance = ActualBalance - @TransferAmount
    WHERE MemberID = @MemberID
END

2017年8月5日 星期六

[SQL Server] 案例分析 : 誤用Local Variable造成效能問題

案例情境
我們的資料庫中有個資料表存放有關訂單的相關資訊,訂單的狀態分為三種:Confirmed, Pending, Canceled,其中Confirmed的訂單占了全部的百分之99以上,剩下的少數才是PendingCanceled的。
此時,我們另外有個
Job會定期去檢視Pending的訂單有那些,客服會查看這些訂單並去處理。
但這個
Job隨著訂單越來越多,查詢時間變得非常的久,其中原因是當初誤用了Local variable增加可讀性,反而造成了嚴重的效能問題

2017年7月28日 星期五

[SQL Server] 如何解決不佳的Parameter sniffing所造成的效能問題

前言
從上一篇文章中 : https://retrydb.blogspot.tw/2017/07/sql-server-parameter-sniffing.html
我們了解
Parameter sniffing的目的是為了讓Plan可以重複使用,避免每次執行Stored procedure都必須耗費CPU編譯其語法來選擇其演算法。
同時,我們也了解到,如果第一次執行所選擇的是資料分布非常極端的情況,可能造成之後在執行此Stored procedure時,所衍生出的效能問題。
本篇會介紹幾個情境如何避免Bad Parameter sniffing

2017年7月23日 星期日

[SQL Server] 淺談Parameter sniffing (一)

什麼是Parameter sniffing?

SQL Server為了避免在Cache有許多重覆的執行計畫,當你的語法是參數化的,且沒有任何的PlanCache中時,會根據你當時的參數產生一份最恰當的執行計畫,爾後除非recompile stored procedure,否則就會一直重用這份執行計畫來選擇是否要Scan/Seek table、選擇哪種Join方式(註解1)、所有相關的運算方法…等等。

2017年4月28日 星期五

[SQL Server] Deadlock案例分析 : 透過Join user-defined table type 來更新資料所引發的死結

在前幾個禮拜查看deadlock extended event時,發現有一段更新的語法被當作Victim(受害者)給放棄掉了,由於此段語法是重要的商業邏輯,且AP端沒有再次做Retry
立馬拉出deadlockgraphxml查看其發生的原因,如下圖:

2017年4月21日 星期五

SQL Server Performance tuning 兩年菜鳥心得雜談

前言

畢業至今也兩年多了,第一份工作也就是現在的工作,一開始主要擔任後端開發的工程師,串接後端的Service,主要負責商業邏輯層跟資料存取層的開發。
由於公司產業的關係,對於交易效能有極度的需求,為了避免不必要的I/O存取,所以大部分的商業邏輯都寫在資料庫,所以有很多的時間在接觸資料庫的開發。
後來在效能調校的工作上有點小小成績,而且也玩出興趣來了,在前輩的
Promote下成為我們teamDB Owner
在此也特別感謝我們公司的前輩們,放任我選擇自己所愛的領域,自由的發展,也不時的糾正出我的錯誤,才能有今天的我。
還記得那時候剛來公司三個多月就上錯了
ScriptProduction table Drop掉了(),不過那是另一段故事了...好了進入正題,分享一點小小心得

2017年4月19日 星期三

[SQL Server][SSMS] 透過建立Code snippet提升工作效率

前言
每個DBA 或者 DB Developer經常都會有許多自己撰寫的花式Script,透過這些語法去查詢DMV或者metadata來幫助我們在緊急狀況的時候做trouble shooting,或者是Load test的時候輔助我們找出bottleneck
但這些語法通常都不太好直接背起來,就算即時自己兜出來的script,其包含資訊也不是那麼完整。最後就會散落在各處(onenotetxt...等等),如果找不到或忘記又得去網路上google
每個同事也都會自己私藏一些好用的獨門秘方,卻沒有一個方便的共享平台。

這個問題困擾了我許久,後來我找到了在SSMS 2012之後推出的新功能 : Code snippet manager

[SQL Server] 了解ACID

前言
SQL SERVER中,一段語法被執行時,被視為一個Logical unit(邏輯位元)
我們可以透過BEGIN TRANSACTION ROLLBACK/COMMIT將多段語法打包為一個Logical unit
為了確保每個
Logical unit在進行資料的變更時是可靠安全的,必須符合四大原則,也就是我們常聽到的ACID原則
  • Atomicity (原子性、不可部份完成性)
  • Consistency (一致性)
  • Isolation (隔離性)
  • Durability (持久性)
下面分別介紹其定義並帶一些簡單的範例來解釋

2017年4月18日 星期二

[SQL Server] 使用RETURN回傳數值發生Overflow

我們經常藉由 T-SQL 中的RETURN,來中斷我們的Stored procedure、一段batch.
有時候也會透過RETURN來回傳一個數值。

但有些人可能不知道 : 透過RETURN只能回傳 INT 大小的數值(-2,147,483,648 to 2,147,483,647)
如果數值超過此大小便會發生Overflowexception
即便你有宣告BIGINTDECIMAL來承接參數。