本篇介紹SQL Server on Linux主體環境的設定，當我們安裝好mssql-server、mssql-tools等套件，也使用"/opt/mssql/bin/mssql-conf setup"指令來安裝、設定及啟動mssql-server服務後，後續可能還需要異動一些設定，如：啟動Agent Service服務、修改預設的備份路徑、變更SQL Server版本等，此時有三種方式可以參考 -- 使用參數指令、使用參數設定檔、使用環境變數
在本篇介紹SQL Server on Linux的Database Mail設定，其實設定方式跟在Windows的版本差不多，只是這裡將自行額外安裝postfix套件來設定Mail Server，擔任MTA(Mail Transfer Agent)的角色，並嘗試設定兩種郵件設定檔(Profile)，即"公開性質"跟"私人性質"兩種，另外，將在sqllnx1及sqllnx2分別使用【UI介面】及【T-SQL】兩種方式分別建置Database Mail。
本篇來記錄一下如何在兩個SQL Server on Linux的Container之間共用同一個Docker Volume，藉以分享檔案(例如: 資料庫備份檔)，另外，同時也都可以擁有各自的Volume，用來保存自己所屬的SQL Server資料庫檔案。
在前一篇【在容器中備份及還原SQL Server資料庫，以及資料磁碟區容器(Docker Volume)的初步應用】有提到利用Docker Volume來保存container上所儲存的SQL Server資料及檔案，這是由於image只是一個檔案，不是程序，裡面封裝了要產生容器時的所有層層資訊，且image只能唯讀；而container不太一樣，container依據image產生，一個image可以建立多個container，很像程式中[class(類別)]與[object(物件)]的關係，但container是可以讀/寫的，所以container一旦被刪除，裡面的資料也會跟著消失，所以才會需要利用Docker Volume來保存資料。本篇將介紹兩種保存SQL Server資料庫檔案的方式，最後亦嘗試搭配MSSQL_DATA_DIR環境變數來變更容器中SQL Server的"預設資料目錄"(即 /var/opt/mssql/data)。
接續上一篇【SQL Server on Container起手式】，這篇來實作Linux主機與container之間(或container與container之間)相互備份/還原SQL Server資料庫，以及資料磁碟區容器(Docker Volume)的初步應用。
這篇文章主要為了對學習的內容留個大概的記錄，方便日後查詢，因前一陣子對單位內部做分享，故稍微研究了一下SQL Server on Linux的安裝，在排定講授內容時，想說反正都是使用Linux環境，就順便把SQL Server on Container的應用一併納入。
本篇主要試著拆解Data Page中的Data Record，並大致說明主要會分成哪幾個部分，先前在"資料分頁(Data Page)中的剩餘空間(m_freeCnt)是如何計算出來的?"內文中，有提到關於Row Overhead的部分，所以文章最後一併指出哪些部分會被視為Row Overhead。
常常聽說，也常常看到書上這樣寫，一個Page有8K，即8192 Bytes，而能夠用來儲存資料的空間為8060 Bytes，這是因為必須扣除Page Header占用的96 Bytes，以及Page尾端的Row Offset所保留使用的36 Bytes(此數據可能會因record的數量而有所變動)，所以8192 Bytes - 96 Bytes - 36 Bytes=8060 Bytes，一個簡單Page Structure的示意圖如下：
一位好友Marty想在SSRS寫一段累加欄位值的T-SQL語法，希望查詢結果如下表所示，SUMAMT是計算後的欄位，查詢微軟官網文件，若是資料庫版本為SQL Server 2012(含)以上，則可以撰寫OVER子句並加上SUM函數，來達到此目的。
此案例剛好發現觸發程序(trigger)對合併式複寫(merge replication)與交易式複寫(transaction replication)的影響。
朋友Mike使用SQL Server 2008的SQL Server Management Studio (SSMS)欲連線SQL Server 2005去修改sa管理員帳號的密碼，卻出現下列錯誤代碼15535：｢無法設定主體’sa’的憑證｣。
於SQL Server欲修改登入(Login)所對應的某個DB的使用者(User)時，出現錯誤｢無法改變使用者’dbo’，錯誤 15150｣。
前幾天遇到跟複寫相關的錯誤[ 無法卸除資料庫 'ooxx'的問題，因為它已用來複寫。 (Microsoft SQL Server, 錯誤: 3724) ]，先暫時筆記一下。
在前一篇文章【透過備份及還原資料庫來初始化交易式複寫的訂閱】中，談到利用資料庫備份檔來處理交易式複寫的訂閱初始化，緊接著來說明當發行者(Publisher)新增了一個資料表，且欲加入發行集(Publication)時，我們該如何來進行。
一般透過複寫精靈來設定交易式複寫時，都會選擇透過快照集代理程式(Snapshot Agent)來產出快照，然後藉由散發代理程式(Distribution Agent)來初始化訂閱的資料，這種方式確實是方便省事，而且當你產出快照集到訂閱被新增，這中間的資料異動，交易式複寫機制都會自動幫你補上去，然而當要複寫的資料量大到上百GB，甚至是TB時，同步資料到訂閱者所耗費的時間將會相當長，更遑論如果是跨國同步資料的情境。
拜讀了楊志強老師在FB上的一篇文章【管理 Life Saver 】之 【拯救交易式複寫問題之未遞送大量交易20170311】，老師使用了(1)關閉Log Reader讓Distributor先遞送，以及(2)調高遞送量這兩個步驟，漂亮的解決了大量交易所造成的複寫堵車問題，心想若複寫能搭配使用預存程序來更新大量資料的話，能否改善此類問題？