SQL Updates, locks and multithreading

Question

I am trying to do the following:
Updating 5M rows in multiple database writer thread using OCI. I have not set any Oracle parallel execution related parameters yet.
However, it is found that there is no performance improvement in doing this in multiple threads.
My questions:
1. Does Oracle lock the table during each update? I think it does and that is why there is no performance enhancement.
- If yes, is there any way to tell Oracle not to lock the table during updates. As it is, my threads will never update the same row in parallel.
2. Is the way out is to do the following?
- Partition the table
- Do an "ALTER SESSION ENABLE PARALLEL DML"
- Fire updates
3. Is there any OCI way of doing this?
Thanks in advance,
~Sri

Answer 1

I am trying to do the following:
Updating 5M rows in multiple database writer thread using OCI. I have not set any Oracle parallel execution related parameters yet.
However, it is found that there is no performance improvement in doing this in multiple threads.
My questions:
1. Does Oracle lock the table during each update? I think it does and that is why there is no performance enhancement.
- If yes, is there any way to tell Oracle not to lock the table during updates. As it is, my threads will never update the same row in parallel.Unless you're explicitly locking the table, Oracle won't lock it. Oracle doesn't ever escalate row locks to table locks.
My guess is that something in your system is bottlenecked. Perhaps your disk, CPU, or RAM is maxed out. Perhaps your system is busy waiting to switch redo logs. There are lots of potential bottlenecks here, you'd have to do some investigation to figure out what's taking so long.
One quick thing you might try is to use the /*+ append */ hint (i.e. insert /*+ append */ into table (your query here)). This tells the database to do a parallel direct path load, avoiding most redo log generation. This improves the speed, but isn't particularly friendly for database recovery. Make sure you read the documentation on this hint before you use it.
You may also be able to change your SQL to use the bulk collection syntax.
I'd also take a look at this bit of the Oracle documentation, "Serial and Parallel INSERT"
<http://technet.oracle.com/docs/products/oracle8i/doc_library/817_doc/server.817/a76965/c21dlins.htm#2507>
There's a pretty good asktom article over here. Search the site and you'll find lots of info on this sort of thing.
<http://asktom.oracle.com/pls/ask/f?p=4950:8:::::F4950_P8_DISPLAYID:1119033812977>
2. Is the way out is to do the following?
- Partition the table
- Do an "ALTER SESSION ENABLE PARALLEL DML"
- Fire updatesI'm assuming that you have the partitioning options in your database. If so, this is likely to be faster, though I'm not sure by how much. Have you benchmarked a test to see? Of course, if you account for the time to partition the table, you're likely to remove all of your performance gain.
Also, unless you are able to spread your inserts across the various partitions, you're unlikely to see any performance benefit.
This strikes me as a pretty drastic approach.
3. Is there any OCI way of doing this?Well, you could execute the SQL above against the table from OCI. I'd recommend doing this sort of thing from SQL*Plus or something of that genre, though, simply because folks may get upset at you if your application partitions their tables for them.
Thanks in advance,
~Sri