Disable ingegrity constraint, then re-enable w/deletion of violations?

Question

Suppose table2 has a foreign-key relationship with table1. Is there any way to disable that constraint on table2, delete a huge number of records from table1, then re-enable the constraint on table 2... telling Oracle to simply delete any records it finds in table2 that no longer satisfy the constraint?
Or, alternatively, is there a way to cascade the deletes, but defer the cascaded deletion until all the records that are going to be deleted from the current table have, in fact, been deleted (or at least marked for deletion)?
For the record, the real situation is nowhere near this trivial... we have a table with ~2 billion records that's partitioned by range on its primary key (from which we want to drop a partition containing ~300 million records) and has dozens of downstream tables with foreign key relationships leading back to it.
The good news is that this isn't a database that has to be kept online and available at all times for continual transaction processing. The foreign-key relationships are mainly there for the sake of academic correctness and self-documentation, and the records being purged are ancient and haven't even been part of a table scan for months. So we're not the least bit worried about having a row in table27 spend two hours on "death row" between the time its deletion becomes inevitable (by virtue of deleting an upstream record with a foreign-key chain leading back to it) and the time it gets physically deleted. Metaphorically, we just need a fast way to slice a chunk off from table1 with a chainsaw, then efficiently eliminate the witnesses from the downstream tables with a meat cleaver. :-)

Answer 1

OK, let's suppose table1 is the big table with billions of records, from which I'm going to drop the first partition and ~250 million records contained within it.
table2 has a foreign key relationship: table2.foo_id = table1.id
table3 has a foreign key relationship to table2: table3.bar = table2.bar
both foreign key relationships are deferrable, initially deferred.
Now, partition #1 gets dropped, taking ~250 million records with it. I'm going to guess that the implicit commit comes at the end of that drop, and that's the point when Oracle officially notices that table2 has a foreign key relationship with table1 and parses through it to cascade the deletion and remove the newly-orphaned rows in table2.
The big question is, when does table2's constraint come into effect? If Oracle defers the next implicit commit attempt until it finishes purging orphaned records from table2, then proceeds to cascade the deletion and purge orphaned records from table3 before its next attempted implicit commit, that's great.
HOWEVER, I can see a conflict. DROP is a DDL statement that implicitly commits, but what about any DELETEs that get cascaded from it as an outcome of the drop? Do they fall under the single umbrella of the original DROP, or does something like this happen:
Partition #1 of table1 gets dropped. implicit commit attempted, but foreign key relationship between table2 and table1 formally noticed. Oracle deletes the first orphaned row from table2, then tries to autocommit it... and notices that table3 has a FK relationship with table2. So it scans through table3, deletes any rows that the deletion of the first row from table2 will orphan, and autocommits that deletion. It then continues looking through table2 for the next orphaned row, deletes it, attempts to autocommit, notices the FK constraint (again) between table3 and table2, scans through table3 (again) looking for rows that will be orphaned by the deletion of the second row from table2, deletes them, and autocommits. Then repeats, over and over again, scanning all of table3 from top to bottom each time it deletes a row from table2.
I have to admit I'm a little fuzzy about what exactly Oracle is doing ACID-wise behind the scenes, mainly because nothing I normally do really requires moment-to-moment integrity. All I really use transactions for is to conveniently undo the mess and restore the database to its original state if a program crashes for some reason, and try to sidestep them (and their overhead) entirely when I'm doing something manually with Toad or SQL*Plus that's time-consuming and doesn't need to keep the database in any kind of usable state between the time it starts and ends. But in the case of deferred integrity checks, I can see how encouraging Oracle to autocommit could actually make performance worse, by prematurely firing otherwise-deferrable constraints.