A single-tenant database or non-container database is a self-contained set of datafiles, control files, redo log files, parameter files, and so on that include all of the Oracle metadata (the definition of ALL_OBJECTS, for example), Oracle data, and Oracle code (such as the code for DBMS_OUTPUT), in addition to all of the application metadata, data, and code. This is the only type of database in Oracle releases prior to version 12c.
Figure 2-1 depicts the single-tenant database architecture. The database name is ORCL, and also the instance name is ORCL. The client initiates a connection to the ORCL instance by connecting to the database listener. The listener hands off the connection to a database server process. From that point on, the database server process handles any SQL requests that the client sends to view or manipulate data.
Figure 2-1. Oracle’s single-tenant (non-container database) architecture
Figure 2-1 shows that you have a single database server (sometimes referred to as host, machine, vm, node, and so on). On the database server, you have one instance (memory structures, background processes, and other processes) and one database (physical files on disk).
The memory structures interact with client (user) processes accessing and manipulating the data (datafiles on disk). The client connects to the listener process running on the database server. The listener then hands off the connection to a server process that handles the SQL processing requests from the client.
Separate from the database files are the Oracle installation software files (sometimes referred to as binaries). These are typically installed in a location on disk named ORACLE_ HOME (with various components stored in subdirectories). Some examples of binary files would be oracle, sqlplus, rman, dbca, expdp, impdp, lsnrctl, and so on.
After the instance has been started, you can display its memory components (on UNIX/Linux) via the ipcs command:
$ ipcs
Here’s a partial snippet of the output:
------ Shared Memory Segments --------key shmid owner perms bytes nattch status
0x00000000 42 oracle 600 8908800 104
0x00000000 43 oracle 600 1056964608 52
0x00000000 44 oracle 600 7868416 52
0x43f8ffbc 45 oracle 600 24576 52
To view system monitor background processes associated with the ORCL instance, you can issue the process status (on UNIX/Linux) command:
| oracle | 7969 | 1 | 0 22:43 ? | 00:00:00 ora_smon_ORCL |
And we can see the datafiles associated with the ORCL database via the following query:
$ sqlplus / as sysdba
SQL> select name from v$datafile;
NAME
/opt/oracle/oradata/ORCL/ORCL/datafile/o1_mf_system_j480tkhg_.dbf
/opt/oracle/oradata/ORCL/ORCL/datafile/o1_mf_sysaux_j480vnpn_.dbf
/opt/oracle/oradata/ORCL/ORCL/datafile/o1_mf_undotbs1_j480wfwd_.dbf
/opt/oracle/oradata/ORCL/ORCL/datafile/o1_mf_users_j480wgz7_.dbf
To summarize, the prior example created a single-tenant (non-container) type database. This single-tenant type of database architecture has been deprecated by Oracle. Additionally, Oracle has stated that the single-tenant architecture is desupported starting with Oracle 21c. Having said that, this type of database is still widely used. Many legacy systems running on older versions of Oracle still use this architecture. Therefore, it’s important to be familiar with this type of database architecture.
