處理 BATCHSQL 中 Google Spanner Replicat 作業的錯誤

將 BATCHSQL 與 Google Spanner 搭配使用時，下列錯誤由 GoldenGate Replicat 管理：

INSERT：重複的索引鍵錯誤
UPDATE/DELETE：找不到資料列錯誤
主鍵更新：找不到鍵值錯誤，新鍵值已存在錯誤

如果任何 DML 作業因這些錯誤而失敗，預設會中止交易並中止 Replicat。如果使用者已啟用 HANDLECOLLISIONS、OVERRIDEDUPS、INSERT_MISSING_UPDATES 或任何其他 REPERROR 規則，則會重試、略過或修改，然後執行 DML 來解決錯誤。

如果有任何 DML 作業因任何其他錯誤而失敗，則會中止交易並中止 Replicat。或者，根據 REPERROR 規則，Replicat 會中止並重試整個交易。

Cloud Spanner 中的 RESOURCE_EXHAUSTED 錯誤通常表示已超過變化數或交易大小總計的交易限制。發生與下列類似的錯誤，建議減少 MAXTRANSOPS 或 BATCHTRANSOPS。

Error: Operation failed on Spanner database due to quota, session limit, or batch size limit error:

Poosible causes :
BATCH LIMIT: Transaction >80,000 mutations or >100 MiB
QUOTA LIMIT: Spanner API quota exhausted (rate-limited)
SESSION LIMIT: Max concurrent sessions (100,000+) exceeded

Action:
For BATCH LIMIT: Reduce batch size or reduce MAXTRANSOPS and restart Replicat.
For QUOTA LIMIT: Increase Spanner quota in Google Cloud Console and restart Replicat.
For SESSION LIMIT: Reduce concurrent sessions to the Spanner and restart Replicat.
Retry using REPERROR with TRANSABORT, MAXRETRIES 5, DELAYSECS 1 is suggested.

使用 Spanner Mutation API

在「跨度」套用 DML 時，需要參數 BATCHSQL USEMUTATIONS 以提高效率，稱為「跨度突變」。

這表示 ExecuteBatchDml 對於起始載入原始內建值資料而言最具吸引力，其中的作業主要是相同表格的連續插入。

對於混合即時 DML 的一般工作負載，BATCHSQL USEMUTATION 模式可提供較佳的效能測量結果。

使用 BATCHSQL 的 USEMUTATIONS 選項時的作業限制

使用 Spanner 突變時，存在下列限制：

衝突統計資料：衝突統計資料不完整，因為確認階段變化結果無法識別有效更新的插入數目，或有效插入的遺漏資料列更新數目或略過的更新 / 刪除作業數目。
DML 層次 REPERROR 動作：使用 Spanner Mutations 時，REPERROR 動作無法套用至 BATCHSQL 模式的個別 DML 敘述句，因為 Spanner 不會傳回緩衝的變化敘述句層次結果，而且會在確認時收到整個交易的錯誤。
遺漏資料列刪除作業：Spanner DeleteMutation 語意會略過遺漏資料列的刪除作業，因此不同於其他具有 USEMUTATIONS 的資料庫 BATCHSQL 在遺漏資料列刪除作業時，一律會傳回成功。
主索引鍵更新回復為一般模式：Replicat 會回到一般模式，對於任何包含主索引鍵更新的交易，只要遇到主索引鍵更新，就會以傳統模式重試。

雖然 Spanner Mutation 行為不會因這些限制而變更，但可能會導致效能降低。

BATCHSQL 模式與 USEMUTATIONS 的行為

以下是每個 GoldenGate BATCHSQL 模式對應至「跨度」變化類型的摘要：

預設情況：

1.1. 插入：如果重複鍵插入，則交易應失敗，且只有在確認時才會傳回錯誤。

1.2. 更新：遺失資料列更新時交易應失敗，且只有在確認時才會傳回錯誤。

1.3. 刪除：如果資料列為 NOT_FOUND，則略過刪除
HANDLECOLLISIONS/OVERRIDEDUPS:

2.1. 插入：如果發生重複索引鍵錯誤，應將插入轉換為更新，且僅在確認時傳回錯誤，且不會有任何 PK 衝突統計資料。

2.2. 更新：發生遺漏資料列錯誤時，應略過更新。
```
 **NOTE:** Spanner locks the row for that specific primary key using Replicat transaction even if it does not exist, which means that Spanner would not allow any other transaction to INSERT that row until Replicat transaction is committed or aborted.  
 {: .infoboxnote}
```
2.3. 刪除項目：如果資料列為 NOT_FOUND，DELETEMUTATION 會略過刪除。
插入遺漏的更新項：

3.1. 插入：如果重複鍵插入，則交易應失敗，且只有在確認時才會傳回錯誤。

3.2. 更新：若發生遺漏資料列錯誤，更新應插入資料列，且只有在確認時間才會傳回錯誤。