各位高手好
小弟最近遇到很麻烦的事 希望各位大侠指点
我最近接手了一个离职同事的项目 项目处于上线三年状态 我做的是银行的项目 数据量比较大
接手这项目后无非是维护罢了 但最近用户都反映系统慢 领导就交给我了一个优化数据库的 任务
要是开发 或者简单表结构设计还得可以 要是做数据库优化小弟功底实在是不够啊
请个大侠帮帮忙指点下 这周就要我出方案 头疼
银行有些业务复杂 一个检索 要套10多个子查询 看着都迷糊 还没注释 （写的人太缺德了）
数据库 存在大量试图，而且有些视图建立在视图基础之上
我现在的想法是 建立历史表 把一部分数据移出去
在就是 有些地方改成存储过程 建临时表 加索引
小弟跪求各位大侠指点 小弟也非常想学习这方面知识 做优化真的要些功力
请给点方案或建议 谢谢
小弟最近遇到很麻烦的事 希望各位大侠指点
我最近接手了一个离职同事的项目 项目处于上线三年状态 我做的是银行的项目 数据量比较大
接手这项目后无非是维护罢了 但最近用户都反映系统慢 领导就交给我了一个优化数据库的 任务
要是开发 或者简单表结构设计还得可以 要是做数据库优化小弟功底实在是不够啊
请个大侠帮帮忙指点下 这周就要我出方案 头疼
银行有些业务复杂 一个检索 要套10多个子查询 看着都迷糊 还没注释 （写的人太缺德了）
数据库 存在大量试图，而且有些视图建立在视图基础之上
我现在的想法是 建立历史表 把一部分数据移出去
在就是 有些地方改成存储过程 建临时表 加索引
小弟跪求各位大侠指点 小弟也非常想学习这方面知识 做优化真的要些功力
请给点方案或建议 谢谢
http://tech.it168.com/db/o/2006-10-26/200610261121253.shtml
http://oracle.chinaitlab.com/serial/717482.html
http://database.51cto.com/art/201001/181249.htm
2.改成存储过程是不会提高系统性能的。
3.做一个awr report,主要关注数据库的top 5 wait.
是sql文写的有问题，还是表结构创建的问题，还是数据量的问题，不一定你在别的地方做的优化在这里就一定好使，还是先好好调查下吧，银行的项目可不能出一点差错的。。
我这几天观察 sql质量 和 数据量上都存在问题的
这个项目还是全国都在用的 是得谨慎啊 压力挺大 不过借这个机会研究学习下也不错
我现在只是 出个方案 下周项目组还得开会讨论
就是感觉无从下手
---------------------------------------
你说sql和数据量上都有问题：那么sql的优化和表分区或索引，结构估计要好好考虑了，具体的东西你再详细调查下，然后发出来大家一块讨论讨论～
由于大数据量处理时系统负荷的突变特性,导致AWR所分析的对象本身就没有特别明显的规律可循,除非在系统参数配置上出了明显的不妥,否则根本无法从AWR报表中看出端倪.
从我的经验来看,优化着手之处首要考虑就是对业务的理解,建模和应用逻辑的化简.一般未经化简的系统会因此在IO和网络传输上浪费30%~70%的带宽,过多视图的嵌套无疑是违背这一原则的,建议在完成可行的数据库重构后,先规划数据流,避免数据的无序流转,随后的所有数据处理逻辑遵从数据流框架设计.
其次考虑系统参数和物理设计的调优,根据数据不同的访问特性设计表分区,表压缩以及存储分布与分配,同时考虑索引设计,宽表合理进行纵向切割避免行链和行迁移,避免clob和long的使用.参数上面:在实例级调整最大IO吞吐量,hash区,排序区大小,合理使用数据库块大小.合理分配操作系统资源.
批处理应用和事务型应用采取隔离措施,尽量避免同时争夺资源,若条件允许,应物理上分离这两类应用主机,使得批处理应用在处理大数据量期间的参数配置能满足最大限度的均衡利用所有可用系统资源.
最后优化单个SQL,针对执行计划调优,使用适当的连接方法(大数据量下hash比较常见)和排序,根据cpu和有效内存资源,使用分析函数解决太多全表扫描带来的IO.合理分解SQL的复杂度,充分利用系统的并行能力.总之,大数据量处理过程的优化原则就是:避免不必要的或过度使用系统资源,在此基础上根据系统可用资源最大程度的平衡各种资源的利用率,使其处于饱和前的峰值状态
不做AWR做什么
其实我们主要业务表不出 10张 其中 四张数据量比较大
这两天晚上看了好多资料 感觉oracle博大精深啊 自己数据库知识太匮乏 惭愧
这些东西要一个一个排除后，才好做oracle调优的，oracle调优肯定要找供应商的，风险太大
先在测试系统弄，完了在备份再在正式系统数据库中实现，除了问题还能恢复过来的