OceanBase 数据库 TPCH ACID 测试
TPC-H ACID 测试是 TPC-H 基准测试中一个至关重要的非性能部分，它用于验证被测系统（SUT）是否满足数据库事务处理所必需的 ACID 属性（原子性、一致性、隔离性、持久性）。由于 TPC-H 本身是一个决策支持（分析型）基准，其主测试流程不包含事务处理，因此 ACID 测试被设计为在非计时部分进行，专门用于证明系统在事务处理方面的正确性。OceanBase 的测试情况可在 OceanBase 的 TPC Benchmark™ H Full Disclosure Report 文档查到。
本文将按照 OceanBase 社区中的 TPCH ACID 测试实战话题的步骤进行复现。
TPCH ACID 测试流程
首先下载 tpch 相关脚本，拷贝到虚拟机上。
解压到指定目录。
接着修改 config.sh，需要将 TPCHDIR 修改成相应的目录。
修改数据库连接信息，包括 DBNAME、TPC_USER、TPC_TENANT。
由于我重置了 test 租户的 root 用户的密码，但是 run_acid.sh 脚本中并没有给出传递 password 的参数，所以自己加上就行。
“4.3-重新编译 acid 的 binary”步骤中，由于对应目录下的都有编译好的文件了，例如下图所示的“acidtransaction”文件，所以可以直接跳过，不用编译。
接着修改默认配置项和系统参数，tpch acid 依赖prepare statement默认打开。
obclient -h192.168.195.138 -P2881 -uroot@sys -p'e4rweynF03+=W9c+WqdWgS8nq~OwAa' -A -Dtest -e "alter system set _ob_enable_prepared_statement = True;"
同时部分语句查询结果返回较慢，需要调大默认超时时间。
obclient -h192.168.195.138 -P2881 -uroot@test -p'aaAA11!!' -A -Dtest -e "set @@global.ob_query_timeout = 100000000;"
接着运行 run_acid.sh 脚本，运行时输出了“权限不够”的信息。
使用 chmod 命令修改权限就行，因为使用的是虚拟机，所以可以直接给目录下的所有文件设置读、写和执行权限。当然已经上线的项目就不能这么搞，需要谨慎一些，虚拟机的话随便弄。
find ./-exec chmod 777 {} +
再次运行，此时报了“ERROR 4179(HY000)”。也就是在进行 ACID 测试时需要先创建一张名叫“test.history”的表，如果这张表创建失败，下面的测试会因为这张表不存在也跟着报错。
在文档下面有人提出了解决方案，照做就行，主要问题是 tablegroup 的 partition 数与 acid 脚本中定义的不对等。
只要把这个脚本修改成我自己的设置就行。
再次运行，在运行 CONSISTENCY 测试时报“ERROR 1045(42000)”，又是认证信息有错。
在被调用的 check_consistency.sh 脚本中，把数据库连接的语句又写了一遍。由于这个地方用的变量是 TPC USER WITH TENANT，这个变量是“用户@租户”，不包括密码。
在被调用的 check_consistency.sh 脚本中，把数据库连接的语句又写了一遍。由于这个地方用的变量是 TPC USER WITH TENANT，这个变量是“用户@租户”，不包括密码。
所以如果重设了密码的话，还需要在这里把密码也提供一下。
排错完成后运行 run_acid.sh 进行 ACID 测试。
测试结果分析
原子性测试
TPCH 官方对 ATOMICITY 测试包括已完成事务的原子性、中止事务的原子性。
已完成事务的原子性的设置是对随机选择的一组输入数据执行 ACID Transaction，并验证 ORDERS、LINEITEM 和 HISTORY 表中是否更改了适当的行。执行以下操作来验证已完成事务的原子性：
- 随机选择一个订单键，然后从表 ORDERS 检索总价，从表 LINEITEM 检索扩展价。
- 使用选定的订单键执行一个事务。
- 事务已提交。
- 从表 ORDERS 中检索总价格，并从表 LINEITEM 中检索订单键的扩展价格。
- 经核实，行已被更改。
中止事务的原子性的设置是对随机选择的一组输入数据执行 ACID Transaction，用事务的 ROLLBACK 替换事务的 COMMIT。验证 ORDERS、LINEITEM 和 HISTORY 表中的适当行没有被更改。执行以下操作来验证终止的事务的原子性：
1、随机选择一个订单键，然后从表 ORDERS 检索总价，从表 LINEITEM 检索扩展价。
2. 使用选定的 order 键执行一个事务，事务在提交之前停止。
3. 事务被回滚。
4. 从表 ORDERS 中检索总价格，并从表LINEITEM中检索订单键的扩展价格。
5. 经核实，行未被更改。
从测试结果中可见 2 个 ATOMICITY 测试中第一项已完成事务的原子性测试没通过，第二项中止事务的原子性测试通过了。
一致性测试
CONSISTENCY 测试只有一个测试项，该测试项是验证 ORDERS 和 LINEITEM 表最初是一致的，使用随机选择的输入参数提交规定数量的 ACID Transactions，并重新验证 ORDERS 和 LINEITEM 的一致性。
在一致性测试之前和之后执行了以下查询，以证明数据库在初始和提交事务后都保持一致状态:
验证 ACID 事务一致性的操作如下：
- 验证了 ORDERS 和 LINEITEM 表的一致性。
- 对于 11 个执行流中的每个流，准备了 100 个事务。
- 对于所有 11 个执行流，执行准备好的 ACID 事务。
- 再次验证了 ORDERS 和 LINEITEM 表的一致性。
CONSISTENCY 测试只有一个测试项，测试没有通过。
隔离性测试
ISOLATION 测试有 6 项，分别是读-写提交冲突、读-写回滚冲突、写-写提交冲突、写-写回滚冲突、不同表上的并发读写事务、持续只读查询流中的更新事务。
隔离测试 1 是读-写提交冲突，测试了在提交读写事务时读写事务和只读事务的读写冲突的隔离。执行以下操作来测试：
- 启动查询并验证已检索行。
- 启动更新事务，读取和更新同一行。提交前停滞。
- 启动相同的查询并验证行没有更改。
- 提交更新事务。
- 启动查询并验证是否检索了新行。
隔离测试 2 是读-写回滚冲突，测试了回滚读写事务时读写事务和只读事务的读写冲突的隔离。执行以下操作来测试：
- 启动查询并验证已检索行。
- 启动更新事务，读取和更新同一行。提交前停滞。
- 启动相同的查询并验证行没有更改。
- 回滚更新事务。
- 启动查询并验证是否检索了旧行。
隔离测试 3 是写-写提交冲突，测试了当第一个事务提交时两个更新事务的写-写冲突的隔离。执行以下操作来测试：
- 用随机的 O_KEY 和 L_KEY 启动一个更新事务 T1，在 COMMIT 之前立即停止 T1。
- 使用相同的 O_KEY 启动一个更新事务 T2，验证 T2 被阻塞。
- Committed T1。T2 报告了一个关于“不能序列化”的错误并进行了回滚。
- 检索到同一行并验证 extended_price 已更新为 T1 中计算的值。
隔离测试 4 是写-写回滚冲突，测试了当第一个事务回滚时两个更新事务的 Write-Write 冲突的隔离。在第一个更新事务回滚后，执行以下操作来测试：
- 启动一个更新事务 T1，并在 COMMIT 之前立即停止 T1。
- 启动更新事务 T2。T2 被阻断。
- 回滚 T1。T2 完成并提交。
- 检索到同一行并验证 extended_price 已更新为 T2 中计算的值。
隔离测试 5 是不同表上并发读写事务，测试了影响不同数据库表的读写事务并发进行的能力。执行以下操作来测试：
- 启动查询并验证已检索行。
- 启动更新事务，读取和更新同一行。提交前停滞。
- 启动另一个执行以下操作的事务：选择 PS_PARTKEY 和 ps_supkey 的随机值。返回 PARTSUPP表中PS_PARTKEY 和 ps_supkey 等于所选值的所有列。
- 已验证读事务是否已完成。
- 提交更新事务。
- 启动相同的查询并验证是否检索到了新行。
隔离测试 6 是在连续只读查询流期间更新事务，测试了对数据库的一个或多个表连续提交任意(只读)查询不会无限期延迟影响这些表的更新事务。
使用以下查询语句：
执行以下操作来测试：
- 在资格数据库上执行上述查询的事务 T1 是使用随机 DELTA 启动的。
- 为随机选择的 O KEY、L KEY 和 DELTA 启动了一个事务 T2。
- 表 ORDERS、LINEITEM 和 HISTORY 中 T2 完整且适当的行已被更改。
- T1 仍然在执行。
- 事务 T1 完成了查询的执行。
ISOLATION 测试有 6 项，其中只有第 2 个测试项通过了，其他 5 个测试项都没通过。
完成运行之后，我配置的 OB 分布式数据库在排除所有显式的报错信息之后，从运行结果可见没有通过 ACID 测试。
浙公网安备 33010602011771号