【 使用环境 】生产环境 or 测试环境
【 OB or 其他组件 】
【 使用版本 】4.2.0
【问题描述】在使用OBD一键测试TPC-H时，合并数据时的SQL执行失败，但可以用sys租户手动执行。
【复现路径】问题出现前后相关操作
【问题现象及影响】
【附件】
1 个赞
发一下完整的日志看一下呢
压测命令发一下，然后查一下这个SQL
select t1.name resource_pool_name, t2.`name` unit_config_name,
t2.max_cpu, t2.min_cpu,
round(t2.memory_size/1024/1024/1024,2) mem_size_gb,
round(t2.log_disk_size/1024/1024/1024,2) log_disk_size_gb, t2.max_iops,
t2.min_iops, t3.unit_id, t3.zone, concat(t3.svr_ip,':',t3.`svr_port`) observer,
t4.tenant_id, t4.tenant_name
from __all_resource_pool t1
join __all_unit_config t2 on (t1.unit_config_id=t2.unit_config_id)
join __all_unit t3 on (t1.`resource_pool_id` = t3.`resource_pool_id`)
left join __all_tenant t4 on (t1.tenant_id=t4.tenant_id)
order by t1.`resource_pool_id`, t2.`unit_config_id`, t3.unit_id;
命令是这个：obd test tpch obtest --tenant=tpch_test -s 100 --remote-tbl-dir=/home/user1/tpch100 -v -O 0 --tmp-dir=/home/user1/tpch100/tmp_dir1
下面是执行SQL的结果
再查下这个看看呢
obd display-trace 70c02c86-696d-11ee-ae4b-6c0b848faf17
到达这一步数据已经初始化完成了哈，后面的步骤主要是合并、收集统计信息以及热加载。
所以进行测试是没问题的了，不过可能第一次的测试结果不是最优。
然后这个问题我们研发同学从代码看了下，是属于SQL执行失败，这个有点奇怪，您看方便重试初始化下看看吗？看能不能稳定复现。
好的，我就重试下，不过估计要明天才能看到结果了
没事的，辛苦了～
帮忙通过压测租户登录集群，获取下 sql_audit
select * from oceanbase.gv$ob_sql_audit where query_sql like ‘%select FROZEN_SCN, LAST_SCN from oceanbase.CDB_OB_MAJOR_COMPACTION where tenant_id = 1008%’\G
然后通过上面搜到的TRACE_ID，到ob的安装目录下获取下日志
grep ‘xxx’ observer.log*
这两个都发一下哈
CDB_OB_MAJOR_COMPACTION在测试租户上看不到吧。脚本在执行那条SQL的时候是不是用的测试租户啊。
测试命令里面用的租户是 tpch_test，查询合并信息应该是用的sys，我看你两个租户都查了，稍等，我们先确认下哈
看下obproxy日志目录下的obproxy_error.log或者obproxy_digest.log，看下有没有obd报错时间点执行select FROZEN_SCN, LAST_SCN from oceanbase.CDB_OB_MAJOR_COMPACTION where tenant_id = 1008这句话的报错记录，找下对应sql的trace id，然后到对应的observer机器上，根据trace id搜一下报错的日志
能找到今天的吗？13号的日志可能已经被gc掉了，想确认的话可以直接看一下observer log有没有 13号的归档日志
