將數據從時態表載入到 Azure 中的另一個時態表
目前，我們只有一個實時數據庫，所有數據都駐留在其中。我為開發創建了一個單獨的 Azure 伺服器和數據庫。DEV DB 應該與 Live DB 保持同步，供開發人員使用。
Live DB 具有時間或系統版本表。我需要一個將實時時態表中的數據同步到 DEV 時態表的過程。它應該將 Live temporal 表中的 sysStartTime 和 sysEndTime 載入到 dev（不應在 DEV 中生成新的 sysStartTime 和 endTime）。
這樣做的最佳方法是什麼？
我已經嘗試過 Azure 數據同步，但它不支持時態表。請幫忙。
這裡有兩個互動問題：在 Azure 數據庫之間傳輸數據，以及更新由系統版本控制維護的數據。可能還有第三個：開發中的實時數據。
在 Azure 中傳輸數據
如果 Azure 數據同步不合適，則可以考慮其他選項。
- 您也許可以使用 SSIS 包或其他 ETL 選項將數據從 A 轉移到 B。
- 連結表的支持方式與本地 SQL Server 不同，但您可以使用“外部表”作為替代方案。
- 彈性數據庫作業提供了一種從一個數據庫查詢數據並將其寫入另一個數據庫的方法，儘管這更適用於記錄日誌而不是更完整的數據傳輸，因此以這種方式使用它感覺有點 hacky。
更新歷史表
無論您使用什麼方法將數據從一個數據庫傳輸到另一個數據庫，您都面臨需要直接操作歷史數據的問題。正如您所注意到的，系統版本表保護自己免受此類修改：您根本不能直接修改歷史表或指定基表中為修改記錄的時間。
你必須為每張桌子做的是：
- 關閉系統版本控制：
ALTER TABLE schema.table SET(SYSTEM_VERSIONING = OFF); ALTER TABLE schema.table DROP PERIOD FOR SYSTEM_TIME;- 對基表和歷史表進行所需的更改
- 重新啟動歷史跟踪：（
ALTER TABLE schema.table ADD PERIOD FOR SYSTEM_TIME (SysStartTime, SysEndTime); ALTER TABLE schema.table SET(SYSTEM_VERSIONING = ON);您可能需要添加其他選項，具體取決於您的表目前的設置方式，例如，如果您的表不使用預設命名約定）。因此，您的整個過程可能分為四個階段：從源獲取更新的數據、關閉歷史跟踪、更新目標數據、打開歷史跟踪。當最後三個階段發生時，您需要阻止對目標數據庫的其他訪問，否則可能導致歷史數據損壞。
選擇
根據數據庫的大小和開發工作流程的性質，每次需要刷新其他副本時，簡單地備份和恢復完整的新副本可能要容易得多。
無論如何，您可能都希望使用數據庫的恢復副本，以消除可能減慢應用程序生產實例的額外 IO 負載，輕鬆確保獲得準確的數據快照而無需持有許多鎖，或允許一個完整的人格解體過程（見下文）。
開發中的實時數據
與您問題的技術問題無關，這可能是數據保護和安全 PoV 的問題。如果您的應用程序包含任何個人身份辨識資訊或其他敏感資訊，那麼這是一個很大的“不”。
如果您確實直接從 Live 系統中獲取數據進行開發，那麼您應該正在“去個性化”。這通常更容易使用整個數據庫備份+恢復方法可靠地完成：在生產中複製數據庫，取消個性化副本，備份，轉移到開發伺服器，刪除生產伺服器上現在不需要的副本。
在開發過程中生成範例數據通常比嘗試使用生產數據更好。這樣一來，任何去個性化過程中的問題都不會讓您面臨安全問題（如果您與要求您接受審計的公司合作，也不會導致審計失敗），因為您永遠不會意外地更改實時數據。如果設計得當，此測試數據可能比真實數據更有用，因為您可以確保它包含所有預期的邊緣情況（以及一些意想不到的情況！），因此它成為您的開發和測試過程的一部分。
當您無法使用其他數據重現報告的問題時，您可能需要偶爾複製生產數據以進行調試，但這種測試與開發不同，應該是最後的手段而不是第一個停靠點。