Escolar Documentos
Profissional Documentos
Cultura Documentos
Only the database administrator can start up an instance and open the database. 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 have control over the current status of an Oracle
database.
Connection with Administrator Privileges
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 following 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 password
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 privileges are a subset of
SYSDBA privileges.
See Also:
Your operating system-specific Oracle documentation for more information about how
administrator privileges work on your operating system
Chapter 20, "Database Security" for more information about password files and
authentication schemes for database administrators
See Also:
Oracle Database Administrator's Guide
How Parameter Values Are Changed
The database administrator can adjust variable parameters to improve the performance of a database system.
Exactly which parameters most affect a system depends on numerous database characteristics 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), 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 SPFILE, you can update the parameters on disk, so that changes persist across database shutdown and
startup.
Oracle provides 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 configuration and options and how you plan to tune the
database. For any relevant initialization parameters not specifically included in the initialization parameter
file, Oracle supplies defaults. If you are creating an Oracle database for the first time, it is suggested that you
minimize the number of parameter values that you alter.
See Also:
Oracle Database Administrator's Guide for a discussion of initialization parameters and the
use of a server parameter file
Oracle Database Reference for descriptions of all initialization parameters
"The SGA_MAX_SIZE Initialization Parameter" for information about parameters that affect
the SGA
Oracle Database Oracle Clusterware and Oracle Real Application Clusters Administration
and Deployment Guide
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:
Oracle Data Guard Concepts and Administration
"Open a Database in Read-Only Mode" for information about opening a standby database
in read-only mode
A clone database is a specialized copy of a database that can be used for tablespace point-intime 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:
Oracle Database Backup and Recovery Advanced User's Guide for 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 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" 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.
You determine whether to operate in automatic undo 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, then the instance is started in automatic
undo management mode. The default value is MANUAL.
If you use the undo tablespace method, then 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 Automatic Undo Management" 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.
5
See Also:
Oracle 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
logs, 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:
One useful 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
Overview of Database and Instance Shutdown
The three steps to shutting down a database and its associated instance are:
1. Close the database.
2. Unmount the database.
3. Shut down the instance.
A database administrator can perform these steps using Enterprise Manager. Oracle automatically
performs all three steps whenever an instance is shut down.
See Also:
Oracle Database 2 Day DBA
Close a Database
When you close a database, Oracle writes all database data and recovery data in the SGA to the
datafiles and redo log files, respectively. Next, Oracle closes all online datafiles and redo log files.
(Any 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 normal operations. The
control files remain open after a database is closed but still mounted.
Close the Database by Terminating the Instance
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
6
writing all data in the buffers of the SGA to the datafiles and redo log files is skipped. The
subsequent reopening of the database requires recovery, which Oracle performs automatically.
Note:
If a system or power failure occurs while the database is open, then the instance is, in effect,
terminated, and recovery is performed when the database is reopened.
Unmount a Database
After the database is closed, Oracle 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.
Shut Down an Instance
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 terminated.
Abnormal Instance Shutdown
In unusual circumstances, shutdown of an instance might not occur 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 administrator can force the new instance to start up by first removing
the remnants of the previous instance and then starting a new instance, 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