现进行数据库迁移，将mysql数据库迁移至Oceanbase，具体版本为server version: 5.7.25 OceanBase_CE 4.2.1.3 (r103000032023122818-8fe69c2056b07154bbd1ebd2c26e818ee0d5c56f) (Built Dec 28 2023 19:07:26)，使用过程中，碰到oceanbase数据库报错：No memory or reach tenant memory limit 问题。
1、启动数据库配置如下：
/var/utm/oceanbase-ce/bin/observer -r 127.0.0.1:2882:3306 -p 3306 -P 2882 -z zone1 -c 1710171466 -d /var/utm/oceanbase-ce/store -I 127.0.0.1 -o __min_full_resource_pool_memory=1073741824,enable_syslog_recycle=True,enable_syslog_wf=False,max_syslog_file_count=4,memory_limit=6G,system_memory=2G,cpu_count=4,datafile_size=10G,datafile_maxsize=20G,datafile_next=2G,log_disk_size=20G
2、底层查询语句如下：
mysql> SELECT
→ user_name,
→ tenant_id, – 租户ID（sys租户的ID通常为1）
→ (SELECT tenant_name FROM __all_tenant WHERE tenant_id = u.tenant_id) AS tenant_name
→ FROM
→ __all_user u
→ WHERE
→ user_name = ‘fwuser’;
±----------±----------±------------+
| user_name | tenant_id | tenant_name |
±----------±----------±------------+
| fwuser | 0 | NULL |
| fwuser | 0 | NULL |
±----------±----------±------------+
mysql> SELECT
→ tenant_id, – 租户唯一ID（如sys租户ID为1）
→ tenant_name, – 租户名称（核心标识，如sys、mysql）
→ status, – 租户状态（NORMAL=正常，IN_RECYCLEBIN=回收站，需过滤）
→ gmt_create, – 租户创建时间
→ compatibility_mode – 兼容模式（0=OceanBase模式，1=MySQL模式等）
→ FROM
→ __all_tenant
→ WHERE
→ status = ‘NORMAL’ ORDER BY
→ tenant_id ASC;
±----------±------------±-------±---------------------------±-------------------+
| tenant_id | tenant_name | status | gmt_create | compatibility_mode |
±----------±------------±-------±---------------------------±-------------------+
| 1 | sys | NORMAL | 2024-07-24 13:57:57.927115 | 0 |
±----------±------------±-------±---------------------------±-------------------+
1 row in set (0.01 sec)
3、那么在fwuser在tenant_id为0的情况下，使用的是谁的资源？
4 个赞
对，所以想请教下，这个报错下，是具体谁的资源不够，造成的这个报错。
现在问了几个ai，在tenant_id为0的情况下，一个说使用sys租户资源的，一个说不能正常使用的，还有一个说使用除sys租户外资源的，这。。。
淇铭
#6
ob4.2.1.3这个版本 不建议使用了 建议使用最新的LTS版本ob425.x
No memory or reach tenant memory limit 这个报错 应该是工作区的内存不足了 下面有个文档可以看看
https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000000218321
好的，谢谢了，我们也试着改下这个看
（工作区内存不足
工作区内存，是指 SQL 排序等阻塞性算子使用的内存，通过租户系统变量 ob_sql_work_area_percentage 控制，默认值为 5%，即 工作区内存 = 租户内存 * ob_sql_work_area_percentage（默认 5%）。
如果请求并发量较大，且每个请求占用的工作区内存比较多，可能出现工作区内存不足的报错，经常出现的场景有 union、sort、group by 等。上述问题如果出现，可以通过适当调大系统变量来规避）
那又回到了这个问题，这个工作区内存，对fwuser这个tenant_id为0的情况下，ob_sql_work_area_percentage是多少呢
现在查询出的值是5
mysql> SHOW VARIABLES LIKE ‘ob_sql_work_area_percentage’;
±----------------------------±------+
| Variable_name | Value |
±----------------------------±------+
| ob_sql_work_area_percentage | 5 |
±----------------------------±------+
淇铭
#9
上面的查看租户的id应该不准确 建议使用oceanbase.dba_ob_tenants 这个视图查看
mysql> select * from oceanbase.dba_ob_tenants;
±----------±------------±------------±---------------------------±---------------------------±-------------±--------------±------------------±-------------------±-------±--------------±-------±------------±------------------±-----------------±---------±---------------±-------------±-------------------±-------------±---------------------------±---------±-----------±----------+
| TENANT_ID | TENANT_NAME | TENANT_TYPE | CREATE_TIME | MODIFY_TIME | PRIMARY_ZONE | LOCALITY | PREVIOUS_LOCALITY | COMPATIBILITY_MODE | STATUS | IN_RECYCLEBIN | LOCKED | TENANT_ROLE | SWITCHOVER_STATUS | SWITCHOVER_EPOCH | SYNC_SCN | REPLAYABLE_SCN | READABLE_SCN | RECOVERY_UNTIL_SCN | LOG_MODE | ARBITRATION_SERVICE_STATUS | UNIT_NUM | COMPATIBLE | MAX_LS_ID |
±----------±------------±------------±---------------------------±---------------------------±-------------±--------------±------------------±-------------------±-------±--------------±-------±------------±------------------±-----------------±---------±---------------±-------------±-------------------±-------------±---------------------------±---------±-----------±----------+
| 1 | sys | SYS | 2024-07-24 13:57:57.927115 | 2024-07-24 13:57:57.927115 | RANDOM | FULL{1}@zone1 | NULL | MYSQL | NORMAL | NO | NO | PRIMARY | NORMAL | 0 | NULL | NULL | NULL | NULL | NOARCHIVELOG | DISABLED | 1 | 4.2.1.3 | 1 |
±----------±------------±------------±---------------------------±---------------------------±-------------±--------------±------------------±-------------------±-------±--------------±-------±------------±------------------±-----------------±---------±---------------±-------------±-------------------±-------------±---------------------------±---------±-----------±----------+
1 row in set (0.29 sec)
淇铭
#12
不要再sys租户导入数据或者建库操作 sys租户是系统租户的内存不会分配太大的 建议自己建个业务租户操作
嗯，不过现在 测试环境在跑数了，想确认下，在只有sys租户的情况下，数据库用户fwuser，他到底在使用谁的资源 毕竟sys租户的资源可以修改分配，启动数据库的时候，资源分配也可以修改。
只有一个租户了都，还能使用谁的资源，当然是仅有的这个租户的啦~
不过，如果我没记错的话，sys 租户在使用方面是与业务租户有诸多不同的，不方便业务使用的~
淇铭
#19
是可以修改 但是最好不要使用sys租户
系统租户 是集群默认创建的租户，与集群生命期一致，负责管理集群和所有租户的生命期。系统租户仅有一个1号日志流，只支持单点写入，不具备扩展能力。系统租户可以创建用户表，所有的用户表和系统表数据均由1号日志流服务。系统租户数据是集群私有的，不支持主备集群物理同步和物理备份恢复。
1 个赞
