| Orac
le® Database Concepts 10g Release 1 (10.1) Part Number B10743-01 |
|
|
View PDF |
| Orac
le® Database Concepts 10g Release 1 (10.1) Part Number B10743-01 |
|
|
View PDF |
This chapter explains the procedures involved in starting and stopping an Oracle instance and database.
This chapter contains the following topics:
Every running Oracle database is associated with a n Oracle instance. When a database is started on a database server (regardless of the type of computer), Oracle allocates a memory ar ea called the System Global Area (SGA) and starts one or more Oracle processes. This combination of the SGA and the Oracle processes is called an Oracle instance. The memory and processes of an instance manage the associated database's data efficiently and serve the one or multiple users of the database.
Figure 12-1 shows an Oracle instance.
After starting an instance, Oracle associates the instance with the specified database. This is a mounted datab ase. The database is then ready to be opened, which makes it accessible to authorized users.
Multiple instances can run con currently on the same computer, each accessing its own physical database. In large-scale cluster systems, Real Application Clusters e nables multiple instances to mount a single database.
Only the database administrator can start up an instance and open the da
tabase. If a database is open, then the database administrator can shut down the database so that it is closed. When a database is closed, users cannot access the information that it contains.
Security for database startup and shutdown is controlled through connections to Oracle with administrator privileges. Normal users do not hav e control over the current status of an Oracle database.
Database startup and shutdown are powerful administrative options and are restricted to users who connect to Oracle with administrator privileges. Depending on the operating system, one of the follo wing conditions establishes administrator privileges for a user:
The user's operating system privileges allow him or her to connect using administrator privileges.
The user is granted the SYSDBA or SYSOPER privileges and the database uses pass
word files to authenticate database administrators.
When you connect with SYSDBA privileges, you are in
the schema owned by SYS. When you connect as SYSOPER, you are in the public schema. SYSOPER p
rivileges are a subset of SYSDBA privileges.
|
See Also:
|
To start an instance, Oracle must read either an initialization parameter file or a server parameter file. These files contain a list of configuration parameters for that instance and database. Oracle traditionally stored initialization parameters in a text in itialization parameter file. You can also choose to maintain initialization parameters in a binary server parameter file (SPFILE).
Initialization parameters stored in a server parameter file are persistent, in that any changes made to the parameters while an instance is running can persist across instance shutdown and startup.
Initialization parameters are divided into two groups: basic and advanced. In the majority of cases, it is necessary to set and tune only the basic parameters to get reasonable performance. In rare situations, modification to the advanced parameters may be needed for optimal perfo rmance.
Most initialization parameters belong to one of the following groups:
Parameters that nam e things, such as files
Parameters that set limits, such as maximums
Parameters that affect capacity, such as the size of the SGA, which are called variable pa rameters
Among other things, the initialization parameters tell Oracle:
The na me of the database for which to start up an instance
How much memory to use for memory structures in the SGA
What to do with filled redo log files
The names of undo tablespaces in the data base
The database administrator can adjust variable paramete rs to improve the performance of a database system. Exactly which parameters most affect a system depends on numerous database charac teristics and variables.
Some parameters can be changed dynamically with the ALTER SESSION or
ALTER SYSTEM statement while the instance is running. Unless you are using a server parameter file (SPFILE<
/code>), changes made using the ALTER SYSTEM statement are only in effect for the current instance. You mus
t 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 SPFILE, you can update the parameters on disk, so that changes persist across database shutdown and startup.
Oracle pro vides values in the starter initialization parameter file provided with your database software, or as created for you by the Database Configuration Assistant. You can edit these Oracle-supplied initialization parameters and add others, depending upon your configurat ion and options and how you plan to tune the database. For any relevant initialization parameters not specifically included in the in itialization parameter file, Oracle supplies defaults. If you are creating an Oracle database for the first time, it is suggested tha t you minimize the number of parameter values that you alter.
|
See Also:
|
The three steps to st arting an Oracle database and making it available for systemwide use are:
Start an instance.
< /li>Mount the database.
Open the database.
A data
base administrator can perform these steps using the SQL*Plus STARTUP statement or Enterprise Manager.
When Oracle starts an instance, it reads the server parameter file (SPFILE) or initialization para meter 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 pr ocesses.
|
See Also:
|
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 privi
lege.
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 i nstance startup. To resolve this problem, you must terminate all remnant Oracle processes of the previous instance before starting th e new instance.
The instance mounts a database t
o associate the database with that instance. To mount the database, the instance finds the database control files and opens them. Con
trol 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 datab ase is still closed and is accessible only to the database administrator. The database administrator can keep the database closed whi le completing specific maintenance operations. However, the database is not yet available for normal operations.
If Oracle allows multiple instances to mount the same database concurrently, then the database a
dministrator can use the CLUSTER_DATABASE initialization parameter 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 CLUSTER_DATA
BASE is set to true on the first instance, then other instances can mount the database if their CLUSTER_DAT
ABASE parameters are set to true. The number of instances that can mount the database is subject to a predetermin
ed maximum, which you can specify when creating the database.
|
See Also:
for more information about the use of multiple instances with a single database |
A standby database maintains a duplicate copy of your primary database and provides cont inued availability in the event of a disaster.
The standby database is constantly in recovery mode. To maintain your standby d
atabase, you must mount it in standby mode using the ALTER DATABASE statement and apply the archived redo l
ogs 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:
|
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 a nd recover the tablespaces to the desired time, then export metadata from the clone to the primary database and copy the datafiles fr om the recovered tablespaces.
|
See Also: Oracle Database Backup and Recovery Advance d User's Guide for information about clone databases and tablespace point-in-time recovery |
Opening a mounted database makes it available for normal database operations. Any valid user can connect to an open database and access its information. Usuall y, a database administrator opens the database to make it available for general use.
When you open the database, Oracle opens the online datafiles and redo log files. If a tablespace was offline when the database was previously shut down, the tablespace and i ts corresponding datafiles will still be offline when you reopen the database.
If any of the datafiles or redo log files are n ot 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.
If the database was last closed abnormally, either because the database administrator terminated its instan ce or because of a power failure, then Oracle automatically performs recovery when the database is reopened.
When y
ou open the database, the instance attempts to acquire one or more undo tablespaces. You determine whether to operate in automatic un
do management mode or manual undo management mode at instance startup using the UNDO_MANAGEMENT initialization parameter. The supported values are AUTO or MANUAL. If AUTO, t
hen 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: "Introduction to A utomatic Undo Management" for more information about managing undo space. |
Occasionally a database closes abnormally with one or more distributed transactions in doubt (neither committe d nor rolled back). When you reopen the database and recovery is complete, the RECO background process automatically, immediately, an d consistently resolves any in-doubt distributed transactions.
|
See Also: Oracle Dat abase Administrator's Guide for information about recovery from distributed transaction failures |
You can open any database in rea d-only mode to prevent its data from being modified by user transactions. Read-only mode restricts database access to read-only trans actions, which cannot write to the datafiles or to the redo log files.
Disk writes to other files, such as control files, oper ating system audit trails, trace files, and alert files, can continue in read-only mode. Temporary tablespaces for sort operations ar e 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 rec overy 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< /p>
The control file remains available for updates about the state of the database
One usef ul application of read-only mode is that standby databases can function as temporary reporting databases.
|
See Also: Oracle Database Administrator's Guide for information about how to open a database in read- only mode |
The three steps to shutting down a database and its associated instance a re:
Close the database.
Unmount the database.
Shut down the ins tance.
A database administrator can perform these steps using Enterprise Ma nager. Oracle automatically performs all three steps whenever an instance is shut down.
When you close a database, Oracle writes all database data and recover y data in the SGA to the datafiles and redo log files, respectively. Next, Oracle closes all online datafiles and redo log files. (An y offline datafiles of any offline tablespaces have been closed already. If you subsequently reopen the database, any tablespace that was offline and its datafiles remain offline and closed, respectively.) At this point, the database is closed and inaccessible for n ormal operations. The control files remain open after a database is closed but still mounted.
In rare emergency situations, you can terminate the instance of an open database to close and completely shut down the database instantaneously. This process is fast, because the operation of writing all data in the b uffers of the SGA to the datafiles and redo log files is skipped. The subsequent reopening of the database requires recovery, which O racle performs automatically.
After the database is closed, Orac le unmounts the database to disassociate it from the instance. At this point, the instance remains in the memory of your computer.
After a database is unmounted, Oracle closes the control files of the database.
The final step in database shutdown is shutting down the instance. When you shut down an instance, the SGA is removed from memory and the background processes are terminat ed.
In unusual circumstances, shutdown of an instance might not o
ccur cleanly; all memory structures might not be removed from memory or one of the background processes might not be terminated. When
remnants of a previous instance exist, a subsequent instance startup most likely will fail. In such situations, the database adminis
trator can force the new instance to start up by first removing the remnants of the previous instance and then starting a new instanc
e, or by issuing a SHUTDOWN ABORT statement in SQL*Plus or using Enterprise Manager.
|
See Also: Oracle Database Administrator's Guide for more detailed information about instance and database startup and shutdown |
|
 Copyright © 1993, 2003 Oracle Corporation All Rights Reserved. |
|
