- 博客(30)
- 收藏
- 关注
RSS订阅转载 /proc/sysrq-trigger文件的强大功能
转自:http://hi.baidu.com/wangzengfang/blog/item/5838e5ee6046f0372df53481.html重启服务器 # echo 1 > /proc/sys/kernel/sysrq # echo b > /proc/sysrq-trigger 1. /proc/sys/kernel/sysrq 向sysr
2012-03-06 10:47:12
829
原创 并发的批量插入数据的应用,app,db层面的优化
这里讲述了一个并发的批量插入数据的应用,应用,数据库层面的优化案例。其实是老白讲述的一个案例,我这里稍微整理了一下,其实如果大家的数据库概念清晰的话,思路还是蛮清晰的: 1.首先,批量插入数据,必然带来大量的重做数据,这个是需要考虑的,所以需要考虑log_buffer的设置和联机日志文件组的设置.应该设置log_buffer为一个合适的大小,避免log buffer space等待(同时
2011-11-21 18:18:23
948
原创 手工设置列的直方图信息
从dba_source中摘取的相关内容信息:-- types for minimum/maximum values and histogram endpointstype numarray is varray(256) of number;type datearray is varray(256) of date;type chararray is varray(256) of varchar2(4000);type rawarray is varray(256) of raw(2000);
2011-03-16 16:48:00
704
原创 开发交流时给同事们讲解的一个sql优化案例
<br /> 这个sql其实是很早之前调整优化的一个sql了,前一阵儿在准备和开发同事们做sql交流的时候,把这个案例又整理了一下,不过在整理那次优化的文档的时候,发现一个以前没有注意的问题,下面会提到一下.这里的数据库版本:10.2.0.4<br />SQL> create table zsj_diy_userlog as select * from diy_userlog;SQL> alter table zsj_diy_userlog add constraint pk_zsj_diy_us
2011-03-09 21:35:00
834
原创 也说执行计划的稳定性
本文探讨了一些影响sql执行计划稳定性的因素,并从数据库管理的角度探讨了如何来稳定执行计划,从而保证数据库性能的稳定性和健壮性
2011-03-08 23:58:00
692
原创 sort unique后card估算直接变为1,bug?
总的来说,就是sort unique后,card的估算忽然变成了1,实际却大得多,导致了随后的一系列问题.当然,这里执行计划的显示也存在一些问题,似乎没有正确的显示实际的估算情况.至于sort unique后为什么card的估算就变成1了,10053 trace文件没有给出任何的信息,也不清楚,我觉得bug的可能性还是有的.
2011-02-28 19:48:00
956
原创 advanced里显示的peeking到的绑定变量值数据来源于哪里?
一个sql语句的执行计划生成时peeking到的绑定变量值保存在v$sql_plan.other_xml中,当然它是以xmltype的形式保存的,要以直观可读的形式显示的话,需要转换一下.awr历史数据的sql的执行计划生成时的绑定变量值保存在dba_hist_sql_plan.other_xml中.v$sql.bind_data和v$sql_bind_capture显示的内容是一致的,很可能是绑定变量定时捕捉机制最近一次捕捉到的绑定变量值.同理awr中sql的绑定变量定时捕捉机制捕捉到的绑定变量值记录
2011-02-23 18:06:00
944
原创 cms系统核心发布提取过程的调整优化
其实有时候真的是这样,oracle看到的只是一堆数据,它不会知道这些数据实际代表的含义,看不到这些数据之间的关联;而真正了解系统,了解业务逻辑,了解数据的只有我们,所以有些调整还是只能由我们来做出的.
2011-02-15 11:33:00
651
原创 一次层次查询相关的sql的调整优化
这里通过table函数的实现,在使用cbo的情况下,对于层次查询,使得sql可以按照自己想要的执行方式去执行.但就像我上面提到的一样,有没有什么提示可以单独的控制层次查询的执行计划呢?对于层次查询大家有什么好的资料吗?
2011-01-28 23:05:00
958
原创 use_concat导致not in时临时表不动态采样进而导致的性能问题
从这个案例,你可以看到无论是限制也好,还是说bug也好,我们并不是总能使用动态采样这个特性的,而且动态采样在硬分析时是有代价的,它会执行带有/* OPT_DYN_SAMP */这样注释的sql语句来执行动态采样数据动作的,而且如果它硬分析时动态采样到的刚好是非典型值的话,可能会生成糟糕的执行计划的.所以随意的使用动态采样,其实也是一种不负责任的行为,对于临时表,还是在插入代表性数据之后手工收集统计信息的好,对于新建的普通表,在加载完数据后,立即手工收集统计信息为好.
2011-01-21 19:51:00
1132
原创 不要制造不必要的混乱把优化器给弄糊涂了
这些都是工作中实际碰到的问题,你当然可以说是因为优化器不足够智能.可问题是我们写出这样的语句的时候,我们是否足够清醒,知道自己在干什么呢?优化器不足够智能,这个我们必须承认,我们也改变不了,我们能做的就是意识到优化器还不足够智能,所以我们在写语句的时候,要保持足够的清醒,知道自己在干什么,不要制造不必要的混乱把优化器给弄糊涂了
2011-01-07 21:18:00
452
原创 继续上一篇文章的实验,越发的让人搞不明白了
我分别在10.2.0.1.0和10.2.0.4.0的版本上进行测试,发现结果是一样的,所以这里只列举10.2.0.4版本上的实验结果了:create table zsj_test_dtime(num number,dtime date not null) pctfree 70;insert into zsj_test_dtime(num,dtime) select rownum,to_date('2011-01-01','yyyy-mm-dd')- 90 -90*6*1
2011-01-05 19:30:00
428
原创 一次执行选择了错误的索引的研究与困惑
size auto(gather_stats_job使用的就是这个选项)最常见的问题是:因为极个别的sql语句的执行,使用这个选项容易导致不必要的柱状图统计信息的收集,且不说这种收集方式是消耗资源的,它导致的问题包括:因为绑定变量peeking,导致执行计划不稳定;假如peeking到的是一个非典型输入值的话,容易生成对于典型输入值的非最优的执行计划;和cursor_sharing=simiar一起来解决应用不使用绑定变量的问题时,因为收集了柱状图统计信息,容易导致一个sql语句存在多个子游标的情况,sql
2011-01-01 03:08:00
980
原创 关于autotrace和explain plan是否可以反映真实的执行计划
explain plan时不使用绑定变量peeking机制,所以它也许显示不了实际的执行计划.autotrace traceonly explain会硬分析一次,但不执行,硬分析时也不使用绑定变量peeking机制,也就是说它也显示不了实际的执行计划.其它的autotrace形式都会执行一次,使用绑定变量peeking机制,但随后显示出来的执行计划都不是实际的执行计划.
2010-12-30 20:59:00
852
原创 有关位图连接索引(bitmap join index)的一些测试
<br />数据库版本:10.2.0.4<br />create table zsj_obj as select owner,object_id from dba_objects where object_id is not null;<br />create table zsj_obj_detail pctfree 90 <br />as select object_id,object_name,object_type,last_ddl_time+rownum last_ddl_time,status <
2010-12-22 20:00:00
1433
原创 这里的谓词为什么推入不了?
我们知道对于一个视图或者说子查询应用某些谓词的时候,优化器在进行查询重写的时候,有时候会应用谓词推入技术(push predicate),把这样的谓词应用推入到子查询内部,过滤出更少的行之后,再进行其它的操作,比如和其它表的连接操作等,这样有时候是效率极高的.数据库版本:10.2.0.4create table zsj_users as select user_id,username from dba_users;alter table zsj_users add constraint pk_zsj_use
2010-12-20 17:31:00
567
原创 杂谈影响性能的一些因素
前几天发现一个3点开始的job(调用了一个数据库过程T)执行到了10点还没有执行完(到了11点才执行完毕).其间使用dbms_monitor 10046了一段时间,然后使用tkprof查看数据,发现在trace的这个时间段里几乎是没有什么等待事件的,主要的流逝时间消耗在了cpu time上,而cpu time,逻辑IO按每个sql的执行次数平均的话,没有一个明显偏高的,主要的问题就是执行次数偏高。因为会话还在执行着,就检查了一下v$session_event,发现也是不存在什么显著的等待事件的,v$sess
2010-12-20 13:00:00
401
原创 查看生成执行计划时peeking到的绑定变量值
<br />有时候,一些sql语句选择了错误的执行计划,与这个语句硬分析的时候peeking到的绑定变量值相关,这个绑定变量值对于问题的诊断是至关重要的,你当然可以根据一些别的线索来确定次优的执行计划是因为硬分析时peeking到了非典型值,但如果能明确的显示硬分析时peeking到的绑定变量值是最好的,其实确实是记录了的:<br />数据库版本:10.2.0.4<br />SQL> select * from table(dbms_xplan.display_awr(sql_id=> '0763n191h
2010-12-15 16:02:00
560
原创 浅谈确定性函数,确定性函数和标量子查询的cache机制,代码可重用和性能
<br />数据库版本:10.2.0.4<br />同事反应下面的查询执行非常慢:<br />select GETNEXTPRODUCTPICURL(p.id, p.brandid) as nextproductpicurl,<br /> GetProductURLNew(p.id, 8) as productpriceurl,<br /> GetProductURLNew(p.id, 9) as productparamurl,<br /> GetProductURLN
2010-12-14 17:17:00
919
1
原创 拼装组合sql时如何使用绑定变量
<br />数据库版本:10.2.0.4<br />create table zsj_objs as select * from dba_objects;<br />*************************<br />方法一<br />使用本地动态SQL实现:<br /> create or replace function f_zsj_cursor(v_owner varchar2,v_object_type varchar2,v_object_id number,v_created date)
2010-12-11 14:30:00
686
原创 一次逻辑从库应用日志缓慢的问题的定位及解决
这台逻辑从库自从建立之后,就没怎么管,因为应用也没有迁移的紧迫性,也不急着迁移过来.这段时间主要还是看看在日志应用的过程中是不是会遭遇bug而导致日志应用不下去的问题.所以只是跳过了比如mlog$这样一些肯定要跳过去的对象,没有仔细的针对应用看看还需要跳过哪些对象.监控上也主要是看看是不是会遭遇bug而导致应用不下去的情况,所以只是每2个小时检查一下SELECT * FROM V$LOGSTDBY_PROGRESS p where nvl(p.LATEST_TIME-p.APPLIED_TIME,10)>1
2010-12-10 21:34:00
507
原创 一个列别名引发的性能问题,兼谈产品设计等(2010-11-15)
<br />其实数据库还是《从一次临时表空间不足错误的处理说起》提到的那个逻辑从库.<br />解决那个问题之后,还是比较关注这个数据库的,看看是否还会报TEMP表空间不足的错误.<br />之后,还是发现IO阻塞,TEMP表空间读写是最频繁的.查找相应时间段里直接写最频繁的SQL语句,又发现下面两个SQL语句:<br />sql1:<br />select b.*, getproducturls(productid) as producturls<br /> from (select rownum as
2010-12-05 16:44:00
581
原创 一次通过switchover物理从库迁移数据库到其它主机上(2010-11-09)
<br />上周一通过switchover物理从库到主库成功的将一台数据库迁移到新的主机上.<br />简单的叙述一下:<br />原来的数据库情况:231:主库,122:物理从库,195:逻辑从库,211:新的主机,打算将数据库主库迁移到这台主机上来.<br />在211上创建231主库的物理从库,并且使得这个物理从库可以正常的应用主库端传输过来的日志.<br />在切换前,停止连接到主库的应用,数据库形式的主库应用也最好停止了,比如说alter system set job_queue_processe
2010-12-05 16:06:00
396
原创 从一次临时表空间不足错误的处理说起(2010-11-8)
因为rownum=1,所以触发了first_rows_1的优化器模式,所以看到了很小的card和cost.虽然没有柱状图统计信息,但minvalue,maxvalue之间的字面值和之外的字面值的card还是不同的,而这种card上的微小的变化在first_rows_1的优化器模式下被放大了,所以不同的字面值导致了不同的执行计划.因为缺少必要的索引,所以选择的执行计划并不好.原来计划中的hash join导致了需要读写临时表空间,而大量并发的情况下,容易导致IO成为瓶颈,这样导致sql执行时间变长,使
2010-12-05 15:53:00
1381
原创 从一个笛卡尔连接说起(2010-10-22)
<br />今天一开发同事反映一个sql执行特慢,执行了十多分钟还没有出结果,一看执行计划,居然出现了CARTESIAN,也就是说出现了笛卡尔积.仔细查看连接条件,才发现是忘了写两个表的连接条件导致的,加上这样的连接条件之后,执行很快出了结果,并且结果是正确的.<br />当然这里出现笛卡尔积是因为没有写应该有的连接条件,有时候因为优化器统计信息不准确,本来是很大的表,因为优化器统计信息过时,优化器可能认为它们都是小表,以至于它会执行笛卡尔积,而后把连接条件作为过滤条件去执行,对小表来说这样执行是好的,可对
2010-12-04 16:00:00
870
原创 一些还算有点儿意思的sql(2010-10-19)
<br />有时候还能写些有点儿意思的sql,还需要想上几分钟才能写出来,这样工作才有点儿意思,不然的话,真的要疯掉了.<br />今天写的两个还算有点儿意思的sql:<br />1.上周客户对某个商家留言超过10条,并且这个商家在上周对客户上周的留言都回复了的商家信息(这里只取出商家ID就可以了)<br />上周:上周一~~~刚刚过去的周日<br />表结构usermessage<br />inputdate:客户留言或者是商家回复留言的时间<br />type = 0:客户留言,companyid是针对
2010-12-04 15:39:00
517
原创 从一个SQL使用了不理想的执行计划说开,浅谈执行计划如何估算cache信息的影响及系统统计信息的收集等(2010-10-15)
其实这个案例总的来说是由两个问题引发的:一个是绑定变量的peeking机制以及相应的字段上收集了柱状图统计信息而带来的执行计划的不稳定性,这个很容易理解,这里就不多说了.另一个就是cache的问题,oracle引入optimizer_index_caching这个参数应该来说就是为了让优化器在计算cost时考虑index cache的影响,但手工设置容易带来这样那样负面的影响,并且加大了DBA的优化负担.所以oracle开始考虑自动收集cache统计信息,然后优化器在计算cost时使用这样的cach
2010-12-04 13:32:00
1560
原创 奇怪的日志应用推迟问题(2010-09-27)
因为百度收录的问题,需要推迟一个逻辑从库的日志应用,我在主库端设置的是推迟4天:SQL> show parameter log_archive_dest_3NAME TYPE VALUE------------------------------------ ----------- ------------------------------log_archive_dest_3 string
2010-12-04 11:11:00
613
原创 一台数据库短时间hang住问题的解决(2010-09-27)
数据库信息: db:10.2.0.4.0 - 64bi os:Red Hat Enterprise Linux AS release 4 (Nahant Update 7) 7月15日开始连接这台数据库的应用监控连续报宕机错误,有当时连接到数据库的同事反应说当时系统反应极慢,所以感觉应该是数据库的问题,登录到数据库主机的时候,系统已经正常了,查看alert.log,并没有任何的异常信息,从sar历史,每10分钟的一个统计来看,刚才过去的10分钟确实是%user cpu比正常时段要高出许多,
2010-12-04 10:23:00
1301
3
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人