RiCo技術農場

最近幾次被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呢?

不建議頻繁執行檔案或資料庫壓縮，因為這些操作對效能有一定的影響

除非硬碟可用空間已經不足，這時先確認那個檔案的壓縮大小是最小的

我以前200GB的資料庫，tempdb 我只需使用18GB，500GB的資料庫也只需使用35GB，

當然這比例沒有一定，完全取決於你系統行為(寫TSQL和c#習慣要好)而定。

之前我介紹RP並了解作用為自動刪除過期資料，但如果你不想完全刪除資料，

這時就可以透過CQ自動把資料存放在另一個MEASUREMENT，

完全定時自動觸發，無須人工介入。

使用過EF應該都知道所產生的TSQL一大長串(尤其新增一些累贅條件是我最討厭的)，

而且執行順序可能非預期(單一包交易中有insert、update、select同table，更容易產生deadlock)，

同時EF並無法產生SQL Server所內建高效率陳述式(如Merge)，

這時TinyORM主推所產生的TSQL絕對簡單並更貼近SQL Server，

且改善Dapper一些缺點和效能。

ps:目前無法支援.NET Core