Tradition and the ability for elegant failure degradation.
As the database has evolved over 11 versions, important views and tables that maintain and support the database have been programmed into the two tablespaces. Furthermore, they represent a fantastic logical separation between the "NEVER EVER TOUCH" and the "third parties can put stuff here."
From the docs:
The SYSAUX tablespace was installed as an auxiliary tablespace to the SYSTEM tablespace when you created your database. Some database components that formerly created and used separate tablespaces now occupy the SYSAUX tablespace.
If the SYSAUX tablespace becomes unavailable, core database functionality will remain operational. The database features that use the SYSAUX tablespace could fail, or function with limited capability.
Thus, while it's critical to have the SYSTEM
tablespace never ever fail, one doesn't need to be nearly as paranoid for SYSAUX, this allows the designers to keep the size of SYSTEM down, while allowing third-party auxiliary features to be part of the "core" database.
You will have to examine how the question is worded. By default 11g will create all three tablespaces. You can however create a database with only SYSTEM and SYSAUX. Technically speaking you can upgrade pre-10g database and not add SYSAUX, or remove the SYSAUX tablespace after the database is created and therefore have a database with only a SYSTEM tablespace, but you would be ill advised to do so and I really don't think they would look for that in an answer.
From the 11.2 Administration Guide:
The SYSAUX tablespace is always created at database creation.
From another section of the Administration Guide:
An auto-extending undo tablespace named UNDOTBS1 is automatically
created when you create the database with Database Configuration
Assistant (DBCA)...
If no undo tablespace is available, then the
instance starts without an undo tablespace, and undo data is written
to the SYSTEM tablespace. You should avoid running in this mode.
From the 10.2 Concepts Guide:
...the SYSAUX tablespace is always created during database creation or
database upgrade...
During normal database operation, the Oracle database server does not
allow the SYSAUX tablespace to be dropped or renamed. Transportable
tablespaces for SYSAUX is not supported.
Note: If the SYSAUX tablespace is unavailable, such as due to a media
failure, then some database features might fail.
From the 10.1 SQL Reference:
You cannot drop the SYSTEM tablespace. You can drop the SYSAUX
tablespace only if you have the SYSDBA system privilege and you have
started the database in MIGRATE mode.
From the 10.1 Administrators Guide:
If the SYSAUX tablespace becomes unavailable, core database
functionality will remain operational. The database features that use
the SYSAUX tablespace could fail, or function with limited capability.
http://oradbpedia.com/wiki/The_SYSAUX_Tablespace has this take:
The SYSAUX tablespace is a new tablespace that is required in Oracle
Database 10g...
When you migrate to Oracle Database 10g, the SYSAUX tablespace needs
to be created as a part of that migration. This is done after mounting
the database under the new Oracle Database 10g database software. Once
you have mounted it, open the database in migrate mode with the
startup migrate command. After the database is open, you can create
the SYSAUX tablespace.
Note: The loss of the SYSAUX tablespace is not fatal to your database.
In our testing it appears that the only real impact is that certain
functionality related to the occupants of the SYSAUX tablespace is
lost.
Earlier versions did not have a SYSAUX tablespace:
SYSAUX is the name of the compulsory tablespace, introduced in Oracle
10g.
Best Answer
First, it is important to understand the purpose of SYSAUX tablespace. As the name implies, it is intended to support system tablespace, by holding metadata about database components and other frequent changing data, such as reports.
Docs: "If the SYSAUX tablespace becomes unavailable, core database functionality will remain operational. The database features that use the SYSAUX tablespace could fail, or function with limited capability."
The startup migrate option was introduced on version 9i, and it's only suitable when migrating oracle across different versions of database. So, why can I drop the sysaux tablespace with "startup migrate"? Only because Oracle will internally take care of the general errors that are expected to happen during migration processes. It will change a bunch of parameters through alter session, enable some trace events, all of these to make sure migration will happen smoothly. Example of parameters:
So do not drop sysaux tablespace if you don't have a reasonable reason to do so. If you need to manage its data, there are a lot of options:
You can query v$sysaux_ocuppants to determine what resources are taking space;
You can move some of its contents to another tablespace through packages/ procedures;