30
million rows, in
one transaction?
Well, "I'm not surprised." Can you imagine what the system would have to do, what it would have to copy and keep and then throw-away, in order to roll-back
that?!
Time to cook up a new strategy. Your computer will love you for it.
For bulk operations like that, you simply need to arrange things so that you purge about 100,000 records per transaction and then commit. Or maybe 10,000. You'll also need to section your data in
some way so that each delete-query only passes through a portion of the database: some way of apportioning it so that: you don't uselessly troll through already-visited territory
and yet, the fact that you're deleting a bunch of records won't cause any candidates to be overlooked.
Transactions are important, on the one hand, because they imply locking and buffering which is very critical for all kinds of bulk-data operations.
But they
also imply "rolling data back," which can quickly balloon into rollback-files of unmanageable size. (They can also lock-out other users, in the manner of a 9-zillion pound gorilla with huge feet.) So you need to devise a strategy that balances between these issues.