Create Database   «Prev  Next»

Lesson 4 Starting an instance
Objective Start the new COIN instance.

Starting Oracle Instance

Remember that an instance refers to the
  1. software processes and
  2. associated memory structures
, and that the term database refers to the physical database files. It follows, then, that before you can create a new database, you must first start the software. You can do this from the command prompt. If you are using Windows, go ahead and open a command prompt window now. The first thing you need to do is indicate which instance you want to work with. Under Windows, this is done using the SET command to set the value of an environment variable named ORACLE_SID to the name of the instance. For example:

SET ORACLE_SID = COIN

On a Linux or UNIX system, the procedure is much the same. You set an environment variable, and then export it. These commands should work on most Linux and UNIX systems:

ORACLE_SID=COIN

export ORACLE_SID

If you don't create a database during installation, the installer never sets ORACLE_SID for you — Windows won't have it in the registry, and a Linux/UNIX shell profile won't have it exported. You're expected to set it yourself once you're ready to work with a specific instance, exactly as shown above.


Starting an Instance with the NOMOUNT Option

The next step is to start SQL*Plus, connect to the instance that you want to start, and then start that instance. Use the SQL*Plus STARTUP command to do this. An important caveat is that you must start the instance using the NOMOUNT option. NOMOUNT tells SQL*Plus to start the instance, but not to mount or open the database. That is important because mounting the database implies opening the control file. Since you have not created the database yet, there are no files to open. The following example shows this entire process being executed under Windows OS:

C:\Oracle\ADMIN\COIN\create>set oracle_sid=coin
C:\Oracle\ADMIN\COIN\create>sqlplus /nolog

SQL*Plus: Release 26.0.0.0.0 - Production

SQL> connect / as sysdba
Connected to an idle instance.
SQL> startup nomount
ORACLE instance started.

Total System Global Area    2147483648 bytes
Fixed Size                     9123456 bytes
Variable Size                 419430400 bytes
Database Buffers             1660944384 bytes
Redo Buffers                  58028032 bytes

Note the connection message this time: connect / as sysdba, not the old connect internal syntax you may still see in outdated tutorials. CONNECT INTERNAL hasn't existed in any supported Oracle release since Oracle 9i — it produces nothing but a syntax error today. The modern equivalents are:

  • CONNECT / AS SYSDBA — operating system authentication. This works if your OS account is a member of the OSDBA group (on Windows, typically the ORA_DBA group; on Linux, typically the dba group).
  • CONNECT SYS AS SYSDBA — prompts for the SYS password, authenticated against the password file rather than the (nonexistent, at this point) database.

Either form works before the database exists, which is exactly why it's the correct way to connect for this step — SYSDBA authentication doesn't depend on the database being open, since it's handled by the OS or the password file, not by a database-level user check.


The process is the same on Linux and UNIX. The only difference is that you use the export command, not SET, to set the value of the ORACLE_SID environment variable. Give this a try now. Set ORACLE_SID=COIN, start SQL*Plus, and issue a STARTUP NOMOUNT command. If you have done everything right so far, the COIN instance should start. Once you've started it, issue the SHUTDOWN command to shut it back down again.

Starting a CDB Versus Opening a PDB

One thing worth being precise about, since every database you create from this point forward is a CDB: STARTUP and STARTUP NOMOUNT operate on the CDB root, not on any individual pluggable database. Once the CDB is open, its PDBs are not automatically open unless you previously ran ALTER PLUGGABLE DATABASE ... SAVE STATE against them — the technique introduced in the previous lesson's CREATE PLUGGABLE DATABASE example. Without that, you open each PDB explicitly after the CDB itself is up:


STARTUP;
ALTER PLUGGABLE DATABASE pdb_custom OPEN;

For a database you're creating for the first time, none of this matters yet — there's no PDB to open until Lesson 2's CREATE PLUGGABLE DATABASE step has actually run. It matters the next time you restart the CDB, which is why SAVE STATE is worth setting once your PDBs exist and you don't want to reopen them by hand every time.


  • Some Common Problems when you first try to start a new Oracle instance from SQL*Plus
    1. Invalid Credentials: Oracle requires valid credentials to connect, and by default, passwords are case-sensitive unless configured otherwise. The correct username/password and connection string are necessary.
    2. Database Not Found: You need to ensure that the database you're trying to connect to exists and is registered with the Oracle listener (for remote connections). Use tools like lsnrctl status to confirm database availability.
    3. Instance Not Running: Attempting to start an already-running instance results in an error such as ORA-01081: cannot start already-running ORACLE - shut it down first. Check the instance's state with ps -ef | grep pmon on Linux/UNIX, or with SELECT status FROM v$instance; in SQL*Plus.
    4. Permissions Issue: Only users with the SYSDBA or SYSOPER privilege can start or stop an instance. Attempting to start an instance without the required privileges results in ORA-01031: insufficient privileges — see below.
    5. Invalid Environment Settings: Oracle relies on properly configured environment variables (ORACLE_HOME, ORACLE_SID, and optionally PATH). Misconfiguration leads to errors when starting an instance.
    6. Corrupted Database Files: Corrupted files (for example control files, datafiles, or redo logs) prevent the instance from starting properly. RMAN and the DBVERIFY utility (dbv) can help identify integrity problems.
    7. Space Issue: Oracle needs sufficient disk space, especially in the Fast Recovery Area (FRA) and for temporary segments. Lack of space can prevent instance startup or lead to further operational problems.
    8. Network Issues: Not applicable to a purely local NOMOUNT startup, but relevant the moment you connect remotely. For remote connections, ensure the correct network configuration (tnsnames.ora or an Easy Connect string) and that the listener is running (lsnrctl start).

    As covered above, every database in Oracle AI Database 26ai is a multitenant Container Database (CDB) holding one or more Pluggable Databases (PDBs) — this isn't an optional architecture choice anymore, it's the only one available since Oracle Database 21c.


Forgetting NOMOUNT option

If you forget to include NOMOUNT on the STARTUP command line, Oracle will try to open the database control files. You will see an error like this:

ORA-00205: error in identifying controlfile, 
check alert log for more info

When this happens, Oracle will have actually started the instance. You could probably ignore the error and go on to create your database. However, to be conservative, I would recommend running a SHUTDOWN command followed by the correct form of the STARTUP command: STARTUP NOMOUNT.

Forgetting AS SYSDBA

Sometimes people forget to include AS SYSDBA when connecting, and try to start an instance as an ordinary user instead.
I do this sometimes, especially when I am in a rush. This is the error that you are likely to see:

SQL> startup nomount

ORA-01031: insufficient privileges

If this happens to you, reconnect using CONNECT / AS SYSDBA (operating system authentication) or CONNECT SYS AS SYSDBA (password file authentication), and then try the STARTUP command again. There's no CONNECT INTERNAL command to fall back on — that syntax was removed from Oracle Database entirely back in the 9i era, and every current reference to it is describing a command that no longer exists.

  • Forgetting ORADIM
    This problem will only affect Windows OS users. If you forgot to run ORADIM to create the Windows service — covered in the previous lesson — or if you did not remember to issue a
    
    SET ORACLE_SID=COIN command,
    

    you may receive a TNS protocol adapter error when you start SQL*Plus. It will look like this:
    
    C:\Oracle\ADMIN\COIN\pfile>sqlplus /nolog
    SQL*Plus: Release 26.0.0.0.0 - Production
    
    SQL> connect / as sysdba
    ORA-12560: TNS:protocol adapter error
    SQL>
    

    You may also receive an unexpected password prompt. Either way, check to be sure that you have correctly set the ORACLE_SID environment variable, and then check the Services control panel to be sure that a service named OracleServiceCOIN exists. If it doesn't, go back one lesson and run ORADIM — remembering to create it with -startmode MANUAL first, not AUTO, since the database doesn't exist yet.

Can't find initialization file

Oracle expects to find the initialization file in a specific directory. On Windows, Oracle looks in the DATABASE directory underneath Oracle Home. On Linux and UNIX, Oracle looks in the dbs directory under Oracle Home. If the software doesn't find the initialization file where it expects it to be, you will get an error message that looks like this:

SQL> startup nomount
LRM-00109: could not open parameter file
'C:\Oracle\product\26.0.0\dbhome_1\DATABASE\initcoin.ora'
ORA-01078: failure in processing system parameters
The useful part about this error message is that Oracle tells you exactly which file it is trying to find and where it is looking. One solution is to move your initialization file to that directory and name it accordingly. Another solution is to use the PFILE option with the STARTUP command, so you can explicitly point to your initialization file. For example:

STARTUP PFILE=C:\coin\initcoin.ora NOMOUNT
I try to avoid using the PFILE option because it's just one more thing that I have to remember. In an environment with multiple DBAs and multiple databases, it can quickly become a struggle for everyone to remember where the initialization files are for each database. It's easier to just place them in the default locations, so that Oracle can find them on its own — or, better still in a modern environment, use an SPFILE, which Oracle locates automatically without any of this path-guessing in the first place.

[1]Multitenant Architecture: Since Oracle Database 21c, a multitenant Container Database (CDB) holding one or more Pluggable Databases (PDBs) is the only supported architecture — not an optional feature you turn on, but what every CREATE DATABASE statement produces. This allows for efficient resource utilization and simplified management by consolidating many databases into one while maintaining isolation and security between PDBs.
SEMrush Software 4 SEMrush Banner 4