ITPub博客

首页 > 应用开发 > IT综合 > 关于应用优化(讨论)

关于应用优化(讨论)

原创 IT综合 作者:m77m78 时间:2004-09-08 14:38:21 0 删除 编辑

1.top sql中找出最耗资源的SQL
2.
提高绑定率
2.1
如果可以修改程序,那么就把常量用变量替换
对于sql语法采用绑定变量的写法
java:使用?代替变量
plsql:
采用绑定变量的写法,":"来代替变量.
2.2 cursor_sharing = similar (可以在不修改程序的前提下提高绑定率)
3.
减少软解析次数
3.1
初始化参数中增加session_cache_cursors
3.2 java:,sql
采用prepared/callable statement.保持cursor的时间
3.3 plsql:
动态sql采用dbms_sql,除非这个sql只是执行一次.
3.4
另外cursor_space_for_time可以减少解析时间
4.
找出db中所有的索引结构
4.1
分析索引的合理性,去除不必要的索引.对于使用5个以上索引时,采取减少性
能最差的索引.
4.2 合理规划索引,新建一些高性能的索引.
4.3 分析表和索引,
>
使用dbms_stats可以收集整个user或者数据库下的对象
gather_schema_stats
gather_database_stats
对于dbms_stats的另一个好处,可以exp/imp统计信息
dbms_stats.export_schema_stats
dbms_stats.import_schema_stats
>
或者使用analyze进行分析
>
如果想动态进行分析可以采用alter table table_name (monitoring)
或者使用job进行分析(看分析对系统的性能影响?)
>
对于常用的判断式,而且该列的分布不太均匀,那么就要考虑使用直方图
analyze table table_name compute statistics for table for all indexes for all indexed columns
注意由于迁移,在初始时要建立所有表的直方图。

dbms_stats.gather_table_stats('scott','emp',method_opt=>'for
columns size 10 sal)
由于直方图对性能有影响,所以在均匀的分布或者在SQL中不常用的可以不考虑
虑使用直方图.
>
如果使用统计信息产生的执行计划对你的性能不够满意,可以采用
analyze table emp delete statistics;
或者采用rbo
>
在刚迁移数据库时,可以对索引进行重建,ALTER INDEX … REBUILD
对表进行移动ALTER TABLE …MOVE
>
如果使用了绑定变量,要考虑到peeking,或者就不用绑定,或者使用outline.
参见http://www.*****.org/cgi-bin/topic_...=3579&h=1#17501
5.
找出系统的所有view,判断sql中是否合理的使用了view(view可能影响执行计划)
6.
存储结构:是否要调整某些对象的存储结构
7.
分析sql缓冲池对象($bh),合理配置缓冲池的大小,
default
池大小(默认的buffer)
keep
:使用比较频繁的小表
:alter table mytable_myind storage (buffer_pool keep); 适合多大的表
recycle:
使用比较随机的大表

cache index

使用optimize_index_caching对于嵌套连接比较好,所以对基于响应的也较好
如果索引用的比较多,可以适当设置optimizer_index_cost_adj一个小值
是否要使用??
8.
优化应用程序
8.1
对于程序在进行性能测试时可以利用dbms_system.set_sql_trace_in_session
+ tkprof
8.2
对于单独的sql语句可以通过 set autot on
set autot traceonly explain stat
8.3
选择优化的目标
以最佳响应时间:
以最佳吞吐量:
需要对整个数据库进行设置还是针对某个应用?
如果要对整个数据库指定目标,可以在init中设置
optimizer_mode = first_rows /*
以最佳响应时间*/
optimizer_mode = all_rows /*
以最佳吞吐量*/
我想修改整个db的参数,可能不是很好,TOM也说最好用choose,那最好还是基于session或者语句级
8.4
是否设置timed_statistics,如果为TRUE,那么对系统性能有一定的影响,但不便于进行优化跟踪,也可以通过alter session set timed_statistics=false;来减少对系统的影响

8.4
对于以最佳响应时间为目的,那么要尽量使用象嵌套连接的方式进行连接,以为此连接是以提取一条显示一条的方式.有时可以用提示如/*+ use_nl(驱动表)*/

8.5
对于以最佳吞吐为目的,那么尽量使用merge join 或者 hash join
如果join列有索引或者是非等式连接,可以采用merge join,对于等式连接,hash_area_size大小合理,其中某个为小表,可以用hash join

8.6
多表连接时尽量少与5个表
可以通过指定/*+ordered ...*/来决定连接顺序
在每步的连接步骤中保证以最小的行被返回并加入下一步连接.
合理选择驱动表和驱动索引
8.7
sql中尽量少用views,采用meger进入views的方式进行优化

8.8
合理优化in exists
注意一般的标准,对于in,那么判定式要在子查询内
对于exists,那么判定式在父查询内
当然以上是基于判定式列有索引

8.9
对于熟悉应用及表结构,且便于修改程序的话可以使用提示来改变执行计划.

8.10
优化列分布不均匀的列,使用直方图.

8.11 简化sql语句的复杂程度

8.12
利用索引减少排序
或者可以增大sort_area_size

8.13
合理使用索引

8.14
在程序中避免用象select 1 from dual此类简单但非常频繁的语句

8.15
定期分析table index

8.16
对于频繁插入的语句,是否需要使用appand

8.17
合理使用常规SQL优化技巧

8.18
优化dump程序
9.
存储概要
在不修改程序的基础上,通过保存存储概要,可以重复利用原来的执行计划(是否要使用?)
10.物化视图
对于经常使用的子查询(使用了大表),可以通过物化视图或snapshot,并使用查询重写的功能来实现扫描更少的数据,减少排序和聚集,减少CPU的消耗。

[@more@]

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/34329/viewspace-778358/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2008-04-25

  • 博文量
    168
  • 访问量
    734527