Module 6 Conclusion

Lesson 1 opened this module with five stated goals: review Optimal Flexible Architecture, create a database parameter file, size the SGA and buffer cache, decide on a block size, and size the initial database files. We did all five, and picked up a fair amount of ground beyond the original list along the way: a full preinstallation checklist, the Fault Diagnosability Infrastructure, and a handful of additional parameters worth knowing before you actually run CREATE DATABASE in the next module. This page pulls the whole nine lessons together, centered on the one artifact that's been under continuous construction the entire time: initCOIN.ora.

Four lessons contributed directly to this file. Lesson 4 laid the foundation, Lesson 5 revised the control files, and Lesson 6 added the block size. Assembled together, here's where COIN's parameter file actually stands right now:

# initCOIN.ora

db_name='COIN'
db_unique_name='COIN'

# Memory: Automatic Memory Management (Lesson 4, confirmed still appropriate in Lesson 8)
memory_target=2G

# Control files: three copies on one mount point for this training environment
# (Lesson 5 revised Lesson 4's original two-file version)
control_files=(
  '/u01/app/oracle/oradata/COIN/control01.ctl',
  '/u01/app/oracle/oradata/COIN/control02.ctl',
  '/u01/app/oracle/oradata/COIN/control03.ctl'
)

# Diagnostics: Automatic Diagnostic Repository root (Lesson 4, elaborated in Lesson 9)
diagnostic_dest='/u01/app/oracle'

# Multitenant: bootstrap parameter for CDB creation (Lesson 4)
enable_pluggable_database=TRUE

# Block size: deliberately 4096, one of two typical values, not the 8192 default (Lesson 6)
db_block_size = 4096

That's six parameters, each one earning its place for a reason covered in an earlier lesson, not copied blindly from an old template. Lesson 9 introduced four more parameters, DB_FILES, PROCESSES, OPTIMIZER_MODE, and COMPATIBLE, but explicitly as situational settings to add if they apply to your environment, not as required additions to COIN specifically. Worth knowing they exist and what they control; not worth cluttering a small training database's parameter file with values you'd only be copying rather than choosing deliberately.

If one architectural fact shaped more of this module than any other, it's that multitenant container database architecture isn't a special configuration anymore, it's the only one. Lesson 2's preinstallation checklist flagged it as the single biggest structural surprise for anyone returning to Oracle after a few years away. Lesson 5 built on it directly: creating a database today means creating SYSTEM/SYSAUX datafiles twice, once for the CDB root and once for the seed pluggable database, PDB$SEED, not the single flat file set older material describes. Lesson 6 showed the same architecture constraining a decision you might not expect it to touch at all: DB_BLOCK_SIZE isn't modifiable at the PDB level, so choosing it isn't just a decision for COIN as a whole, it's a decision for every PDB you'll ever plug into COIN. And Lesson 9 closed the loop on diagnostics: the ADR records everything at the CDB level, so a trace file generated inside a PDB still carries the CDB's name, not the PDB's.

A second pattern repeated across this module: old, narrowly-scoped parameters getting consolidated into single, broader ones. Lessons 1, 4, and 9 all touched the same story from different angles, BACKGROUND_DUMP_DEST, USER_DUMP_DEST, and CORE_DUMP_DEST are all superseded by one parameter, DIAGNOSTIC_DEST, which governs the entire Automatic Diagnostic Repository structure, alert, cdump, trace, and incident subdirectories, all organized underneath it automatically. Lesson 9 traced the exact fallback chain if you never set it explicitly: your $ORACLE_BASE environment variable first, then whatever Oracle Universal Installer configured as ORACLE_BASE, and only as a last resort, $ORACLE_HOME/rdbms/log.
Lesson 8 showed the same consolidation pattern playing out for memory. The old two-parameter approach, db_block_buffers plus shared_pool_size, is genuinely broken today, not just outdated: db_block_buffers defaults to 0 and can't even coexist with the modern db_cache_size parameter in the same file. What COIN actually uses instead is memory_target, letting Oracle redistribute SGA and PGA memory automatically. Lesson 8 also introduced Unified Memory, a newer, single-parameter alternative (MEMORY_SIZE) built for consolidated, multi-workload environments, worth knowing about even though it's not what COIN uses, since it's mutually exclusive with memory_target, not layered on top of it.

The same "one location moves elsewhere under a read-only Oracle home" pattern showed up three separate times. Lesson 1 introduced it for the ADR itself. Lesson 4 confirmed it for PFILE and SPFILE location, $ORACLE_HOME/dbs under the standard setup, $ORACLE_BASE_CONFIG/dbs under a read-only home. Lesson 7 confirmed the identical split for TNS_ADMIN and network files, right down to Oracle's actual documented search order: the TNS_ADMIN variable first, then /etc, then ORACLE_BASE_HOME/network/admin, then ORACLE_HOME/network/admin as the last fallback. This isn't a 26ai-specific change, all three lessons were careful to note it's an established, version-independent capability, but it's exactly the kind of thing worth knowing if you ever work in an environment where someone else made that configuration choice before you arrived.

None of the specific values in COIN's parameter file were arbitrary:

• 4096 for the block size (Lesson 6): one of two values Oracle's own documentation calls typical, deliberately not the 8192 default, chosen to illustrate that the default isn't the only reasonable choice for a small training database.
• Three control files on one mount point (Lesson 5): a training-environment compromise. Real multiplexing benefit needs genuinely separate storage, physical disks or ASM failure groups, which Lesson 5 covered in detail for when this database eventually needs to look more like a production one.
• Redo logs sized at the practical minimum (Lesson 7): not an arbitrary small number, but Oracle's actual enforced floor, 4 MB. Anything smaller doesn't just perform poorly, it fails outright with an error. This was chosen specifically to let COIN generate archive log files without first pushing a large volume of data through it.
• 2G for memory_target (Lesson 4, revisited in Lesson 8): comfortably above Unified Memory's 1.5 GB floor, meaning COIN could switch to MEMORY_SIZE later without any real obstacle, though there's no reason to for a database this size.

Lesson 1 promised that the module following this one would actually create the course project database we've been preparing for this entire time. That's still the plan. Everything built here, the parameter file, the directory structure following OFA, the block size decision, the redo log and control file placement, exists specifically so that CREATE DATABASE in the next module has something real to start from, not a blank slate. If you're running Oracle yourself, you now have a working initCOIN.ora ready to bootstrap an instance to NOMOUNT. If you're not, you've still walked through every decision a DBA actually has to make before that command runs, which is the more durable skill either way.

Click the Quiz link below to test what you have learned.
Names, Domains, Parameter File Settings - Quiz