.replace extents 命令
此命令會在特定資料庫的內容中執行。 其會將指定的範圍從來源資料表移至目的地資料表,然後從目的地資料表中卸除指定的範圍。 所有卸除和移動作業都是使用單一交易所完成。
注意
數據分區稱為 「範圍」,而且所有命令都會使用「範圍」或「範圍」作為同義字。 如需範圍的詳細資訊,請參閱範圍 (資料分區) 概觀。
權限
您必須至少擁有來源和目的地數據表的資料表 管理員 許可權。
限制
- 來源和目的地資料表都必須在內容資料庫中。
- ExtentsToDropQuery 所指定的所有範圍都預期屬於目的地數據表。
- 來源資料表中的所有資料行都應該存在於具有相同名稱和資料類型的目的地資料表中。
- 如果目的地數據表是 具體化檢視的源數據表,命令可能會失敗,因為具體化檢視不會處理移動範圍中的記錄。 如需詳細數據,請參閱 具體化檢視限制 頁面。 您可以在移動命令期間設定新的擷取時間,以因應此錯誤。 請參閱
setNewIngestionTime
支持的屬性。
Syntax
.replace
[async
] extents
in
table
DestinationTableName [ with
(
PropertyName=
PropertyValue [,
...])
] <|
{
ExtentsToDropQuery},{
ExtentsToMoveQuery}
深入瞭解 語法慣例。
參數
名稱 | 類型 | 必要 | Description |
---|---|---|---|
async |
string |
如果指定,命令會以異步方式執行。 | |
DestinationTableName | string |
✔️ | 要移動範圍之數據表的名稱。 |
FromDate | datetime |
查詢視窗開始日期。 | |
ToDate | datetime |
查詢窗口結束日期。 | |
PropertyName、 PropertyValue | string |
一或多個 支持的屬性。 | |
ExtentsToDropQuery | string |
✔️ | 此查詢的結果會指定應該從目的地數據表卸除的範圍標識碼。 應該傳回具有名為 「ExtentId」 資料行的記錄集。 |
ExtentsToMoveQuery | string |
✔️ | 此 Kusto 查詢語言 (KQL) 查詢的結果會指定要移至目的地數據表的源數據表和範圍識別碼。 應該傳回名為 「ExtentId」 和 「TableName」 資料行的記錄集。 |
支援的屬性
屬性名稱 | 類型 | 必要 | Description |
---|---|---|---|
setNewIngestionTime |
bool |
如果設定為 true ,則會將新的 擷取時間 指派給移動範圍中的所有記錄。 當工作負載應該處理相依於 資料庫數據指標的記錄時,例如 具體化檢視 和 連續數據匯出,這非常有用。 |
|
extentCreatedOnFrom |
datetime |
✔️ | 套用在此時間點之後建立的範圍。 |
extentCreatedOnTo |
datetime |
✔️ | 套用至在此時間點之前建立的範圍。 |
注意
為了提升效能,請將 extentCreatedOnFrom 和 extentCreatedOnTo 參數設定為最小可能的範圍。
傳回
當命令以同步方式執行時,會傳回具有下列架構的數據表。
輸出參數 | 類型 | 描述 |
---|---|---|
OriginalExtentId | string |
下列範圍的唯一識別碼 (GUID):來源資料表中已移至目的地資料表的原始範圍,或目的地資料表中已卸除的範圍。 |
ResultExtentId | string |
已從來源資料表移至目的地資料表的結果範圍的唯一識別碼 (GUID)。 如果已從目的地資料表中卸除範圍,則為空白。 失敗時:「失敗」。 |
詳細資料 | string |
如果作業失敗,則包含失敗詳細資料。 |
當命令以異步方式執行時,會傳回作業標識碼 (GUID) 。 使用 .show operations 命令監視作業的狀態,並使用 .show 作業詳細 數據命令擷取成功執行的結果。
注意
如果 ExtentsToDropQuery 查詢傳回的範圍不存在於目的地數據表中,此命令將會失敗。 如果已在執行 replace 命令之前合併範圍,則可能會發生這種情況。 若要確定命令在遺漏範圍上失敗,請檢查查詢是否傳回預期的 ExtentId。 如果要卸除的範圍不存在於資料表 MyOtherTable 中,則下面的範例 #1 將會失敗。 不過,範例 #2 即使要卸除的範圍不存在也會成功,因為要卸除的查詢未傳回任何範圍識別碼。
範例
從兩個數據表移動指定建立時間範圍中的所有範圍
將所有範圍從兩個特定數據表 (MyTable1
移動, MyTable2
) 在指定的建立時間範圍內移至數據表 MyOtherTable
,並以 卸除標記drop-by:MyTag
中的所有範圍MyOtherTable
:
.replace extents in table MyOtherTable with (extentCreatedOnFrom=datetime(2023-03-10), extentCreatedOnTo=datetime(2023-03-12)) <|
{
.show table MyOtherTable extents where tags has 'drop-by:MyTag'
},
{
.show tables (MyTable1,MyTable2) extents
}
範例輸出
OriginalExtentId | ResultExtentId | 詳細資料 |
---|---|---|
e133f050-a1e2-4dad-8552-1f5cf47cab69 | 0d96ab2d-9dd2-4d2c-a45e-b24c65aa6687 | |
cdbeb35b-87ea-499f-b545-defbae091b57 | a90a303c-8a14-4207-8f35-d8ea94ca45be | |
4fcb4598-9a31-4614-903c-0c67c286da8c | 97aafea1-59ff-4312-b06b-08f42187872f | |
2dfdef64-62a3-4950-a130-96b5b1083b5a | 0fb7f3da-5e28-4f09-a000-e62eb41592df |
將指定建立時間範圍中的所有範圍從一個數據表移至另一個數據表,卸除特定範圍
將指定建立時間範圍中的所有範圍從一個特定資料表 () MyTable1
移至資料表 MyOtherTable
,然後依標識元卸除 中的 MyOtherTable
特定範圍:
.replace extents in table MyOtherTable with (extentCreatedOnFrom=datetime(2023-03-10), extentCreatedOnTo=datetime(2023-03-12)) <|
{
print ExtentId = "2cca5844-8f0d-454e-bdad-299e978be5df"
},
{
.show table MyTable1 extents
}
.replace extents in table MyOtherTable with (extentCreatedOnFrom=datetime(2023-03-10), extentCreatedOnTo=datetime(2023-03-12)) <|
{
.show table MyOtherTable extents
| where ExtentId == guid(2cca5844-8f0d-454e-bdad-299e978be5df)
},
{
.show table MyTable1 extents
}
實作等冪邏輯
實作等冪邏輯,讓 Kusto 只有在有範圍可從資料表 t_source
移至資料表 t_dest
時,才從資料表 t_dest
中卸除範圍:
.replace async extents in table t_dest with (extentCreatedOnFrom=datetime(2023-03-10), extentCreatedOnTo=datetime(2023-03-12)) <|
{
let any_extents_to_move = toscalar(
t_source
| where extent_tags() has 'drop-by:blue'
| summarize count() > 0
);
let extents_to_drop =
t_dest
| where any_extents_to_move and extent_tags() has 'drop-by:blue'
| summarize by ExtentId = extent_id()
;
extents_to_drop
},
{
let extents_to_move =
t_source
| where extent_tags() has 'drop-by:blue'
| summarize by ExtentId = extent_id(), TableName = 't_source'
;
extents_to_move
}
意見反應
https://aka.ms/ContentUserFeedback。
即將登場:在 2024 年,我們將逐步淘汰 GitHub 問題作為內容的意見反應機制,並將它取代為新的意見反應系統。 如需詳細資訊,請參閱:提交並檢視相關的意見反應