Thanks Chris,

To illustrate it in simple way. Below is original state of my table. Data loaded into this table with null bucket_no.
ID EMP_ID DEPT BUCKET_NO
---------- -------------------- -------------------- ----------
1 2000 A
2 2001 A
3 2002 B
4 2003 C
5 2004 D

Expected state of table after dividing records into 3(configurable) parts. Need not be perfectly equal but near equal.

ID EMP_ID DEPT BUCKET_NO
---------- -------------------- -------------------- ----------
1 2000 A 1
2 2001 A 1
3 2002 B 2
4 2003 C 2
5 2004 D 3

ntile might give me results with grouping done as select but I need to persist the bucket_no in the table. i.e I need to update the bucket_no column for all 2 mil rows in the table. There are some batch processes outside of Oracle(say some java application) that use this buket_no for parallel processing. Oracle does not have to process them after bucket_no updated.

Is there any cost efficient SQL to update all rows with bucket numbers?

How below piece of code is going to fare for over 2 million records update? is there any better way of doing it?

update employee f set bucket_no= (select mybucket from (SELECT 
   NTILE(4) OVER (order by id) as mybucket,id
  FROM employee ) e where e.id=f.id);

Parallel DML

dbms_redefinition.execute_update 

Create-table-as-select

create table tmp as 
  select .., ntile(N) over (...) bucket.
  from ...

DBMS_parallel_execute

ntile might give me results with grouping done as select but I need to persist the bucket_no in the table. i.e I need to update the bucket_no column for all 2 mil rows in the table. There are some batch processes outside of Oracle(say some java application) that use this buket_no for parallel processing. Oracle does not have to process them after bucket_no updated.

Chiran,
You have not mentioned it but I am really hoping that the requirement of persisting bucket numbers is original requirement which has some justification (I believe you have mentioned in original post something like "I want to persist the bucket number"...)
Because above you also claim that Oracle (aka database code) is not going to use the bucket number at all. While I understand that some batch processes outside database need to have ability to process this table data in near-equal sized chunks, it still does not necessarily mean that there is a requirement to STORE the bucket number.
For e.g. if this outside batch process is only ever going to process all data in this table only once then you still don't need to persist bucket number. All that is needed is to be able to present the data in this table with an extra column containing bucket number, which can be achieved by creating a view on this table columns and adding a derived column using NTILE function.

I would be tempted to revisit the real requirement behind the bucket number column value. Is the same batch process (or some other process) going to use this bucket number value to either create and store data in database that needs the ability to reconcile with original source data? Or is someone worried about the case where if batch process fails without processing all data and needs to be restarted, either from the beginning or simply resume from the point of failure (after fixing the underlying cause of failure)?

As someone has rightly said, the best way to speed up something is to not do it, it would help if you are able to revisit and confirm that the requirement for persisting bucket number is valid.

You say you want the bucket numbers in order to do batch processing in parallel later on.

Batch processing is usually more efficient if you have buckets based on blocks, not on rows. DBMS_PARALLEL_EXECUTE allows you to divide a table into buckets based on blocks; you dictate the number of blocks per bucket, not the number of buckets.

If for some reason you want to dictate the number of buckets, see https://stewashton.wordpress.com/category/chunking-tables/