百万条数据的表。插入数据的优化问题。

真心觉得你插入的sql语句有问题！
是不是插入的sql语句有神马子查询什么的？

解决方案 »

免费领取超大流量手机卡，每月29元包185G流量+100分钟通话, 中国电信官方发货

没有子查询
就是一条直传递，NOLOGING的语句。
数据库是不是很老了，跑的job比较多
也不老啊。最大的表才2个G。总共数据库使用了。9个多G。
JOB也只有四个。
服务器配置。两颗4核CPU。 8G内存。SAS1.5K硬盘。
你要确定你的job里面只有插入操作么？
如果确定是插入操作的问题，那么就把插入的代码复制出来，然后在外面执行一次看看插入的时间是否真的很慢！确定是插入慢了那么就插入一条试试要多长的时间。然后在用forall语句插入几十万条试试要多长时间。
最好贴你的job插入部分关键代码来看看！
测试一下不放job直接执行插入语句，需要多长时间？
我执行insert用NOLOGING 4W多条也就1分钟不到，主要时间还是用在select的关联查询上。你插入10多个小时会不会是因为4个job同时往这个表插入造成锁表？
使用oracle的sqlloader工具导入数据很快的，insert的话很慢的
没有锁表之类的情况。都是在JOB没执行的时候手工插入的。
手工插入需要一两个小时。没有关联查询。就是直传递的一条语句。
create table SALES_PRO
(
  sdate      DATE not null,
  grpcode    VARCHAR2(20) not null,
  shopcode   VARCHAR2(20) not null,
  sstyle     VARCHAR2(20) not null,
  pcode      VARCHAR2(20) not null,
  unit       VARCHAR2(20) not null,
  num        NUMBER(18,3) not null,
  pname      VARCHAR2(64) not null,
  svalue     NUMBER(18,4),
  scname     VARCHAR2(60) not null,
  fpcode     VARCHAR2(20),
  supercode  VARCHAR2(20) not null,
  bcname     VARCHAR2(60) not null,
  bccode     VARCHAR2(20) not null,
  sccode     VARCHAR2(20) not null,
  price      NUMBER(18,3),
  shopname   VARCHAR2(20),
  grpname    VARCHAR2(20),
  classes    VARCHAR2(50),
  scost      NUMBER(18,4),
  departcode VARCHAR2(20),
  departname VARCHAR2(20),
  teamcode   VARCHAR2(20) not null,
  teamname   VARCHAR2(50) not null,
  sdepartno  VARCHAR2(20),
  barcode    VARCHAR2(20),
  discount   NUMBER(18,4),
  zzk        NUMBER(18,4),
  tax        NUMBER(18,3) default 0 not null,
  sheettype  VARCHAR2(6) not null,
  dkrate     NUMBER(18,3) default 0 not null
)
tablespace DATA_SPC
  pctfree 10
  initrans 1
  maxtrans 255
  storage
  (
    initial 2000M
    minextents 1
    maxextents unlimited
  );
-- Create/Recreate primary, unique and foreign key constraints
alter table SALES_PRO
  add constraint SALES_PK primary key (SDATE, SHOPCODE, PCODE, NUM, SUPERCODE, SCCODE, SHEETTYPE, TAX)
  using index
  tablespace DATA_SPC
  pctfree 10
  initrans 2
  maxtrans 255
  storage
  (
    initial 64K
    minextents 1
    maxextents unlimited
  );
-- Create/Recreate indexes
create index IND_PCODE on SALES_PRO (PCODE)
  tablespace DATA_SPC
  pctfree 10
  initrans 2
  maxtrans 255
  storage
  (
    initial 64K
    minextents 1
    maxextents unlimited
  );
create index IND_SDATE_SUPERCODE on SALES_PRO (SDATE, SUPERCODE)
  tablespace DATA_SPC
  pctfree 10
  initrans 2
  maxtrans 255
  storage
  (
    initial 64K
    minextents 1
    maxextents unlimited
  );
create index IND_SUPERCODE on SALES_PRO (SUPERCODE)
  tablespace DATA_SPC
  pctfree 10
  initrans 2
  maxtrans 255
  storage
  (
    initial 64K
    minextents 1
    maxextents unlimited
  );
这么一条删除语句，都执行了15分钟。
delete sales_pro  where sdate=to_date('2014-01-28','yyyy-mm-dd') ;
看看索引有没失效，检查SQL代码有没问题。正常insert那么点数据不可能慢的，insert上百万都只要那么点时间。
delete很慢，如果sdate=to_date('2014-01-28','yyyy-mm-dd')的数据量大确实很可能
索引没有失效。
DELETE 15分钟，我还能接受。
INSERT 用了2个小时插入6万条记录。
insert into sales_pro
  select *from tk;
commit;
就这么一条语句2小时。
select * from tk需要多少时间,是不是有触发器什么的影响了插入的速度？
利用直接路径加载试试 /*+ APPEND */ NOLOGING 也可以加上并行 PARALLEL 并行度最好不要超过CPU个数
删除数据条件涉及的数量多吗？走索引了吗？可以尝试用ROWID方式删除
删除速度还能可以。加NOLOGING 速度还是慢。
TK这个表也没触发器。
插入前先禁用或者删除索引插入完成后在重新建立
ps alter index index_name unusable;
想要知道为什么执行insert慢的话，你可以使用10046和10053去查看一下trace具体分析一下问题。你也可以使用hint的append句式去直接把数据在高水位线上添加，应该会加快点insert的速度。
我觉的是表的问题，我遇到这样的问题，不晓得是什么情况，create  select 建一张表后，再drop原表，改表名就好了。估计不是有资源争用就是表空间碎片化了
索引会影响insert的速度，特别是联合索引比一般索引的开销要大