当前位置：首页 > 问答 > 正文

怎么看数据库里的pga信息，查pga那些事儿怎么弄才对

酒紫萱
问答
2026-01-01 00:07:59
4

要搞清楚数据库里的PGA那些事儿,咱们得一步步来，别急着跑复杂的命令，PGA你可以把它想象成数据库给每个干活的“服务员”（也就是每个连接到数据库的会话）分配的一块“私人小厨房”，每个服务员炒菜、备料都在自己的小厨房里忙活，互不打扰，看PGA的信息，其实就是去看看这些“小厨房”的使用情况：有没有人占着太大的地方不用？是不是所有小厨房加起来快把整个后厨的面积都占满了？

最直接了当的看法：用数据库自带的系统视图。

数据库自己有个“监控中心”，记录着所有这些“小厨房”的使用情况，这个监控中心提供了一些视图（你可以理解为特殊的表格），我们查这些视图就行了，根据不同的需求，看不同的视图。

想看看整个数据库PGA的“总账本”？ 那就查 V$PGASTAT，这个视图就像公司的财务报表摘要，一眼就能看到PGA相关的关键总数。怎么查？登录到数据库的SQL命令行（比如SQLPlus或SQL Developer），然后输入： `SELECT FROM V$PGASTAT;` 你会看到好几行数据，重点关注这几条：
- aggregate PGA target parameter: 这是你给PGA设定的“总预算”，就是所有“小厨房”加起来最多能占多大地方，这个值是可以由DBA（数据库管理员）调整的。
- aggregate PGA auto target: 这是总预算里，系统可以自动灵活调配给各个“服务员”的部分，如果这个值很小，说明可用的“机动面积”不多了。
- total PGA inuse: 这是当前所有“服务员”的“小厨房”实际正在使用的面积总和。
- total PGA allocated: 这是数据库实际划拨出去的总面积，可能比正在使用的（inuse）要大一点，因为有些地方虽然划出来了，但可能暂时空着。
- cache hit percentage: 这是个非常重要的百分比！它表示在“小厨房”里找到所需材料的成功率，这个值越高越好，一般希望能在90%以上，如果太低，说明“小厨房”太小，服务员老是得跑回远处的“中央仓库”（磁盘）取东西，速度就慢下来了。（参考来源：Oracle官方文档关于V$PGASTAT视图的说明）
想看看每个“服务员”的“小厨房”具体情况？ 那就查 V$PROCESS 视图，这个视图记录了每个数据库进程（包括用户会话对应的进程）的详细信息，其中就包含PGA的使用情况。可以这样查： SELECT program, pga_used_mem, pga_alloc_mem, pga_max_mem FROM V$PROCESS;
- program: 告诉你这个“服务员”是干嘛的，是用户连接还是后台进程。
- pga_used_mem: 这个进程“小厨房”当前正用着的面积。
- pga_alloc_mem: 数据库划给这个进程的面积。
- pga_max_mem: 这个进程曾经达到过的最大使用面积，这个值有助于发现哪些操作特别“占地方”。（参考来源：Oracle官方文档关于V$PROCESS视图的说明）
想把会话（用户连接）和它使用的PGA关联起来看？ 有时候我们需要更精确地知道是哪个用户、哪个SQL语句占用了大量PGA，这时可以结合 V$SESSION 和 V$PROCESS 视图来查。比如这样一个查询： SELECT s.sid, s.username, s.program, p.pga_used_mem, p.pga_alloc_mem, p.pga_max_mem FROM V$SESSION s, V$PROCESS p WHERE s.paddr = p.addr; 这样就能看到每个会话及其对应的PGA使用量，方便定位“大户”。

除了实时查看，还要学会看“历史报告”。

数据库有个叫AWR（自动工作负载仓库）的功能，它会定期给数据库的性能状况拍“快照”，我们可以生成两个时间点之间的性能报告，里面会有关于PGA的详细分析。

报告里会告诉你这段时间内PGA的使用趋势,平均使用量，峰值是多少。
会再次强调那个重要的 PGA Cache Hit Percentage，并评估它是否健康。
可能会指出PGA的“总预算”（target）设置是否合理。生成AWR报告通常需要DBA权限，命令相对复杂一些（比如使用@?/rdbms/admin/awrrpt.sql），但提供的信息非常全面。（参考来源：Oracle官方文档关于AWR的说明）

查PGA这些事儿，怎么弄才对呢？

怎么看数据库里的pga信息，查pga那些事儿怎么弄才对

先总后分，由浅入深：别一上来就钻到每个会话的细节里，先通过 V$PGASTAT 看看整体情况是否健康，特别是“命中率”（cache hit percentage），如果整体命中率很高，总体使用量也远低于预算，那通常说明PGA层面没啥大问题，不必过度紧张。
带着问题去查：如果你已经感觉到数据库变慢了，或者监控报警了，再去深入查看，这时候可以去看 V$SESSION 和 V$PROCESS，找出是哪个会话、哪个程序占用了异常的PGA，是不是有人在跑一个需要大量排序（比如ORDER BY）或者数据关联（HASH JOIN）的复杂报表？找到源头才能对症下药。
关注趋势，而非单点：数据库的负载是波动的，某个时刻PGA使用高可能是正常的高峰期业务，利用AWR报告看一段时间（比如一个业务周期）内的趋势更重要，如果发现PGA的使用峰值持续接近甚至超过总预算，或者命中率持续低迷，那就需要考虑调整PGA的“总预算”参数（PGA_AGGREGATE_TARGET）了，或者优化那些消耗PGA严重的SQL语句。
理解限制：PGA是每个会话私有的，所以当并发用户数非常多的时候，即使每个用户只用一点点PGA，总和也可能很大，这也是需要考虑的因素。