我没看明白您的指示的需求
就是在leader是在57上 捞一下trace_id=YB420A01E03A-0006456AE1380FCF-0-0的observer.log日志信息 时间节点和截图的日志时间对应上 主要想看看oms_step表在leader节点的日志信息
没有保留截图的trace，已提供给你的就是执行查询oms_step表，报错后的trace最后几行
你怎么手动切换oms_step的leader的节点的
那你的那个trace日志信息 是在哪个节点查看的？看着不是在leader节点查看的 想着你在oms_step这个leader节点上 找一下trace日志
ALTER TABLE table_name MOVE PARTITION partition_name TO zone_name;你是这样执行的是么？这个日志信息 是全部的日志信息么？如果不是全部trace信息 建议全部提供一下
再试一下看看oms_step这个表能否查询
root 15:48: [_rm]> ALTER SYSTEM TRANSFER PARTITION TABLE_ID = 501426, OBJECT_ID = 501426 TO LS 1001;
Query OK, 0 rows affected (0.54 sec)
先看一下 是不是有问题 主要合并的日志信息也被覆盖了
租户的primary zone是radom么
select /*+ query_timeout(1000000000),parallel(2) */
e.tenant_name,
b.owner as database_name,
b.table_name,
a.object_id as index_table_id,
b.index_name,
group_concat(d.column_name order by d.column_position separator ', ') as index_columns,
case
when c.index_type in (1, 2) then ‘local’
when c.index_type in (3, 4) then ‘global’
end as indextype
from
cdb_objects a
join
cdb_indexes b on a.con_id = b.con_id and a.owner = b.owner and a.object_name = b.index_name
join
__all_virtual_table c on a.con_id=c.tenant_id and a.object_id = c.table_id
join
cdb_ind_columns d on b.con_id = d.con_id and b.owner = d.index_owner and b.table_name = d.table_name and b.index_name = d.index_name
join
dba_ob_tenants e on a.con_id=e.tenant_id
where
a.object_type like ‘%index%’
and e.tenant_name in (‘test1’,‘test7’)
and b.owner = ‘test’ – database_name
– and b.table_name = ‘t123’
group by
e.tenant_name,
b.owner,
b.table_name,
a.object_id,
b.index_name,
indextype
order by e.tenant_name,b.owner,b.table_name;
可以通过样查看索引表名 在去查看表名
看着日志信息应该微块内存被写坏了导致的解析微块header的时候报错 当时这个表所在的日志流有问题 你把日志流迁移走以后 应该没有问题
都是经验啊，学习了
目前这个环境先保留着 我们想看看具体的根因是什么
好的，没有刻意动环境，不清楚是不是第一现场了
好的 感谢 我先让研发看看后面还需要什么信息 我加你钉钉了 麻烦同意一下