GBase 8a 目前版本都是采用一个库一个目录，表是库下面的子目录的方式保存数据，本文提供了一些查看一个库或schema占用磁盘空间方法以供参考。
目录导航
文件系统级估算
直接从文件系统，找到该库所在的目录，计算其占有的空间。该才做仍然会消耗大量的磁盘资源，表越多，列越多，消耗越大。
du -sh 安装目录/gnode/userdata/gbase/库名影响程度建议在实际环境测试后，再决定是否使用。比如100万个表，预计可能要几分钟到几十分钟的磁盘消耗，换SSD等高速盘会极大改善影响程度。
需要计算每个节点的空间，然后累加后为占用的总空间。 如果各个节点磁盘占用接近，也可以用单个节点统计结果*计算节点数量来估算。
自定义表空间
V95版本支持自定义表空间，并支持配额管理。 详情和注意事项，请参考 GBase 8a V95版本表空间配额使用样例
通过查询元素据表 information_schema.tablespaces ,获得表空间的磁盘占用。
该使用空间，在每次数据有变动是自动修正，无需每次都扫描所有子目录，故性能好。
如下是一个库，配置了2个表空间的例子。将每个节点的每个表空间，累加后就是总空间占用。
gbase> select * from information_schema.tablespaces where db_name='ab';
+-----------+---------+---------------+-----------------+----------------------------+------------+-----------+-----------+-----------+----------+
| NODE_NAME | DB_NAME | TABLESPACE_ID | TABLESPACE_NAME | TABLESPACE_PATH | IS_DEFAULT | MAX_SIZE | USED_SIZE | FREE_SIZE | SEG_SIZE |
+-----------+---------+---------------+-----------------+----------------------------+------------+-----------+-----------+-----------+----------+
| node1 | ab | 1 | sys_tablespace | /opt/gbase/tablespace_100m | yes | 104857600 | 160042004 | 0 | 16777216 |
| node1 | ab | 2 | ts_1 | /opt/gbase/tablespace_1 | no | 52428800 | 80020808 | 0 | 10485760 |
| node2 | ab | 1 | sys_tablespace | /opt/gbase/tablespace_100m | yes | 104857600 | 160042004 | 0 | 16777216 |
| node2 | ab | 2 | ts_1 | /opt/gbase/tablespace_1 | no | 52428800 | 80020808 | 0 | 10485760 |
+-----------+---------+---------------+-----------------+----------------------------+------------+-----------+-----------+-----------+----------+
4 rows in set (Elapsed: 00:00:00.00)累计每个表的空间
通过元数据，获得每个表占用的空间。 详情和注意事项，请参考 GBase8a 集群查看某张表占用的磁盘空间大小
好处是可以通过SQL获得，且循环调度可以控制；缺点是要扫描每个表，系统消耗大。
总结
如果是V9版本，且要控制一些大表占用的空间，建议用自定义表空间。
其它2个方案，都会占用较大的系统资源，建议在测试影响后再考虑是否使用。 另外建议降低频率，比如每天一次，且选择在对业务影响最小的时间操作，比如凌晨4-5点。