如何优化oracle网络 oracle效率优化

如何对Oracle进行优化

Oracle有很多值得学习的地方，这里我们主要介绍Oracle优化，包括介绍可变参数的Oracle优化等方面。数据库系统和操作系统一样，在计算机上安装成功后，还需要进一步配置和优化，从而使其具有更强大的功能和运行在最佳状态。如果在设计阶段因为各种因素没有进行较为合理的配置和计划，那么就需要在后期对数据库系统进行优化。

创新互联公司服务项目包括龙潭网站建设、龙潭网站制作、龙潭网页制作以及龙潭网络营销策划等。多年来，我们专注于互联网行业，利用自身积累的技术优势、行业经验、深度合作伙伴关系等，向广大中小型企业、政府机构等提供互联网行业的解决方案，龙潭网站推广取得了明显的社会效益与经济效益。目前，我们服务的客户以成都为中心已经辐射到龙潭省份的部分城市，未来相信会继续扩大服务区域并继续获得客户的支持与信任！

数据库系统性能的优化，除了在设计阶段对其逻辑存储结构和物理存储结构设计进行优化，使之在满足需求条件下，时空开销性能最佳外，还可在运行阶段，采取一些优化措施，使系统性能最佳。本专题所讨论的性能优化主要指运行阶段的性能优化，即讨论如何使用Oracle所提供的优化手段来提高系统性能。大多数性能问题并不是一种孤立的症状，而是系统设计的结果，因此性能优化就集中在那些导致不可接受特征的同一的、固定的和潜在的问题上。优化是数据库设计中“计划”、 “设计”、“监视”和“优化”四大步骤的最后一步。除了用Oracle优化器来优化数据库的性能外，DBA还可通过Oracle优化的参数设置等手段来优化数据库的性能，对参数的细微优化便能影响系统整体性能。

如何进行oracle数据库性能优化

你最好买一本专门讲ORACLE性能优化的书，好好看看\x0d\x0a1、调整数据库服务器的性能\x0d\x0aOracle数据库服务器是整个系统的核心，它的性能高低直接影响整个系统的性能，为了调整Oracle数据库服务器的性能，主要从以下几个方面考虑： \x0d\x0a1.1、调整操作系统以适合Oracle数据库服务器运行\x0d\x0aOracle数据库服务器很大程度上依赖于运行服务器的操作系统，如果操作系统不能提供最好性能，那么无论如何调整，Oracle数据库服务器也无法发挥其应有的性能。 \x0d\x0a1.1.1、为Oracle数据库服务器规划系统资源 \x0d\x0a据已有计算机可用资源, 规划分配给Oracle服务器资源原则是：尽可能使Oracle服务器使用资源最大化,特别在Client/Server中尽量让服务器上所有资源都来运行Oracle服务。 \x0d\x0a1.1.2、调整计算机系统中的内存配置 \x0d\x0a多数操作系统都用虚存来模拟计算机上更大的内存，它实际上是硬盘上的一定的磁盘空间。当实际的内存空间不能满足应用软件的要求时，操作系统就将用这部分的磁盘空间对内存中的信息进行页面替换，这将引起大量的磁盘I/O操作，使整个服务器的性能下降。为了避免过多地使用虚存，应加大计算机的内存。 \x0d\x0a1.1.3、为Oracle数据库服务器设置操作系统进程优先级 \x0d\x0a不要在操作系统中调整Oracle进程的优先级，因为在Oracle数据库系统中，所有的后台和前台数据库服务器进程执行的是同等重要的工作，需要同等的优先级。所以在安装时，让所有的数据库服务器进程都使用缺省的优先级运行。 \x0d\x0a1.2、调整内存分配\x0d\x0aOracle数据库服务器保留3个基本的内存高速缓存，分别对应3种不同类型的数据：库高速缓存，字典高速缓存和缓冲区高速缓存。库高速缓存和字典高速缓存一起构成共享池，共享池再加上缓冲区高速缓存便构成了系统全程区(SGA)。SGA是对数据库数据进行快速访问的一个系统全程区，若SGA本身需要频繁地进行释放、分配，则不能达到快速访问数据的目的，因此应把SGA放在主存中，不要放在虚拟内存中。内存的调整主要是指调整组成SGA的内存结构的大小来提高系统性能，由于Oracle数据库服务器的内存结构需求与应用密切相关，所以内存结构的调整应在磁盘I/O调整之前进行。 \x0d\x0a1.2.1、库缓冲区的调整 \x0d\x0a库缓冲区中包含私用和共享SQL和PL/SQL区，通过比较库缓冲区的命中率决定它的大小。要调整库缓冲区，必须首先了解该库缓冲区的活动情况，库缓冲区的活动统计信息保留在动态性能表v$librarycache数据字典中，可通过查询该表来了解其活动情况，以决定如何调整。 \x0d\x0a \x0d\x0aSelect sum(pins),sum(reloads) from v$librarycache; \x0d\x0a \x0d\x0aPins列给出SQL语句，PL/SQL块及被访问对象定义的总次数；Reloads列给出SQL 和PL/SQL块的隐式分析或对象定义重装载时在库程序缓冲区中发生的错误。如果sum(pins)/sum(reloads) ≈0，则库缓冲区的命中率合适；若sum(pins)/sum(reloads)1, 则需调整初始化参数 shared_pool_size来重新调整分配给共享池的内存量。 \x0d\x0a1.2.2、数据字典缓冲区的调整 \x0d\x0a数据字典缓冲区包含了有关数据库的结构、用户、实体信息。数据字典的命中率，对系统性能影响极大。数据字典缓冲区的使用情况记录在动态性能表v$librarycache中，可通过查询该表来了解其活动情况，以决定如何调整。 \x0d\x0a \x0d\x0aSelect sum(gets),sum(getmisses) from v$rowcache; \x0d\x0a \x0d\x0aGets列是对相应项请求次数的统计；Getmisses 列是引起缓冲区出错的数据的请求次数。对于频繁访问的数据字典缓冲区，sum(getmisses)/sum(gets)10%～15%。若大于此百分数，则应考虑增加数据字典缓冲区的容量，即需调整初始化参数shared_pool_size来重新调整分配给共享池的内存量。 \x0d\x0a1.2.3、缓冲区高速缓存的调整 \x0d\x0a用户进程所存取的所有数据都是经过缓冲区高速缓存来存取，所以该部分的命中率，对性能至关重要。缓冲区高速缓存的使用情况记录在动态性能表v$sysstat中，可通过查询该表来了解其活动情况，以决定如何调整。 \x0d\x0a \x0d\x0aSelect name,value from v$sysstat where name in ('dbblock gets','consistent gets','physical reads'); \x0d\x0a \x0d\x0adbblock gets和consistent gets的值是请求数据缓冲区中读的总次数。physical reads的值是请求数据时引起从盘中读文件的次数。从缓冲区高速缓存中读的可能性的高低称为缓冲区的命中率，计算公式： \x0d\x0a \x0d\x0aHit Ratio=1-(physical reds/(dbblock gets+consistent gets)) \x0d\x0a \x0d\x0a如果Hit Ratio60%～70%，则应增大db_block_buffers的参数值。db_block_buffers可以调整分配给缓冲区高速缓存的内存量，即db_block_buffers可设置分配缓冲区高速缓存的数据块的个数。缓冲区高速缓存的总字节数=db_block_buffers的值*db_block_size的值。db_block_size 的值表示数据块大小的字节数，可查询 v$parameter 表： \x0d\x0a \x0d\x0aselect name,value from v$parameter where name='db_block_size'; \x0d\x0a \x0d\x0a在修改了上述数据库的初始化参数以后，必须先关闭数据库，在重新启动数据库后才能使新的设置起作用。

在Linux系统下如何优化Oracle具体步骤

1. 标准优化：遵从Oracle技术文档中的说明tune你的Linux，比如共享内存等等。这里不赘述了，因为文档中很全。 2. 根据你的使用情况采取Dedicate型或MTS型数据库。详细方法也看文档。 3. 如果你不是对数据库中的Java应用特别有需求的话，不要装它，也不要启动它。（如果你装了的话） 4. 对你的服务器来说，最好专用。如果你不专用，说明你对性能并不那么敏感，也用不着优化了。 5. 内存越大越好。但Linux对内存大小有限制，因此需要去找一些Patch。 6. 下载一个SGI's POSIX Asynchronous I/O and Raw I/O的内核Patch。它能大幅度提高你数据文件的访问速度。 9. 这里是一个示例程序: set -a VM=/proc/sys/vm BDFLUSH="40 1024 64 256 500 3000 500 1884 2" BUFFERMEM="5 8 10" FREEPAGES="512 1024 3072" OVERCOMMIT="1" case $1 in start) echo "$BDFLUSH"$VM/bdflush echo "$BUFFERMEM"$VM/buffermem echo "$FREEPAGES"$VM/freepages echo "$OVERCOMMIT"$VM/overcommit_memory /sbin/hdparm -k -u 1 -m 32 -c 1 /dev/hda; /sbin/hdparm -k -u 1 -m 16 -c 1 /dev/hdc; ;; stop) touch /root/shouldnt.happen; ;; *) echo "USAGE $0 {start|stop}"; ;; esac;10. 如果你有Solaris for X86的话，可以运用它的分区工具把你的所有分区都改成UFS。

ORACLE性能调优遵循的基本原则

任何事情都有它的源头 要解决问题 也得从源头开始 影响ORACLE性能的源头非常多 主要包括如下方面 数据库的硬件配置 CPU 内存 网络条件 CPU 在任何机器中CPU的数据处理能力往往是衡量计算机性能的一个标志 并且ORACLE是一个提供并行能力的数据库系统 在CPU方面的要求就更高了 如果运行队列数目超过了CPU处理的数目 性能就会下降 我们要解决的问题就是要适当增加CPU的数量了 当然我们还可以将需要许多资源的进程KILL掉 内存 衡量机器性能的另外一个指标就是内存的多少了 在ORACLE中内存和我们在建数据库中的交换区进行数据的交换 读数据时 磁盘I/O必须等待物理I/O操作完成 在出现ORACLE的内存瓶颈时 我们第一个要考虑的是增加内存 由于I/O的响应时间是影响ORACLE性能的主要参数 我将在这方面进行详细的讲解 网络条件 NET*SQL负责数据在网络上的来往 大量的SQL会令网络速度变慢 比如 M的网卡和 的网卡就对NET*SQL有非常明显的影响 还有交换机 集线器等等网络设备的性能对网络的影响很明显 建议在任何网络中不要试图用 个集线器来将网段互联 OS参数的设置 下表给出了OS的参数设置及说明 DBA可以根据实际需要对这些参数进行设置 用户SQL质量 以上讲的都是硬件方面的东西 在条件有限的条件下 我们可以调整应用程序的SQL质量 不要进行全表扫描（Full Table Scan） 全表扫描导致大量的I/O 尽量建好和使用好索引 建索引也是有讲究的 在建索引时 也不是索引越多越好 当一个表的索引达到 个以上时 ORACLE的性能可能还是改善不了 因为OLTP系统每表超过 个索引即会降低性能 而且在一个sql 中 Oracle 从不能使用超过 个索引 当我们用到GROUP BY和ORDER BY时 ORACLE就会自动对数据进行排序 而ORACLE在INIT ORA中决定了sort_area_size区的大小 当排序不能在我们给定的排序区完成时 ORACLE就会在磁盘中进行排序 也就是我们讲的临时表空间中排序 过多的磁盘排序将会令 free buffer waits 的值变高 而这个区间并不只是用于排序的 对于开发人员我提出如下忠告: ) select update delete 语句中的子查询应当有规律地查找少于 %的表行 如果一个语句查找的行数超过总行数的 % 它将不能通过使用索引获得性能上的提高 ） 索引可能产生碎片 因为记录从表中删除时 相应也从表的索引中删除 表释放的空间可以再用 而索引释放的空间却不能再用 频繁进行删除操作的被索引的表 应当阶段性地重建索引 以避免在索引中造成空间碎片 影响性能 在许可的条件下 也可以阶段性地truncate表 truncate命令删除表中所有记录 也删除索引碎片 ） 在使用索引时一定要按索引对应字段的顺序进行引用 ） 用（+）比用NOT IN更有效率 降低ORACLE的竞争 先讲几个ORACLE的几个参数 这几个参数关系到ORACLE的竞争 ） freelists 和 freelist 组 他们负责ORACLE的处理表和索引的空间管理 ） pctfree 及 pctused 该参数决定了freelists 和 freelist 组的行为 pctfree 和pctused 参数的唯一目的就是为了控制块如何在 freelists 中进出设置好pctfree 及 pctused对块在freelists的移走和读取很重要 其他参数的设置 ） 包括SGA区（系统全局区） 系统全局区（SGA）是一个分配给Oracle 的包含一个 Oracle 实例的数据库的控制信息内存段 主要包括数据库高速缓存(the database buffer cache) 重演日志缓存（the redo log buffer） 共享池（the shared pool） 数据字典缓存（the data dictionary cache）以及其它各方面的信息 ） db_block_buffers（数据高速缓冲区）访问过的数据都放在这一片内存区域 该参数越大 Oracle在内存中找到相同数据的可能性就越大 也即加快了查询速度 ） share_pool_size （SQL共享缓冲池） 该参数是库高速缓存和数据字典的高速缓存 ） Log_buffer （重演日志缓冲区） ） sort_area_size（排序区） ） processes （同时连接的进程数） ） db_block_size （数据库块大小） Oracle默认块为 KB 太小了 因为如果我们有一个 KB的数据 则 KB块的数据库要读 次盘 才能读完 而 KB块的数据库只要 次就读完了 大大减少了I/O操作 数据库安装完成后 就不能再改变db_block_size的值了 只能重新建立数据库并且建库时 要选择手工安装数据库 ） open_links （同时打开的链接数） ） dml_locks ） open_cursors （打开光标数） ） dbwr_io_slaves （后台写进程数） lishixinzhi/Article/program/Oracle/201311/17955

优化数据库的三板斧 大幅提高Oracle性能

几个简单的步骤大幅提高Oracle性能 我优化数据库的三板斧数据库优化的讨论可以说是一个永恒的主题 资深的Oracle优化人员通常会要求提出性能问题的人对数据库做一个statspack 贴出数据库配置等等 还有的人认为要抓出执行最慢的语句来进行优化 但实际情况是 提出疑问的人很可能根本不懂执行计划 更不要说statspack了 而我认为 数据库优化 应该首先从大的方面考虑 网络 服务器硬件配置 操作系统配置 Oracle服务器配置 数据结构组织 然后才是具体的调整 实际上网络 硬件等往往无法决定更换 应用程序一般也无法修改 因此应该着重从数据库配置 数据结构上来下手 首先让数据库有一个良好的配置 然后再考虑具体优化某些过慢的语句 我在给我的用户系统进行优化的过程中 总结了一些基本的 简单易行的办法来优化数据库 算是我的三板斧 呵呵 不过请注意 这些不一定普遍使用 甚至有的会有副作用 但是对OLTP系统 基于成本的数据库往往行之有效 不妨试试 （注 附件是Burleson写的用来报告数据库性能等信息的脚本 本文用到） 一．设置合适的SGA 常常有人抱怨服务器硬件很好 但是Oracle就是很慢 很可能是内存分配不合理造成的 ( )假设内存有 M 这通常是小型应用 建议Oracle的SGA大约 M 其中 共享池（SHARED_POOL_SIZE）可以设置 M到 M 根据实际的用户数 查询等来定 数据块缓冲区可以大致分配 M M i下需要设置DB_BLOCK_BUFFERS DB_BLOCK_BUFFER*DB_BLOCK_SIZE等于数据块缓冲区大小 i 下的数据缓冲区可以用db_cache_size来直接分配 ( )假设内存有 G Oracle 的SGA可以考虑分配 M 共享池分配 M到 M 数据缓冲区分配 M到 M ( )内存 G SGA可以考虑分配 G 共享池 M到 M 剩下的给数据块缓冲区 ( )内存 G以上 共享池 M到 M就足够啦 再多也没有太大帮助 (Biti_rainy有专述)数据缓冲区是尽可能的大 但是一定要注意两个问题 一是要给操作系统和其他应用留够内存 二是对于 位的操作系统 Oracle的SGA有 G的限制 有的 位操作系统上可以突破这个限制 方法还请看Biti的大作吧 二．分析表和索引 更改优化模式 Oracle默认优化模式是CHOOSE 在这种情况下 如果表没有经过分析 经常导致查询使用全表扫描 而不使用索引 这通常导致磁盘I/O太多 而导致查询很慢 如果没有使用执行计划稳定性 则应该把表和索引都分析一下 这样可能直接会使查询速度大幅提升 分析表命令可以用ANALYZE TABLE 分析索引可以用ANALYZE INDEX命令 对于少于 万的表 可以考虑分析整个表 对于很大的表 可以按百分比来分析 但是百分比不能过低 否则生成的统计信息可能不准确 可以通过DBA_TABLES的LAST_ANALYZED列来查看表是否经过分析或分析时间 索引可以通过DBA_INDEXES的LAST_ANALYZED列 下面通过例子来说明分析前后的速度对比 （表CASE_GA_AJZLZ大约有 万数据 有主键）首先在SQLPLUS中打开自动查询执行计划功能 (第一次要执行\RDBMS\ADMIN\utlxplan sql来创建PLAN_TABLE这个表)SQL SET AUTOTRACE ONSQLSET TIMING ON通过SET AUTOTRACE ON 来查看语句的执行计划 通过SET TIMING ON 来查看语句运行时间 SQL select count(*) from CASE_GA_AJZLZ;COUNT(*) 已用时间: : : Execution Plan SELECT STATEMENT Optimizer=CHOOSE SORT (AGGREGATE) TABLE ACCESS (FULL) OF CASE_GA_AJZLZ ……………………请注意上面分析中的TABLE ACCESS(FULL) 这说明该语句执行了全表扫描 而且查询使用了 秒 这时表还没有经过分析 下面我们来对该表进行分析 SQL *** yze table CASE_GA_AJZLZ pute statistics;表已分析 已用时间: : : 然后再来查询 SQL select count(*) from CASE_GA_AJZLZ;COUNT(*) 已用时间: : : Execution Plan SELECT STATEMENT Optimizer=FIRST_ROWS (Cost= Card= ) SORT (AGGREGATE) INDEX (FAST FULL SCAN) OF PK_AJZLZ (UNIQUE) (Cost= Card= )…………………………请注意 这次时间仅仅用了 秒！这要归功于INDEX(FAST FULL SCAN) 通过分析表 查询使用了PK_AJZLZ索引 磁盘I/O大幅减少 速度也大幅提升！下面的实用语句可以用来生成分析某个用户的所有表和索引 假设用户是GAXZUSR SQL set pagesize SQL spool d:\ *** yze_tables sql;SQL select *** yze table ||owner|| ||table_name|| pute statistics; from dba_tables where owner= GAXZUSR ;SQL spool offSQL spool spool d:\ *** yze_indexes sql;SQL select *** yze index ||owner|| ||index_name|| pute statistics; from dba_indexes where owner= GAXZUSR ;SQL spool offSQL @d:\ *** yze_tables sqlSQL @d:\ *** yze_indexes sql解释 上面的语句生成了两个sql文件 分别分析全部的GAXZUSR的表和索引 如果需要按照百分比来分析表 可以修改一下脚本 通过上面的步骤 我们就完成了对表和索引的分析 可以测试一下速度的改进啦 建议定期运行上面的语句 尤其是数据经过大量更新 当然 也可以通过dbms_stats来分析表和索引 更方便一些 但是我仍然习惯上面的方法 因为成功与否会直接提示出来 另外 我们可以将优化模式进行修改 optimizer_mode值可以是RULE CHOOSE FIRST_ROWS和ALL_ROWS 对于OLTP系统 可以改成FIRST_ROWS 来要求查询尽快返回结果 这样即使不用分析 在一般情况下也可以提高查询性能 但是表和索引经过分析后有助于找到最合适的执行计划 三．设置cursor_sharing=FORCE 或SIMILAR 这种方法是 i才开始有的 oracle 不支持 通过设置该参数 可以强制共享只有文字不同的语句解释计划 例如下面两条语句可以共享 SQL SELECT * FROM MYTABLE WHERE NAME= tom SQL SELECT * FROM MYTABLE WHERE NAME= turner 这个方法可以大幅降低缓冲区利用率低的问题 避免语句重新解释 通过这个功能 可以很大程度上解决硬解析带来的性能下降的问题 个人感觉可根据系统的实际情况 决定是否将该参数改成FORCE 该参数默认是exact 不过一定要注意 修改之前 必须先给ORACLE打补丁 否则改之后oracle会占用 %的CPU 无法使用 对于ORACLE i 可以设置成SIMILAR 这个设置综合了FORCE和EXACT的优点 不过请慎用这个功能 这个参数也可能带来很大的负面影响！ 四．将常用的小表 索引钉在数据缓存KEEP池中 内存上数据读取速度远远比硬盘中读取要快 据称 内存中数据读的速度是硬盘的 倍！如果资源比较丰富 把常用的小的 而且经常进行全表扫描的表给钉内存中 当然是在好不过了 可以简单的通过ALTER TABLE tablename CACHE来实现 在ORACLE i之后可以使用ALTER TABLE table STORAGE(BUFFER_POOL KEEP) 一般来说 可以考虑把 数据块之内的表放在keep池中 当然要根据内存大小等因素来定 关于如何查出那些表或索引符合条件 可以使用本文提供的access sql和access_report sql 这两个脚本是著名的Oracle专家 Burleson写的 你也可以在读懂了情况下根据实际情况调整一下脚本 对于索引 可以通过ALTER INDEX indexname STORAGE(BUFFER_POOL KEEP)来钉在KEEP池中 将表定在KEEP池中需要做一些准备工作 对于ORACLE i 需要设置DB_KEEP_CACHE_SIZE 对于 i 需要设置buffer_pool_keep 在 i中 还要修改db_block_lru_latches 该参数默认是 无法使用buffer_pool_keep 该参数应该比 * *CPU数量少 但是要大于 才能设置DB_KEEP_CACHE_BUFFER buffer_pool_keep从db_block_buffers中分配 因此也要小于db_block_buffers 设置好这些参数后 就可以把常用对象永久钉在内存里 五．设置optimizer_max_permutations 对于多表连接查询 如果采用基于成本优化(CBO) ORACLE会计算出很多种运行方案 从中选择出最优方案 这个参数就是设置oracle究竟从多少种方案来选择最优 如果设置太大 那么计算最优方案过程也是时间比较长的 Oracle 和 i默认是 建议改成 对于 i 已经默认是 了 六．调整排序参数 ( ) SORT_AREA_SIZE:默认的用来排序的SORT_AREA_SIZE大小是 K 通常显得有点小 一般可以考虑设置成 M（ ） 这个参数不能设置过大 因为每个连接都要分配同样的排序内存 ( ) SORT_MULTIBLOCK_READ_COUNT:增大这个参数可以提高临时表空间排序性能 该参数默认是 可以改成 来对比一下排序查询时间变化 注意 这个参数的最大值与平台有关系 七．调整其它几个关键的性能参数 很多人认为使用oracle数据库 系统的默认参数就是最好的 其实不是这样 lishixinzhi/Article/program/Oracle/201311/16704

优化数据库大幅度提高Oracle的性能

几个简单的步骤大幅提高Oracle性能 我优化数据库的三板斧

数据库优化的讨论可以说是一个永恒的主题 资深的Oracle优化人员通常会要求提出性能问题的人对数据库做一个statspack 贴出数据库配置等等 还有的人认为要抓出执行最慢的语句来进行优化 但实际情况是 提出疑问的人很可能根本不懂执行计划 更不要说statspack了 而我认为 数据库优化 应该首先从大的方面考虑 网络 服务器硬件配置 操作系统配置 Oracle服务器配置 数据结构组织 然后才是具体的调整 实际上网络 硬件等往往无法决定更换 应用程序一般也无法修改 因此应该着重从数据库配置 数据结构上来下手 首先让数据库有一个良好的配置 然后再考虑具体优化某些过慢的语句 我在给我的用户系统进行优化的过程中 总结了一些基本的 简单易行的办法来优化数据库 算是我的三板斧 呵呵 不过请注意 这些不一定普遍使用 甚至有的会有副作用 但是对OLTP系统 基于成本的数据库往往行之有效 不妨试试 （注 附件是Burleson写的用来报告数据库性能等信息的脚本 本文用到）

一．设置合适的SGA

常常有人抱怨服务器硬件很好 但是Oracle就是很慢 很可能是内存分配不合理造成的 ( )假设内存有 M 这通常是小型应用 建议Oracle的SGA大约 M 其中 共享池（SHARED_POOL_SIZE）可以设置 M到 M 根据实际的用户数 查询等来定 数据块缓冲区可以大致分配 M M i下需要设置DB_BLOCK_BUFFERS DB_BLOCK_BUFFER*DB_BLOCK_SIZE等于数据块缓冲区大小 i 下的数据缓冲区可以用db_cache_size来直接分配

( )假设内存有 G Oracle 的SGA可以考虑分配 M 共享池分配 M到 M 数据缓冲区分配 M到 M

( )内存 G SGA可以考虑分配 G 共享池 M到 M 剩下的给数据块缓冲区

( )内存 G以上 共享池 M到 M就足够啦 再多也没有太大帮助 (Biti_rainy有专述)数据缓冲区是尽可能的大 但是一定要注意两个问题 一是要给操作系统和其他应用留够内存 二是对于 位的操作系统 Oracle的SGA有 G的限制 有的 位操作系统上可以突破这个限制 方法还请看Biti的大作吧

二．分析表和索引 更改优化模式

Oracle默认优化模式是CHOOSE 在这种情况下 如果表没有经过分析 经常导致查询使用全表扫描 而不使用索引 这通常导致磁盘I/O太多 而导致查询很慢 如果没有使用执行计划稳定性 则应该把表和索引都分析一下 这样可能直接会使查询速度大幅提升 分析表命令可以用ANALYZE TABLE 分析索引可以用ANALYZE INDEX命令 对于少于 万的表 可以考虑分析整个表 对于很大的表 可以按百分比来分析 但是百分比不能过低 否则生成的统计信息可能不准确 可以通过DBA_TABLES的LAST_ANALYZED列来查看表是否经过分析或分析时间 索引可以通过DBA_INDEXES的LAST_ANALYZED列

下面通过例子来说明分析前后的速度对比 （表CASE_GA_AJZLZ大约有 万数据 有主键）首先在SQLPLUS中打开自动查询执行计划功能 (第一次要执行\RDBMS\ADMIN\utlxplan sql来创建PLAN_TABLE这个表)

SQL SET AUTOTRACE ON SQLSET TIMING ON

通过SET AUTOTRACE ON 来查看语句的执行计划 通过SET TIMING ON 来查看语句运行时间

SQL select count(*) from CASE_GA_AJZLZ; COUNT(*) 已用时间: : : Execution Plan SELECT STATEMENT Optimizer=CHOOSE SORT (AGGREGATE) TABLE ACCESS (FULL) OF CASE_GA_AJZLZ ……………………

请注意上面分析中的TABLE ACCESS(FULL) 这说明该语句执行了全表扫描 而且查询使用了 秒 这时表还没有经过分析 下面我们来对该表进行分析

SQL *** yze table CASE_GA_AJZLZ pute statistics;

表已分析 已用时间: : : 然后再来查询

SQL select count(*) from CASE_GA_AJZLZ; COUNT(*) 已用时间: : : Execution Plan 　 SELECT STATEMENT Optimizer=FIRST_ROWS (Cost= Card= ) SORT (AGGREGATE) INDEX (FAST FULL SCAN) OF PK_AJZLZ (UNIQUE) (Cost= Card= ) …………………………

请注意 这次时间仅仅用了 秒！这要归功于INDEX(FAST FULL SCAN) 通过分析表 查询使用了PK_AJZLZ索引 磁盘I/O大幅减少 速度也大幅提升！下面的实用语句可以

用来生成分析某个用户的所有表和索引 假设用户是GAXZUSR

SQL set pagesize SQL spool d:\ *** yze_tables sql; SQL select *** yze table ||owner|| ||table_name|| pute statistics; from dba_tables where owner= GAXZUSR ; SQL spool off SQL spool spool d:\ *** yze_indexes sql; SQL select *** yze index ||owner|| ||index_name|| pute statistics; from dba_indexes where owner= GAXZUSR ; SQL spool off SQL @d:\ *** yze_tables sql SQL @d:\ *** yze_indexes sql

解释 上面的语句生成了两个sql文件 分别分析全部的GAXZUSR的表和索引 如果需要按照百分比来分析表 可以修改一下脚本 通过上面的步骤 我们就完成了对表和索引的分析 可以测试一下速度的改进啦 建议定期运行上面的语句 尤其是数据经过大量更新

当然 也可以通过dbms_stats来分析表和索引 更方便一些 但是我仍然习惯上面的方法 因为成功与否会直接提示出来

另外 我们可以将优化模式进行修改 optimizer_mode值可以是RULE CHOOSE FIRST_ROWS和ALL_ROWS 对于OLTP系统 可以改成FIRST_ROWS 来要求查询尽快返回结果 这样即使不用分析 在一般情况下也可以提高查询性能 但是表和索引经过分析后有助于找到最合适的执行计划

三．设置cursor_sharing=FORCE 或SIMILAR

这种方法是 i才开始有的 oracle 不支持 通过设置该参数 可以强制共享只有文字不同的语句解释计划 例如下面两条语句可以共享

SQL SELECT * FROM MYTABLE WHERE NAME= tom SQL SELECT * FROM MYTABLE WHERE NAME= turner

这个方法可以大幅降低缓冲区利用率低的问题 避免语句重新解释 通过这个功能 可以很大程度上解决硬解析带来的性能下降的问题 个人感觉可根据系统的实际情况 决定是否将该参数改成FORCE 该参数默认是exact 不过一定要注意 修改之前 必须先给ORACLE打补丁 否则改之后oracle会占用 %的CPU 无法使用 对于ORACLE i 可以设置成SIMILAR 这个设置综合了FORCE和EXACT的优点 不过请慎用这个功能 这个参数也可能带来很大的负面影响！

四．将常用的小表 索引钉在数据缓存KEEP池中

内存上数据读取速度远远比硬盘中读取要快 据称 内存中数据读的速度是硬盘的 倍！如果资源比较丰富 把常用的小的 而且经常进行全表扫描的表给钉内存中 当然是在好不过了 可以简单的通过ALTER TABLE tablename CACHE来实现 在ORACLE i之后可以使用ALTER TABLE table STORAGE(BUFFER_POOL KEEP) 一般来说 可以考虑把 数据块之内的表放在keep池中 当然要根据内存大小等因素来定 关于如何查出那些表或索引符合条件 可以使用本文提供的access sql和access_report sql 这两个脚本是著名的Oracle专家 Burleson写的 你也可以在读懂了情况下根据实际情况调整一下脚本 对于索引 可以通过ALTER INDEX indexname STORAGE(BUFFER_POOL KEEP)来钉在KEEP池中

将表定在KEEP池中需要做一些准备工作 对于ORACLE i 需要设置DB_KEEP_CACHE_SIZE 对于 i 需要设置buffer_pool_keep 在 i中 还要修改db_block_lru_latches 该参数默认是 无法使用buffer_pool_keep 该参数应该比 * *CPU数量少 但是要大于 才能设置DB_KEEP_CACHE_BUFFER buffer_pool_keep从db_block_buffers中分配 因此也要小于db_block_buffers 设置好这些参数后 就可以把常用对象永久钉在内存里

五．设置optimizer_max_permutations

对于多表连接查询 如果采用基于成本优化(CBO) ORACLE会计算出很多种运行方案

从中选择出最优方案 这个参数就是设置oracle究竟从多少种方案来选择最优 如果设置太大 那么计算最优方案过程也是时间比较长的 Oracle 和 i默认是 建议改成 对于 i 已经默认是 了

六．调整排序参数

( ) SORT_AREA_SIZE:默认的用来排序的SORT_AREA_SIZE大小是 K 通常显得有点小 一般可以考虑设置成 M（ ） 这个参数不能设置过大 因为每个连接都要分配同样的排序内存

lishixinzhi/Article/program/Oracle/201311/18879