调整插入和数据负载的HANA性能

参见1999998，如果需要，优化锁等待情况。插入必须等待锁的典型情况是:

• 重要的保存点阶段
• 同一主键的并发插入
• SAP HANA内部锁
• 同一表上的DDL操作已激活

Columns

在插入期间，必须分别维护每一列，因此插入时间在很大程度上取决于表列的数量。

Indexes

每个现有索引都会减慢插入操作的速度。检查是否可以在大量插入和数据加载期间减少索引的数量。SAP BW提供了在数据加载期间自动删除和重新创建索引的可能性。主索引通常不能被删除。

Bulk load

如果加载了大量记录，就不应该对每条记录执行插入。相反，您应该尽可能利用批量加载选项(即使用单个插入操作插入多个记录)。

Parallelism

如果加载了大量记录，则应该考虑客户端上的并行性，以便使用到SAP HANA的多个连接来加载数据。

Commits

确保在执行大规模插入时定期执行COMMIT (after each bulk of a bulk load)。

Delta merge

大的增量存储会降低负载性能，所以要确保定期执行增量合并。

避免重复合并小的增量存储或使用大量未提交的数据，以避免不必要的开销。

Table vs. record lock

如果只可能进行一次非并行插入，并且不需要对底层表进行并发更改，那么使用全局表锁而不是大量的单独记录锁可能会很有用。表锁可以通过以下方式设置:

LOCK TABLE " " IN EXCLUSIVE MODE

之后，SAP HANA不再需要维护单独的记录锁。这种方法也适用于INSERT…选择可以在内部并行化的操作。

Savepoints

需要保存点将修改后的数据写入磁盘。通常的主要意图是尽可能缩短阻塞保存点阶段，同时接受较长的保存点持续时间。在大量导入期间，相反的情况可能更好:保存点更短，阻塞阶段增加的风险更大。较短的保存点可以减少写入磁盘的数据量，还可以减少需要保留的日志量，从而降低文件系统溢出的风险。

在大量更改期间，可以考虑以下参数调整来减少总体保存点持续时间:

• lower values for global.ini -> [persistence] -> savepoint_max_pre_critical_flush_duration (e.g. 300 instead of 900)
• higher values for global.ini -> [persistence] -> savepoint_pre_critical_flush_retry_threshold (e.g. 10000 instead of 3000)

Bugs

以下SAP HANA bug可能会对插入性能产生负面影响:

Impacted RevisionsDetails 1.00.120 - 1.00.122.11

2.00.000 - 2.00.012.00如果大量的空间数据是在没有提交的情况下逐行插入的，那么由于SAP HANA bug和调用堆栈模块AttributeEngine::spatialae::DeltaComponents::reserveDocid所花费的大量时间，性能可能会很差。作为“GeometryDeltaAttribute锁”上的次要影响争用是可能的。

（编辑：广元站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!