sys租户执行select * from dba_ob_tenants;报错 no memory or reach tenant memory limit ，并且只有在查询dba_ob_tenants表时才会报这个错误，查询其它表则正常，sys租户的unit内存配置为10G，并且租户下gv$ob_sql_audit中没有看到有active的语句。数据库版本是4.4.1.0
2 个赞
还没有创建其他租户，想办法修改sys租户内存，把他修改小一点试一试
2 个赞
还有一个业务租户，unit是1G。
2 个赞
最开始报错的时候sys租户内存是1G，后面改为了10G还是报错
1）设置trace信息
SET ob_enable_show_trace=‘ON’;
2）执行sql。
3）获取上个命令的trace
select last_trace_id();
4）获取trace对应的节点
select query_sql,svr_ip from gv$ob_sql_audit where trace_id=‘第三步获取的trace信息’；
5）取对应的svr_ip节点 过滤日志
grep “第三步获取的trace信息” observer.log*
grep “第三步获取的trace信息” rootservice.log*
6）提供日志信息即可。
麻烦协助获取一份日志看下
1 个赞
我们把业务租户unit的内存上限改为了5G,之后再用sys租户查询dba_ob_tenants就没有报错了，这是为什么
现在可以了，还需要trace日志吗
需要报错时候的日志。目前执行成功后的日志不需要了
这边复现一下看看
1 个赞
用obdiag诊断下
3 个赞
好工具
检查内存配置：
-
检查
sys租户的内存配额：你可以通过查询dba_ob_tenants或gv$memory_limit表，确认该租户的内存配额是否已经用尽，或者是否被限制。
SELECT tenant_id, tenant_name, memory_limit, memory_used
FROM gv$memory_limit WHERE tenant_id = <sys租户的tenant_id>;
- 查询资源使用情况：使用以下查询检查当前租户的内存使用情况：
SELECT * FROM gv$memory_resource WHERE tenant_id = <sys租户的tenant_id>;
1 个赞
obdiag
我这边的内核版本是4.19
dba_ob_tenants视图内部涉及多个虚拟表，其中会涉及到业务的meta租户表。新版新增了很多功能都会占用一些内存，1g内存偏小，在不使用租户情况下，内存可能就会超限推荐下次至少部署2g的来使用吧。