postgres常用运维sql

Posted 2020-12-01 学无止境

1、查看数据库大小

select pg_database_size(\'log_analysis\');

 

postgres=# select pg_database_size(\'postExpress\');
 pg_database_size 
------------------
    4417902485676
(1 row)

SELECT pg_size_pretty(pg_database_size(\'postExpress\'));

postExpress=# SELECT pg_size_pretty(pg_database_size(\'postExpress\'));
 pg_size_pretty 
----------------
 4115 GB
(1 row)

2、按顺序查询数据库大小

select pg_database.datname, pg_size_pretty (pg_database_size(pg_database.datname)) AS size from pg_database; 

 

 

3、按顺序查看索引

select indexrelname, pg_size_pretty(pg_relation_size(relid)) from pg_stat_user_indexes where schemaname=\'public\' order by pg_relation_size(relid) desc;

4、查看所有表的大小

select relname, pg_size_pretty(pg_relation_size(relid)) from pg_stat_user_tables where schemaname=\'public\' order by pg_relation_size(relid) desc;

5、检查临时文件

SELECT datname, temp_files AS "Temporary files",temp_bytes AS "Size of temporary files" FROM pg_stat_database ;

临时文件是按后端或会话连接存储的文件，它们可用作资源池或缓冲区。这些文件与共享资源空间分开存储。

重要提示：视图 pg_stat_database 中的 temp_files 和 temp_bytes 列收集聚合中的统计信息（累积值）。这是设计使然，因为这些重置计数器只能在服务器启动时通过恢复进行重置，例如当服务器刚关闭时、服务器崩溃以及时间点恢复 (PITR)。因此，最好的做法是监控这些文件的数量和大小的增长，而不是仅查看输出。

6、查询并确认复制槽存在及其大小：

PostgreSQL v9

select slot_name, pg_size_pretty(pg_xlog_location_diff(pg_current_xlog_location(),restart_lsn)) as 
replicationSlotLag, active from pg_replication_slots ;

PostgreSQL v10 and v11

select slot_name, pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(),restart_lsn)) as replicationSlotLag, 
active from pg_replication_slots ;

7、在确定目前未使用的复制槽（有效状态为 False）后，查询删除该复制槽

select pg_drop_replication_slot(\'Your_slotname_name\');

8、该pg_replication_slots视图提供了数据库集群上当前存在的所有复制插槽及其当前状态的列表

select * from pg_replication_slots;

跨区域只读副本

如果您使用跨区域只读副本，则在主实例上创建一个物理复制槽。如果跨区域只读副本失败，则主数据库实例上的存储空间可能会受影响，因为 WAL 文件未复制到只读副本。您可以使用 CloudWatch 指标“最旧复制槽延迟”和“事务日志磁盘使用”来确定关于接收的 WAL 数据的最滞后副本以及有有多少存储空间用于 WAL 数据。

9、查询连接数

select count(1) from pg_stat_activity;

 查询连接详情

select pid,datname,usename,client_addr,client_port, application_name from pg_stat_activity;

 杀死所有连接进程

select pg_terminate_backend(pid) from pg_stat_activity where usename=\'admin\';  -- 杀死admin账户的当前连接（我这里业务账号用的是admin）

10、查询最大连接数

show max_connections;

11、导出数据到csv文件

copy (select * from test) to \'/data/test.csv\' with csv header;

12、查询最消耗CPU的sql语句

先获取进程的PID，顺序排列最消耗cpu的进程

ps aux|head -1;ps aux|grep -v PID|sort -rn -k +3|head

 

select procpid, start, now() - start as lap, current_query 
from 
(select backendid, pg_stat_get_backend_pid(s.backendid) as procpid, pg_stat_get_backend_activity_start(s.backendid) as start, pg_stat_get_backend_activity(s.backendid) as current_query 
from 
(select pg_stat_get_backend_idset() as backendid) as s 
) as s 
where 
current_query <> \'<IDLE>\' and procpid IN （17637,123,321） --加入查找到的进程ID
order by 
lap desc;

13、停止正在执行的sql

kill select查询，对update、delete 及DML不生效)
SELECT pg_cancel_backend(PID);

kill掉各种操作(select、update、delete、drop等)
SELECT pg_terminate_backend(PID);

14、使用“explain your_statements”的方式来查看SQL语句的执行计划

explain delete from p_table ;

这里，需要注意的是，explain analyze 会分析SQL语句的执行计划，并真正执行SQL语句。而，默认情况下，PostgreSQL数据库的事务是自动开启、提交的。那么，对于DML语句来说，如果要使用explain analyze来查看其执行计划的话，就得格外注意了

explain analyze delete from p_table ;

explain analyze delete from p_table ;查看一条删除操作SQL的执行计划，其结果就是，真正的把表里的数据删除了，且提交了。
对于所有的DML操作，如果只是想通过explain analyze来查看其执行计划的话，需要在执行之前，显示开启事务，然后查看执行计划，最后回滚事务。　

postgres=# begin;
BEGIN
postgres=# explain analyze xxxxxxxxx;
postgres=# rollback;
ROLLBACK
postgres=#

15、查询索引使用记录

select * from pg_stat_all_indexes where schemaname = \'postgres\' and relname = \'表/索引/视图名称\';

　　

参考材料：https://aws.amazon.com/cn/premiumsupport/knowledge-center/diskfull-error-rds-postgresql/

https://www.postgresql.org/docs/current/index.html

http://www.oracleonlinux.cn/2018/08/differences-between-explain-and-explain-analyze/