一个数据记录系统,需要长期性每秒钟记录10个记录。开始性能没有问题,但是当表中数据超过150000行时,插入数据就变得很慢而使系统不可用。我在另一贴问过,http://topic.csdn.net/u/20101208/11/601d1467-cbaa-49c2-926b-7af2237c096e.html我按照里面的提示方法,去掉了所有索引,插入时加了 nologging,但是性能还是没有一点改观。我使用 TOAD的 rebuild table 工具后,性能恢复到开始时的状态。我查看了 rebuild table 的 sql 代码,Toad只是把原来的表rename了,然后重建了 一个同名的表。但是我想,插入一定数据后,肯定还会有性能下降的情况出现。请问各位高手,这种问题我该如何解决呢。系统要求较高的插入性能,但查询性能要求倒不是很高。

解决方案 »

  1.   

    1、批量提交,及时释放回滚段空间
    2、有索引最好先禁掉index 等插入完之后再rebuild
      

  2.   

    你应该做个shell,没过1个月或者你估计的时间,重整下这个表,
    重整之后应该和开始时一样快。
      

  3.   

    这个shell可以设置成自动执行
      

  4.   


    批量数据的DML操作,养成良好的习惯就是批量提交,这很重要,经验告诉我的
      

  5.   

    不是,他必须等这个事务的数据在undo表空间存在的时间超出undo_retention的时间的时候才有可能释放掉
      

  6.   

     数据在没提交之前是写到了redolog里的。。
      

  7.   


    有可能?为什么是有可能?原理是什么?
    undo_rentention是可配置的吗?
      

  8.   

    undo_retention是数据保存在undo表空间的最少的时间,如果你的表空间足够大,他将一直保存在这个表空间里,当表空间里有限的时候,他不得不交换出一部分数据出去,这样你的数据就有可能是置换出去,不知道你对操作系统的最近未使用算法有了解不,意思差不多,他不过多了个条件就是至少保存了undo_retention这么久且好久没用了,这个参数是可以使用alter system 来改变的
      

  9.   

    表结构如下,从表的创建上是不是还可以优化?
    CREATE TABLE TB_PROCESSDATA
    (
      INSERT_COUNTER       NUMBER(28)               DEFAULT NULL                  NOT NULL,
      DT                   TIMESTAMP(3)             DEFAULT LOCALTIMESTAMP,
    //然后是80多列
    ...
    )
    TABLESPACE USERS
    PCTUSED    0
    PCTFREE    10
    INITRANS   1
    MAXTRANS   255
    STORAGE    (
                INITIAL          64K
                MINEXTENTS       1
                MAXEXTENTS       2147483645
                PCTINCREASE      0
                BUFFER_POOL      DEFAULT
               )
    NOLOGGING 
    NOCOMPRESS 
    NOCACHE
    NOPARALLEL
    MONITORING;
    CREATE OR REPLACE TRIGGER TB_PROCESSDATA_TRIG
    BEFORE INSERT
    ON TB_PROCESSDATA 
    REFERENCING NEW AS New OLD AS Old
    FOR EACH ROW
    WHEN (
    NEW.INSERT_COUNTER IS NULL
          )
    BEGIN
       SELECT SEQ_PROCESSDATA.NEXTVAL INTO :NEW.INSERT_COUNTER FROM dual;   EXCEPTION
         WHEN OTHERS THEN
           -- Consider logging the error and then re-raise
           RAISE;
    END TB_PROCESSDATA_TRIG;
    /
    SHOW ERRORS;
      

  10.   

    -- 这 INSERT_COUNTER NUMBER(28) DEFAULT NULL NOT NULL, 不矛盾吗?-- DEFAULT NULL , 后面又不允许 NULL
      

  11.   

    undo_retention不是说一定保留这么长时间,是尽量最少保持这么长时间,如果没有空间可用,那么是会去重用已经commit但是还没超过undo_retention时间的空间.
    UNDO_RETENTION specifies (in seconds) the low threshold value of undo retention. For AUTOEXTEND undo tablespaces, the system retains undo for at least the time specified in this parameter, and automatically tunes the undo retention period to satisfy the undo requirements of the queries. For fixed- size undo tablespaces, the system automatically tunes for the maximum possible undo retention period, based on undo tablespace size and usage history, and ignores UNDO_RETENTION unless retention guarantee is enabled.The setting of this parameter should account for any flashback requirements of the system. Automatic tuning of undo retention is not supported for LOBs. The RETENTION value for LOB columns is set to the value of the UNDO_RETENTION parameter.The UNDO_RETENTION parameter can only be honored if the current undo tablespace has enough space. If an active transaction requires undo space and the undo tablespace does not have available space, then the system starts reusing unexpired undo space. This action can potentially cause some queries to fail with a "snapshot too old" message.
      

  12.   


    在开始时用 Toad 建的表,不小心点了 DEFAULT NULL,后来不知怎么在 TOAD 里就去不掉了,后来也没管它了。:D
      

  13.   

    undo_retention没保存这么久的数据就置换出去了,那就得问你的DBA了,数据库在这个时候已经报错了,ora-01555.
      

  14.   

    貌似楼歪了。回到正题。
    1、影响插入性能的因素有哪些,如硬件、数据库系统配置、数据插入代码等。
    2、针对这些因素有哪些解决方法?
    3、如果在数据库管理层面不能解决,还有别的方法吗,比如说适时rebuild table。