tags:

views:

267

answers:

4

This hangs in Php (5.2.6-Win32 + Oracle10g) is it a bug, or I'm doing something fundamentally wrong?

try {
    $conn = new PDO($DB,$USER,$PASSWORD);
    $conn->setAttribute( PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION );
    //connected
    try {
     $conn->exec("DELETE FROM MY_TABLE");
     echo "done";
...

Note: I don't know if this is a bug or not, I'm guessing it is. However as I couldn't find a bug report for this after a quick search. I might be doing something wrong, so I figured I'd ask here first, and for posterity in case someone else has a similar issue.

+1  A: 

Pretty unlikely that it's hanging since PDO seems to be in use quite a bit, though how much with Oracle, I don't know.

A delete from my_table may take some time depending on how many records there are. How long did you wait before deciding it was hung and how many records were in the table?

paxdiablo
Waited 1 hour to delete 4 records of two columns with no foreign keys, triggers or indexes... I guess Oracle isn't that slow ;)
Robert Gould
No, I would think not.
paxdiablo
My only other suggestion would be to echo before the exec as well so you know that's where the problem is. And to post more of the code - I'm wondering whether there's something earlier on that's problematic (specifically an exception in the outer-try block that prevents the exec from being called).
paxdiablo
That line seems to be perfectly valid but I *have* seen ones that say "delete from x where 1" - I'm wondering if there's a bug somewhere that requires the where-clause since it's superfluous otherwise.
paxdiablo
Are you using the OCI8 interface? The PHP PDO site says it's experimental !!
paxdiablo
That is true. I'm using the experimental PDO :/
Robert Gould
+1  A: 

Are there other activities going on in the database at the same time? If yes, I'd suspect deadlocks. Some uncommitted DML transaction(s) might be locking some rows of the MY_TABLE.

If you don't need rollback capability, consider using TRUNCATE instead of DELETE.

Juris
There was no other activity going on, and thus no deadlocks or in transit DML transactions. So I'm guessing it is some sort of Bug...But your suggestion to use TRUNCATE did work, now I can go on with my work, thanks!!!
Robert Gould
Just be aware, TRUNCATE is DDL, if you are using transactions here, the statement will cause an implicit commit and cannot be rolled back
Matthew Watson
+2  A: 

A DELETE without a WHERE will (most likely) a full scan of the table. That means it reads every block under the 'high-water mark' - that is every block that has ever been used by the table. So if the table was, at one time, very big, then it can take a very long time to delete just a handful of records. [Because it doesn't 'know' there are only four records until it reads all that space.]

A truncate doesn't do this. It simply moves the high-water mark of the table so that any blocks that were in use quickly become unused.

Gary
thanks for the explanation!
Robert Gould
A: 

If there is a transaction running on the same table, it might block your DELETE.