Oracle 数据库中的大量交换

嗨，Oracle专业人士，
请给我们建议并给出正确的方向。

我们在OS Red Hat Enterprise Linux服务器版本6.10上有12c上的数据库与内存设置:
SGA: 4928M
PGA: 1250M

操作系统内存: 8gb
中央处理器质量: 2
大页面禁用。

在启用数据保护之前，使用上述设置可以正常工作。

2) 启用了DG-然后我们收到了以下消息:

2018-08-28T09:02:50。604204 05:00
警告: 在过去5分钟内，系统上观察到大量交换。
大量交换会导致超时，性能差和实例逐出。
2018-08-28T09:02:52。420519 05:00
文件/u01/app/oracle/diag/rdbms/pp_sm/PP_SM/trace/PP_SM_dbrm_32047.trc中的错误 (事故 = 89163):
ORA-00700: 软内部错误，参数: [kskvmstatact: 观察到的过度交换]，[]，[]
事件详情见: /u01/app/oracle/diag/rdbms/pp_sm/PP_SM/事件/incdir_89163/PP_SM_dbrm_32047_i89163.trc
2018-08-28T09:03:47。866712 05:00
在目录 =[cdmp_20180828090347] 中转储诊断数据，由 (实例 = 1，osid = 32047 (DBRM)) 请求，摘要 = [事件 = 89163]。


事件中的详细信息:
----- 自定义事件转储的开始 -----
==========================================
实例范围内的交换警报摘要
------------------------------------------
警告: 在系统上观察到大量交换。
大量交换会导致超时，性能差和实例逐出。
要减少交换，请减少此数据库实例和/或
此服务器上运行的其他应用程序。

总物理内存: 8001 MB
过去5分钟内换入/换出的字节: 1003028 KB
cpu利用率: 98%

SGA_TARGET: 4928 MB

PGA_AGGREGATE_LIMIT: 0 MB
自启动以来分配的最大PGA: 5554 MB
当前分配的PGA总数: 4797 MB
PGA_AGGREGATE_TARGET: 1250 MB

注意PGA使用率 (5554 MB) 超过PGA_AGGREGATE_TARGET (1250 MB)。
通过降低PGA_AGGREGATE_TARGET和PGA_AGGREGATE_LIMIT来降低PGA使用率。

通过降低SGA_TARGET降低此数据库实例的内存使用量，
PGA_AGGREGATE_TARGET和/或PGA_AGGREGATE_LIMIT。


*
---- 我们增加了额外的容量，如下:
操作系统: 增加了额外的4 GB内存 (总计 = 12 GB)
CPU a-TY: 额外增加2个CPU (总计 = 4个CPU)

同样在DB级别:
SGA: 8gb (已扩展)
PGA: 1700M (已延长)
巨大的页面仍然禁用。

然后在重新启动DB之后。
1天后，我们继续遇到以上错误。

[TOC00000]
跳转到目录
转储从文件继续: /u01/应用程序/oracle/diag/rdbms/pp_sm/PP_SM/trace/PP_SM_dbrm_3857.trc
[TOC00001]
ORA-00700: 软内部错误，参数: [kskvmstatact: 观察到的过度交换]，[]，[]

[TOC00001-END]
[TOC00002]
=
[TOC00003]
----- 自定义事件转储的开始 -----
==========================================
实例范围内的交换警报摘要
------------------------------------------
警告: 在系统上观察到大量交换。
大量交换会导致超时，性能差和实例逐出。
要减少交换，请减少此数据库实例和/或
此服务器上运行的其他应用程序。

总物理内存: 12041 MB
过去5分钟内换入/换出的字节: 771796 KB
cpu利用率: 91%

SGA_TARGET: 8192 MB

PGA_AGGREGATE_LIMIT: 0 MB
自启动以来分配的最大PGA: 4446 MB
当前分配的PGA总数: 4086 MB
PGA_AGGREGATE_TARGET: 1700 MB

注意PGA使用率 (4446 MB) 超过PGA_AGGREGATE_TARGET (1700 MB)。
通过降低PGA_AGGREGATE_TARGET和PGA_AGGREGATE_LIMIT来降低PGA使用率。

通过降低SGA_TARGET降低此数据库实例的内存使用量，
PGA_AGGREGATE_TARGET和/或PGA_AGGREGATE_LIMIT。

*

所以，我有问题-对我们来说至关重要:
严重交换问题的根源可能是什么？
1.启用数据保护？它的过程吞噬了所有的记忆？在启用DG之前，数据库工作正常，没有启用巨大的页面。
2.禁用巨大页面-导致性能低下？
3.我在某处读到，如果OS总内存 => 8gb-必须启用大页面。
是真的吗？如果有任何ORA文档说数据保护功能必须具有巨大的页面启用功能？

另外，我们尝试返回没有DG的状态数据库。
即使在禁用所有启用的DG参数 (LOG_ARCHIVE_CONFIG，LOG_ARCHIVE_DEST_2，
日志 _ 归档 _ dest_state_2，FAL_CLIENT，FAL_SERVER，STANDBY_FILE_MANAGEMENT) 和重新启动数据库
-我们遇到了上述错误-大量交换和低性能。我们不使用DG经纪人。
我得出的结论是，禁用DG参数后-数据保护没有被禁用，
因为我们继续得到错误。
4.是否可以禁用Data Guard (在不使用DG Broker的状态下)，因为它已成为独立服务器，并完全从备用数据库服务器中切断？

问候!

我们用于消息的规则是总换入 + 换出百分比超过某个阈值 (2%)。

但是看看你的数字 (我将重点放在最后一个配置上):

SGA_TARGET: 8192 MB
自启动以来分配的最大PGA: 4446 MB

在12g机器上已经是12.5G了，所以我对您看到有关内存压力的警报并不感到惊讶。而且由于在8g配置中，您的最大PGA为5G，因此您的流程似乎很可能需要更多的内存，如果它们可用的话。

因此，我暂时将DataGuard放在一边，并专注于识别 * 哪些 * 进程正在消耗所有内存。

select
  st.sid,
  s.name, 
  st.value
from v$statname s, v$sesstat st
where st.statistic# = s.statistic#
and s.name = 'session pga memory max';
复制

是一个简单的起点。获取麻烦制造者的SID，然后查看它们映射到哪些会话。如果它们是您的应用程序，那么您需要进行一些代码检查。如果它们是Oracle会话，那么您可以提出一个案例来支持并完成一些分析。

关于巨大页面的话题，如果你有

a) 大型SGA，以及
b) 很多会议

然后会有相当大的好处。这里有几篇关于这个主题的博客文章

https://kevinclosson.net/2009/07/25/little-things-doth-crabby-make-%E2%80%93-part-ix-sometimes-you-have-to-really-really-want-your-hugepages/

https://kevinclosson.net/2009/07/28/quantifying-hugepages-memory-savings-with-oracle-database-11g/