資料分頁(Data Page)中的剩餘空間(m_freeCnt)是如何計算出來的?

常常聽說,也常常看到書上這樣寫,一個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的示意圖如下:

...繼續閱讀 »

設定多因素驗證(MFA),讓Azure帳戶的使用多一層保障(以簡訊來傳送驗證碼為範例)

多因素驗證(Multi-Factor Authentication,MFA)可以讓我們在登入Azure時,除了可以在第一層驗證使用者帳號跟密碼外,還可以再加上第二層的驗證(如:簡訊、電話語音、應用程式密碼),讓帳戶的使用更具安全性。以下我們將以設定簡訊為例,於登入時由系統主動送出一次性密碼,並提示使用者在登入Azure的畫面上輸入此密碼。

...繼續閱讀 »

透過備份及還原資料庫來初始化交易式複寫的訂閱

 一般透過複寫精靈來設定交易式複寫時,都會選擇透過快照集代理程式(Snapshot Agent)來產出快照,然後藉由散發代理程式(Distribution Agent)來初始化訂閱的資料,這種方式確實是方便省事,而且當你產出快照集到訂閱被新增,這中間的資料異動,交易式複寫機制都會自動幫你補上去,然而當要複寫的資料量大到上百GB,甚至是TB時,同步資料到訂閱者所耗費的時間將會相當長,更遑論如果是跨國同步資料的情境。

...繼續閱讀 »

交易式複寫若常常執行大量資料的更新,用預存程序處理或許也是另一個可以考慮的選項

拜讀了楊志強老師在FB上的一篇文章【管理 Life Saver 】之 【拯救交易式複寫問題之未遞送大量交易20170311】,老師使用了(1)關閉Log Reader讓Distributor先遞送,以及(2)調高遞送量這兩個步驟,漂亮的解決了大量交易所造成的複寫堵車問題,心想若複寫能搭配使用預存程序來更新大量資料的話,能否改善此類問題?

...繼續閱讀 »