注意:

套用此熱修復程式後,您必須在擁有512個位元組物理磁區大小並重新啟動的所有伺服器或複本上啟用追蹤標誌1800作為啟動參數,以使此修復程式正常運作。

徵狀

請試想下列情況:

  • 您可以在 Microsoft SQL Server 中啟用 AlwaysOn 可用性群組或 Logshipping 功能。

  • 儲存 AlwaysOn 可用性群組(AG)中主要和次要複本之記錄檔的磁片是不同的磁區大小。 或者,在 Logshipping 環境中,將 Logshipping 主要伺服器和 Logshipping 次要伺服器的記錄檔案儲存在不同磁區大小的磁片。 例如:

    • 主要複本記錄檔位於磁區大小為512位元組的磁片上。 不過,次要複本記錄檔位於磁區大小為 4 kb 的磁片上。

    • 主要複本記錄檔位於內部部署的本機系統,其磁區大小為512位元組。 不過,副複本位於其磁區大小為 4 kb 的 Windows Azure 儲存空間磁片上。

在這種情況下,會在 SQL Server 錯誤記錄中記錄下列錯誤訊息。 如果在重新開機伺服器之前,沒有已將記錄套用至次要,則錯誤訊息可能會在重新開機後繼續進行。

已有 X 個未對齊的記錄 IOs,需要回退到同步 IO。 目前的 IO 為 [檔案 ...]。

此外,由於同步處理 i/o,AG 或 Logshipping 同步處理執行速度非常緩慢。 如果次要複本是在 Windows Azure 儲存空間中,則會花費比預期更長的時間來完成同步處理常式。 注意: 當您同時使用具有 4 KB 磁區大小的新磁片磁碟機,以及具有512個位元組磁區大小的舊磁片磁碟機時,就會發生此問題。 如需新磁片磁碟機的詳細資訊,請參閱 SQL Server-新磁片磁碟機使用4k 磁區大小SQL Server – Storage spaces/VHDx 和4k 磁區大小

 

每個新的 SQL Server 累計更新都包含所有的修正程式,以及前一個累積更新中所包含的所有安全性修正程式。 請參閱 SQL Server 的最新累計更新:

因應措施

若要解決此問題,請將事務日誌檔移至目的地,並將 [ 每個物理磁區 ] 設定為512位元組的磁片磁碟機。

狀態

Microsoft 已確認<適用於>一節中所列的 Microsoft 產品確實有上述問題。

其他相關資訊

最佳做法是,請務必確認所有複本的磁片(至少是主機記錄檔案的所有磁片)都有相同的磁區大小。 在混合式環境中,第二個實體的物理磁區是512位元組,主要是 4 KB 的磁區大小,TF 1800 應該在具有512位元組物理磁區大小及重新開機的所有伺服器或複本上做為啟動標誌 。 這可確保正在進行的記錄建立格式使用 4 KB 磁區大小。 如需有關 SQL Server 如何搭配較大磁區大小使用的詳細資訊,請參閱支援博客上的下列文章: SQL Server –儲存空間/VHDx 與4k 磁區大小 您可以使用 Fsutil 命令提示字元實用程式 來判斷 每個物理磁區值的位元組數。 如果在輸出中看不到這個參數,您必須套用在 知識庫文章 982018中指定的熱修復程式。 若要驗證您擁有的磁片磁碟機類型,請遵循下列步驟:

  1. 在提升許可權的命令提示字元執行下列命令:

    Fsutil fsinfo ntfsinfo x: 注意: X 預留位置代表您要檢查的磁片磁碟機。

  2. 使用 每個磁區的位元組 值和 每個物理磁區的位元組數 ,以判斷您擁有的磁片磁碟機類型。 若要這樣做,請使用下表:

    "每個磁區的位元組數" 值

    「每個物理磁區的位元組數」值

    磁片磁碟機類型

    4096

    4096

    4K 原生

    512

    4096

    [高級格式] (也稱為512E)

    512

    512

    512-位元組原生

Need more help?

Expand your skills
Explore Training
Get new features first
Join Microsoft Insiders

Was this information helpful?

How satisfied are you with the translation quality?
What affected your experience?

Thank you for your feedback!

×