orcale并行的问题。

[搜索引擎式编程领军人物]

在测试orcale并行执行查找、dml、ddl在这台服务器上是否合适时，出现了一些小问题：PL/SQL developer、4核cpu服务器、500万条数据 。因为主要是测试update，服务器压力过大，所以选在晚上深夜用job设置procedure进行测试。
1、理论上来说，在特定的并行度以内，应该是并行度越高（我觉得应该是4），时间越短，但是实际情况是时间跳度很大。
2、如果把每一个事务都放到一个procedure里面的话。时间就开始不稳定，如果单独一个一个的procedure（只含一个事务）设置job的时候，时间就很稳定。这是为什么？
3、是不是超过cpu核数的并行度以后，越高反而用的时间越慢？

[碧水幽幽泉]

测试update的存储过程或job不能随便开多个并行去测试，尤其是在不确定服务器是否空闲的时候。

[搜索引擎式编程领军人物]

引用 1 楼 qq646748739 的回复:

测试update的存储过程或job不能随便开多个并行去测试，尤其是在不确定服务器是否空闲的时候。

意思是不能多个并行测试写入一个procedure里面吗？这是为什么呢？是在争夺资源吗？在晚上服务器应该是空闲的。

[Tiger_Zhao]

并行增加的是CPU利用率。
但是大批量处理数据的时候硬盘IO才是瓶颈。
并行的话可能同时争用IO就比较耗时，也可能正好错开就比较快。这个状态就不稳定了。

[搜索引擎式编程领军人物]

引用 3 楼 Tiger_Zhao 的回复:

并行增加的是CPU利用率。 但是大批量处理数据的时候硬盘IO才是瓶颈。 并行的话可能同时争用IO就比较耗时，也可能正好错开就比较快。这个状态就不稳定了。

虽然多个事务写在同一个procedure里面，但是按照开始时间来说，是一个事务处理完成后，才会开始下一个任务的，所以这个IO争夺是怎么发生的呢？一下是代码的以下部分例子，在一个procedure里面： begin --修改名字为“新的名字2” starttime:=systimestamp; update /* +parallel(a,2)*/ student a set a.name='新的名字2'; endtime:=systimestamp; insert into TIME_LY_TEST values(1,starttime,endtime,'并行 * 修改,并行度为2'); commit; --修改名字为“新的名字4” starttime:=systimestamp; update /* +parallel(a,4)*/ student a set a.name='新的名字4'; endtime:=systimestamp; insert into TIME_LY_TEST values(2,starttime,endtime,'并行 * 修改,并行度为4'); commit; --修改名字为“新的名字6”

[搜索引擎式编程领军人物]

引用 5 楼 Tiger_Zhao 的回复:

数据有缓存啊。 对你来说，一句语句返回后操作就算完成了，而数据库还需要一定的时间才能把数据完全刷到硬盘。 你用一个事务，缓存中都是这个事务的数据，语句执行后就返回了，之后刷的时间不算在执行时间内。 你用多个事务，缓存中还有前个事务的数据，语句执行过程中多了这部分数据的写硬盘，也算在执行时间内。 虽然缓存数据有重用的可能，但是大数据下重用概率比较小，基本上会优先把前个事务的数据刷到硬盘以便空出缓存来。

懂了。。谢谢。但是在不同的并行度下这个时间并不是很明显的有变化，这个有什么原因吗？还是因为服务器的瓶颈在那里了?

[Tiger_Zhao]

瓶颈是硬盘IO，这个满负荷后再怎么并行也快不起来。

[Tiger_Zhao]

数据有缓存啊。
对你来说，一句语句返回后操作就算完成了，而数据库还需要一定的时间才能把数据完全刷到硬盘。
你用一个事务，缓存中都是这个事务的数据，语句执行后就返回了，之后刷的时间不算在执行时间内。
你用多个事务，缓存中还有前个事务的数据，语句执行过程中多了这部分数据的写硬盘，也算在执行时间内。
虽然缓存数据有重用的可能，但是大数据下重用概率比较小，基本上会优先把前个事务的数据刷到硬盘以便空出缓存来。