GP DBA基本操作

时间：2015-11-27 13:04:55 阅读：323 评论：0 收藏：0 [点我收藏+]

标签：

1、查看队列情况

SELECT * FROM gp_toolkit.gp_resqueue_status;

如果出现了资源占用大于1.1 e+11SQL，则可能存在不合理执行计划的SQL，基本跑不出来，库也会很卡。

2、查看用户归属的队列

select * from gp_toolkit.gp_resq_role ;

3、查看某账号下运行中sql

SELECT * from pg_stat_activity where current_query <> ‘<IDLE>‘ and waiting =‘f‘ and usename = ‘etl_user‘;

所有账号都有权限查看。

Query_start字段就是SQL真正启动时间点

4、等待中sql

SELECT * from pg_stat_activity where current_query <> ‘<IDLE>‘ and waiting =‘t‘;

5、检查执行时间超长的SQL

执行如下SQL 检查是否有select * from pg_stat_activity where current_query<>‘<IDLE>‘ and query_start < now() - interval ‘10 mins‘;

6、终止sql

----终止sql的语句，下语句的数字是procid，可以通过上一页的语句查到:

select pg_cancel_backend(27334);

-----终止sql的同时终止会话。

select pg_terminate_backend(27334);

超级账号才有终止权限，如：super_user账号

一定要在数据库里终止一个SQL或任务，因为在ＢＤＩ界面终止一个外部程序任务事实上ＳＱＬ没有终止，还继续运行。

7、执行计划：explain SQL

执行SQL前用explain SQL 查看执行计划

如果执行计划存在针对很大的表做Broadcast Motion 或Nested Loop步骤则不合理，则尝试以下动作：

执行收集表的统计信息语句：ANALYZE 表名;

一般analyze 一天的分区: ANALYZE 表名_1_prt_data_part_20150305;

“_1_prt_”是数据库分区表名固定段。 “data_part_”是我们自动脚本里生成的分区名前缀。

重新看执行计划，如果合理了，则代表源表缺少统计信息导致执行计划不合理。只有在表的数据量发生大变化时或重来没收集过时需要做一次收集。

8、执行计划：explain SQL

ANALYZE完源表重新看执行计划，如果还不合理，执行一下set optimizer to on；更换一个执行计划生成器。

重新生成执行计划。如果合理了，则后续在在ＳＱＬ前加上：set optimizer to on；不要所有SQL加这个，因为该特性未发布。

如果还不合理，则需要优化SQL，即把ＳＱＬ由多张表关联拆开。

9、后台运行SQL，免输入密码

nohup psql -h 10.154.147.130 -d ‘dbname=gpadmin user=etl_user password=etl_pppp‘ -f /home/bdiunivers/aa.sql -L /home/bdiunivers/aa.log &

用psql 命令跑aa.sql文件，如果文件里有多个SQL，想一个SQL报错后不往下跑，则在aa.sql 文件的第一行加上下面内容，行末没有分号 \set ON_ERROR_STOP

10、报内存不足

sql可用内存不够大时，可以用以下方法临时加大。如选择的表分区数很多可能会报内存不足，可以使用该方法。例如：

SET statement_mem=‘500MB‘;

SELECT * FROM my_big_table WHERE column=‘value‘ ORDER BY id limit 10;

RESET statement_mem;

11、left join 右表非常庞大

如果以后业务场景中确实存在left join 右表非常庞大，并且关联字段重复值比较高，可以采取以下方式：

1，按照关联字段进行数据打散

2，在会话级别设置以下参数

set max_statement_mem=‘8GB‘

set statement_mem=‘4GB‘

set gp_workfile_per_query=0

12、使用super_user创建外部表的过程：

a. 删除并重建err表。

drop table if exists masadw .err_ext_表名;

CREATE TABLE masadw.err_ext_表名 ( cmdtime timestamp with time zone, relname text, filename text, linenum integer, bytenum integer, errmsg text, rawdata text, rawbytes bytea) DISTRIBUTED RANDOMLY;

b.把err表修改owner为etl_user

ALTER TABLE masadw.err_ext_表名 OWNER TO etl_user;

c. 创建外部表：

drop EXTERNAL TABLE if exists masadw.ext_表名;

CREATE EXTERNAL TABLE masadw.ext_表名 ( time_id integer, area_id integer, grp_code character varying(50), cust_id bigint, usr_id bigint, svc_code character varying(50)) LOCATION ( ‘gphdfs://hacluster/tmp/zht/NEW_表名.TXT‘) FORMAT ‘text‘ (delimiter E‘‘ null E‘‘ escape E‘OFF‘)ENCODING ‘UTF8‘LOG ERRORS INTO masadw.err_ext_表名 SEGMENT REJECT LIMIT 10 PERCENT;

d.把外部表修改owner为etl_user:

ALTER EXTERNAL TABLE masadw.ext_表名 OWNER TO etl_user;

13、不要创建default分区

不要创建default分区，更不要把大量数据放到default分区，因为default分区在每个sql都会扫描。

14、找出需要做vacuum的表

select * from gp_toolkit.gp_bloat_diag ;

这些表需要做空间回收操作

一般vacumm 和analyze一起执行: vacuum analyze 表名

15、找出没有统计信息需要做ANALYZE的表

select ‘ANALYZE ‘||smischema||‘.‘||smitable||‘;‘ from gp_toolkit.gp_stats_missing where smisize = ‘f‘ and smitable like ‘%_1_prt_%‘ and smitable not like ‘err_%‘ and smitable not like ‘ext_%‘ and smitable like ‘%201503%‘ order by smitable limit 10;

所有存储过程在最后增加GPDB. analyze_partition(表名, 日期)收集一个分区表信息。

16、经常检查数据库状态 gpstate -e

17、经常用nmon命令检查seg节点资源占用率

18、经常检查各机器/data目录 gpssh -f allhosts

19、经常检查各模式下表数量，总共不要超过10万

select schemaname,count(*) from gp_tables group by schemaname order by 2 desc

GP DBA基本操作

标签：

原文地址：http://www.cnblogs.com/tychyg/p/5000247.html

踩

(0)

评论一句话评论（0）

分享档案

更多>

2021年07月29日 (22)
2021年07月28日 (40)
2021年07月27日 (32)
2021年07月26日 (79)
2021年07月23日 (29)
2021年07月22日 (30)
2021年07月21日 (42)
2021年07月20日 (16)
2021年07月19日 (90)
2021年07月16日 (35)

周排行