我正在研究大约一年前升级到Oracle 10g(现为10.2.0.5)的数据仓库系统。
数据库设置为workarea_size_policy=auto
和pga_aggregate_target=1G
。大多数ETL过程都是用PL / SQL编写的,这段代码通常设置workarea_size_policy=manual
,并在构建仓库的特定部分时为特定会话设置SORT_AREA_SIZE
和HASH_AREA_SIZE
。
为SORT_AREA_SIZE
和HASH_AREA_SIZE
选择的值对于构建的不同部分是不同的。这些大小可能基于将在每个区域中处理的预期数据量。
我遇到的问题是此代码开始导致出现大量ORA-600错误。这让我想知道我们是否应该完全覆盖自动设置。
设置手动设置的代码是多年前由不再在这里的开发人员编写的。它最初可能是为Oracle 8编写的,修订版为Oracle 9,将workarea_size_policy设置为手动。没有人真正知道如何找到用于HASH_AREA_SIZE和SORT_AREA_SIZE的值。对于我所知道的一切,它们可能完全不合适。
在那么长的序言之后,我有几个问题。
我知道这是一个非常广泛的问题,但我们将不胜感激。
答案 0 :(得分:1)
我建议你注释掉手动设置并仅使用自动(动态)设置进行测试运行,例如PGA_AGGREGATE_TARGET
。
自Oracle 8以来,Sort和Hash内存区域的管理已经有了很大的改进。
很难预先确定程序的内存要求,因此最好使用具有代表性的数据量来测试它们,看看它是如何进行的。
然后,您可以创建一个AWR报告,其中包含执行过程的时间范围。报告中有一节名为 PGA内存咨询。这将告诉您是否需要根据当前数据量为PGA_AGGREGATE_TARGET
分配更多内存。
请参阅sample here:
在这种情况下,您可以清楚地看到,不需要查看当前分配的103 MB,实际上您可以保持52 MB而不会影响应用程序。
根据我们所讨论的卷,如果您无法分配更多内存,则某些排序或散列操作可能会溢出到TEMPORARY
表空间,因此请确保您具有适当大小的内容并且可能会传播跨越尽可能多的磁盘/卷(请参阅SAME配置,here)。