Changing the size of a traditional tablespacemeant resizing its datafiles individually using theALTER DATABASE statement and identifying each datafileto resize by its complete operating system pathname or internal file number:

ALTER DATABASE
DATAFILE '/u07/oracle/oradata/train/media01.dbf'
RESIZE 1G;

Similarly, setting the autoextendproperties of a tablespace was done by setting each datafile individually:

ALTER DATABASE
DATAFILE '/u07/oracle/oradata/train/media01.dbf'
AUTOEXTEND ON NEXT 100M MAXSIZE UNLIMITED;

For large tablespaces withhundreds of datafiles, this can be a major chore. Butbecause BIGFILE tablespaces have only one datafile, there is no need to identify that datafile when they need to be resized. The resize can bedone much more conveniently at the tablespace level,using the ALTER TABLESPACE statement:

ALTER TABLESPACE media
RESIZE 1G;

Likewise, a datafile's AUTOEXTENDproperties can be changed for the tablespace as a wholefor BIGFILE tablespaces:

ALTER TABLESPACE media
AUTOEXTEND ON NEXT 100M MAXSIZE UNLIMITED;

This is especially beneficial if you're using ASM diskgroups with Oracle Managed Files, as you may not even know the exact name ofthe datafile because it was autogenerated.

However, BIGFILE tablespacesshould not be used just for this feature. BIGFILE tablespacesare designed to be used with storage area networks (SAN), RAID arrays, ASM, andsimilar storage solutions that provide striping of data across multipledevices. Because they can only have one datafile,there is no opportunity to load balance among separate datafilesor add an additional datafile as the tablespace grows if these technologies are not used.