关于应用优化(讨论)

关于应用优化(讨论)


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只是执行一次,那么就使用execute immediate '.....';
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_show.cgi?id=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/7282477/viewspace-993569/,如需转载,请注明出处,否则将追究法律责任。

转载于:http://blog.itpub.net/7282477/viewspace-993569/

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值