一分钟查一个案例带你看看Oracle数据库到底有多牛逼性能难题
OracleSQL性能优化及案例分析
OracleSQL性能优化及案例分析标题：Oracle SQL性能优化及案例分析一、引言Oracle数据库作为全球最受欢迎的数据库之一，其性能优化问题一直是用户和开发者的焦点。
尤其是在处理大量数据或复杂查询时，性能问题可能会严重影响应用程序的响应时间和用户体验。
因此，对Oracle SQL进行性能优化及案例分析显得尤为重要。
二、Oracle SQL性能优化1、索引优化索引是提高Oracle SQL查询性能的重要工具。
通过创建合适的索引，可以大大减少查询所需的时间，提高数据库的响应速度。
然而，过多的索引可能会导致额外的存储空间和插入、更新、删除的性能损失。
因此，需要根据实际应用的需求，合理地选择需要索引的字段。
2、查询优化编写高效的SQL查询语句也是提高Oracle SQL性能的关键。
这包括选择正确的查询语句、避免在查询中使用复杂的子查询、使用连接（JOIN）代替子查询等。
还可以使用Oracle SQL Profiler来分析和优化查询语句的性能。
3、数据库参数优化Oracle数据库有许多参数可以影响SQL性能，如内存缓冲区、磁盘I/O参数等。
根据实际应用的需求和硬件环境，对这些参数进行合理的调整，可以提高Oracle SQL的性能。
三、案例分析1、案例一：索引优化问题描述：在一个电商系统中，用户在搜索产品时，使用全文本搜索功能时经常出现延迟。
解决方案：通过分析用户搜索的习惯和需求，对产品表的名称和描述字段创建全文索引。
同时，调整Oracle的全文搜索参数以提高搜索效率。
2、案例二：查询优化问题描述：在一个银行系统中，客户查询自己的贷款信息时，查询时间过长。
解决方案：通过使用Oracle SQL Profiler分析查询语句，发现查询中存在复杂的子查询。
将子查询改为连接（JOIN）方式，减少了查询时间。
3、案例三：数据库参数优化问题描述：在一个大型电商系统中，用户在访问高峰期经常遇到响应时间过长的问题。
数据库查询性能优化的经典案例分享
数据库查询性能优化的经典案例分享概述：随着互联网和大数据的发展，数据库成为了现代应用开发中的核心组成部分。
在应用程序中，大量的数据查询操作对数据库性能提出了巨大的挑战。
为了提高用户的体验和系统的响应速度，数据库查询性能优化变得至关重要。
本文将分享一些经典的案例，以展示常见的数据库查询性能优化技术。
案例一：索引优化索引是提高数据库查询性能的关键机制。
在一个大型的数据集中，使用索引可以大大减少查询所需的时间。
然而，不正确的索引设计可能会导致性能下降，甚至更糟糕的结果。
因此，我们需要仔细考虑索引的设计和使用。
案例二：查询重构查询的编写方式和查询的性能密切相关。
一些查询可能会导致全表扫描或使用不必要的临时表，这会导致性能下降。
通过对查询进行重构，优化关联条件、使用合适的连接方式、避免使用通配符等，可以有效减少查询的执行时间。
案例三：数据分区在处理大量数据时，数据分区技术可以将数据划分为多个分区，从而提高查询效率。
通过将数据分散存储在多个物理位置上，可以实现并行查询和负载均衡，改善数据库的性能。
同时，数据分区还可以减少索引的大小，加快索引的扫描速度。
案例四：内存优化内存是数据库查询性能优化的重要因素之一。
通过将常用的表和索引数据加载到内存中，可以降低磁盘I/O的使用，加快查询速度。
此外，调整数据库的内存配置参数，扩大内存缓冲区的大小，可以显著提高查询的性能。
案例五：性能监控与调优性能监控是优化数据库查询性能的关键步骤之一。
通过监控数据库的关键性能指标（如CPU使用率、磁盘I/O、响应时间等），可以及时发现性能瓶颈和潜在问题，并进行相应的调优。
使用性能监控工具和技术，可以帮助我们深入了解数据库的运行状况，以及查询的执行计划等信息。
案例六：合理的数据类型选择在数据库设计中，选择合适的数据类型可以极大地影响查询的性能。
使用整数类型替代字符类型、压缩存储数据、避免存储冗余数据等策略，都可以减少存储空间和提升查询效率。
Oracle数据库性能优化与案例分析
千里之行，始于足下。
Oracle数据库性能优化与案例分析Oracle数据库性能优化是指通过调整数据库的配置参数、优化SQL语句、增加索引等措施，以提升数据库的响应速度、减少资源消耗和提高系统的稳定性的过程。
下面是一个案例分析，介绍了一个实际的Oracle数据库性能优化案例。
案例分析：某公司使用Oracle数据库存储了大量的销售数据，随着数据量的增加，数据库的性能逐渐下降。
经过检查，发现以下问题：1. 缺少必要的索引：在数据库中存在大量的查询操作，但是缺少必要的索引导致查询效率低下。
解决方法：根据查询需求，为经常用到的列添加合适的索引，可以通过分析查询语句的执行计划来确定需要哪些索引。
同时，也要注意避免过多的索引导致性能下降。
2. SQL语句性能低下：存在一些复杂的SQL语句，执行时间较长。
解决方法：对于复杂的SQL语句，可以通过优化查询语句和重构查询逻辑来提升性能。
可以考虑使用JOIN操作替代子查询，避免使用全表扫描等。
3. 数据库参数设置不合理：数据库的一些配置参数没有进行调整，导致性能下降。
第1页/共2页锲而不舍，金石可镂。
解决方法：根据数据库的性能需求，适当调整一些关键的配置参数，如SGA和PGA的大小、缓冲区大小等。
4. 数据库统计信息过期：数据库的统计信息没有及时更新，导致查询优化器的估算不准确。
解决方法：定期收集和更新统计信息，可以使用Oracle提供的统计信息收集工具或者手动收集统计信息。
通过以上优化措施，可以显著提升Oracle数据库的性能，提高系统的响应速度和稳定性。
但需要注意，在进行性能优化时需要综合考虑多个因素，不能片面追求性能提升而导致其他问题的出现。
另外，性能优化也是一个持续的过程，需要定期检查和优化。
一分钟查一个案例带你看看Oracle数据库到底有多牛逼性能难题
一分钟查一个案例带你看看Oracle数据库到底有多牛逼性能难题问题来了电话响了，是一位证券客户 DBA 的来电，看来，问题没过两天，又出现了。
接起电话，果不其然。
“小y,前天那个问题又重现了。
重启后恢复正常，这次抓到了hangAnalyze,不过领导在身后一直催，所以没来得及抓取 systemstate dump 就重启了。
你尽快帮忙分析下吧，hanganalyze 的 trace 文件已经转到你邮箱了。
”就在 2 天前，该客户找到小 y, 他们有一套比较重要的系统出现了数据库无法登陆的情况，导致业务中断，重启后业务恢复，但原因未明，搞的他们压力很大。
可惜的是，他们是事后找过来，由于客户现场保护意识不足，最后也只能是巧妇难为无米之炊了…总的来说，小 y 还算是比较熟悉证券行业的。
毕竟，小 y 多年来一直在银行、证券、航空等客户提供数据库专家支持服务，这其中就包括了北京排名前 6 的所有证券公司。
简而言之，证券行业的要求就是快速恢复，快速恢复业务大于一切。
原因很简单，股价瞬息万变，作为股民，如果当时无法出售或者购买股票，甚至可能引发官司。
所以，证券核心交易系统如果中断时间超过 5 分钟，则可以算得上是严重故障了，一旦被投诉，则可能会被证监会通报，届时业务可能被降级，影响到证券公司的经营和收益。
结合这个特点，小 y 为客户制定了应急预案，看来收集 systemstate dump 是来不及了，只能先收集 hangAnalyze, 时间来得及的话则可以继续收集 systemstate dump。
收集 hangAnalyze 的命令很简单，照敲就是了，没什么技术含量。
$sqlplus –prelim “/as sysdba”SQL>oradebug setmypidSQL>oradebug hanganalyze 3.. 此处等上一会 ..SQL>oradebug hanganalyze 3 SQL>oradebugtracefile_name开启分析之旅1、hanganalyze 初体验打开附件，内容如下，中间部分太长了，所以用省略号代替。
Oracle数据库性能优化与案例分析
Oracle数据库性能优化与案例分析
性能优化探讨
• 原因：为什么？ • 慢（响应时间） • 慢（吞吐量）
性能优化探讨
• 目的：为了什么？ • 快（响应时间） • 快（吞吐量）
性能优化之案例分析
• 案例之方法论 • 案例之登录访问 • 案例之资源 • 案例之锁
性能优化方法论发展
• 登录输入指标测量 • Logons：= EndSnap. logons cumulative– StartSnap. logons
cumulative。 • Logons Per Second:= Logons / TimeInterval
案例之登录访问
登录输出指标测量：
Logon Response Time:= Network Response Time * 10 + Native TCP Logon :=Network Response Time * 10 + Listener Response Time + Native IPC Logon Time 。
案例之登录访问
• 例：
•
某医院HIS业务系统的账户登录操作异常缓慢，部分情况下
甚至会出现长时间的卡壳情况，业务影响主要发生在每天早上
的上班时刻。
案例之登录访问
优化过程： • 账户登录过程一般涉及到在账户表格以及对应日志表格上的冲
突，比如Buffer busy waits或者TX lock。AWR未体现该特征。 • AWR报告显示connection management call elapsed time时间偏长
成功率：98% 高 失败率：2% 低
失败人数：500*2%=10
数据库性能优化案例分析和优化数据库性能的实际案例
数据库性能优化案例分析和优化数据库性能的实际案例数据库作为管理和存储数据的重要工具，在现代信息系统中扮演着至关重要的角色。
然而，随着数据量的不断增长和业务的复杂化，数据库性能问题也随之而来。
为了解决这些问题，数据库性能优化成为了关注的焦点。
本文将通过分析实际案例，探讨数据库性能优化的方法和实践。
一、案例一：查询性能优化在一个电商平台的数据库中，查询操作占据了绝大部分的数据库负载。
客户在平台上进行商品搜索等操作时，查询的速度变慢，影响了用户体验和交易效率。
经过分析，我们发现以下几个问题：1. 没有适当的索引：索引是加速数据库查询的关键因素。
在该案例中，我们发现很多查询语句没有合适的索引，导致数据库需要进行全表扫描，严重影响了查询的速度。
解决方案：根据实际查询需求和数据表的特点，合理地创建索引，以提高查询效率。
但是需要注意的是，过多或者过少的索引都会对性能产生负面影响，需要做好平衡。
2. 查询语句优化：检查并优化查询语句，避免使用过于复杂的 SQL 语句，例如多重嵌套查询、不必要的关联等。
通过优化查询语句，减少数据库的负载，提高查询速度。
3. 数据库服务器性能不足：在高峰期，数据库服务器的性能出现瓶颈，无法满足用户的查询需求。
这可能是由于硬件配置不足或者数据库参数设置不合理等原因。
解决方案：可以考虑升级硬件设备，并对数据库参数进行调整，以提高数据库服务器的性能。
二、案例二：写入性能优化在一个订单管理系统的数据库中，写入操作频繁而且耗时较长，导致订单处理效率低下。
在分析问题原因后，发现以下几个关键问题：1. 锁冲突：在高并发情况下，多个写入操作会引发锁竞争，导致大量的阻塞和等待，进而降低数据库的写入性能。
解决方案：通过合理的事务隔离级别和锁调整，减少锁的粒度，降低锁冲突的可能性。
可以使用乐观锁或者行级锁来解决并发写入问题。
2. 数据库日志写入性能不足：数据库的写入操作通常需要将数据写入到日志中，以确保数据的持久性。
Oracle数据库常见的瓶颈问题与性能监测工具
内容摘要：数据库系统的性能最终了决定数据库的可用性和生命力。
大多数数据库系统在运行一段时间后都会存在一定的性能问题，主要涉及数据库硬件、数据库服务器、数据库内存、应用程序、操作系统、数据库参数等方面。
因此，基于数据库系统的性能调整与优化对于整个系统的正常运行起着至关重要的作用。
数据库性能调整与优化涉及到多个层面，通过统一规划、系统分析做出相应的调整，可以提高数据库的稳定性和可用性，保障系统高效地运行，解决系统瓶颈，节约系统开销，具有良好的应用价值，同时也对理论研究提供了一定的方法指导。
基于此，论文将Oracle 10g数据库的内存分配、磁盘I/O以及SQL语句等方面的性能调整与优化问题作为主要研究内容，对其进行了深入地分析和讨论，给出了一般情况下Oracle数据库应用系统的性能调整策略及优化方法。
关键词：Oracle 10g 数据库；体系结构；系统全局区；性能调整与优化AbstractAbstract: The performance of database systems eventually determines their availability and survivability. Most of them will bring about some performance problems more or less after running for a period of time, which mainly involve database hardware, database server, database memory, applications, operating systems and database parameters, etc. Therefore,performance tuning and optimization of database systems,which concern multiple aspects, are very vital to the normal running of the whole system. We can improve the stability and availability of database, guarantee its high running efficiency,solve system bottleneck, reduce system overhead, obtain considerable applicability and in them meanwhile, provide some guidelines for theoretical research through a unified plan and systematical analysis to make appropriate adjustment.Based on the above-mentioned idea, the paper principally pays attention to the research on the performance tuning and optimization problems of memory allocation of Oracle 10g, disc I/O, SQL statements, etc, and makes a further analysis and discuss. Besides, it provides some performance tuning strategies and optimization approaches of Oracle application system in general condition.Key Words: Oracle 10g Database不Architecture不System Global Area不 Adjustment and Optimization of Performance1 导言网格技术是本世纪初最新和最有吸引力的技术之一，数据库管理系统作为信息系统的基本支撑在信息化建设中扮演着重要的要色。
数据库性能优化方法&案例分析
开发、设计、运行维护各阶段 均可能导致性能问题
案例3：神奇的Oracle内部参数
• 内部参数列表
Parameter Name _b_tree_bitmap_plans _bump_highwater_mark_count _cursor_features_enabled _db_block_hash_buckets _db_block_hash_latches _db_block_numa _enable_NUMA_optimization _enqueue_hash_chain_latches _fix_control _in_memory_undo _index_join_enabled _optim_peek_user_binds _optimizer_mjc_enabled _sort_elimination_cost_ratio _sqlexec_progression_cost _table_lookup_prefetch_size _wait_for_sync Begin value FALSE 30 10 134217728 1048576 1 FALSE 256 5705630:ON, 5765456:3 TRUE FALSE FALSE FALSE 10 0 0 FALSE End value (if different)
的优化效果 80%的性能问题可以由20%的优 化技术所解决
应用开发技术运用策略
比较项目 操作特点 响应速度 吞吐量 并发访问量 联机业务 批处理业务 日常业务操作，尤其是包含 后台操作，例如统计报表、 大量前台操作 大批量数据加载 优先级最高，要求反应速度 要求速度高、吞吐量大 非常高 小 非常高 小 大 不高 大
自底向上
数据库性能管理的全面性
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
一分钟查一个案例带你看看Oracle数据库到底有多牛逼性能难题问题来了电话响了，是一位证券客户 DBA 的来电，看来，问题没过两天，又出现了。
接起电话，果不其然。
“小y,前天那个问题又重现了。
重启后恢复正常，这次抓到了hangAnalyze,不过领导在身后一直催，所以没来得及抓取 systemstate dump 就重启了。
你尽快帮忙分析下吧，hanganalyze 的 trace 文件已经转到你邮箱了。
”就在 2 天前，该客户找到小 y, 他们有一套比较重要的系统出现了数据库无法登陆的情况，导致业务中断，重启后业务恢复，但原因未明，搞的他们压力很大。
可惜的是，他们是事后找过来，由于客户现场保护意识不足，最后也只能是巧妇难为无米之炊了…总的来说，小 y 还算是比较熟悉证券行业的。
毕竟，小 y 多年来一直在银行、证券、航空等客户提供数据库专家支持服务，这其中就包括了北京排名前 6 的所有证券公司。
简而言之，证券行业的要求就是快速恢复，快速恢复业务大于一切。
原因很简单，股价瞬息万变，作为股民，如果当时无法出售或者购买股票，甚至可能引发官司。
所以，证券核心交易系统如果中断时间超过 5 分钟，则可以算得上是严重故障了，一旦被投诉，则可能会被证监会通报，届时业务可能被降级，影响到证券公司的经营和收益。
结合这个特点，小 y 为客户制定了应急预案，看来收集 systemstate dump 是来不及了，只能先收集 hangAnalyze, 时间来得及的话则可以继续收集 systemstate dump。
收集 hangAnalyze 的命令很简单，照敲就是了，没什么技术含量。
$sqlplus –prelim “/as sysdba”SQL>oradebug setmypidSQL>oradebug hanganalyze 3.. 此处等上一会 ..SQL>oradebug hanganalyze 3 SQL>oradebugtracefile_name开启分析之旅1、hanganalyze 初体验打开附件，内容如下，中间部分太长了，所以用省略号代替。
朋友们，不妨自己停下来，耐心阅读一下，看看是否可以看的明白。
很快，根据这个 trace, 小 y 在一分钟找到了问题原因。
而这种问题，在其它数据库中属于很难查清的问题。
所以不得不说，Oracle 的 hangAnalyze 是如此的牛逼…问题原因就在后面，什么时候往下翻，由你决定…2、如何开始先看 trace 的第一部分，如下所示：上面的信息为出现异常时数据库的整体状态摘要，这些信息表示：1）共 76 个会话被 sid=494 的会话阻塞，原因是 sid=494 的会话本身申请 latch: shared pool资源时被其他会话阻塞。
2）共 22 个会话被 sid=496 的会话阻塞，原因是 sid=496 的会话本身申请 latch: shared pool资源时被其他会话阻塞。
3）共11个会话被sid=598的会话阻塞，”No Wait”表示sid=598的会话本身并未等待任何资源，即该进程在使用 CPU。
4）共 13 个会话被 sid=518 的会话阻塞，原因是 sid=518 的会话本身申请 latch: shared pool 资源时被其他会话阻塞。
用一张图来表示，如下所示：3、找到阻塞的源头会话 494、496、598、518 之间可能相互独立，也可能存在互相阻塞的关系。
小 y 带着大家继续往下梳理。
从抓取到的 hanganalyze 信息摘取上述会话信息的细节，如下所示 :在该信息中，关注 4 列的内容即可，其中：第 1 列为 oracle 给 trace 中每一个会话所取的唯一逻辑标识；第 3 列表示会话 sid；第 6 列表示操作系统进程号；第 10 列表示阻塞该会话的唯一逻辑标识，为空时表示无阻塞。
因此，从上述信息可知：1)sid=494 的会话被唯一逻辑标识为 597 的会话阻塞2)sid=496 的会话被唯一逻辑标识为 597 的会话阻塞3)sid=518 的会话被唯一逻辑标识为 597 的会话阻塞而唯一逻辑标识为 597 的会话信息为 :即唯一逻辑标识为 597 的会话的 sid=598, 操作系统进程号 553382，该行的第 10 列为空，即再也没有其他会话阻塞 sid=598 的会话。
也就是说，sid=598 的会话就是数据库异常时的会话获取资源时阻塞的源头。
如下图所示：4、陷入僵局？（阻塞的源头只是一个数字！）前面的分析，已经找到了源头是 SID=598 的会话。
那么 sid=598 的会话是什么用户什么程序什么机器发起，在执行什么 SQL，进程的 callstack 是什么呢？所有这些信息，我们都可以在systemstate dump 中可以找到，但可惜的是，客户虽然由于时间关系没有来得及抓取 systemstate dump，因此无法进一步获取该进程的信息。
悲剧了！难道要再一次陷入巧妇难为无米之炊的尴尬境地么？如果是你，你会怎么办，此处不妨思考几分钟…5、找到打开天堂大门的钥匙打开天堂之门的钥匙有很多把，但上帝总是会眷恋把握细节和用心的人。
难道因为缺少systemstatedump 就放弃了么？那客户怎么办？这里介绍其中一把钥匙，当然还有其他钥匙，如果你也找到了其他钥匙，不妨留言告诉小 y。
继续看阻塞源头的相关信息。
SID=598 的会话，在操作系统上的进程号是 553382。
一个进程要么是前台进程（服务进程），要么是后台进程。
如果是后台进程，则我们可以在 alert 日志中，找到操作系统上进程号是 553382 对应的后台进程到底是什么！打开 alert 日志，果然不出所料，凶手真的是他如下所示 :因此，造成数据库异常的源头就是数据库后台进程mman 进程 !即负责 ORACLE 内存动态调整的后台进程！该进程在数据库中负责SGA 内存在各个组件比如buffer cache 和shared pool 之间的动态调整。
通俗的来说，我们在配置数据库所使用的相关内存参数时，在 10g 版本之前，需要手工设置 buffer cache 和 shared pool 的大小，但是 10g 版本后，为了简化管理，可以只设置 buffer cache 和 shared pool 加起来的总内存大小，不需要关注单独为 buffercache和shared pool设置多大的内存，数据库后台进程mman进程可以在两者之间根据需要动态调整。
很多客户都默认地选择了这样一种智能但并不完美的内存管理方式。
那么整个系统中，是否有出现 SGA 内存动态调整的情况呢 ?摘取问题当天其他时段，例如 15 点到 16 点之间的 AWR 报告，观察该系统的情况。
（数据库重启后无法观察到问题时段 v$sga_resize_ops 了）从中可以看到，shared pool 在15 点时的大小为3584M，到了16 点就已经被动态调整到了1760M, 这些就是由后台mman 进程来完成的。
如此大幅度的下降，说明期间经历过多次的调整，不断的对shared pool 进程 shrink 操作。
那么到底是 sharedpool 中的哪部分内存被挪到了 buffercache 呢？从 AWR 报告的 SGA breakdown difference 可以看到：SQL AREA 从 2088M 降至 370M，被刷出了82% ！SQLAREA 大量的内存被挪走，SQL 语句( 含登陆的递归 SQL) 必然被大量刷出，后续需要硬解析（hanganalyze 可以看到有latch:shared pool）。
6、进一步分析原因根据上述分析，有一个问题仍然需要确认 :那就是为什么 SGA 动态调整导致如此严重的问题？这明显与 ORACLE 的 BUG 相关。
当发现整个系统 buffer cache 命中率低、物理读高的时候，buffer cache 需要从sharedpool 中借走部分内存（由 MMAN 进程来负责完成动态调整）。
当需要借走的 granula 属于 shared pool 的SQL AREA, 但是由于 SQL 语句长时间在执行，SQL AREA 被 pin 住，MMAN 进程持有了 latch:shared pool 又不得不等，就容易导致其他进程无法获得 latch:shared pool 而引发问题。
当然，还有包括 ORACLE 内部实现动态机制的机制不够合理和高效等缺陷，也可能导致 SGA 动态调整引发问题。
实际上，小y的经验是，但凡涉及到内存动态调整的，不管是数据库，还是操作系统，都可能出现问题，例如操作系统的透明大页内存转换，就可能导致 kernel hang 。
如果想要查 BUG, 从上文的分析中可以知道，大概搜索的关键字是 MMAN 进程、latch Child shared pool 和 shrink 和 CPU, 以此为关键字在 ORACLE METALINK BUG 库中查找相关 BUG，与“ Bug 8211733- Shared pool latch contention when shared pool is shrinking [ID 8211733.8]”中的描述吻合，但缺少 systemstate dump, 无法核对 call stack, 因此无法完全确认。
但具体到该 CASE，核对 SGA 动态调整的具体 BUG 号的意义不大，因为 SGA 在各个版本中还是存在或多或少的问题，个别补丁不能完全预防隐患，最有效的解决办法时关闭 SGA 动态调整，使用手工管理的方式进行，同时为了避免关闭动态调整后的副作用，需要对应用进行对应的优化和调整。
7、头脑风暴之是否可以不关闭 SGA 动态调整来解决问题呢各位看官不妨也想一想这个问题？答案是当然可以，但是不知道能持续多长时间，因为应用可能在变，SQL 可能在变。
说可以，是因为，可以看到，该系统物理读高的SQL 有不少，并且很多 SQL 单次执行时间超过 100 秒！如果 SQL 语句优化后，buffercache 就几乎不需要动态调大了，同时SQL 优化后执行时间短了，需要 pin 的时间也短了，几个因素变好了，问题遇到的概率就小很多很多。
如果 SQL 语句短期无法优化和解决呢？如下图所示，物理读主要集中在两张表，并且表不大，因此可以通过 keep 到内存也可以解决物理读高导致动态调整的问题。
8、头脑风暴之如何避免关闭内存动态调整后的副作用单纯的关闭 SGA 动态调整，意味着 shared pool 没有自动增大的机会，可能因为内存碎片化导致ORA-4031 的几率增大，特别是对于硬解析较高的系统。