Lesson 1

Finally, you have a chance to do some real work with Oracle. In this module, we make preparations to create the database that will be used for the remainder of this course. Together, we will:

1. Review Oracle's Optimal Flexible Architecture
2. Create a database parameter file
3. Size the SGA and the database buffer cache
4. Decide on a database block size
5. Size the initial database files

In the module following this one, we actually create the course project database discussed earlier in the course. If you are running Oracle, you'll be building an actual database. If you are not, we walk you through the steps so you understand how it's done. Beyond this course, this project database also supports the next four courses in the Oracle Database Administration Certification Series. Now, let's make the necessary preparations.

Before you install Oracle and start creating databases, you need to understand Oracle's Optimal Flexible Architecture (OFA) standard, a set of conventions for consistent directory structures and file naming when installing and creating Oracle databases.
One irony of this ubiquitous "standard" is that almost every DBA customizes it, in some way, to fit their environment. Because most shops still implement some form of OFA, understanding the structure remains critical even where a given site has deviated from it. Figure 6-1 shows the directory structure and file names used with the OFA standard, from the operating-system layer all the way down to where database files and recovery files actually live. Not every directory and file in a real Oracle environment fits in one figure, but the critical, most frequently used ones are all here.

The OFA standard includes several directories you should be familiar with:

1. Oracle inventory directory: holds platform-level Oracle configuration files (such as oraInst.loc, oratab, and orasec) that exist outside any single ORACLE_HOME, tracking every Oracle installation on the host, not just one version.
2. Oracle base directory (ORACLE_BASE): the root under which most Oracle-specific files live. A given software install shows up beneath it as something like $ORACLE_BASE/product/26.1.0/db_1, making the version-to-home relationship visible directly in the path.
3. Oracle home directory (ORACLE_HOME): the specific software installation for a given Oracle version, holding bin/ (the executables: oracle, sqlplus, rman, lsnrctl) and rdbms/admin/ (SQL and administration scripts).
4. Oracle network files directory (TNS_ADMIN): holds listener.ora, sqlnet.ora, and tnsnames.ora. On a database configured with a read-only Oracle home, an established, version-independent capability rather than something new, this directory lives under a separate, writable location rather than inside ORACLE_HOME itself.
5. Automatic Diagnostic Repository: governed by the DIAGNOSTIC_DEST initialization parameter, not by something called "ADR_HOME" directly. ADR_HOME is actually the name of the path Oracle reports back to you once DIAGNOSTIC_DEST is set, queryable through dynamic views, not a setting you configure yourself. This is a meaningfully different, and considerably more modern, layout than the pre-11g diagnostic structure of $ORACLE_BASE/admin/<db_name>/bdump, cdump, and udump, which some long-lived environments may still carry traces of.

These directories are discussed in more depth in the sections that follow.

Yes, OFA remains a live, recommended set of guidelines, not a historical curiosity. A few reasons it still earns its place in a course built around the current release:

• Structured file system: OFA promotes a well-organized directory layout for Oracle software and databases, simplifying administration, improving maintainability, and reducing the risk of conflicts between different Oracle versions or products coexisting on the same host.
• Scalability and manageability: separating data files, binaries, and configuration files into designated locations makes it easier to scale and manage an Oracle environment as it grows, especially once multiple databases or multiple Oracle homes are involved.
• A standardized approach: following OFA principles keeps Oracle software laid out consistently across different servers, so administrators familiar with the standard can navigate an unfamiliar system quickly.

OFA is not a strict requirement. Nothing stops you from laying out an installation differently. But Oracle continues to recommend configuring components according to OFA guidelines, particularly for large or multi-database environments, and the Oracle Universal Installer places components in locations and with permissions that comply with OFA by default. Oracle's installation documentation for the current release continues to describe and promote the standard for exactly this reason: it lets multiple databases of different versions, potentially owned by different users, coexist cleanly on the same server. That's still the core problem OFA solves, and it's just as real a problem on Oracle AI Database 26ai, the current long-term support release, as it was on any version before it.