优化技巧 (oracle数据库 性能)
在现今经济高速发展的时代，优化已成为企业成功的关键。如何做好优化？如何利用提高生产效率、提高产品质量，降低成本，成为内部业务流程优化的佼佼者？以下就是几种：
1. 制度优化
企业内部制度与规章的优化，可以产生明显的效益。通过不断地调整规章体系以提高团队的协作性、缩短工作流程、减少客户投诉和重复沟通，这将大大提高生产效率。制度优化可以分为三个方面，一是管理制度，二是职业道德和责任感，三是员工机制。
2. 流程优化
每一件事情都有它的流程，流程的合理化能有效地提高效率和极限化严格质量控制。可以通过通过把生产或管理流程放在行业规范标准里，仔细评估这个流程的每个环节，在必要的地方添加设备，接口和技术手段，不断地优化它而不影响下游客户的需求。
3. 技术优化
在信息化的今天，技术优化已经成为企业成功的必要要素。通过对生产过程把控、产品质量追求的管控等方面的技术手段，增加生产效率和降低成本。这种优化可以包括多项技术，如ERP、MES、SPC、PDS和APC等。
4. 设计优化
在实现更高品质和降低成本的同时，设计优化有助于改进产品性能和工艺。设计优化应在产品生命周期全过程中进行，从最初的印刷设计和建筑设计（如房间布局和机件）到产品设计（如规格、材料和结构）再到销售和售后服务（如保修期和维护保养）。
5. 绩效优化
企业在走在发展的路上，必然面临着一些问题，其中比较重要的问题是关于人员的绩效考核。虽然每个企业自己的形式相同，在具体操作过程中还是有很多不同的因素让绩效考核变得有所不同。绩效考核需要根据企业的目标设定，基于统一的标准和方法，权衡不同人员的贡献并作出正确的决策。
为实现企业的全方位发展，企业需要不断地优化自己的管理、流程和技术，方能赢得市场竞争的优势。这些有利于提升企业的能力、水平和信誉。只有坚持不懈地进行优化，才能取得持久的收益，成为业界的佼佼者！
相关问题拓展阅读：
怎样保持Oracle数据库SQL性能的稳定性
有客户遇到SQL性能不稳定 突然变差导致系统性能出现严重问题的情况 对于大型的系统来说 SQL性能不稳定 有时突然变差 这是常常遇到的问题 这也是一些DBA的挑战
对于使用Oracle数据库的应用系统 有时会出现运行得好好的SQL 性能突然变差 特别是对于OLTP类型系统执行频繁的核心SQL 如果出现性能问题 通常会影响整个数据库的性能 进而影响整个系统的正常运行 对于个别的SQL 比如较少使用的查询报表之类的SQL 如果出现问题 通常只影响少部分功能模块 而不会影响整个系统
那么应该怎么样保持SQL性能的稳定性？
SQL的性能变差 通常是在SQL语句重新进行了解析 解析时使用了错误的执行计划出现的 下列情况是SQL会重新解析的原因
SQL语句没有使用绑定变量 这样SQL每次执行都要解析
SQL长时间没有执行 被刷出SHARED POOL 再次执行时需要重新解析
在SQL引用的对象（表 视图等）上执行了DDL操作 甚至是结构发生了变化 比如建了一个索引
对SQL引用的对象进行了权限更改森拿
重新分析（收集统计信息）了SQL引用的表和索引 或者表和索引统计信息被删除
修改了与性能相关的部分参数
刷新了共享池
当然重启数据库也会使所有SQL全部重新解析
SQL重新解析后 跟以前相比 性能突然变差 通常是下列原因
表和索引的优化统计信息被删除 或者重新收集后统计信息不准确 重新收集统计信息通常是由于收集策略（方法）不正确引起 比如对分区表使用yze命令而不是用dbms_stats包 收集统计信息时采样比例过小等等 Oracle优化器严重依赖于统计信息 如果统计信息有问题 则很容易导致SQL不能使用正确的执行计划
SQL绑定变量窥蚂祥探(bind peeking) 同时绑定变量对应的列上有直方图 或者绑定变量的值变化范围过大 分区数据分布极不均匀
） 绑定变量的列上有闷春搏直方图
假如表orders存储所有的订单 state列有 种不同的值 表示未处理 表示处理成功完成 表示处理失败 State列上有一个索引 表中绝大部分数据的state列为 和 占少数 有下面的SQL
select * from orders where state=:b
这里:b 是变量 在大多数情况下这个值为 则应该使用索引 但是如果SQL被重新解析 而之一次执行时应用传给变量b 值为 则不会使用索引 采用全表扫描的方式来访问表 对于绑定变量的SQL 只在之一次执行时才会进行绑定变量窥探 并以此确定执行计划 该SQL后续执行时全部按这个执行计划 这样在后续执行时 b 变量传入的值为 的时候 仍然是之一次执行时产生的执行计划 即使用的是全表扫描 这样会导致性能很差
） 绑定变量的值变化范围过大
同样假如orders表有一列created_date表示一笔订单的下单时间 orders表里面存储了最近 年的数据 有如下的SQL
Select * from orders where created_date >=:b ;
假如大多数情况下 应用传入的b 变量值为最近几天内的日期值 那么SQL使用的是created_date列上的索引 而如果b 变量值为 个月之前的一个值 那么就会使用全表扫描 与上面描述的直方图引起的问题一样 如果SQL第 次执行时传入的变量值引起的是全表扫描 那么将该SQL后续执行时都使用了全表扫描 从而影响了性能
） 分区数据量不均匀
对于范围和列表分区 可能存在各个分区之间数据量极不均匀的情况下 比如分区表orders按地区area进行了分区 P 分区只有几千行 而P 分区有 万行数据 同时假如有一列product_id 其上有一个本地分区索引 有如下的SQL
select * from orders where area=:b and product_id =:b
这条SQL由于有area条件 因此会使用分区排除 如果第 次执行时应用传给b 变量的值正好落在P 分区上 很可能导致SQL采用全表扫描访问 如前面所描述的 导致SQL后续执行时全部使用了全表扫描
其他原因 比如表做了类似于MOVE操作之后 索引不可用 对索引进行了更改 当然这种情况是属于维护不当引起的问题 不在本文讨论的范围
综上所述 SQL语句性能突然变差 主要是因为绑定变量和统计信息的原因 注意这里只讨论了突然变差的情况 而对于由于数据量和业务量的增加性能逐步变差的情况不讨论
为保持SQL性能或者说是执行计划的稳定性 需要从以下几个方面着手
规划好优化统计信息的收集策略 对于Oracle g来说 默认的策略能够满足大部分需求 但是默认的收集策略会过多地收集列上的直方图 由于绑定变量与直方图固有的矛盾 为保持性能稳定 对使用绑定变量的列 不收集列上的直方图 对的确需要收集直方图的列 在SQL中该列上的条件就不要用绑定变量 统计信息收集策略 可以考虑对大部分表 使用系统默认的收集策略 而对于有问题的 可以用DBMS_STATS LOCK_STATS锁定表的统计信息 避免系统自动收集该表的统计信息 然后编写脚本来定制地收集表的统计信息 脚本中类似如下
exec dbms_stats unlock_table_stats…
exec dbms_stats gather_table_stats…
exec dbms_stats lock_table_stats…
修改SQL语句 使用HINT 使SQL语句按HINT指定的执行计划进行执行 这需要修改应用 同时需要逐条SQL语句进行 加上测试和发布 时间较长 成本较高 风险也较大
修改隐含参数 _optim_peek_user_binds 为FALSE 修改这个参数可能会引起性能问题（这里讨论的是稳定性问题）
使用OUTLINE 对于曾经出现过执行计划突然变差的SQL语句 可以使用OUTLINE来加固其执行计划 在 g中DBMS_OUTLN CREATE_OUTLINE可以根据已有的执行正常的SQL游标来创建OUTLINE 如果事先对所有频繁执行的核心SQL使用OUTLINE加固执行计划 将更大可能地避免SQL语句性能突然变差
注 DBMS_OUTLN可以通过$ORACLE_HOME/rdbms/admin/dbmsol sql脚本来安装
使用SQL Profile SQL Profile是Oracle g之后的新功能 此处不再介绍 请参考相应的文档
除此之外 可以调整一些参数避免潜在的问题 比如将 _btree_bitmap_plans 参数设置为FALSE（这个参数请参考互联网上的文章或Oracle文档）
lishixinzhi/Article/program/Oracle/202311/18054
影响数据库性能的主要因素有哪些？
1、1、调整数据结构的设计。这一部分在开发信息系统之前完成，程序员需要考虑是否使用ORACLE数据库的分区功能，对于经常访问的数据库表是否需要建立索引等。 \x0d\x0a\x0d\x0a2、2、调整应用程序结构设计。这一部分也是在开发信息系统之前完成，程序员在这一步需要考虑应用程序使用什么样的体系结构，是使用传统的Client/Server两层体系结构，还是使用Browser/Web/Database的三层体系结构。不同的应用程序体系结构要求的数据库资源是不同的。 \x0d\x0a\x0d\x0a3、3、调整数据库SQL语句。应用程序的执行最终将归结为数据库中的SQL语句执行，因此SQL语句的执行效率最终决定了ORACLE数据库的性能。ORACLE公司推荐使用ORACLE语句优化器（Oracle Optimizer）和行锁管理器（row-level manager）来调整优化SQL语句。 \x0d\x0a\x0d\x0a4、4、调整服务器内存分销和段配。内存分配是在信息系统运行过程中优化配置的，数据库管理员可以根据数据库运行状况调整数据库系统全局区（SGA区）的数据缓冲区、日志缓冲区和共享池的大小；还可以调整程序全局区（PGA区）的大小。需要注意的是，SGA区不是越大越好，SGA区过大会占用操作系统使用的内存而引起虚拟内存的页面交换，这样反而会降低系统。 \x0d\x0a\x0d\x0a5、5、调整硬盘I/O，这一步是在信息系统开发之前完成的。数据库管理员可以将组成同一个表空间的数据文件放在不同的硬盘上，做到硬盘之间I/O负载均衡。 \x0d\x0a\x0d\x0a6、6、调整操作系统参数，例如：运行在UNIX操作系统上的ORACLE数据库，可以调整UNIX数据缓冲池的大小，每个进程所能使用的内存大小等参数。 \x0d\x0a\x0d\x0a实际上，上述数据库优化措施之间是相互联系的。ORACLE数据库性能恶化表现基本上都是用户响应时间比较长，需要用户长时间的等待。但性能恶化的原因却是多种多样的，有时是多个因素共同造成了性能恶化的结果，这就需要数据库管理员有比较全面的计算机知识，能够敏感地察觉到影响数据库性能的主要原因所在。另外，良好的数据库管理工具对于优化数据库性能也是很重要的。 \x0d\x0a\x0d\x0aORACLE数据库性能优化工具 \x0d\x0a\x0d\x0a常用的数据库性能优化工具有： \x0d\x0a\x0d\x0a1、1、ORACLE数据库在线数据字典，ORACLE在线数据字典能够反映出ORACLE动态运行情况，对于调整数据库性能是很有帮助的。 \x0d\x0a\x0d\x0a2、2、操作系统工具，例如UNIX操作系统的vmstat，iostat等命令可以查看到系统系统级内存和硬盘I/O的使用情况，这些工具对于管理员弄清出系统瓶颈出现棚行在什么地方有时候很有用。 \x0d\x0a\x0d\x0a3、3、SQL语言跟踪工具（SQL TRACE FACILITY），SQL语言跟踪工具可以记录SQL语句的执行情况，管理员可以使用虚拟表来调整实例，使用SQL语句跟踪文件调整应用程序性能。SQL语言跟踪工具将结果输出成一个操作系统的文亏誉件，管理员可以使用TKPROF工具查看这些文件。 \x0d\x0a\x0d\x0a4、4、ORACLE Enterprise Manager（OEM），这是一个图形的用户管理界面，用户可以使用它方便地进行数据库管理而不必记住复杂的ORACLE数据库管理的命令。 \x0d\x0a\x0d\x0a5、5、EXPLAIN PLAN——SQL语言优化命令，使用这个命令可以帮助程序员写出高效的SQL语言。 \x0d\x0a\x0d\x0aORACLE数据库的系统性能评估 \x0d\x0a\x0d\x0a信息系统的类型不同，需要关注的数据库参数也是不同的。数据库管理员需要根据自己的信息系统的类型着重考虑不同的数据库参数。 \x0d\x0a\x0d\x0a1、1、在线事务处理信息系统（OLTP），这种类型的信息系统一般需要有大量的Insert、Update操作，典型的系统包括民航机票发售系统、银行储蓄系统等。OLTP系统需要保证数据库的并发性、可靠性和最终用户的速度，这类系统使用的ORACLE数据库需要主要考虑下述参数： \x0d\x0a\x0d\x0al l 数据库回滚段是否足够？ \x0d\x0a\x0d\x0al l 是否需要建立ORACLE数据库索引、聚集、散列？ \x0d\x0a\x0d\x0al l 系统全局区（SGA）大小是否足够？ \x0d\x0a\x0d\x0al l SQL语句是否高效？ \x0d\x0a\x0d\x0a2、2、数据仓库系统（Data Warehousing），这种信息系统的主要任务是从ORACLE的海量数据中进行查询，得到数据之间的某些规律。数据库管理员需要为这种类型的ORACLE数据库着重考虑下述参数： \x0d\x0a\x0d\x0al l 是否采用B*-索引或者bitmap索引？ \x0d\x0a\x0d\x0al l 是否采用并行SQL查询以提高查询效率？ \x0d\x0a\x0d\x0al l 是否采用PL/SQL函数编写存储过程？ \x0d\x0a\x0d\x0al l 有必要的话，需要建立并行数据库提高数据库的查询效率 \x0d\x0a\x0d\x0aSQL语句的调整原则 \x0d\x0a\x0d\x0aSQL语言是一种灵活的语言，相同的功能可以使用不同的语句来实现，但是语句的执行效率是很不相同的。程序员可以使用EXPLAIN PLAN语句来比较各种实现方案，并选出更优的实现方案。总得来讲，程序员写SQL语句需要满足考虑如下规则： \x0d\x0a\x0d\x0a1、1、尽量使用索引。试比较下面两条SQL语句： \x0d\x0a\x0d\x0a语句A：SELECT dname, deptno FROM dept WHERE deptno NOT IN \x0d\x0a\x0d\x0a(SELECT deptno FROM emp); \x0d\x0a\x0d\x0a语句B：SELECT dname, deptno FROM dept WHERE NOT EXISTS \x0d\x0a\x0d\x0a(SELECT deptno FROM emp WHERE dept.deptno = emp.deptno); \x0d\x0a\x0d\x0a这两条查询语句实现的结果是相同的，但是执行语句A的时候，ORACLE会对整个emp表进行扫描，没有使用建立在emp表上的deptno索引，执行语句B的时候，由于在子查询中使用了联合查询，ORACLE只是对emp表进行的部分数据扫描，并利用了deptno列的索引，所以语句B的效率要比语句A的效率高一些。 \x0d\x0a\x0d\x0a2、2、选择联合查询的联合次序。考虑下面的例子： \x0d\x0a\x0d\x0aSELECT stuff FROM taba a, tabb b, tabc c \x0d\x0a\x0d\x0aWHERE a.acol between :alow and :ahigh \x0d\x0a\x0d\x0aAND b.bcol between :blow and :bhigh \x0d\x0a\x0d\x0aAND c.ccol between :clow and :chigh \x0d\x0a\x0d\x0aAND a.key1 = b.key1 \x0d\x0a\x0d\x0aAMD a.key2 = c.key2; \x0d\x0a\x0d\x0a这个SQL例子中，程序员首先需要选择要查询的主表，因为主表要进行整个表数据的扫描，所以主表应该数据量最小，所以例子中表A的acol列的范围应该比表B和表C相应列的范围小。 \x0d\x0a\x0d\x0a3、3、在子查询中慎重使用IN或者NOT IN语句，使用where (NOT) exists的效果要好的多。 \x0d\x0a\x0d\x0a4、4、慎重使用视图的联合查询，尤其是比较复杂的视图之间的联合查询。一般对视图的查询更好都分解为对数据表的直接查询效果要好一些。 \x0d\x0a\x0d\x0a5、5、可以在参数文件中设置SHARED_POOL_RESERVED_SIZE参数，这个参数在SGA共享池中保留一个连续的内存空间，连续的内存空间有益于存放大的SQL程序包。 \x0d\x0a\x0d\x0a6、6、ORACLE公司提供的DBMS_SHARED_POOL程序可以帮助程序员将某些经常使用的存储过程“钉”在SQL区中而不被换出内存，程序员对于经常使用并且占用内存很多的存储过程“钉”到内存中有利于提高最终用户的响应时间。 \x0d\x0a\x0d\x0aCPU参数的调整 \x0d\x0a\x0d\x0aCPU是服务器的一项重要资源，服务器良好的工作状态是在工作高峰时CPU的使用率在90％以上。如果空闲时间CPU使用率就在90％以上，说明服务器缺乏CPU资源，如果工作高峰时CPU使用率仍然很低，说明服务器CPU资源还比较富余。 \x0d\x0a\x0d\x0a使用操作相同命令可以看到CPU的使用情况，一般UNIX操作系统的服务器，可以使用sar _u命令查看CPU的使用率，NT操作系统的服务器，可以使用NT的性能管理器来查看CPU的使用率。 \x0d\x0a\x0d\x0a数据库管理员可以通过查看v$sysstat数据字典中“CPU used by this session”统计项得知ORACLE数据库使用的CPU时间，查看“OS User level CPU time”统计项得知操作系统用户态下的CPU时间，查看“OS System call CPU time”统计项得知操作系统系统态下的CPU时间，操作系统总的CPU时间就是用户态和系统态时间之和，如果ORACLE数据库使用的CPU时间占操作系统总的CPU时间90％以上，说明服务器CPU基本上被ORACLE数据库使用着，这是合理，反之，说明服务器CPU被其它程序占用过多，ORACLE数据库无法得到更多的CPU时间。 \x0d\x0a\x0d\x0a数据库管理员还可以通过查看v$sesstat数据字典来获得当前连接ORACLE数据库各个会话占用的CPU时间，从而得知什么会话耗用服务器CPU比较多。 \x0d\x0a\x0d\x0a出现CPU资源不足的情况是很多的：SQL语句的重解析、低效率的SQL语句、锁冲突都会引起CPU资源不足。 \x0d\x0a\x0d\x0a1、数据库管理员可以执行下述语句来查看SQL语句的解析情况： \x0d\x0a\x0d\x0aSELECT * FROM V$SYSSTAT \x0d\x0a\x0d\x0aWHERE NAME IN \x0d\x0a\x0d\x0a(‘parse time cpu’, ‘parse time elapsed’, ‘parse count (hard)’); \x0d\x0a\x0d\x0a这里parse time cpu是系统服务时间，parse time elapsed是响应时间，用户等待时间 \x0d\x0a\x0d\x0awaite time = parse time elapsed _ parse time cpu \x0d\x0a\x0d\x0a由此可以得到用户SQL语句平均解析等待时间＝waite time / parse count。这个平均等待时间应该接近于0，如果平均解析等待时间过长，数据库管理员可以通过下述语句 \x0d\x0a\x0d\x0aSELECT SQL_TEXT, PARSE_CALLS, EXECUTIONS FROM V$SQLAREA \x0d\x0a\x0d\x0aORDER BY PARSE_CALLS; \x0d\x0a\x0d\x0a来发现是什么SQL语句解析效率比较低。程序员可以优化这些语句，或者增加ORACLE参数SESSION_CACHED_CURSORS的值。 \x0d\x0a\x0d\x0a2、数据库管理员还可以通过下述语句： \x0d\x0a\x0d\x0aSELECT BUFFER_GETS, EXECUTIONS, SQL_TEXT FROM V$SQLAREA; \x0d\x0a\x0d\x0a查看低效率的SQL语句，优化这些语句也有助于提高CPU的利用率。 \x0d\x0a\x0d\x0a3、3、数据库管理员可以通过v$system_event数据字典中的“latch free”统计项查看ORACLE数据库的冲突情况，如果没有冲突的话，latch free查询出来没有结果。如果冲突太大的话，数据库管理员可以降低spin_count参数值，来消除高的CPU使用率。 \x0d\x0a\x0d\x0a内存参数的调整 \x0d\x0a\x0d\x0a内存参数的调整主要是指ORACLE数据库的系统全局区（SGA）的调整。SGA主要由三部分构成：共享池、数据缓冲区、日志缓冲区。 \x0d\x0a\x0d\x0a1、 1、 共享池由两部分构成：共享SQL区和数据字典缓冲区，共享SQL区是存放用户SQL命令的区域，数据字典缓冲区存放数据库运行的动态信息。数据库管理员通过执行下述语句： \x0d\x0a\x0d\x0aselect (sum(pins – reloads)) / sum(pins) “Lib Cache” from v$librarycache; \x0d\x0a\x0d\x0a来查看共享SQL区的使用率。这个使用率应该在90％以上，否则需要增加共享池的大小。数据库管理员还可以执行下述语句： \x0d\x0a\x0d\x0aselect (sum(gets – getmisses – usage – fixed)) / sum(gets) “Row Cache” from v$rowcache; \x0d\x0a\x0d\x0a查看数据字典缓冲区的使用率，这个使用率也应该在90％以上，否则需要增加共享池的大小。 \x0d\x0a\x0d\x0a2、 2、 数据缓冲区。数据库管理员可以通过下述语句： \x0d\x0a\x0d\x0aSELECT name, value FROM v$sysstat WHERE name IN (‘db block gets’, ‘consistent gets’,’physical reads’); \x0d\x0a\x0d\x0a来查看数据库数据缓冲区的使用情况。查询出来的结果可以计算出来数据缓冲区的使用命中率＝1 – ( physical reads / (db block gets + consistent gets) )。 \x0d\x0a\x0d\x0a这个命中率应该在90％以上，否则需要增加数据缓冲区的大小。 \x0d\x0a\x0d\x0a3、 3、 日志缓冲区。数据库管理员可以通过执行下述语句： \x0d\x0a\x0d\x0aselect name,value from v$sysstat where name in (‘redo entries’,’redo log space requests’);查看日志缓冲区的使用情况。查询出的结果可以计算出日志缓冲区的申请失败率： \x0d\x0a\x0d\x0a申请失败率＝requests/entries，申请失败率应该接近于0，否则说明日志缓冲区开设太小，需要增加ORACLE数据库的日志缓冲区。
oracle数据库 性能的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于oracle数据库 性能,优化技巧,怎样保持Oracle数据库SQL性能的稳定性,影响数据库性能的主要因素有哪些？的信息别忘了在本站进行查找喔。
