数据库服务器重启后，首次insert操作很慢

[truetempus]

我的oracle数据库中有一张数据表，按照时间进行了分区，根据表空间的使用率，会定期删除老的分区，为防止删分区时的导致的全局索引问题，该表没有创建主键，现在的问题是，每次重启服务器之后的第一个插入操作，会等待50秒，哪怕只插入一条数据，我用sqldeveloper连上测试，并用10046进行了跟踪，trace如下：
********************************************************************************

SQL ID: 06nvwn223659v
Plan Hash: 0
alter session set events '10046 trace name context off'


call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.00 0.00 0 0 0 0
Fetch 0 0.00 0.00 0 0 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 2 0.00 0.00 0 0 0 0

Misses in library cache during parse: 0
Parsing user id: 86



********************************************************************************

OVERALL TOTALS FOR ALL NON-RECURSIVE STATEMENTS

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 8 0.13 0.26 0 0 0 0
Execute 8 0.63 0.76 17 4 62 1
Fetch 6 0.15 0.41 50 20980 0 15
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 22 0.92 1.43 67 20984 62 16

Misses in library cache during parse: 7
Misses in library cache during execute: 2

Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
SQL*Net message to client 8 0.00 0.00
SQL*Net message from client 8 24.35 51.83
db file sequential read 67 0.03 0.25


OVERALL TOTALS FOR ALL RECURSIVE STATEMENTS

call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 2516 0.06 0.07 0 0 0 0
Execute 2872 0.50 0.65 4 15 41 8
Fetch 3171 1.10 50.42 2489 14118 0 6462
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 8559 1.68 51.15 2493 14133 41 6470

Misses in library cache during parse: 42
Misses in library cache during execute: 42

Elapsed times include waiting on following events:
Event waited on Times Max. Wait Total Waited
---------------------------------------- Waited ---------- ------------
db file sequential read 2493 0.12 49.58
Disk file operations I/O 11 0.00 0.00

8 user SQL statements in session.
2872 internal SQL statements in session.
2880 SQL statements in session.
********************************************************************************
Trace file: agc_ora_3991.trc
Trace file compatibility: 11.1.0.7
Sort options: default

1 session in tracefile.
8 user SQL statements in trace file.
2872 internal SQL statements in trace file.
2880 SQL statements in trace file.
48 unique SQL statements in trace file.
70356 lines in trace file.
95 elapsed seconds in trace file.

我现在想弄明白三件事情：
1.现在这种慢，到底是什么导致的，是因为表没有主键的原因吗？
2.如果主键的原因，那为什么网上有很多帖子说建议分区表不要建主键？
3.为什么只在首次插入的时候出现问题，紧接着第二次插入就非常的快？

希望有高人给予指点，本人对数据库比较小白，多谢，有的分全给了~~~

[江南小鱼]

mark一下，坐等大拿，我也很好奇这种现象是怎么造成的。

[truetempus]

我的SQL非常简单insert into yc_scadasrv values(1,1,sysdate);往表里插入一条数据而已 刚刚我用EXPLAIN PLAN FOR insert into yc_scadasrv values(1,1,sysdate); select * from table(DBMS_XPLAN.DISPLAY) 得到的执行计划如下，也是非常简单，但值得一提的是，执行第一条SQL创建执行计划用了111秒。。。。 ---------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | ---------------------------------------------------------------------------------------- | 0 | INSERT STATEMENT | | 1 | 100 | 1 (0)| 00:00:01 | | 1 | LOAD TABLE CONVENTIONAL | YC_SCADASRV | | | | | ---------------------------------------------------------------------------------------- 我用的oracle版本是11.2 创建yc_scadasrv表的脚本如下，是用一个存储过程创建的 create table YC_ScadaSrv (globalid NUMBER(10) NOT NULL, rtvalue NUMBER NOT NULL, savetime TIMESTAMP NOT NULL) partition by range(savetime) interval(numtodsinterval(1,''hour'')) (partition lz_yc_part_01 values less than(to_date(''' ||hiVal||''',''yyyy-mm-dd hh24:mi:ss'')))';

[minsic78]

从10046来看，50秒都是空闲等待： SQL*Net message from client 8 24.35 51.83 但通常出现这种数据库应该干活却经历很长时间空闲等待的时候，怕是底下有些不太寻常的事情发生。 怀疑： 1、可能因为11g的deferred segment creation导致的，因为空表一开始没有分配物理空间，而是在插入数据的时候才开始插入； 2、因为一般来说，初始的extent也并不会太大，除非：a）建表时候手工指定了很大的extent；b）exp的时候使用了compress=y来到处大表，导入的时候会分配一个很大的足够容下所有数据的extent（即便不导入数据），虽然可以排除这两种情况，但楼主可以确认下这张表的初始extent是否很大？ 3、如果并不大，那么是否数据文件较小，插入数据时是否存在动态扩展？ 暂时就这些。

[minsic78]

引用 3 楼 minsic78 的回复:

从10046来看，50秒都是空闲等待： SQL*Net message from client 8 24.35 51.83 但通常出现这种数据库应该干活却经历很长时间空闲等待的时候，怕是底下有些不太寻常的事情发生。 怀疑： 1、可能因为11g的deferred segment creation导致的，因为空表一开始没有分配物理空间，而是在插入数据的时候才开始插入； 2、因为一般来说，初始的extent也并不会太大，除非：a）建表时候手工指定了很大的extent；b）exp的时候使用了compress=y来到处大表，导入的时候会分配一个很大的足够容下所有数据的extent（即便不导入数据），虽然可以排除这两种情况，但楼主可以确认下这张表的初始extent是否很大？ 3、如果并不大，那么是否数据文件较小，插入数据时是否存在动态扩展？ 暂时就这些。

更正，怀疑1：“而是在插入数据的时候才开始插入”——>“而是在插入数据的时候才开始分配”