检测到您已登录华为云国际站账号,为了您更好的体验,建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
GS_WLM_REBUILD_USER_RESOURCE_POOL 该视图用于在当前连接节点上重建内存中用户的资源池信息,无输出。只在资源池信息缺失或错乱时用作补救措施。查询该视图需要sysadmin权限。内核多租模式下禁用。 表1 GS_WLM_REBUILD_USER_RESOURCE_POOL字段
GS_SEG_SPC_REMAIN_SEGMENTS GS_SEG_SPC_REMAIN_SEGMENTS获取索引表空间残留的段信息,包含main fork、fsm fork、vm fork段。只支持管理员权限用户查询。 表1 GS_SEG_SPC_REMAIN_SEGMENTS字段
对二级分区表清空一级分区 使用ALTER TABLE TRUNCATE PARTITION可以清空二级分区表的一个一级分区,数据库会将这个一级分区下的所有二级分区都进行清空。 例如,通过指定分区名清空二级分区表range_list_sales的一级分区date_202005,并更新Global索引。
对二级分区表清空二级分区 使用ALTER TABLE TRUNCATE SUBPARTITION可以清空二级分区表的一个二级分区。 例如,通过指定分区名清空二级分区表range_list_sales的二级分区date_202005_channel1,并更新Global索引。 ALTER
Local索引分区重建/不可用 使用ALTER INDEX PARTITION可以设置Local索引分区是否可用。 使用ALTER TABLE MODIFY PARTITION可以设置分区表上指定分区的所有索引分区是否可用。这个语法如果作用于二级分区表的一级分区,数据库会将这个一级分区下的所有二级分区均进行设置。
RCR(Row Consistency Read) UB-tree多版本管理 UB-tree的多版本管理采用基于Key的多版本管理,最新版本和历史版本均在UB-tree上。 为了节省空间,xmin/xmax采用xid-base + delta的方式表示,64位的xid-base储
GS_WLM_REBUILD_USER_RESOURCE_POOL 该视图用于在当前连接节点上重建内存中用户的资源池信息。只在资源池信息缺失或错乱时作为补救措施。查询该视图需要sysadmin权限。 表1 GS_WLM_REBUILD_USER_RESOURCE_POOL字段 名称
对二级分区表重命名二级分区 使用ALTER TABLE RENAME SUBPARTITION可以对二级分区表重命名二级分区。 例如,通过指定分区名将二级分区表range_list_sales的分区date_202001_channel1重命名。 ALTER TABLE range_list_sales
PG_TOTAL_USER_RESOURCE_INFO_OID PG_TOTAL_USER_RESOURCE_INFO_OID视图显示所有用户的资源使用情况,需要使用管理员用户进行查询。此视图在GUC参数use_workload_manager为on时才有效。具体字段信息如表1所示。
PG_TOTAL_USER_RESOURCE_INFO_OID PG_TOTAL_USER_RESOURCE_INFO_OID视图显示所有用户的资源使用情况,需要使用管理员用户进行查询。此视图在GUC参数use_workload_manager为on时才有效。 表1 PG_TOT
对二级分区表重命名一级分区 使用ALTER TABLE RENAME PARTITION可以对二级分区表重命名一级分区。具体方法与一级分区表相同。 父主题: 重命名分区
大量回滚事务拖慢Undo空间回收 问题现象 使用gs_async_rollback_xact_status视图查看有大量的待回滚事务,且待回滚的事务数量维持不变或者持续增高。 SELECT * FROM gs_async_rollback_xact_status(); 处理方法
长查询执行期间大量并发更新偶现写入性能下降 问题现象 执行全表扫描类型的长查询,扫描期间页面发生大量并发更新,部分DML写入性能较没有长查询时出现性能下降。 问题分析 对于全表扫描场景下的长查询(例如持续两小时以上),在扫描到某个页面前,该页面发生大量集中并发更新(例如十万次以上
大量回滚事务拖慢Undo空间回收 问题现象 使用gs_async_rollback_xact_status视图查看有大量的待回滚事务,且待回滚的事务数量维持不变或者持续增高。 SELECT * FROM gs_async_rollback_xact_status(); 处理方法
长查询执行期间大量并发更新偶现写入性能下降 问题现象 执行全表扫描类型的长查询,扫描期间页面发生大量并发更新,部分DML写入性能较没有长查询时出现性能下降。 问题分析 对于全表扫描场景下的长查询(例如持续两小时以上),在扫描到某个页面前,该页面发生大量集中并发更新(例如十万次以上
_workers是1,recovery_max_workers大于1为并行回放),备机的查询线程在做索引扫描时,会先对索引页面加读锁,每当扫到一个元组时会去判可见性,如果该元组对应的事务处于committing状态,需要等待该事务提交后再判断。而备机上的事务提交是依赖日志回放线程
_workers是1,recovery_max_workers大于1为并行回放),备机的查询线程在做索引扫描时,会先对索引页面加读锁,每当扫到一个元组时会去判可见性,如果该元组对应的事务处于committing状态,需要等待该事务提交后再判断。而备机上的事务提交是依赖日志回放线程
_workers是1,recovery_max_workers大于1为并行回放),备机的查询线程在做索引扫描时,会先对索引页面加读锁,每当扫到一个元组时会去判可见性。如果该元组对应的事务处于committing状态,需要等待该事务提交后再判断。而备机上的事务提交是依赖日志回放线程
_workers是1,recovery_max_workers大于1为并行回放),备机的查询线程在做索引扫描时,会先对索引页面加读锁,每当扫到一个元组时会去判可见性,如果该元组对应的事务处于committing状态,需要等待该事务提交后再判断。而备机上的事务提交是依赖日志回放线程