[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 (一)

什麼是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] 了解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來承接參數。