使用SQL Server作爲源時的AWS DMS限制 - 複製具有超過8000字節信息的行

我正在考慮在Amazon RDS中使用它們的DMS從現場數據庫中複製數據來創建只讀數據庫。對一般限制亞馬遜DMS列表，其中之一是：使用SQL Server作爲源時的AWS DMS限制 - 複製具有超過8000字節信息的行

變化與超過8000個字節的信息，包括標題和映射信息行，不正確由於在SQL Server TLOG緩衝限制處理尺寸。

在什麼情況下適用？我的印象是一個表最多可以包含每行8,060個字節。據我所知，varchar，nvarchar,varbinary,sql_variant，或CLR用戶定義的類型被推入另一行，其中有一個指針。這是指什麼？我試圖瞭解會發生這種情況的任何情況。

另外，如何確定哪些表（如果有的話）會受到影響？

來源

2017-09-06 TheTor

這段文字看起來像hogwash給我的。限制將來自亞馬遜自己的技術，而不是SQL Server。特別是，顯然SQL Server允許通過溢出存儲更新佔用更多字節的行，並且事務日誌沒有問題。作者可能意思是「由於我們從事務日誌中吮吸數據的方式，如果行更改佔用的不止一頁，我們就無法做到這一點」，但不清楚實際的實際影響是什麼 - 如果只有某些更新或某些表的全部更新不會被複制。 –

這很可能是真的。要清楚，我並不是說那些數據類型的行不會被複制。我只是試圖找出上述情況在什麼情況下。如果一行不能超過8060字節，爲什麼這甚至是AWS DMS的限制？ – TheTor

這不是在談論行大小，而是在談論事務日誌緩衝區的限制（無論這些限制是什麼）。行內數據不能超過8060字節，但可能與此處討論的限制無關。如果你想要一個明確的答案，直接詢問亞馬遜可能比等待專家出現在SO上更有建設性。這裏討論的「複製」與SQL Server中的複製功能沒有任何關係。 –

好的，現在我似乎可以回答我自己的問題了，至少在一個用例中。

它與組合列的可能大小無關，但如前所述，它們中的數據量相關。用一個id和9個varchar（1000）列創建一個表。用第一個8字節填充1000字節，並且所有內容都按照原樣複製。用數據填充剩餘的列，並且不會複製更新（可能是因爲列數據被推出頁面）。奇怪的是，varchar（max）似乎沒有受到這種方式的影響。

定位與受此影響行的表，運行以下，開始重視MaximumRecordSize柱：

dbcc showcontig with tableresults

解決該問題的方法是你的問題的表分割成較小的相關表（又名規範化它），並執行連接來檢索數據。根據數據庫的大小，這可能也可能不可行。

來源

2017-09-13 10:09:53 TheTor

使用SQL Server作爲源時的AWS DMS限制 - 複製具有超過8000字節信息的行

回答

相關問題