史丹利好熱

前陣子有幾個大型資料表要封存用了破壞重建再扶正，接下來碰巧有2個資料表當初就是開Partition Table，筆記一下釜底抽薪的作法。

Switch Partiton

初始資料庫時，我們Developers們會準備很多.sql指令碼來建立資料表、檢視甚至初始資料，那麼要怎麼一次執行資料夾內的*.sql或是指定的幾個.sql指令碼？

來節省一點點初始化資料庫的作業時間。

準備初始資料習慣用SSMS管理工具在資料庫右鍵[工作]、[產生指令碼]，進階選項選擇資料碼類型為僅限資料；但...產生指令碼之後臨時想改資料值時，就悲劇了，要用睡不著數綿羊的絕招。

先前嘗試一種用xml替代初始資料的作法，感覺有方便一點，趕緊筆記下來。

.NET程式存取AlwaysOn可用性群組(Availability Group)下的唯讀複本有兩個連線方式:

1.直接連接次要複本所在的資料庫伺服器。

2.透過Availability Group Listener (AG Listener)唯讀路由讀取。

為了降低主要複本負載，除了倉儲與報表作業讀取非同步認可的複本，最近計畫把線上交易查詢改道同步認可的複本，一種類讀寫分流。

開始測試網站，就在明細頁修改完資料(主要複本)回到清單頁重查資料時(次要同步複本)，顯示的還是舊資料?

為減少資料爭用避免擴大鎖定，我們常調整T-SQL或預存程序使用小量分批更新或寫入。
常用SqlBulkCopy來提升.NET大量資料寫入效能(真的很快)，那麼SqlBulkCopy會不會造成資料表鎖定(Tabe Lock)?
(1)會  (2)不會  (3)不一定 
 

先前案子多把SQL Server 2012 新功能AlwaysOn作為備援用途，這次的案子則進一步希望在SQL Server 2014完成讀寫分流，

設定好ReadOnly Routing和Listener，也請SP幫忙加AD(VCO)及DNS，使用SSMS連入時卻一直連到主要複本，

明明設好了ApplicationIntent=ReadOnly..

繼ADO.NET Sqlcommand AddWithValue可能產生的效能問題，那麼Dapper有沒有類似的情形?

針對居家旅行 殺人滅口 必備良藥Dapper與參數化的實驗:

ADO.NET呼叫帶入資料表值參數的預存程序失敗，錯誤訊息:

資料表值參數不可以使用資料庫名稱，只有結構描述名稱和類型名稱是有效的。
Database name is not allowed with a table-valued parameter, only schema name and type name are valid

在SQL Server資料庫端SELECT * FROM  .NET端 SqlBulkCopy大量複製進來的(#TEMP)Temporary Table

• (方案1)Table variable (user type)
• (方案2)Temporary table

最近大型資料表要進行歷史資料封存，為了使線上交易持續正常運作，
選用 A.小量分批刪除 + B.關閉擴大鎖定方案，但執行時間需要數小時，不太符合效能需求。

想到刪除資料量比保留的多，於是靈光一現，改採以前主機常用的哪招:

A.先建立只有保留資料的新資料表

B.再改名來減少封存執行的時間。

BIG5-難字

鍵入BIG-5造字，寫入BIG-5造字對應中文內碼到資料庫中。

Execute Current Statement

要將BIG5中被定義成難字但Unicode中有支援的系統字寫入資料庫，筆記兩個關鍵:

• 寫入值時的前置詞N(表示Unicode)
• 資料庫欄位資料型別NCHAR、NVARCHAR(Unicode)