大家做过统计的一些存储过程可能会知道，我们经常有这类表，要先truncate它，执行插入，再在执行相关sql，这就会导致有一个时间误差，如果在truncate和插入的中间进行了表的分析，这个统计信息是不准确的，也会影响执行计划：   SQL> select num_rows,blocks from user_tables; NUM_ROWS BLOCKS -------

执行计划如何显示e-rows,a-rows？   今天一个学生问我在执行计划如何显示E-rows,A-rows 通常有两种方式：   1.  加入hint:   SQL> create table daodao (a integer);   表已创建。   SQL> insert into daodao select object_idfrom dba_objects;  

最近被很多朋友问起关于绑定变量窥探的问题: 讨论的是如果绑定变量窥探被关闭了，oracle 会怎么处理， 是每次都硬解析还是这样处理?   首先介绍下什么是绑定变量窥探? 使用SQL首次运行时的值来生成执行计划。后续再次运行该SQL语句则使用首次执行计划来执行。     影响的版本：Oracle 9i, Oracle 10g     对于绑定变量列中的特殊值或非均匀分布列上的绑定变

在我们迁移数据，或者进行同步数据的时候,对于应用变更频繁的表进行抽取数据，经常会碰到oracle需要读取回滚段，会导致很慢，有时候甚至会报ora01555错误， 比如我们有个表比较大是40G左右，就是一个月的按月分区数据，这个时候如果想尽快抽取数据到另外一个库，有几种方法： 方法1：      大家都知道的使用append，然后不写日志，parallel抽取方式: 代码类似如下: alt

问题描述: 公司的一个sql平常都是运行一个小时的，突然有一天3个小时还不能出来， sql如下: open cursor for SELECT PROVCODE,        AREACODE,        COUNT(DISTINCT USERNUMBER) MON_USERCOUNT,        SUM(LOGINCOUNT) AS MON_TOTALCOUNT   FR

开发人员提交一个执行sql: DELETE SMS_LOVERMOBILENUMBER AWHERE USERNUMBER = :B1OR A.LOVERMOBILENUMBER =LTRIM(:B1 ,'86');   SMS_LOVERMOBILENUMBER的表结构以及索引如下： create table OSS01.SMS_LOVERMOBILENUMBER (   USE

今天收到一个上线sql: 相关脚本如下: 索引结构: create unique index PK_OSS_OPERATORSITE_ACT_DAY on OSS_OPERATORSITE_ACT_DAY (STATEDATE, PROVCODE, AREACODE, SITECODE, USERNUMBER, PORTALID); merge into 条件是:  Forall i

今天快下班的时候，群里有个朋友在问，这个sql非常慢，如何解决: 原sql如下: insert /*+ append */ into dr_bps_guna_yyyymm_ch_01 select file_type,file_sn,rec_type,org_id,imsi,trm_id,forward_id,call_date,duration,base_fee,toll_fee,toll

1.  我们都知道什么是hint,但是如何写好复杂sql的hint,保证他比较稳定的执行: 比如：我们看这样一个sql: SQL> create table t1(n1 integer,n2 integer); Table created. SQL> create table t2(n1 integer,n2 integer); Table created. SQL>

对于dml频繁的统计一定要注意一点是必须分阶段实施统计，不可以一次性取很长时间的数据，因为数据库为了保证一致性，会在sql执行的时候记录一个起始时间点，然后对于之后所有修改过的块都会去回滚段去寻找，这样有两个问题： 第一:       造成回滚段长时间占用，尤其是在分布式事务（比如dblink取数据），这个查询是以事务的方式进行占用回滚段的，回滚段不足会导致数据库正常的dml由于无回滚段使用而