[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

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

案例情境

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

[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。

[SQL Server] 淺談Parameter sniffing (一)

什麼是Parameter sniffing?

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

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

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

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

前言

畢業至今也兩年多了，第一份工作也就是現在的工作，一開始主要擔任後端開發的工程師，串接後端的Service，主要負責商業邏輯層跟資料存取層的開發。

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

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

前言

每個DBA 或者 DB Developer經常都會有許多自己撰寫的花式Script，透過這些語法去查詢DMV或者metadata來幫助我們在緊急狀況的時候做trouble shooting，或者是Load test的時候輔助我們找出bottleneck。

但這些語法通常都不太好直接背起來，就算即時自己兜出來的script，其包含資訊也不是那麼完整。最後就會散落在各處（onenote、txt...等等)，如果找不到或忘記又得去網路上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 (持久性)

下面分別介紹其定義並帶一些簡單的範例來解釋

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

我們經常藉由 T-SQL 中的RETURN，來中斷我們的Stored procedure、一段batch.

有時候也會透過RETURN來回傳一個數值。

但有些人可能不知道 : 透過RETURN只能回傳 INT 大小的數值(-2,147,483,648 to 2,147,483,647)

如果數值超過此大小便會發生Overflow的exception。

即便你有宣告BIGINT、DECIMAL來承接參數。