Comments on: Loading Oracle Part 2: Hundreds of Virtual Users in Oracle 10g… http://husnusensoy.wordpress.com/2007/03/04/loading-oracle-part-2-hundreds-of-virtual-users-in-oracle-10g%e2%80%a6/ You never know how long the battles going to be. You have to be ever ready... Sat, 21 Nov 2009 17:21:45 +0000 http://wordpress.com/ hourly 1 By: H.Tonguç YILMAZ Blog » PL/SQL based Oracle Database Loader(PSODL) Release 2.0 on sourceforge.net http://husnusensoy.wordpress.com/2007/03/04/loading-oracle-part-2-hundreds-of-virtual-users-in-oracle-10g%e2%80%a6/#comment-612 H.Tonguç YILMAZ Blog » PL/SQL based Oracle Database Loader(PSODL) Release 2.0 on sourceforge.net Mon, 03 Mar 2008 08:20:18 +0000 http://husnusensoy.wordpress.com/2007/03/04/loading-oracle-part-2-hundreds-of-virtual-users-in-oracle-10g%e2%80%a6/#comment-612 [...] announced the ancestor of this package a while ago in his Loading Oracle series. I developed this second release based on his idea and [...] [...] announced the ancestor of this package a while ago in his Loading Oracle series. I developed this second release based on his idea and [...]

]]> By: PL/SQL based Oracle Database Loader(PSODL) Release 2.0 on sourceforge.net « H.Tonguç YILMAZ Oracle Blog http://husnusensoy.wordpress.com/2007/03/04/loading-oracle-part-2-hundreds-of-virtual-users-in-oracle-10g%e2%80%a6/#comment-610 PL/SQL based Oracle Database Loader(PSODL) Release 2.0 on sourceforge.net « H.Tonguç YILMAZ Oracle Blog Mon, 03 Mar 2008 07:58:57 +0000 http://husnusensoy.wordpress.com/2007/03/04/loading-oracle-part-2-hundreds-of-virtual-users-in-oracle-10g%e2%80%a6/#comment-610 [...] Filed under: Oracle Performance — H.Tonguç Yılmaz @ 7:58 am Hüsnü announced the ancestor of this package a while ago in his Loading Oracle series. I developed this second release based on his idea and [...] [...] Filed under: Oracle Performance — H.Tonguç Yılmaz @ 7:58 am Hüsnü announced the ancestor of this package a while ago in his Loading Oracle series. I developed this second release based on his idea and [...]

]]> By: kocakahin http://husnusensoy.wordpress.com/2007/03/04/loading-oracle-part-2-hundreds-of-virtual-users-in-oracle-10g%e2%80%a6/#comment-10 kocakahin Mon, 05 Mar 2007 12:10:58 +0000 http://husnusensoy.wordpress.com/2007/03/04/loading-oracle-part-2-hundreds-of-virtual-users-in-oracle-10g%e2%80%a6/#comment-10 Wait for the 5th or 6th part of the post. I know that the power of IOT and clustered tables are hidden in the read operations,especially bulk ones. But remember the myth that IOT tables are tooooo much vulnarable against insert/update operations. Just as you see in Figure 2 it really dependends on the level of concurrency you use. Wait for the 5th or 6th part of the post. I know that the power of IOT and clustered tables are hidden in the read operations,especially bulk ones. But remember the myth that IOT tables are tooooo much vulnarable against insert/update operations. Just as you see in Figure 2 it really dependends on the level of concurrency you use.

]]> By: H.Tonguç Yılmaz http://husnusensoy.wordpress.com/2007/03/04/loading-oracle-part-2-hundreds-of-virtual-users-in-oracle-10g%e2%80%a6/#comment-9 H.Tonguç Yılmaz Mon, 05 Mar 2007 11:51:03 +0000 http://husnusensoy.wordpress.com/2007/03/04/loading-oracle-part-2-hundreds-of-virtual-users-in-oracle-10g%e2%80%a6/#comment-9 dbms_alert and dbms_scheduler together, nice trick really :) thank you for sharing the idea. but I believe when it comes to iot vs. heap, the comparison must contain the 10046 event analysis of the reading part also, single and bulk reads of course. check this serial test results for example; select * from heap single_row where username = :b1 call count cpu elapsed disk query current rows ------- ------ ----- ------- ---- ------- ------- ------- Parse 1 0.00 0.00 0 0 0 0 Execute 440 0.05 0.05 0 0 0 0 Fetch 44440 1.50 1.52 0 88886 0 44000 ------- ------ ----- ------- ---- ------- ------- ------- total 44881 1.55 1.57 0 88886 0 44000 Rows Row Source Operation ------- --------------------------------------------------- 44000 TABLE ACCESS BY INDEX ROWID HEAP 44000 INDEX RANGE SCAN HEAP_PK (object id 43271) *********************************************************** select * from iot single_row where username = :b1 call count cpu elapsed disk query current rows ------- ------ ----- ------- ---- ------- ------- ------- Parse 1 0.00 0.00 0 0 0 0 Execute 440 0.07 0.07 0 0 0 0 Fetch 44440 1.11 1.12 0 44987 0 44000 ------- ------ ----- ------- ---- ------- ------- ------- total 44881 1.18 1.19 0 44987 0 44000 Rows Row Source Operation ------- --------------------------------------------------- 44000 INDEX RANGE SCAN IOT_PK (object id 43273) SELECT * from heap bulk_collect where username = :b1 call count cpu elapsed disk query current rows ------- ------ ----- ------- ---- ------- ------- -------- Parse 1 0.00 0.00 0 0 0 0 Execute 440 0.06 0.05 0 0 0 0 Fetch 440 0.49 0.48 0 36100 0 44000 ------- ------ ----- ------- ---- ------- ------- -------- total 881 0.55 0.54 0 36100 0 44000 Rows Row Source Operation ------- --------------------------------------------------- 44000 TABLE ACCESS BY INDEX ROWID HEAP 44000 INDEX RANGE SCAN HEAP_PK (object id 43271) *********************************************************** SELECT * from iot bulk_collect where username = :b1 call count cpu elapsed disk query current rows ------- ------ ----- ------- ---- ------- ------- ------- Parse 1 0.00 0.00 0 0 0 0 Execute 440 0.06 0.05 0 0 0 0 Fetch 440 0.24 0.24 0 2110 0 44000 ------- ------ ----- ------- ---- ------- ------- ------- total 881 0.31 0.30 0 2110 0 44000 Rows Row Source Operation ------- --------------------------------------------------- 44000 INDEX RANGE SCAN IOT_PK (object id 43273) dbms_alert and dbms_scheduler together, nice trick really :) thank you for sharing the idea.

but I believe when it comes to iot vs. heap, the comparison must contain the 10046 event analysis of the reading part also, single and bulk reads of course. check this serial test results for example;

select * from heap single_row where username = :b1

call count cpu elapsed disk query current rows
——- —— —– ——- —- ——- ——- ——-
Parse 1 0.00 0.00 0 0 0 0
Execute 440 0.05 0.05 0 0 0 0
Fetch 44440 1.50 1.52 0 88886 0 44000
——- —— —– ——- —- ——- ——- ——-
total 44881 1.55 1.57 0 88886 0 44000

Rows Row Source Operation
——- —————————————————
44000 TABLE ACCESS BY INDEX ROWID HEAP
44000 INDEX RANGE SCAN HEAP_PK (object id 43271)
***********************************************************
select * from iot single_row where username = :b1

call count cpu elapsed disk query current rows
——- —— —– ——- —- ——- ——- ——-
Parse 1 0.00 0.00 0 0 0 0
Execute 440 0.07 0.07 0 0 0 0
Fetch 44440 1.11 1.12 0 44987 0 44000
——- —— —– ——- —- ——- ——- ——-
total 44881 1.18 1.19 0 44987 0 44000

Rows Row Source Operation
——- —————————————————
44000 INDEX RANGE SCAN IOT_PK (object id 43273)

SELECT * from heap bulk_collect where username = :b1

call count cpu elapsed disk query current rows
——- —— —– ——- —- ——- ——- ——–
Parse 1 0.00 0.00 0 0 0 0
Execute 440 0.06 0.05 0 0 0 0
Fetch 440 0.49 0.48 0 36100 0 44000
——- —— —– ——- —- ——- ——- ——–
total 881 0.55 0.54 0 36100 0 44000

Rows Row Source Operation
——- —————————————————
44000 TABLE ACCESS BY INDEX ROWID HEAP
44000 INDEX RANGE SCAN HEAP_PK (object id 43271)
***********************************************************
SELECT * from iot bulk_collect where username = :b1

call count cpu elapsed disk query current rows
——- —— —– ——- —- ——- ——- ——-
Parse 1 0.00 0.00 0 0 0 0
Execute 440 0.06 0.05 0 0 0 0
Fetch 440 0.24 0.24 0 2110 0 44000
——- —— —– ——- —- ——- ——- ——-
total 881 0.31 0.30 0 2110 0 44000

Rows Row Source Operation
——- —————————————————
44000 INDEX RANGE SCAN IOT_PK (object id 43273)

]]>