活动专区

活动公告

上车！GBase 8a开发者联盟发车了 技术福利、人脉资源全都有！

认证培训专区

认证培训资料

GBase 8s GDCA 认证培训课前准备

GBase 8a

其他

物化视图报错：references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them

01-GBase 8s 事务型数据库 安装与卸载

GBase 8s

适配迁移

[GBase 8s 教程]GBase 8s 常用函数、表达式



# GBase 8a 资源池白天查询和夜间跑批切换记录

我最近看 GBase 8a 资源管理资料时，觉得白天查询、夜间跑批这个场景很适合单独拿出来整理。很多集群白天主要服务报表查询，晚上主要跑加载、加工、汇总任务。如果所有用户都挤在同一套资源限制里，白天容易被跑批拖慢，晚上又可能因为查询用户占着资源导致批处理拖到早高峰。

GBase 8a 的资源管理可以通过消费组、资源池、资源计划和资源指令，把不同用户挂到不同资源策略上。官方示例里也给过类似思路：白天给查询用户更多 CPU 和内存，晚上给加载用户更多 CPU 和内存，通过切换 plan 达到同一个用户在不同时段受到不同资源控制的目的。这个设计很适合现场落地，但真正实施时不能只照抄比例，还要结合业务窗口、任务优先级和回退方式。

## 先分清楚用户角色

资源管理的第一步不是创建资源池，而是先分清楚用户角色。很多现场只有几个共用账号，所有报表、加工、临时查询都混在一起。这样即使配置资源池，也很难把控制真正落到业务边界上。

我通常会建议至少拆出三类账号：加载账号、加工账号、查询账号。如果还有领导驾驶舱、抽查审计、应急分析，也可以再拆出高优先级查询账号。

| 用户类型 | 典型任务 | 白天策略 | 夜间策略 |
|---|---|---|---|
| 加载用户 | LOAD、外部数据入库 | 限制资源，避免影响查询 | 提高资源，保证批次完成 |
| 加工用户 | 汇总、宽表、清洗 | 中低资源 | 较高资源 |
| 查询用户 | 报表、BI、取数 | 高资源、低等待 | 降低资源 |
| 抽查用户 | 应急核查 | 预留少量高优先级 | 按需开放 |
| 默认用户 | 临时或未归类任务 | 保守限制 | 保守限制 |

这一步做不好，后面配置再细也会打折扣。资源池不是替代账号治理的工具，它需要清楚的用户边界作为前提。

## 资源池不是只管 CPU

GBase 8a 资源池里会涉及 CPU、内存、临时磁盘、磁盘空间、读写 IO、最大活动任务、并行度、等待超时、运行超时等多个维度。现场最容易只盯着 `cpu_percent`，但很多查询问题其实出在临时空间、并发数或长时间等待上。

下面是一个简化示意，具体值要按现场硬件和业务压力调整：

```sql
CREATE CONSUMER GROUP group_load COMMENT = 'users for load';
CREATE CONSUMER GROUP group_select COMMENT = 'users for select';

ALTER CONSUMER GROUP group_load ADD USER userload;
ALTER CONSUMER GROUP group_select ADD USER userselect;

CREATE RESOURCE POOL static_pool0(
    cpu_percent=100,
    max_memory=10000,
    max_temp_diskspace=10000,
    max_disk_space=10000,
    max_disk_writeio=1000,
    max_disk_readio=1000
) TYPE STATIC;

CREATE RESOURCE POOL pool_query_high(
    priority=1,
    cpu_percent=80,
    max_memory=8000,
    max_temp_diskspace=5000,
    max_activetask=200,
    task_waiting_timeout=100000,
    task_running_timeout=100000
) TYPE DYNAMIC BASE ON static_pool0;

CREATE RESOURCE POOL pool_load_high(
    priority=1,
    cpu_percent=80,
    max_memory=8000,
    max_temp_diskspace=8000,
    max_activetask=100,
    task_waiting_timeout=100000,
    task_running_timeout=100000
) TYPE DYNAMIC BASE ON static_pool0;
```

这里的重点不是参数值，而是设计思路：白天查询池更强，夜间加载池更强。不同池的内存和临时空间也要配合任务类型，而不是只改 CPU。

## 白天和夜间计划要可切换、可回退

资源计划切换是现场风险点。切换成功以后，后续连接和任务怎么归属、老任务是否继续跑、切换失败怎么回退，都要提前想清楚。示例：

```sql
CREATE RESOURCE PLAN plan_day COMMENT = 'day query first plan';
CREATE RESOURCE PLAN plan_night COMMENT = 'night batch first plan';

CREATE RESOURCE DIRECTIVE d_day_select(
    plan_name='plan_day',
    pool_name='pool_query_high',
    group_name='group_select',
    comment='select user resource usage on day'
);

CREATE RESOURCE DIRECTIVE d_day_load(
    plan_name='plan_day',
    pool_name='pool_load_low',
    group_name='group_load',
    comment='load user resource usage on day'
);

CREATE RESOURCE DIRECTIVE d_night_select(
    plan_name='plan_night',
    pool_name='pool_query_low',
    group_name='group_select',
    comment='select user resource usage on night'
);

CREATE RESOURCE DIRECTIVE d_night_load(
    plan_name='plan_night',
    pool_name='pool_load_high',
    group_name='group_load',
    comment='load user resource usage on night'
);
```

激活计划时，我建议由调度系统或标准运维脚本执行，而不是人工在命令行随手敲。

```sql
-- 白天切换
DEACTIVE RESOURCE PLAN ON VC vc1;
ACTIVE RESOURCE PLAN plan_day ON VC vc1;

-- 夜间切换
DEACTIVE RESOURCE PLAN ON VC vc1;
ACTIVE RESOURCE PLAN plan_night ON VC vc1;
```

如果现场存在多个 VC，就不能只切一个 VC。资源计划的生效范围要和业务入口一致，否则会出现同一类任务在不同 VC 上表现不同。

## 切换前后要做轻量验收

我不太建议资源计划切换后只看“命令执行成功”。更稳的做法是准备几条轻量验证 SQL，确认当前计划、消费组和用户归属都符合预期。

```sql
-- 资源管理相关系统表名称按现场版本确认
SHOW RESOURCE PLAN;
SHOW RESOURCE POOL;
SHOW CONSUMER GROUP;
```

再用业务账号跑一个低成本查询，观察是否能正常排队和执行。不要一上来就用最重的日报任务测试，否则一旦配置不合理，会把问题放大。

| 验收点 | 检查内容 | 异常表现 |
|---|---|---|
| 计划是否激活 | 当前 VC 上 active plan | 仍是旧计划或无计划 |
| 用户是否入组 | 用户属于目标消费组 | 进入 default 组 |
| 池参数是否正确 | CPU、内存、并发、超时 | 值和变更单不一致 |
| 低成本 SQL | 业务账号能正常执行 | 排队异常或权限异常 |
| 重任务观察 | 夜间跑批是否按时完成 | 批处理拖到白天 |

## 不要把默认组放飞

默认消费组经常被忽略。现场如果新建了一个临时账号，忘了挂到指定消费组，它就可能进入默认组。如果默认组资源给得太高，临时账号可能挤占正式任务；如果默认组资源给得太低，临时排查又会被误判为数据库慢。

我的习惯是默认组采用保守策略：能执行，但不应该拿到比正式组更高的资源。这样即使有账号漏归类，也不会直接冲击主业务。

```sql
CREATE RESOURCE DIRECTIVE d_day_default(
    plan_name='plan_day',
    pool_name='pool_default_low',
    group_name='default_consumer_group',
    comment='default users on day'
);
```

同时要建立账号申请和消费组绑定流程。资源管理不是一次性配置，后续每个新增用户都要纳入这个体系。

## 常见坑

| 常见坑 | 现场表现 | 原因 | 建议 |
|---|---|---|---|
| 只按 CPU 分配 | 查询仍然慢或报临时空间不足 | 忽略内存、临时空间、并发 | 多维度配置资源池 |
| 用户未入组 | 配置看似正确但不生效 | 账号落在默认组 | 定期核对用户归属 |
| 只切一个 VC | 部分业务表现不同 | 生效范围不完整 | 按业务入口切换 |
| 没有回退脚本 | 切换异常后手忙脚乱 | 只写了上线命令 | 准备回退命令 |
| 默认组过强 | 临时任务抢资源 | 默认组无约束 | 默认组保守配置 |
| 夜间计划忘切回 | 白天报表变慢 | 调度失败 | 加切换监控和告警 |

## 结尾总结

GBase 8a 资源池和资源计划的价值，不只是限制某个用户，而是把不同时间段的业务优先级表达出来。白天查询优先，夜间跑批优先，这是很常见也很实用的策略。真正落地时，要先做账号分类，再建消费组和资源池，最后用计划切换承载时段策略。

我自己的建议是：资源计划一定要有验收和回退，默认组一定要保守，切换动作一定要脚本化。这样资源管理才不会只是文档里的配置样例，而能真正成为稳定集群负载的工具。

## 参考资料

```text
[1] GBase 8a 资源管理示例 https://www.gbase.cn/docs/gbase-8a/%E4%BA%A7%E5%93%81%E6%89%8B%E5%86%8C/admin-administrator-guide/admin-resource-management/admin-resource-manage-example
[2] GBase 8a 管理员指南 https://www.gbase.cn/docs/gbase-8a/%E4%BA%A7%E5%93%81%E6%89%8B%E5%86%8C/admin-administrator-guide/
[3] GBase 社区优质文章区 https://www.gbase.cn/community/section/11
```

```

```



GBase 8a 资源池白天查询和夜间跑批切换记录

GBase 8a 资源池白天查询和夜间跑批切换记录

评论

热门帖子