Instance and Database Startup
server parameter file, changes made using the ALTER SYSTEM statement are only in effect for the current instance. You must manually update the text initialization parameter file for the changes to be known the next time you start up an instance. When you use a server parameter file, you can update the parameters on disk, so that changes persist across database shutdown and startup.
See Also:
Oracle9i Database Administrator’s Guide for a discussion of initialization parameters and the use of a server parameter file
Oracle9i Database Reference for descriptions of all initialization parameters
"Dynamic SGA" on page 7-4 for information about parameters that affect the SGA
Instance and Database Startup
The three steps to starting an Oracle database and making it available for systemwide use are:
1.Start an instance.
2.Mount the database.
3.Open the database.
A database administrator can perform these steps using the SQL*Plus STARTUP statement or Enterprise Manager.
See Also: Oracle Enterprise Manager Administrator’s Guide
How an Instance Is Started
When Oracle starts an instance, it reads the initialization parameter file to determine the values of initialization parameters. Then, it allocates an SGA, which is a shared area of memory used for database information, and creates background processes. At this point, no database is associated with these memory structures and processes.
Database and Instance Startup and Shutdown 5-5
Instance and Database Startup
See Also:
Chapter 7, "Memory Architecture" for information about the SGA
Chapter 8, "Process Architecture" for information about background processes
Restricted Mode of Instance Startup
You can start an instance in restricted mode (or later alter an existing instance to be in restricted mode). This restricts connections to only those users who have been granted the RESTRICTED SESSION system privilege.
Forced Startup in Abnormal Situations
In unusual circumstances, a previous instance might not have been shut down cleanly. For example, one of the instance’s processes might not have terminated properly. In such situations, the database can return an error during normal instance startup. To resolve this problem, you must terminate all remnant Oracle processes of the previous instance before starting the new instance.
How a Database Is Mounted
The instance mounts a database to associate the database with that instance. To mount the database, the instance finds the database control files and opens them. Control files are specified in the CONTROL_FILES initialization parameter in the parameter file used to start the instance. Oracle then reads the control files to get the names of the database’s datafiles and redo log files.
At this point, the database is still closed and is accessible only to the database administrator. The database administrator can keep the database closed while completing specific maintenance operations. However, the database is not yet available for normal operations.
How a Database Is Mounted with Real Application Clusters
Note: The features described in this section are available only if you have purchased Oracle9i Enterprise Edition with Real Application Clusters.
5-6 Oracle9i Database Concepts
Instance and Database Startup
If Oracle allows multiple instances to mount the same database concurrently, then the database administrator can use the initialization parameter CLUSTER_ DATABASE
to make the database available to multiple instances. The default value of the CLUSTER_DATABASE parameter is false. Versions of Oracle that do not support Real Application Clusters only allow CLUSTER_DATABASE to be false.
If CLUSTER_DATABASE is false for the first instance that mounts a database, thne only that instance can mount the database. If CLUSTER_DATABASE is set to true on the first instance, then other instances can mount the database if their CLUSTER_ DATABASE parameters are set to true. The number of instances that can mount the database is subject to a predetermined maximum, which you can specify when creating the database.
See Also:
Oracle9i Real Application Clusters Concepts
Oracle9i Real Application Clusters Setup and Configuration
Oracle9i Real Application Clusters Administration
Oracle9i Real Application Clusters Deployment and Performance
for more information about the use of multiple instances with a single database
How a Standby Database Is Mounted
A standby database maintains a duplicate copy of your primary database and provides continued availability in the event of a disaster.
The standby database is constantly in recovery mode. To maintain your standby database, you must mount it in standby mode using the ALTER DATABASE statement and apply the archived redo logs that your primary database generates.
You can open a standby database in read-only mode to use it as a temporary reporting database. You cannot open a standby database in read/write mode.
See Also:
Oracle9i Data Guard Concepts and Administration
"Open a Database in Read-Only Mode" on page 5-9 for information about opening a standby database in read-only mode
Database and Instance Startup and Shutdown 5-7
Instance and Database Startup
How a Clone Database Is Mounted
A clone database is a specialized copy of a database that can be used for tablespace point-in-time recovery. When you perform tablespace point-in-time recovery, you mount the clone database and recover the tablespaces to the desired time, then export metadata from the clone to the primary database and copy the datafiles from the recovered tablespaces.
See Also:
Oracle9i Recovery Manager User’s Guide
Oracle9i User-Managed Backup and Recovery Guide
for detailed information about clone databases and tablespace point-in-time recovery
What Happens When You Open a Database
Opening a mounted database makes it available for normal database operations. Any valid user can connect to an open database and access its information. Usually, a database administrator opens the database to make it available for general use.
When you open the database, Oracle opens the online datafiles and online redo log files. If a tablespace was offline when the database was previously shut down, the tablespace and its corresponding datafiles will still be offline when you reopen the database.
If any of the datafiles or redo log files are not present when you attempt to open the database, then Oracle returns an error. You must perform recovery on a backup of any damaged or missing files before you can open the database.
See Also: "Online and Offline Tablespaces" on page 3-13 for information about opening an offline tablespace
Instance Recovery
If the database was last closed abnormally, either because the database administrator terminated its instance or because of a power failure, then Oracle automatically performs recovery when the database is reopened.
Undo Space Acquisition and Management
When you open the database, the instance attempts to acquire one or more undo tablespaces or rollback segments. You determine whether to operate in automatic undo management mode or manual undo management mode at instance startup
5-8 Oracle9i Database Concepts
Instance and Database Startup
using the UNDO_MANAGEMENT inialization parameter. The supported values are AUTO or MANUAL. If AUTO, then the instance is started in automatic undo management mode. The default value is MANUAL.
If you use the undo tablespace method, you are using automatic undo management mode. This is recommended.
If you use the rollback segment method of managing undo space, then you are using manual undo management mode.
See Also: "Automatic Undo Management" on page 2-16 for more information about managing undo space.
Resolution of In-Doubt Distributed Transaction
Occasionally a database closes abnormally with one or more distributed transactions in doubt (neither committed nor rolled back). When you reopen the database and recovery is complete, the RECO background process automatically, immediately, and consistently resolves any in-doubt distributed transactions.
See Also: Oracle9i Database Administrator’s Guide for information about recovery from distributed transaction failures
Open a Database in Read-Only Mode
You can open any database in read-only mode to prevent its data from being modified by user transactions. Read-only mode restricts database access to read-only transactions, which cannot write to the datafiles or to the redo log files.
Disk writes to other files, such as control files, operating system audit trails, trace files, and alert files, can continue in read-only mode. Temporary tablespaces for sort operations are not affected by the database being open in read-only mode. However, you cannot take permanent tablespaces offline while a database is open in read-only mode. Also, job queues are not available in read-only mode.
Read-only mode does not restrict database recovery or operations that change the database’s state without generating redo data. For example, in read-only mode:
Datafiles can be taken offline and online
Offline datafiles and tablespaces can be recovered
The control file remains available for updates about the state of the database
One useful application of read-only mode is that standby databases can function as temporary reporting databases.
Database and Instance Startup and Shutdown 5-9