RiCo技術農場

我目前使用docker for windows，前一陣子才解決Linux container和windows host網路問題，

而主要的方式是透過bridge，這篇再來看看windows container虛擬網路設定。

以前我總認為SQL engine會完整接收並執行sqlcommand，不應該發生截斷問題，

直到xml_deadlock_report讓我知道原來有例外。

上一篇我示範在Linux container存取本身的http server，

這篇示範如何透過windows host的外部程式來存取Linux container的http server。

最近幾次被code review，有位同事建議我一些變數加上const，

但另位同事則覺得沒有多大效益，

起初我認為const對執行時間應該沒多大影響(雖然ReSharp希望我轉換為constant)。

Nancy 是一個open source 輕量Web Framework，基於Http的Web服務而生，且目前也支援.netCore2.0了。

之前我因為要快速建立Http Server而接觸到Nancy，Nancy開發上不只簡單且外掛功能相當豐富，

這次簡單紀錄web api with .net Core2.0和Nancy開發過程。

微軟愛Linux有一段時間了，SQL Server on Linux這目標也看到光了，

隨者.Net Core 2.0 Announcing，今天我就透過GDD和SOD方式動手實作

(我沒很了解.netCore，但這兩種方式對我來說有快速學習的效果~哈)，

看看.Net Core 2.0是否讓我有不同的開發體驗。

我在超過20幾個的OLTP系統，啟用資料壓縮功能都不曾遇到吃掉系統大部分CPU資源，

不管是我在當DBA、consultant或developer角色時，只要使用企業版SQL SERVER，

我都會建議啟用資料壓縮功能。

當我們使用Exists判斷資料是否存在時，是否需要再子查詢中額外使用 Top 1來告訴QO，

我只需判斷一筆資料即可，請不要進行多餘(非必要)的處理。

No Join Predicate警告，是指出在這Query中，有存在無聯結述詞，那我們到底要不要在意這警告呢?

In recently, I tried to enhance performance of some operator api on our company system.

I found some operator api so fast on our system.

All queries using index seeks and no more than 3ms.

This post , I will show you how to improve its query performance.

I had known some tips for coding store procedure already.

Such as “don’t forget enable nocount”,”2 part names” ,”avoid prefix store procedure with sp_” and more…..

Today I will show you why don’t use sp_ as a prefix for store procedure and how to impact performance on the SQL server.

紀錄一下再寫單元測試時，如何測試internal class

partition table對資料維護的效率是一直吸引我的主因，

透過switch partition可說秒殺insert+delete操作，

不僅lock request少，且又可降低交易紀錄檔使用量，整體對我來說好處不少，

但以前經驗告訴我，partition table影響insert和update效能，

我想如果這部分能使用In-Memory table來接管的話那真是太美妙了，可惜In-Memory table並不支援partition，

但我們依然可以透過SQL2016來模擬partition，讓我們同時享有高效率的資料維護和高效能的交易處理。

Recovery model選項，可以控制交易的紀錄方式，以及可用的還原交易類型，

大家也一定都知道，Simple將使用最少交易紀錄，Full使用最多交易紀錄，

但對In-Memory table 是否有ㄧ樣的關聯呢 ?

以前我很早就被植入使用Reflection大部分效能都不好，所以應該要盡量避免，

但朋友昨天傳給我一篇文章指出現在的dynamic call不會有效能問題，

雖然我知道C#早已不是以前的吳下阿蒙了，但我還是覺得應該還是有效能上的差異，

所以我這裡簡單測試dynamic call 和 direct call兩者效能差異。

SQL2016大幅改善In-Memory OLTP效能，所以我在SQL2016花了很多時間研究、測試並閱讀相關whitepaper，

我也先告訴大家一件事，In-Memory table並非效能萬靈丹，

不要以為把disk-table轉換到in-memory table，現有系統交易效能就可突飛猛進，

而且真實世界要把disk table要轉換in-memory table也非那麼簡單(除非你的disk table layout真的很單純)。

最近進行SQL Tuning時，深入查看相關執行計畫，發現QO改寫用有趣的陳敘式，馬上又引起我的興趣

最近我花了一些時間比較分析kafka,rabbitMQ,NATS何者適合Log Aggregation並符合公司系統要求

一般企業內Server的C:大約分配40~60G，如果ERRORLOG和AGENT LOG存放路徑未變更，

同時又疏於管理的話，那麼檔案吃爆C:空間應該也是早晚的事。

SQL Server process的狀態為sleeping，

如果一個資料庫有太多的sleeping process會有影響嗎?這些process是否可能封鎖其他process呢?