为 Google Spanner 复制操作处理 BATCHSQL 中的错误

将 BATCHSQL 与 Google Spanner 结合使用时，以下错误由 GoldenGate Replicat 管理：

INSERT：关键字错误重复
UPDATE/DELETE：未找到行错误
主关键字更新：未找到关键字错误，新关键字已存在错误

如果任何 DML 操作失败并出现其中任何错误，默认情况下将中止事务处理并异常终止复制。如果用户启用了 HANDLECOLLISIONS、OVERRIDEDUPS、INSERT_MISSING_UPDATES 或任何其他 REPERROR 规则，则它将重试、跳过或修改，然后运行 DML 以解决错误。

如果任何 DML 操作失败并出现任何其他错误，则事务处理将中止，复制将异常终止。或者，基于 REPERROR 规则，复制将中止并重试整个事务处理。

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 突变 API

在 Spanner（名为 Spanner Mutations）中应用 DML 时，需要使用参数 BATCHSQL USEMUTATIONS 来提高效率。

这意味着对于初始加载种子数据，ExecuteBatchDml 最具吸引力，因为这些数据中的操作主要是同一表的连续插入。

对于具有混合实时 DML 的通用工作负载，BATCHSQL USEMUTATION 模式可提供更好的性能度量。

使用 BATCHSQL 的 USEMUTATIONS 选项时的操作限制

使用 Spanner Mutations 时存在以下限制：

碰撞统计信息：碰撞统计信息不完整，因为提交时变更结果无法确定实际变为更新的插入数、实际变为插入的缺失行更新数或跳过更新/删除操作数。
DML 级 REPERROR 操作：在使用 Spanner 突变时，REPERROR 操作无法应用于 BATCHSQL 模式下的各个 DML 语句，因为 Spanner 不会返回缓冲突变的语句级结果，并且在提交时会收到整个事务处理的错误。
缺少行删除操作：Spanner DeleteMutation 语义跳过对缺失行的删除操作，因此与其他数据库不同，具有 USEMUTATIONS 的 BATCHSQL 在缺少行删除操作时将始终返回成功。
PK 更新回退到正常模式：复制将恢复到正常模式，对于包含主键更新的任何事务处理，一旦遇到 PK 更新，将立即以经典模式重试。

尽管 Spanner Mutation 行为不会因这些限制而改变，但可能会导致性能下降。

使用 USEMUTATIONS 的 BATCHSQL 模式的行为

以下是每个 GoldenGate BATCHSQL 模式如何映射到 Spanner 突变类型的摘要：

默认案例：

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. 更新：更新应在缺少行错误的情况下插入行，并且错误仅在提交时返回。