If you are operating an Oracle database in `NOARCHIVELOG` mode, it implies that you are not archiving the redo logs. This mode restricts the types of recovery operations you can perform, specifically limiting you to only instance or crash recovery. You cannot perform point-in-time, media, or complete recoveries without restoring the entire database from a backup.
Given this limitation, the data structures required for Oracle `NOARCHIVELOG` database recovery are:

1. Data Files: These files contain the actual data and are a crucial part of the database. When performing a recovery in `NOARCHIVELOG` mode, you'd typically restore the data files from the most recent full backup.
2. Control File: This is a crucial file for any Oracle database. The control file contains metadata about the database, including the database's name, timestamp of database creation, information about data files and redo log files, and the log history. It is essential for synchronizing and coordinating all components of a database.
3. Online Redo Log Files: In `NOARCHIVELOG` mode, only online redo logs are available. These logs record changes made to data, ensuring that these changes can be redone in case of an instance or system failure. During a crash recovery, Oracle will use the online redo log files to reapply changes made after the most recent backup to bring the database to a consistent state.
4. Parameter File (pfile) or Server Parameter File (spfile): This is a configuration file that contains initialization parameters for the database instance. It's important for starting up an Oracle instance.
5. System Global Area (SGA): Though not a persistent storage data structure, the SGA is a shared memory area containing data and control information for one database instance. The Redo Log Buffer, a component of the SGA, is especially relevant for recovery as it contains changes not yet written to the disk.

Given the restrictions of the `NOARCHIVELOG` mode, it's imperative to maintain regular full backups of the database, as these backups are the primary source of data recovery. In many production scenarios, it is advisable to consider operating in `ARCHIVELOG` mode instead, as it provides a more granular level of control and flexibility for recovery scenarios by archiving redo log files before they are overwritten. This allows for point-in-time recovery options. However, the choice largely depends on the specific requirements and acceptable levels of risk for your database environment.