I have a table that contain huge amount of records.
There is a problem to run delete sql on this capacity.
Is it possible to do commit after number of records ?
Whenever you delete any record(s), your RDBMS keeps them in Rollback segment, so in case if you issue a rollback command old data can be restored. In case you delete huge amount of record, you need to make sure that size of those records should not exceed what rollback segment can take care of.
If you need to delete all records you can truncate the table. on the other side write a small PL/SQL procedure and delete the inside loop based on row number and commit.
Alternatively you can run the same query from you SQL console multiple times. For example If you are working on oracle
I need to delete all records from table via java class (not from the console)
How can I check that: "the size of those records should not exceed what rollback segment can take care of" ?
for rollback segment information you can check with your DBA , but rather going in such details I would advice you to write a java program , and delete aprroximately 50K or 100K records in one go.
1. Execute a query to get the count of satisfying record
2. Identify the number of loop iteration by dividing total record with number you decide to delete in one go
3. commit inside the loop.
by the way, how many records are there which you want to delete from table.
You can also use PreparedStatement#addBatch() in a loop to add every record to a batch and execute it only once afterwards. Costs only one DB hit instead of a hit for every row which would be far more expensive and slow.
If you do not need to be able to rollback the changes, this can work from java (please test first - and - yes - it is not a best practice):
Drop table, then recreate it and it's constraints.
It might exceed the rollback segment space.
The issue the OP has is that when lots of records are deleted, the undo log might become bigger as allowed.
Just to add, truncate isn't part of SQL92 and thus not supported by all database(version)s. Although it is less or more adopted by many DB's and likely to be part of the upcoming SQL92 successor. Since a certain version Informix supports Truncate as well, so this should be the way to go.