Is it ok if I change my UNDO_TABLESPACE intial_exten, next_extent to 1M by 1M? (maybe equivalent to RBS_BIG) the default is 100k by 65k
This is intended for long runnings jobs which creates lots of extents when reading large amount of data.

not exactly, it will vary the number of undo tablespace extents.
for example:
if you have undo tablespace size to 100M and initial extent in 1M and next extent in 1M, you will have 100 extents in it.
if you have undo tablespace size to 100M and initial extent in 10M and next extent in 10M, you will have only 10 extents.

just only less reallocations on disk.

The undo tablespace is configured with this parameters, if you change any the follow changes will get this new values.

It is good idea to keep big size extents of UNDO tablespace to support huge transaction & for oracle it will be less overhead while allocation/re-allocation.
But in Local managed undo tablespace created by oracle (default) will not contain any value specified to NEXT_EXTENT , check if you can re-create it with customized extent value

John and Fran Thanks....but I can not understand what you are explaining.

My issue is I got ORA-01555 snapshot too old. One way of resolving this is to increase undo_segment chunks to a higher value, but the problem is it not possible as John had demo.

Do I need to drop the UNDOTBS1 and recreate it with bigger initial and next? Or do I need to choose and old rbs01, rbs02, rbs_big, manually managed rollbacks so that I could create bigger segment for LONG RUNNING BATCH JOBS WITH BIG DATA TO PROCESS?

Only Oracle knows, but it could be because it will eventually all be allocated anyways, and it really is doing everything in 64K chunks under the covers. New allocation requests could be a lot more variable in user tablespaces, only DBA's can decide if their data usage patters are going to be helped by preallocating large segments.

Review the causes of ORA-1555. Too often, they are self-inflicted by programmers.