- 博客(6)
- 资源 (3)
- 收藏
- 关注
RSS订阅原创 保障执行计划正确
现在项目中经常 出现有的时候 SQL跑的很快， 有时候确像 蜗牛。。 我当时觉得奇怪， 为啥 哥优化好了一个SQL， 怎么 又慢的？？ 于是哥开始反思， 这个哥的第一反应是 统计信息导致的问题。 统计信息 把rows 算的错误的太离谱了。 导致本来走hash 的走了 NL。 于是哥找出SQl， 看了下执行计划， 果然 /* 1 Plan hash value
2015-11-30 23:36:23
298
原创 一周优化总结
这一周 在搞oracle 性能优化。 哥记得 哥刚刚接手这个 项目时候， 发现有SQL 居然跑出了400 多分钟的时间，200，100 ， 70 多分钟，很多的， 南京分区的一个 什么流程 跑了 7， 8 个小时。 于是哥 开始着手优化。 其实我做优化 心里 自然是要一把尺子的， 首先看 系统 数据量， dba_segements 这个表， 大致是什么表最大等等.... 。 再看
2015-11-27 23:06:51
374
原创 分页SQL的优化。 秒杀了。。。。
目前项目组中的 分页语句， 存在 很大问题， 按照 道理来说 分页语句首页 都不会很慢的。 结果应该是 秒出的。 但我们项目组中 的分页， 哥首次优化时候， 出现35S， 这个肯定不行的。 SQL 涉及到保密问题， 简写 select b.* from (select rownum as r, a.* from (select smzor.A
2015-11-19 23:15:04
520
原创 SQL优化工作, 不能太激动。记录失败的优化经历，优化从 70分钟优化到 30秒， 再到1s但还是失败了
今天思前想后还是把一次失败的优化 经历写下来吧， 防止以后再犯同样的错误。 以后谨记教训。 哎， 其实还差一点就到达我想要的效果了。 update st_mntr_bus_inteorder_oc a set a.unreach = 1 where arch_flag = 0 and parent_tache_id = 2017
2015-11-12 22:55:10
405
原创 优化表空间扩展过于频繁 insert select 性能
在项目组中发现 SQL insert into ST_MNTR_RM_INTEORDER_OC partition(P_NJ)-----127s ( *****) select ****** from tmp_ST_MNTR_RM_INTEORDER_OC where LOCAL_AREA_ID = 3;
2015-11-04 20:12:20
869
原创 关机后数据库启动错误
后悔不已， 电脑非正常关机。数据库启动出错。先是监听出错， 后来是 没有权限连接， 后来又是数据库不可用， 再后来是 通信文件结束， 后来又是 ORA-01034: ORACLE not available ORA-27101， 连接到空闲例程。 一大堆 SQL> startup nomount; ORACLE 例程已经启动。 Total System Global Area 148649
2015-11-03 00:15:02
608
flex 小节.rar
2015-05-09
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人