急求：oracle存取速度问题 （50分）

Question

现在要求平均每秒钟插入100条数据，也就是要求每10毫秒钟向数据库中插入一条数据。我测试了oracle9i数据库服务器，它插入1000条数据的话大概要770毫秒，但是我又测试它每插入一条数据的时间，结果很奇怪，大多数是在0.5-0.6毫秒，可是在插入1000条数据中，会有20条左右的时间会是几毫秒，甚至10几或20几毫秒，这样就满足不了每插入一条数据都能在10毫秒范围内了，请大家帮忙谢谢了。注（每条数据量大概不查过1K）
想知道oracle9i数据库服务器的数据存储模式，为什么同样是插入一条数据，有的需要时间那么长，而大多数都是那么短呢？有什么好的方法解决么？谢谢了，急求啊！

Answer 1

你的100条数据的insert语句是怎么写的?使用绑定变量了吗?如果不用绑定变量每次数据库都要进行硬解析的,会影响效率.

Answer 2

zxf_feng：能具体说一下在vc下用ado连oracle9i，怎么使用绑定变量进行数据插入么？谢谢了

Answer 3

编程的话不使用绑定变量都难.应该不是绑定变量的问题,windows的时钟本来就不精确,只能到10ms的级别,不可能到毫秒级

Answer 4

是这样的，我使用的外部硬件时钟，每10ms触发一次，然后就将数据插入表里一次，而且每次的数据不同，但都是插入到相同的表。每次大概同时要向四个表进行插入。我感觉我现在的代码不是绑定变量的，就是直接的插入insert into student('aaaaa',25,123456,'computer science and technology')
然后就执行。请帮忙，谢谢了

Answer 5

这跟服务器当时的IO,CPU的负载情况都有关系吧。服务器忙的时候自然插入就慢一些了。

Answer 6

我程序里的代码是这样的，每次只是插入一条，应该是没有提交。我连续插入10W条，大多数插入时间是在0.7-1ms，而会有很多插入时间很大，最大的会有几百ms。这难道是oracle9i在数据量达到一定程度才自动提交么？如果我代码中每插入一条记录就提交一次，能保证每次插入的时间大致相同么，误差在ms级。我现在要求的就是每次同时插入四条记录到四个表中，而且时间要控制在10ms以内（外时钟触发），请大家帮忙，谢谢

Answer 7

vc中我不太清楚，但我在delphi中
with adoquery1 do
begin
  close;
  sql.text := ' insert into table (a,b,c) values(:a,:b,:c);
  parameters.parambyname('a').value := edit1.text;
  ...
  execsql;
end;你参考一下
在java中也差不多类似

Answer 8

wffffc:想问你一下，oracle9i是不是都是等到要插入的数据量达到一定量之后才一起写入硬盘呢？能不能每插入一条语句就写入一条呢？谢谢

Answer 9

oracle中主要是通过后台进程DBWn将数据写到磁盘的，我在网上找了下，这个解释的还比较清楚，参考一下：
DBWn进程写数据到磁盘主要是两种情况：
1，LRU list与dirty list
一般情况，buffer cache中的数据先要从LRU list转移到dirty list，当脏数据达到dirty list的阀值时（25%），dbwn开始将脏数据写入到磁盘；
如果buffer cache中不足以缓冲新数据时，dbwn也会直接从LRU list写入到磁盘，不再经过dirty list的转移。
2，checkpoint
发生检查点时，同样会使dbwn进程写数据，checkpoint的情况相对较多。
表空间的offline，hot backup，段删除都会使dbwn写磁盘。上述检查点相关的写磁盘同样也要把数据从LRU list转移到dirty list然后开始写磁盘。
commit与DBWn进程的操作不要混淆。
commit的主要操作是将redo records写入到logfile。
主要的作用就是避免了数据完全没有或者部分没有写入到磁盘时，数据库出现问题，丢失数据。
如果此时宕机了，数据库会依据SCN重新redo一下之前写进去的redo records，这样就确保数据不会丢失了。

Answer 10

to:zxf_feng
看完了你给的意见，我有了不少体会。
我现在是想保证每次插入四条数据的时间控制在10ms内，如果数据库等到数据量达到一定量之后才一起写入硬盘，这时写磁盘的时间就过长了，会使下次插入数据发生延迟，导致时间超过10ms。能否控制DBWn进程的操作每插入一条语句就写磁盘呢？

Answer 11

请参考：
http://blog.csdn.net/pathuang68/archive/2009/04/16/4084139.aspx
和
http://blog.csdn.net/pathuang68/archive/2009/04/16/4084116.aspx