Oracle Concepts_13_Oracle 数据库实例

第 13 章 Oracle 数据库实例

 

http://docs.oracle.com/cd/E11882_01/server.112/e40540/startup.htm#CNCPT89065

This chapter contains the following sections:

• Introduction to the Oracle Database Instance

• Overview of Instance Startup and Shutdown

• Overview of Checkpoints

• Overview of Instance Recovery

• Overview of Parameter Files

• Overview of Diagnostic Files

Introduction to the Oracle Database Instance

A database instance is a set of memory structures that manage database files. A database is a set of physical files on disk created by the CREATE DATABASE statement. The instance manages its associated data and serves the users of the database.

Every running Oracle database is associated with at least one Oracle database instance. Because an instance exists in memory and a database exists on disk, an instance can exist without a database and a database can exist without an instance.

Oracle 数据库实例简介

 

数据库实例是一组用于管理数据库文件的内存结构。数据库是一组由CREATE DATABASE 语句在磁盘上创建的物理文件。由实例管理其关联的数据，并为数据库用户提供服务。

每个正在运行的 Oracle 数据库至少与一个 Oracle 数据库实例相关联。因为实例存在于内存中，而数据库存在于磁盘上，所以实例可以在没有数据库时而存在，数据库也可以在没有实例时存在。

Database Instance Structure

When an instance is started, Oracle Database allocates a memory area called the system global area (SGA) and starts one or more background processes. The SGA serves various purposes, including the following:

• Maintaining internal data structures that are accessed by many processes and threads concurrently

• Caching data blocks read from disk

• Buffering redo data before writing it to the online redo log files

• Storing SQL execution plans

The SGA is shared by the Oracle processes, which include server processes and background processes, running on a single computer. The way in which Oracle processes are associated with the SGA varies according to operating system.

A database instance includes background processes. Server processes, and the process memory allocated in these processes, also exist in the instance. The instance continues to function when server processes terminate.

Oracle 实例结构

当实例启动时， Oracle 数据库分配一个叫做系统全局区（SGA） 的内存区域，并启动一个或多个后台进程。SGA 用于以下几个目的：

• 维护由很多进程和线程同时访问的内部数据结构
• 缓存从磁盘中读取的数据块
• 缓冲重做数据，然后再将其写入联机重做日志文件
• 存储 SQL 执行计划

SGA 由运行在一台单一计算机上的多个 Oracle 进程共享，包括服务器进程和后台进程。Oracle 进程与 SGA 相关联的方式会因不同的操作系统而有所不同。

数据库实例包括多个后台进程。服务器进程和在这些的进程中分配的进程内存也存在于实例中。当服务器进程终止时，实例仍会继续运行。

Figure 13-1 shows the main components of an Oracle database instance.

Figure 13-1 Database Instance

Description of "Figure 13-1 Database Instance"

See Also:

• "Overview of the System Global Area"

• "Overview of Background Processes"

Database Instance Configurations

You can run Oracle Database in either of the following mutually exclusive configurations:

• Single-instance configuration

  A one-to-one relationship exists between the database and an instance.

• Oracle Real Application Clusters (Oracle RAC) configuration

  A one-to-many relationship exists between the database and instances.

  数据库实例配置

  您可以在以下两种互斥配置中的一种来运行 Oracle 数据库：

  单实例配置

  数据库和实例之间存在一对一关系。

  Oracle 真正应用集群 （Oracle RAC）配置

  数据库与实例之间存在一对多关系。

Figure 13-2 shows possible database instance configurations.

图 13-2 显示了这两种可能的数据库实例配置。

Figure 13-2 Database Instance Configurations

图 13-2 数据库实例的配置

 

Description of "Figure 13-2 Database Instance Configurations"

Whether in a single-instance or Oracle RAC configuration, a database instance is associated with only one database at a time. You can start a database instance and mount (associate the instance with) one database, but not mount two databases simultaneously with the same instance.

无论是在单实例还是在 Oracle RAC 配置中，一个数据库实例在同一时刻只与一个数据库相关联。您可以启动一个实例，并装载（与实例相关联）一个数据库，但不能同时将两个数据库装载到同一实例。

Note:

This chapter discusses a single-instance database configuration unless otherwise noted.

除非另有说明，本章仅讨论单实例数据库配置。

Multiple instances can run concurrently on the same computer, each accessing its own database. For example, a computer can host two distinct databases:prod1 and prod2. One database instance manages prod1, while a separate instance manages prod2.

在同一台计算机上可以同时运行多个实例，每个实例访问其自己的数据库。

例如，一台计算机可以承载两个完全不同的数据库： prod1 和 prod2。一个数据库实例管理 prod1，而另一个实例管理 prod2。

See Also:

Oracle Real Application Clusters Administration and Deployment Guide  for information specific to Oracle RAC

《Oracle 真正应用集群管理和部署指南》关于 Oracle RAC 的特定信息

Duration of an Instance

实例的持续时间

An instance begins when it is created with the STARTUP command and ends when it is terminated. During this period, an instance can associate itself with one and only one database. Furthermore, the instance can mount a database only once, close it only once, and open it only once. After a database has been closed or shut down, you must start a different instance to mount and open this database.

实例在使用 STARTUP 命令创建时开始，在终止时结束。这此期间，实例能且只能与一个数据库相关联。此外，该实例只能装载数据库一次，关闭数据库一次、打开数据库一次。在数据库已关闭后，您必须启动一个不同实例来装载并打开此数据库。

Table 13-1 illustrates a database instance attempting to reopen a database that it previously closed.

表 13-1 说明了一个数据库实例试图重新打开一个之前已关闭的数据库。

Table 13-1 Duration of an Instance

Statement	Explanation
SQL> STARTUP ORACLE instance started.   Total System Global Area  468729856 bytes Fixed Size                  1333556 bytes Variable Size             440403660 bytes Database Buffers           16777216 bytes Redo Buffers               10215424 bytes Database mounted. Database opened.	The STARTUP command creates an instance, which mounts and opens the database. STARTUP 命令创建一个实例，它会装载并打开数据库。
SQL> SELECT TO_CHAR(STARTUP_TIME,'MON-DD-RR HH24:MI:SS') AS "Inst Start Time" FROM V$INSTANCE;   Inst Start Time ------------------ JUN-18-11 13:14:48	This query shows the time that the current instance was started. 此查询显示当前实例的启动时间。
SQL> SHUTDOWN IMMEDIATE	The instance closes the database and shuts down, ending the life of this instance. 关闭实例，结束此实例的生命周期。
SQL> STARTUP Oracle instance started. . . .	The STARTUP command creates a new instance and mounts and open the database. STARTUP 命令创建一个新的实例，装载并打开数据库。
SQL> SELECT TO_CHAR(STARTUP_TIME,'MON-DD-RR HH24:MI:SS') AS "Inst Start Time" FROM V$INSTANCE;   Inst Start Time ------------------ JUN-18-11 13:16:40	This query shows the time that the current instance was started. The different start time shows that this instance is different from the one that shut down the database. 此查询显示当前实例的启动时间。不同的开始时间显示此实例不同于之前已关闭数据库的那个实例。

Oracle System Identifier (SID)

Oracle 系统标识符 (SID)

The system identifier (SID) is a unique name for an Oracle database instance on a specific host. On UNIX and Linux, Oracle Database uses the SID andOracle home values to create a key to shared memory. Also, the SID is used by default to locate the parameter file, which is used to locate relevant files such as the database control files.

系统标识符 (SID) 是特定主机上的某个 Oracle 数据库实例的唯一名称。在UNIX 及 Linux 上，Oracle 数据库使用 SID 和 Oracle Home 的值来创建一个指向共享内存的键。此外，SID 在默认情况下用于定位参数文件，并使用参数文件来进一步定位其它相关文件，如数据库控制文件等。

On most platforms, the ORACLE_SID environment variable sets the SID, whereas the ORACLE_HOME variable sets the Oracle home. When connecting to an instance, clients can specify the SID in an Oracle Net connection or use a net service name. Oracle Database converts a service name into an ORACLE_HOME andORACLE_SID.

在大多数的平台上， 由 ORACLE_SID 环境变量设置 SID，而ORACLE_HOME 变量设置 Oracle Home。当客户端要连接到实例时，可以在 Oracle Net 连接中指定 SID，或使用网络服务名称。Oracle 数据库将服务名称转换为一个 ORACLE_HOME 和 ORACLE_SID 。

See Also:

• "Service Names"

• Oracle Database Administrator's Guide to learn how to specify an Oracle SID

  
  

    "服务名"

    《Oracle 数据库管理员指南》了解如何指定 Oracle SID 

Overview of Instance Startup and Shutdown

A database instance provides user access to a database. This section explains the possible states of the instance and the database.

实例启动和关闭概述

数据库实例提供了用户对数据库的访问。此部分说明了实例和数据库可能存在的状态。

Overview of Instance and Database Startup

In a typical use case, you manually start an instance and then mount and open the database, making it available for users. You can use the SQL*Plus STARTUPcommand, Oracle Enterprise Manager (Enterprise Manager), or the SRVCTL utility to perform these steps. Figure 13-3 shows how a database progresses from a shutdown state to an open state.

实例和数据库启动概述

举一个典型的使用案例，您手动启动一个实例，然后装载并打开数据库，使其对用户可用。您可以使用 SQL*Plus 的 STARTUP 命令、 Oracle 企业管理器 （企业管理器） 、或 SRVCTL 实用程序来执行这些步骤。图 13-3 显示了数据库如何从关闭状态一步步推进到打开状态。

Figure 13-3 Instance and Database Startup Sequence

Description of "Figure 13-3 Instance and Database Startup Sequence"

A database goes through the following phases when it proceeds from a shutdown state to an open database state:

当数据库从关闭状态推进到打开状态时，会经历以下几个阶段：

1. Instance started without mounting database

     1  启动实例，但未装载数据库

   The instance is started, but is not yet associated with a database.

   "How an Instance Is Started" explains this stage.

   实例已启动，但尚未与某个数据库相关联。"实例是如何启动的"解释了这一阶段。

    

2. Database mounted

     2  装载数据库

   The instance is started and is associated with a database by reading its control file (see "Overview of Control Files"). The database is closed to users.

   "How a Database Is Mounted" explains this stage.

   实例已启动，并且通过读取控制文件，来与数据库相关联 （请参阅"控制文件概述"）。数据库对用户是关闭的。
   "数据库是如何装载的"解释了这一阶段。

3. Database open

     3  打开数据库

   The instance is started and is associated with an open database. The data contained in the data files is accessible to authorized users.

   "How a Database Is Opened" explains this stage.

   实例已启动，并与一个打开的数据库相关联。授权的用户可以访问数据文件中包含的数据。

See Also:

• "Oracle Enterprise Manager"

• Oracle Database 2 Day DBA and Oracle Database Administrator's Guide to learn how to start an instance

• Oracle Database Administrator's Guide to learn how to use SRVCTL

    "Oracle 企业管理器"
    《Oracle 数据库 2 日 DBA》 和 《Oracle 数据库管理员指南》了解如何启动实例
    《Oracle 数据库管理员指南》了解如何使用 SRVCTL 

Connection with Administrator Privileges

具有管理员权限的连接

Database startup and shutdown are powerful administrative options that are restricted to users who connect to Oracle Database with administrator privileges.Normal users do not have control over the current status of an Oracle database.

数据库启动和关闭是功能强大的管理选项，仅限于能以管理员权限连接到Oracle 数据库的用户来使用。一般用户对 Oracle 数据库的当前状态不具有控制权。

Depending on the operating system, one of the following conditions establishes administrator privileges for a user:

取决于不同的操作系统，使用下列条件之一来建立用户的管理员权限：

• The operating system privileges of the user enable him or her to connect using administrator privileges.

    用户的操作系统权限使其能够使用管理员权限来连接。

• The user is granted the SYSDBA or SYSOPER system privileges and the database uses password files to authenticate database administrators over the network.

    用户被授予了 SYSDBA 或 SYSOPER 的系统权限，数据库通过网络使用密码文件对数据库管理员进行身份验证。

SYSDBA and SYSOPER are special system privileges that enable access to a database instance even when the database is not open. Control of these privileges is outside of the database itself.When you connect with the SYSDBA system privilege, 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.

SYSDBA 和 SYSOPER 是特殊的系统权限，使你甚至能够在数据库未打开时仍能访问数据库实例。这些权限控制处于数据库本身之外。当你使用SYSDBA 系统权限连接时，你将处于 SYS 模式中。当你使用 SYSOPER 连接时，你将处于 PUBLIC 模式中。SYSOPER 权限是 SYSDBA 权限的子集。

See Also:

• "SYS and SYSTEM Schemas"

• "Overview of Database Security" to learn about password files and authentication for database administrators

• Oracle Database Administrator's Guide to learn about SYSDBA and SYSOPER

    "SYS 和 SYSTEM 模式"

    "数据库安全性概述"了解密码文件和数据库管理员的身份验证

    《Oracle 数据库管理员指南》了解 SYSDBA 和 SYSOPER

How an Instance Is Started

实例是如何启动的

When Oracle Database starts an instance, it performs the following basic steps:

当 Oracle 数据库启动一个实例时，它执行以下基本步骤：

1. Searches for a server parameter file in a platform-specific default location and, if not found, for a text initialization parameter file (specifyingSTARTUP with the SPFILE or PFILE parameters overrides the default behavior)

     1. 在特定于平台的默认位置搜索服务器参数文件，如果未找到 ，则搜索一个初始化参数文本文件（为 STARTUP 指定 SPFILE 或 PFILE 

   参数将覆盖该默认行为）

2. Reads the parameter file to determine the values of initialization parameters

     2. 读取参数文件，以确定初始化参数值

3. Allocates the SGA based on the initialization parameter settings

     3. 基于初始化参数设置，分配 SGA

4. Starts the Oracle background processes

     4. 启动 Oracle 后台进程

5. Opens the alert log and trace files and writes all explicit parameter settings to the alert log in valid parameter syntax

     5. 打开警报日志和跟踪文件，并以有效的参数语法将所有显式参数设置写入警报日志中

At this stage, no database is associated with the instance. Scenarios that require a NOMOUNT state include database creation and certain backup and recovery operations.

这一阶段还没有数据库与该实例相关联。需要 NOMOUNT 状态的场景包括创建数据库和某些备份与恢复操作。

See Also:

Oracle Database Administrator's Guide  to learn how to manage initialization parameters using a server parameter file

《Oracle 数据库管理员指南》了解如何使用服务器参数文件来管理初始化参数

How a Database Is Mounted

数据库是如何装载的

The instance mounts a database to associate the database with this instance. To mount the database, the instance obtains the names of the database control files specified in the CONTROL_FILES initialization parameter and opens the files. Oracle Database reads the control files to find the names of the data files and the online redo log files that it will attempt to access when opening the database.

由实例装载数据库，以将数据库与该实例相关联。为装载数据库，该实例获取由 CONTROL_FILES 初始化参数指定的数据库控制文件名称，并打开文件。Oracle 数据库读取控制文件，以查找数据文件和联机重做日志文件的名称，当打开数据库时，它会尝试访问这些文件。

In a mounted database, the database is closed and accessible only to database administrators. Administrators can keep the database closed while completing specific maintenance operations. However, the database is not available for normal operations.

在一个已装载的数据库中，该数据库是关闭的，且只有数据库管理员可以访问。管理员可以在完成某些特定的维护操作时保持数据库关闭。但是，数据

库此时还不可用于常规操作。

If Oracle Database allows multiple instances to mount the same database concurrently, then the CLUSTER_DATABASE initialization parameter setting can make the database available to multiple instances. Database behavior depends on the setting:

如果 Oracle 数据库允许多个实例同时装载同一数据库，则CLUSTER_DATABASE 初始化参数设置可以使数据库可用于多个实例。数据库的行为取决于其设置：

• If CLUSTER_DATABASE is false (default) for the first instance that mounts a database, then only this instance can mount the database.

    如果装入数据库的第一个实例的 CLUSTER_DATABASE 为 false （默认），则仅此实例可以装入数据库。

• If CLUSTER_DATABASE is true for the first instance, then other instances can mount the database if their CLUSTER_DATABASE parameter settings are set totrue. The number of instances that can mount the database is subject to a predetermined maximum specified when creating the database.

    如果第一个实例的 CLUSTER_DATABASE 为 true，则其他实例在其CLUSTER_DATABASE 参数也设置为 true 时可以装载数据库。可以装载数据库的实例数量决定于在创建数据库时指定的预定最大值。

See Also:

• Oracle Database Administrator's Guide to learn how to mount a database

• Oracle Real Application Clusters Administration and Deployment Guide for more information about the use of multiple instances with a single database

    《Oracle 数据库管理员指南》了解如何装载数据库

    《Oracle 真正应用集群管理和部署指南》关于如何将单个数据库和多个实例一起使用的详细信息

How a Database Is Opened

数据库是如何打开的

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 Database performs the following actions:

在打开数据库时， Oracle 数据库执行下列操作：

• Opens the online data files in tablespaces other than undo tablespaces

    打开除撤消表空间之外的其他的表空间中的联机数据文件

  If a tablespace was offline when the database was previously shut down (see "Online and Offline Tablespaces"), then the tablespace and its corresponding data files will be offline when the database reopens.

  如果在之前数据库关闭时，某个表空间是脱机的（见"联机和脱机表空间"），则该表空间及其相应的数据文件，在重新打开数据库时，仍将处于脱机状态。

• Acquires an undo tablespace

    获取一个撤消表空间

  If multiple undo tablespaces exists, then the UNDO_TABLESPACE initialization parameter designates the undo tablespace to use. If this parameter is not set, then the first available undo tablespace is chosen.

  如果存在多个撤消表空间，则由 UNDO_TABLESPACE 初始化参数指定要使用的撤消表空间。如果尚未设置此参数，则会选择第一个可用的撤消表空间。

• Opens the online redo log files

    打开联机重做日志文件

See Also:

"Data Repair"

"数据修复"

Read-Only Mode

只读模式

By default, the database opens in read/write mode. In this mode, users can make changes to the data, generating redo in the online redo log. Alternatively, you can open in read-only mode to prevent data modification by user transactions.

默认情况下，数据库打开为读/写模式。在这种模式下，用户可以对数据作出更改，并在联机重做日志中生成重做。或者，也可以打开为只读模式，以防止数据被用户事务修改。

Note:

By default, a physical  standby database  opens in read-only mode. See  Oracle Data Guard Concepts and Administration .

默认情况下，物理备用数据库将以只读模式打开。请参见 《Oracle 数据卫士概念和管理》。

Read-only mode restricts database access to read-only transactions, which cannot write to data files or to online redo log files. However, the database can perform recovery or operations that change the database state without generating redo. For example, in read-only mode:

只读模式限制数据库访问只能为只读事务，也就无法写入到数据文件或联机重做日志文件。但是，数据库能执行恢复，或更改数据库状态但不生成重做的操作。例如，在只读模式：

• Data files can be taken offline and online. However, you cannot take permanent tablespaces offline.

    数据文件可以被脱机和联机。但是，你不能将永久表空间脱机。

• Offline data files and tablespaces can be recovered.

    脱机数据文件和表空间是可以恢复的。

• The control file remains available for updates about the state of the database.

    控制文件仍然可用，以更新有关数据库的状态。

• Temporary tablespaces created with the CREATE TEMPORARY TABLESPACE statement are read/write.

    使用 CREATE TEMPORARY TABLESPACE 语句创建的临时表空间是可读/写的。

• Writes to operating system audit trails, trace files, and alert logs can continue.

    可以继续往操作系统写入审计文件、跟踪文件、和警报日志。

See Also:

Oracle Database Administrator's Guide  to learn how to open a database in read-only mode

《Oracle 数据库管理员指南》了解如何在只读模式下打开数据库

Database File Checks

数据文件检查 

If any of the data files or redo log files are not present when the instance attempts to open the database, or if the files are present but fail consistency tests, then the database returns an error. Media recovery may be required.

当实例尝试打开数据库时，如果任何数据文件或重做日志文件不存在，或者虽然文件存在，但一致性测试失败，则数据库将返回一个错误。此时可能需要介质恢复。

See Also:

"Backup and Recovery"

Overview of Database and Instance Shutdown

数据库和实例关闭概述

In a typical use case, you manually shut down the database, making it unavailable for users while you perform maintenance or other administrative tasks. You can use the SQL*Plus SHUTDOWN command or Enterprise Manager to perform these steps. Figure 13-4 shows the progression from an open state to a consistent shutdown.

举一个典型的使用案例，您手动关闭数据库以执行维护或其他管理任务，这将使数据库对用户不可用。您可以使用 SQL * Plus 的 SHUTDOWN 命令或企业管理器来执行这些步骤。图 13-4 显示从打开状态推进到一致关闭的过程。

Figure 13-4 Instance and Database Shutdown Sequence

图 13-4 实例和数据库关闭顺序

 

Description of "Figure 13-4 Instance and Database Shutdown Sequence"

Oracle Database automatically performs the following steps whenever an open database is shut down consistently:

当一致地关闭打开的数据库时，Oracle 数据库自动执行以下步骤：

1. Database closed

   数据库关闭

   The database is mounted, but online data files and redo log files are closed.

   数据库仍处于装载状态，但数据文件和联机重做日志文件已被关闭。

   "How a Database Is Closed" explains this stage.

   "数据库是如何关闭的"解释了这一阶段。

2. Database unmounted

   数据库卸载

   The instance is started, but is no longer associated with the control file of the database.

   实例仍处于启动状态，但已不再与数据库的控制文件相关联。

   "How a Database Is Unmounted" explains this stage.

   "数据库是如何卸载的"解释了这一阶段。

3. Database instance shut down

   数据库实例关闭

   The database instance is no longer started.

   数据库实例不再处于启动状态。

   "How an Instance Is Shut Down" explains this stage.

   "实例是如何关闭的"解释了这一阶段。

Oracle Database does not go through all of the preceding steps in an instance failure or SHUTDOWN ABORT, which immediately terminates the instance.

当实例失败或遭遇 SHUTDOWN ABORT 时，Oracle 数据库不会经历之前这些所有步骤，而只是立即终止该实例。

See Also:

Oracle Database 2 Day DBA  and  Oracle Database Administrator's Guide  to learn how to shut down a database

《Oracle 数据库 2 日 DBA》 和 《Oracle 数据库管理员指南》了解如何关闭数据库

Shutdown Modes

关闭模式

A database administrator with SYSDBA or SYSOPER privileges can shut down the database using the SQL*Plus SHUTDOWN command or Enterprise Manager. TheSHUTDOWN command has options that determine shutdown behavior. Table 13-2 summarizes the behavior of the different shutdown modes.

具有 SYSDBA 或 SYSOPER 权限的数据库管理员，可以使用 SQL*Plus 的SHUTDOWN 命令或企业管理器来关闭数据库。SHUTDOWN 命令有几个决定关闭行为的选项。表 13-2 总结了在各种不同关闭模式下的行为。

Table 13-2 Shutdown Modes

Database Behavior 数据库行为	ABORT	IMMEDIATE	TRANSACTIONAL	NORMAL
Permits new user connections 允许新用户连接	No	No	No	No
Waits until current sessions end 将等待，直到当前会话结束	No	No	No	Yes
Waits until current transactions end 将等待，直到当前事务结束	No	No	Yes	Yes
Performs a checkpoint and closes open files 执行一个检查点，并关闭打开的文件	No	Yes	Yes	Yes

The possible SHUTDOWN statements are:

可能的几种 SHUTDOWN 语句选项是：

• SHUTDOWN ABORT

  This mode is intended for emergency situations, such as when no other form of shutdown is successful. This mode of shutdown is the fastest. However, a subsequent open of this database may take substantially longer because instance recovery must be performed to make the data files consistent.

  此模式用于紧急情况，如其他形式的关闭方式都未能成功时。这种模式的关闭是最快的。但是，随后打开该数据库可能时间会显著增加，因为必须执行实例恢复以使数据文件一致。

  Note:

  Because SHUTDOWN ABORT does not  checkpoint the open data files, instance recovery is necessary before the database can reopen. The other shutdown modes do not require instance recovery before the database can reopen.
  因为 SHUTDOWN ABORT 不对打开的数据文件执行检查点操作，所以在重新打开数据库之前，必须进行实例恢复。对于其他的关闭模式，在数据库重新打开之前不需要进行实例恢复。

• SHUTDOWN IMMEDIATE

  This mode is typically the fastest next to SHUTDOWN ABORT. Oracle Database terminates any executing SQL statements and disconnects users. Active transactions are terminated and uncommitted changes are rolled back.

  这种模式通常是除 SHUTDOWN ABORT 之外最快的关闭模式了。Oracle 数据库终止任何正在执行的 SQL 语句，并断开用户连接。所有活动事务都将终止，并回滚所有未提交的更改。

• SHUTDOWN TRANSACTIONAL

  This mode prevents users from starting new transactions, but waits for all current transactions to complete before shutting down. This mode can take a significant amount of time depending on the nature of the current transactions.

  这种模式可以防止用户启动新事务，但在关闭之前会等待所有的当前事务完成。这种模式可能会花费相当长的时间，这取决于当前事务的特征。

• SHUTDOWN NORMAL

  This is the default mode of shutdown. The database waits for all connected users to disconnect before shutting down.

  这是默认的关闭模式。在关闭之前数据库会等待所有连接的用户断开连接。

See Also:

• Oracle Database 2 Day DBA and Oracle Database Administrator's Guide to learn about the different shutdown modes

• SQL*Plus User's Guide and Reference to learn about the SHUTDOWN command

    《Oracle 数据库 2 日 DBA》 和 《Oracle 数据库管理员指南》了解不同的关闭模式

    《SQL*Plus 用户指南和参考》了解 SHUTDOWN 命令

How a Database Is Closed

数据库是如何关闭的

The database close operation is implicit in a database shutdown. The nature of the operation depends on whether the database shutdown is normal or abnormal.

数据库的关闭操作是在数据库停机中的一个隐含步骤。该操作的性质取决于数据库停机是正常还是非正常的。

How a Database Is Closed During Normal Shutdown

正常停机过程中是如何关闭数据库的

When a database is closed as part of a SHUTDOWN with any option other than ABORT, Oracle Database writes data in the SGA to the data files and online redo log files. Next, the database closes online data files and online redo log files. Any offline data files of offline tablespaces have been closed already. When the database reopens, any tablespace that was offline remains offline.

当数据库作为 SHUTDOWN 的一部分（不使用 ABORT 选项）而关闭时，Oracle 数据库将 SGA 中的数据写入数据文件和联机重做日志文件。然后数

据库关闭联机数据文件和联机重做日志文件。脱机表空间中的任何脱机数据文件是本来就是已关闭的。当重新打开数据库时，任何本来脱机的空间仍然

保持脱机状态。

At this stage, the database is closed and inaccessible for normal operations. The control files remain open after a database is closed.

这一阶段中，该数据库是关闭的，且无法进行正常操作访问。在数据库关闭后，控制文件仍保持打开状态。

How a Database Is Closed During Abnormal Shutdown

非正常关机过程中是如何关闭数据库

If a SHUTDOWN ABORT or abnormal termination occurs, then the instance of an open database closes and shuts down the database instantaneously. Oracle Database does not write data in the buffers of the SGA to the data files and redo log files. The subsequent reopening of the database requires instance recovery, which Oracle Database performs automatically.

如果执行了 SHUTDOWN ABORT，或出现异常终止，则打开数据库的实例会关闭，并在瞬间将数据库停机。Oracle 数据库不会将 SGA 缓冲区中的数据写入数据文件和重做日志文件。随后重新打开数据库需要实例恢复，这将由 Oracle 数据库自动执行。

How a Database Is Unmounted

数据库是如何卸载的

After the database is closed, Oracle Database unmounts the database to disassociate it from the instance. After a database is unmounted, Oracle Database closes the control files of the database. At this point, the instance remains in memory.

数据库关闭之后，Oracle 将数据库卸载，并解除与实例的关联。数据库卸载后 ，Oracle 数据库关闭数据库的控制文件。这个时候，实例仍将保留在内存中。

How an Instance Is Shut Down

实例是如何关闭的

The final step in database shutdown is shutting down the instance. When the database instance is shut down, the SGA is removed from memory and the background processes are terminated.

关闭数据库的最后一步是关闭实例。当数据库实例关闭时，SGA 被从内存中移除，且后台进程都将被终止。

In unusual circumstances, shutdown of an instance may not occur cleanly. Memory structures may not be removed from memory or one of the background processes may not be terminated. When remnants of a previous instance exist, a subsequent instance startup may fail. In such situations, you can force the new instance to start by 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.

在异常情况下，实例可能并未干净地关闭。内存结构可能未从内存中删除，或某个后台进程可能未被终止。当之前的实例存在残留物时，后续的实例启动可能会失败。在这样的情况下，为强制启动一个新实例，您可以通过删除之前实例的残留物并启动一个新实例、或通过在 SQL*Plus 中发出SHUTDOWN ABORT 语句、或使用企业管理器。

See Also:

Oracle Database Administrator's Guide  for more detailed information about database shutdown

《Oracle 数据库管理员指南》关于关闭数据库的更详细的信息

Overview of Checkpoints

检查点概述

A checkpoint is a crucial mechanism in consistent database shutdowns, instance recovery, and Oracle Database operation generally. The term checkpointhas the following related meanings:

检查点是进行一致的数据库关闭、 实例恢复、和 Oracle 数据库通用操作的关键机制。术语检查点具有如下相关含义：

• A data structure that indicates the checkpoint position, which is the SCN in the redo stream where instance recovery must begin

    指示检查点位置的一个数据结构，该位置是在重做流中实例恢复必须开始处的 SCN

  The checkpoint position is determined by the oldest dirty buffer in the database buffer cache. The checkpoint position acts as a pointer to the redo stream and is stored in the control file and in each data file header.

  检查点位置是由数据库缓冲区高速缓存中最旧的脏缓冲区来确定的。检查点位置作为一个指向重做流的指针，并存储在控制文件中，和在每个数据文件头中。

• The writing of modified database buffers in the database buffer cache to disk

    将数据库缓存中已修改的数据库缓冲区写入到磁盘中

See Also:

"System Change Numbers (SCNs)"

Purpose of Checkpoints

检查点的目的

Oracle Database uses checkpoints to achieve the following goals:

Oracle 数据库使用检查点，来实现以下目标：

• Reduce the time required for recovery in case of an instance or media failure

    减少实例失败或介质故障情况下恢复所需的时间

• Ensure that dirty buffers in the buffer cache are written to disk regularly

    确保在缓冲区高速缓存中的脏缓冲区被定期写入磁盘

• Ensure that all committed data is written to disk during a consistent shutdown

    确保在一致的关闭过程中所有已提交的数据都被写入磁盘

  
  

When Oracle Database Initiates Checkpoints

Oracle 数据库何时启动检查点

The checkpoint process (CKPT) is responsible for writing checkpoints to the data file headers and control file. Checkpoints occur in a variety of situations. For example, Oracle Database uses the following types of checkpoints:

检查点进程 （CKPT） 负责将检查点写入数据文件头和控制文件。检查点会在多种情况下发生。例如， Oracle 数据库使用以下类型的检查点：

• Thread checkpoints

    线程检查点

  The database writes to disk all buffers modified by redo in a specific thread before a certain target. The set of thread checkpoints on all instances in a database is a database checkpoint. Thread checkpoints occur in the following situations:

  数据库将某个确定目标之前、被某个特定的重做线程所修改的所有缓冲区写入磁盘。数据库中所有实例的线程检查点的集合即为数据库检查点。线程检查点在下列情况下发生：

  • Consistent database shutdown

  • ALTER SYSTEM CHECKPOINT statement

  • Online redo log switch

  • ALTER DATABASE BEGIN BACKUP statement

    o  一致的数据库关闭

    o  ALTER SYSTEM CHECKPOINT 语句

    o  联机重做日志切换

    o  ALTER DATABASE BEGIN BACKUP 语句

• Tablespace and data file checkpoints

    表空间和数据文件的检查点

  The database writes to disk all buffers modified by redo before a specific target. A tablespace checkpoint is a set of data file checkpoints, one for each data file in the tablespace. These checkpoints occur in a variety of situations, including making a tablespace read-only or taking it offline normal, shrinking a data file, or executing ALTER TABLESPACE BEGIN BACKUP.

  数据库将某个确定目标之前、被重做线程所修改的所有缓冲区写入磁盘。表空间检查点是一组数据文件检查点，每个数据文件检查点对表空间中的某个数据文件做检查点操作。这些检查点发生在很多情况下，包括将一个表空间变为只读、将表空间脱机、收缩数据文件、或执行 ALTER TABLESPACE BEGIN BACKUP 等。

• Incremental checkpoints

    增量检查点

  An incremental checkpoint is a type of thread checkpoint partly intended to avoid writing large numbers of blocks at online redo log switches. DBWnchecks at least every three seconds to determine whether it has work to do. When DBWn writes dirty buffers, it advances the checkpoint position, causing CKPT to write the checkpoint position to the control file, but not to the data file headers.

  增量检查点是一种线程检查点，部分原因是为了避免在联机重做日志切换时写入大量的块。DBWn 至少每隔三秒会进行检查以确定是否有工作要做。当 DBWn 将脏缓冲区写入磁盘时, 它会向前推进检查点位置，导致 CKPT 将检查点位置写入控制文件，而不是数据文件头。

Other types of checkpoints include instance and media recovery checkpoints and checkpoints when schema objects are dropped or truncated.

其他类型的检查点包括实例和介质恢复检查点，和删除或截断模式对象时的检查点。

See Also:

• "Checkpoint Process (CKPT)"

    "检查点进程(CKPT)"

• Oracle Real Application Clusters Administration and Deployment Guide for information about global checkpoints in Oracle RAC

  《Oracle 真正应用集群管理和部署指南》了解在 Oracle RAC 中的全局检查点信息

Overview of Instance Recovery

实例恢复概述

Instance recovery is the process of applying records in the online redo log to data files to reconstruct changes made after the most recent checkpoint. Instance recovery occurs automatically when an administrator attempts to open a database that was previously shut down inconsistently.

实例恢复是将联机重做日志中的记录应用到数据文件，以重建最近检查点之后所做更改的过程。当管理员尝试打开一个之前以不一致方式关闭的数据库时，会自动执行实例恢复。

Purpose of Instance Recovery

实例恢复的目的

Instance recovery ensures that the database is in a consistent state after an instance failure. The files of a database can be left in an inconsistent state because of how Oracle Database manages database changes.

实例恢复可确保数据库在一个实例失败后仍能回到一个一致的状态。由于Oracle 数据库对数据文件更改的管理方式所致，数据库的文件可以处于不一致的状态。

A redo thread is a record of all of the changes generated by an instance. A single-instance database has one thread of redo, whereas an Oracle RAC database has multiple redo threads, one for each database instance.

重做线程是对实例生成的所有更改的记录。单实例数据库拥有一个重做线程，而一个 Oracle RAC 数据库拥有多个重做线程——每个数据库实例有一个。

When a transaction is committed, log writer (LGWR) writes both the remaining redo entries in memory and the transaction SCN to the online redo log. However, the database writer (DBW) process writes modified data blocks to the data files whenever it is most efficient. For this reason, uncommitted changes may temporarily exist in the data files while committed changes do not yet exist in the data files.

当事务提交时，日志写入器 (LGWR) 将内存中的重做条目和事务 SCN 同时写入联机重做日志。但是，数据库写入器 (DBWn) 进程只在最有利的时机将已修改的数据块写入数据文件。由于这个原因，未提交的更改可能会暂时存在于数据文件中，而已提交的更改也可能还不在数据文件中。

If an instance of an open database fails, either because of a SHUTDOWN ABORT statement or abnormal termination, then the following situations can result:

如果某个打开的数据库的实例失败，或者由于 SHUTDOWN ABORT 语句或异常终止，则可能会导致下列情况：

• Data blocks committed by a transaction are not written to the data files and appear only in the online redo log. These changes must be reapplied to the database.

    由某事务已提交的数据块更新还未写入数据文件，而仅写入了联机重做日志中。这些更改必须重新应用到数据库。

• The data files contains changes that had not been committed when the instance failed. These changes must be rolled back to ensure transactional consistency.

    数据文件包含实例失败时尚未提交的更改。这些更改必须回滚，以确保事务一致性。

Instance recovery uses only online redo log files and current online data files to synchronize the data files and ensure that they are consistent.

实例恢复只使用联机重做日志文件和当前在线的数据文件，以同步数据文件，并确保它们一致。

See Also:

• "Database Writer Process (DBWn)" and "Database Buffer Cache"

• "Introduction to Data Concurrency and Consistency"

When Oracle Database Performs Instance Recovery

Oracle 数据库何时执行实例恢复

Whether instance recovery is required depends on the state of the redo threads. A redo thread is marked open in the control file when a database instance opens in read/write mode, and is marked closed when the instance is shut down consistently. If redo threads are marked open in the control file, but no live instances hold the thread enqueues corresponding to these threads, then the database requires instance recovery.

是否需要实例恢复取决于重做线程的状态。在数据库实例被打开为读/写模式时，重做线程在控制文件中被标记为打开，而当实例被一致关闭时，重做线程被标记为关闭。如果重做线程在控制文件中被标记为打开，但没有活动的实例持有对应于这些线程的线程队列，则数据库将需要实例恢复。

Oracle Database performs instance recovery automatically in the following situations:

Oracle 数据库在以下情况下自动执行实例恢复：

• The database opens for the first time after the failure of a single-instance database or all instances of an Oracle RAC database. This form of instance recovery is also called crash recovery. Oracle Database recovers the online redo threads of the terminated instances together.

    单实例数据库或 Oracle RAC 数据库的所有实例失败后第一次打开数据库。这种形式的实例恢复也称为崩溃恢复。Oracle 数据库一起恢复所有已终止实例的联机重做线程。

• Some but not all instances of an Oracle RAC database fail. Instance recovery is performed automatically by a surviving instance in the configuration.

    只是 Oracle RAC 数据库中的某些、但不是所有实例失败。实例恢复将由配置中的某个存活实例自动进行。

The SMON background process performs instance recovery, applying online redo automatically. No user intervention is required.

SMON 后台进程自动执行实例恢复并应用联机重做记录。而不需要任何用户干预。

See Also:

• "System Monitor Process (SMON)"

• Oracle Real Application Clusters Administration and Deployment Guide to learn about instance recovery in an Oracle RAC database

Importance of Checkpoints for Instance Recovery

实例恢复检查点的重要性

Instance recovery uses checkpoints to determine which changes must be applied to the data files. The checkpoint position guarantees that every committed change with an SCN lower than the checkpoint SCN is saved to the data files.

实例恢复使用检查点来确定必须将哪些更改应用到数据文件。检查点位置始终保证所有比其 SCN 低的检查点所对应的已提交更改都已保存到数据文件。

Figure 13-5 depicts the redo thread in the online redo log.

图 13-5 描述了联机重做日志中的重做线程。

Figure 13-5 Checkpoint Position in Online Redo Log

 

Description of "Figure 13-5 Checkpoint Position in Online Redo Log"

During instance recovery, the database must apply the changes that occur between the checkpoint position and the end of the redo thread. As shown in Figure 13-5, some changes may already have been written to the data files. However, only changes with SCNs lower than the checkpoint position are guaranteed to be on disk.

实例恢复期间，数据库必须应用检查点位置和重做线程结尾之间发生的更改。如图 13-5 所示， 某些更改可能已经写入数据文件。但是，只有其 SCN低于检查点位置的更改，才保证已被写到了磁盘上。

See Also:

Oracle Database Performance Tuning Guide  to learn how to limit instance recovery time

Instance Recovery Phases

实例恢复阶段

The first phase of instance recovery is called cache recovery or rolling forward, and involves reapplying all of the changes recorded in the online redo log to the data files. Because rollback data is recorded in the online redo log, rolling forward also regenerates the corresponding undo segments.

实例恢复的第一阶段称为缓存恢复或前滚，这涉及将联机重做日志中记录的所有更改重新应用到数据文件。因为回滚数据记录在联机重做日志中，前滚也会重新生成相应的撤消段。

Rolling forward proceeds through as many online redo log files as necessary to bring the database forward in time. After rolling forward, the data blocks contain all committed changes recorded in the online redo log files. These files could also contain uncommitted changes that were either saved to the data files before the failure, or were recorded in the online redo log and introduced during cache recovery.

前滚会遍历各个必要的联机重做日志，以将数据库推进到一个更前的一致时间点。前滚之后，数据块包含记录在联机重做日志文件中的所有已提交更改。这些文件可能还包含未提交的更改，要么是在实例失败前保存到数据文件中的，或者是在缓存恢复过程中引入的。

After the roll forward, any changes that were not committed must be undone. Oracle Database uses the checkpoint position, which guarantees that every committed change with an SCN lower than the checkpoint SCN is saved on disk. Oracle Database applies undo blocks to roll back uncommitted changes in data blocks that were written before the failure or introduced during cache recovery. This phase is called rolling back or transaction recovery.

前滚之后，任何未提交的更改必须被撤消。Oracle 数据库使用检查点位置，保证每个低于其 SCN 的已提交更改都已保存到磁盘。Oracle 数据库应用撤消块，以回滚数据块中在实例失败前写入的或缓存恢复过程中引入的未提交更改。这一阶段称为回滚或事务恢复。

Figure 13-6 illustrates rolling forward and rolling back, the two steps necessary to recover from database instance failure.

图 13-6 说明了前滚和回滚，这是恢复数据库实例失败的两个必要步骤。

Figure 13-6 Basic Instance Recovery Steps: Rolling Forward and Rolling Back

图 13-6 基本的实例恢复步骤： 前滚和回滚

Description of "Figure 13-6 Basic Instance Recovery Steps: Rolling Forward and Rolling Back"

Oracle Database can roll back multiple transactions simultaneously as needed. All transactions that were active at the time of failure are marked as terminated. Instead of waiting for the SMON process to roll back terminated transactions, new transactions can roll back individual blocks themselves to obtain the required data.

Oracle 数据库可以根据需要同时回滚多个事务。实例失败时的所有活动事务被标记为终止。新事务可以自己回滚个别块以获取所需的数据，而不必等待 SMON 进程来回滚这些已终止的事务。

See Also:

• "Undo Segments" to learn more about undo data

• Oracle Database Performance Tuning Guide for a discussion of instance recovery mechanics and tuning

Overview of Parameter Files

参数文件的概述

To start a database instance, Oracle Database must read either a server parameter file, which is recommended, or a text initialization parameter file, which is a legacy implementation. These files contain a list of configuration parameters.

要启动数据库实例，Oracle 数据库必须读取一个（推荐的）服务器参数文件或一个（传统的）文本初始化参数文件。这些文件包含配置参数的列表

To create a database manually, you must start an instance with a parameter file and then issue a CREATE DATABASE command. Thus, the instance and parameter file can exist even when the database itself does not exist.

要手动创建一个数据库，必须用一个参数文件启动实例，然后发出CREATE DATABASE 命令。因此，即使数据库本身还不存在，实例和参数文件即可以存在。

Initialization Parameters

初始化参数

Initialization parameters are configuration parameters that affect the basic operation of an instance. The instance reads initialization parameters from a file at startup.

初始化参数是会影响实例基本操作的配置参数。实例在启动时从一个文件读取初始化参数。

Oracle Database provides many initialization parameters to optimize its operation in diverse environments. Only a few of these parameters must be explicitly set because the default values are adequate in most cases.

Oracle 数据库提供了许多初始化参数，以优化其在不同环境中的操作。只需要显式设置几个参数，因为其默认值对大多数情况已经足够。

Functional Groups of Initialization Parameters

初始化参数的功能分组

Most initialization parameters belong to one of the following functional groups:

绝大多数的初始化参数属于以下功能分组之一：

• Parameters that name entities such as files or directories

    名字条目参数，如文件或目录

• Parameters that set limits for a process, database resource, or the database itself

    限制设置参数，如进程、 数据库资源、或数据库本身等

• Parameters that affect capacity, such as the size of the SGA (these parameters are called variable parameters)

    影响容量的参数，如 SGA 的大小（这些参数也称为可变参数）

Variable parameters are of particular interest to database administrators because they can use these parameters to improve database performance.

数据库管理员可能会对可变参数特别感兴趣，因为他们可以使用这些参数来提高数据库性能。

Basic and Advanced Initialization Parameters

基本和高级的初始化参数

Initialization parameters are divided into two groups: basic and advanced. In most cases, you must set and tune only the approximately 30 basic parameters to obtain reasonable performance. The basic parameters set characteristics such as the database name, locations of the control files, database block size, and undo tablespace.

初始化参数可以分为两组： 基本的和高级的。在大多数的情况下，你只需设置和调整大约 30 个基本参数，就可以获得还不错的性能。基本参数设置的特性包括数据库名称、控制文件的位置、数据库的块大小、和撤消表空间等。

In rare situations, modification to the advanced parameters may be required for optimal performance. The advanced parameters enable expert DBAs to adapt the behavior of the Oracle Database to meet unique requirements.

在某些情况下，为获得最佳性能，可能需要修改高级参数。启用高级参数可以使专家级 DBA 能够调整 Oracle 数据库以满足某些特殊需求。

Oracle Database provides values in the starter initialization parameter file provided with your database software, or as created for you by the Database Configuration Assistant (see "Tools for Database Installation and Configuration"). You can edit these Oracle-supplied initialization parameters and add others, depending on your configuration and how you plan to tune the database. For relevant initialization parameters not included in the parameter file, Oracle Database supplies defaults.

Oracle 数据库软件自带的初始化参数文件提供了一些初级参数值，或者你也可以通过数据库配置助手来产生这些值（请参见"数据库安装和配置工具"）。您可以编辑这些 Oracle 提供的初始化参数并添加其他参数，这取决于您的配置，以及你计划如何优化数据库。对于初始化参数文件中不包含的有关参数，Oracle 数据库提供默认值。

See Also:

• Oracle Database 2 Day DBA and Oracle Database Administrator's Guide to learn how to specify initialization parameters

• Oracle Database Reference for an explanation of the types of initialization parameters

• Oracle Database Reference for a description of V$PARAMETER and SQL*Plus User's Guide and Reference for SHOW PARAMETER syntax

Server Parameter Files

服务器参数文件

A server parameter file is a repository for initialization parameters that is managed by Oracle Database. A server parameter file has the following key characteristics:

服务器参数文件是 Oracle 数据库用来管理初始化参数的一个存储库。服务器参数文件具有以下主要特征：

• Only one server parameter file exists for a database. This file must reside on the database host.

    对于一个数据库，只存在一个服务器参数文件。此文件必须驻留在数据库主机上。

• The server parameter file is written to and read by only by Oracle Database, not by client applications.

    服务器参数文件只由 Oracle 数据库读取和写入，而不能由客户端应用程序读取和写入。

• The server parameter file is binary and cannot be modified by a text editor.

    服务器参数文件是二进制的，且不能使用文本编辑器修改。

• Initialization parameters stored in the server parameter file are persistent. Any changes made to the parameters while a database instance is running can persist across instance shutdown and startup.

    存储在服务器参数文件中的初始化参数是永久性的。数据库实例正在运行时对参数所做的任何更改，可以跨实例关闭和启动而存在。

A server parameter file eliminates the need to maintain multiple text initialization parameter files for client applications. A server parameter file is initially built from a text initialization parameter file using the CREATE SPFILE statement. It can also be created directly by the Database Configuration Assistant.

服务器参数文件消除了为多个客户端应用程序维护多个文本初始化参数文件的需要。服务器参数文件最初可以从一个文本初始化参数文件，使用CREATE SPFILE 语句来生成。也可以直接由数据库配置助手创建。

See Also:

• Oracle Database Administrator's Guide to learn more about server parameter files

• Oracle Database SQL Language Reference to learn about CREATE SPFILE

Text Initialization Parameter Files

文本初始化参数文件

A text initialization parameter file is a text file that contains a list of initialization parameters. This type of parameter file, which is a legacy implementation of the parameter file, has the following key characteristics:

文本初始化参数文件是一个文本文件，其中包含初始化参数的列表。这是一种旧式参数文件，具有以下关键特征：

• When starting up or shutting down a database, the text initialization parameter file must reside on the same host as the client application that connects to the database.

    当启动或关闭数据库时，文本初始化参数文件必须驻留在连接到该数据库的客户端应用程序相同的主机上。

• A text initialization parameter file is text-based, not binary.

    文本初始化参数文件是基于文本的，而非二进制。

• Oracle Database can read but not write to the text initialization parameter file. To change the parameter values you must manually alter the file with a text editor.

    Oracle 数据库可以读取，但不能写入文本初始化参数文件。若要更改参数值，必须使用文本编辑器手动更改文件。

• Changes to initialization parameter values by ALTER SYSTEM are only in effect for the current instance. You must manually update the text initialization parameter file and restart the instance for the changes to be known.

    通过 ALTER SYSTEM 对初始化参数值所做的更改，仅在当前实例中有效。您必须手动更新文本初始化参数文件，并重新启动实例以使更改生效。

The text initialization parameter file contains a series of key=value pairs, one per line. For example, a portion of an initialization parameter file could look as follows:

文本初始化参数文件包含一系列 key=value 对，每行一个。例如，某个初始化参数文件中的一部分看起来如下所示： 

db_name=sample

control_files=/disk1/oradata/sample_cf.dbf

db_block_size=8192

open_cursors=52

undo_management=auto

shared_pool_size=280M

pga_aggregate_target=29M

.

.

.

To illustrate the manageability problems that text parameter files can create, assume that you use computers clienta and clientb and must be able to start the database with SQL*Plus on either computer. In this case, two separate text initialization parameter files must exist, one on each computer, as shown inFigure 13-7. A server parameter file solves the problem of the proliferation of parameter files.

为了说明文本参数文件可能产生的可管理性问题，假定您使用计算机clienta 和 clientb，并且必须能够从其中任何一台计算机上使用 SQL*Plus 启动数据库。在这种情况下，必须存在两个独立的文本初始化参数文件，每台计算机上一个，如图 13-7 所示。服务器参数文件解决了分散的参数文件问题。

Figure 13-7 Multiple Initialization Parameter Files

图 13-7 多个初始化参数文件

Description of "Figure 13-7 Multiple Initialization Parameter Files"

See Also:

• Oracle Database Administrator's Guide to learn more about text initialization parameter files

• Oracle Database SQL Language Reference to learn about CREATE PFILE

Modification of Initialization Parameter Values

修改初始化参数的值

You can adjust initialization parameters to modify the behavior of a database. The classification of parameters as static or dynamic determines how they can be modified. Table 13-3 summarizes the differences.

您可以修改初始化参数，以调整数据库行为。将其按静态或动态参数的分类，确定了应如何修改它们。表 13-3 总结了的其中的差异。

Table 13-3 Static and Dynamic Initialization Parameters

Characteristic	Static	Dynamic
Requires modification of the parameter file (text or server) 需要修改（文本或服务器）参数文件	Yes	No
Requires database instance restart before setting takes affect 在设置生效之前数据库实例需要重启	Yes	No
Described as "Modifiable" in Oracle Database Reference initialization parameter entry 在 《Oracle 数据库参考》初始化参数条目中被描述为"可修改"	No	Yes
Modifiable only for the database or instance 仅对数据库或实例可修改	Yes	No

Static parameters include DB_BLOCK_SIZE, DB_NAME, and COMPATIBLE. Dynamic parameters are grouped into session-level parameters, which affect only the current user session, and system-level parameters, which affect the database and all sessions. For example, MEMORY_TARGET is a system-level parameter, while NLS_DATE_FORMAT is a session-level parameter (see "Locale-Specific Settings").

静态参数包括 DB_BLOCK_SIZE、DB_NAME 、和 COMPATIBLE 等。动态参数可分为会话级参数和系统级参数，会话级参数只影响当前的用户会话，而系统级参数影响数据库及所有会话。例如，MEMORY_TARGET 是一个系统级参数，而 NLS_DATE_FORMAT 是一个会话级参数 （请参见"特定于区域的设置"）。

The scope of a parameter change depends on when the change takes effect. When an instance has been started with a server parameter file, you can use the ALTER SYSTEM SET statement to change values for system-level parameters as follows:

参数更改的范围取决于更改何时生效。若实例是用服务器参数文件启动的，则可以使用 ALTER SYSTEM SET 语句更改系统级参数的值，如下所示：

• SCOPE=MEMORY

  Changes apply to the database instance only. The change will not persist if the database is shut down and restarted.

  更改只应用于数据库实例。如果数据库关闭并重新启动，更改将不会保留。 

• SCOPE=SPFILE

  Changes are written to the server parameter file but do not affect the current instance. Thus, the changes do not take effect until the instance is restarted.

  更改被写入服务器参数文件，但不会影响当前实例。因此，所做的更改不会生效，直到重新启动该实例。

  Note:

  You must specify SPFILE when changing the value of a parameter described as not modifiable in  Oracle Database Reference .
  当你修改某个在《Oracle 数据库参考》中描述为不可修改的参数的值时，必须指定 SPFILE。

• SCOPE=BOTH

  Changes are written both to memory and to the server parameter file. This is the default scope when the database is using a server parameter file.

  将更改同时写入内存和服务器参数文件。当数据库使用服务器参数文件时，这是默认的范围。

The database prints the new value and the old value of an initialization parameter to the alert log. As a preventative measure, the database validates changes of basic parameter to prevent illegal values from being written to the server parameter file.

数据库会在警报日志中输出初始化参数的旧值和新值。作为一项预防措施，数据库会验证对基本参数的更改，以防止非法值被写入到服务器参数文件中。

See Also:

• Oracle Database Administrator's Guide to learn how to change initialization parameter settings

• Oracle Database Reference for descriptions of all initialization parameters

• Oracle Database SQL Language Reference for ALTER SYSTEM syntax and semantics

Overview of Diagnostic Files

诊断文件概述

Oracle Database includes a fault diagnosability infrastructure for preventing, detecting, diagnosing, and resolving database problems. Problems include critical errors such as code bugs, metadata corruption, and customer data corruption.

Oracle 数据库包括一个故障可诊断性基础设施，以预防、 检测、 诊断、并解决各种数据库问题。这些问题包括如代码错误、 元数据损坏、和客户数据损坏等严重错误。

The goals of the advanced fault diagnosability infrastructure are the following:

这个先进的故障可诊断性基础设施的目标如下：

• Detecting problems proactively

• Limiting damage and interruptions after a problem is detected

• Reducing problem diagnostic and resolution time

• Simplifying customer interaction with Oracle Support

    主动侦测问题

    在检测到问题后，限制破坏和中断

    减少问题诊断和解决时间 

    简化客户与 Oracle 支持的交互

Automatic Diagnostic Repository

自动诊断存储库

Automatic Diagnostic Repository (ADR) is a file-based repository that stores database diagnostic data such as trace files, the alert log, and Health Monitor reports. Key characteristics of ADR include:

自动诊断存储库 （ADR） 是一个基于文件的存储库，存储了如跟踪文件、警报日志、和健康监测报告等数据库诊断数据。ADR 的关键特征包括：

• Unified directory structure

• Consistent diagnostic data formats

• Unified tool set

    统一的路径结构

    一致的诊断数据格式

    统一的工具集

The preceding characteristics enable customers and Oracle Support to correlate and analyze diagnostic data across multiple Oracle instances, components, and products.

上述特性使得客户和 Oracle 支持部门能跨多个 Oracle 实例、 组件、和产品对诊断数据进行关联和分析。

ADR is located outside the database, which enables Oracle Database to access and manage ADR when the physical database is unavailable. An instance can create ADR before a database has been created.

ADR 处于数据库之外，这使得即便物理数据库不可用时，也可以访问和管理 ADR。在创建数据库之前，其实例就可以创建 ADR。

Problems and Incidents

问题和事件

ADR proactively tracks problems, which are critical errors in the database. Critical errors manifest as internal errors, such as ORA-600, or other severe errors. Each problem has a problem key, which is a text string that describes the problem.

ADR 主动跟踪数据库中的严重错误问题。严重错误通常显示为内部错误，如 ORA-600 或其他严重错误。每个问题有一个问题键，它是一个描述此问题的文本字符串。

When a problem occurs multiple times, ADR creates a time-stamped incident for each occurrence. An incident is uniquely identified by a numeric incident ID. When an incident occurs, ADR sends an incident alert to Enterprise Manager. Diagnosis and resolution of a critical error usually starts with an incident alert.

当一个问题出现多次时， ADR 为每次发生的错误创建一个带时间戳的事件。事件由一个数字事件 id 唯一标识。当事件发生时， ADR 发送一个事件警报到企业管理器中。对严重错误的诊断和解决，通常从一个事件警报开始。

Because a problem could generate many incidents in a short time, ADR applies flood control to incident generation after certain thresholds are reached. Aflood-controlled incident generates an alert log entry, but does not generate incident dumps. In this way, ADR informs you that a critical error is ongoing without overloading the system with diagnostic data.

因为一个问题可以在短时间内生成许多事件，ADR 在达到某些阈值时，将对事件生成应用防洪控制措施。防洪受控事件将生成一个警报日志条目，但不会生成事件转储。这样一来，ADR 会通知您正在发生一个严重错误，而不会在系统中产生过量诊断数据。

See Also:

Oracle Database Administrator's Guide  for detailed information about the fault diagnosability infrastructure

ADR Structure

ADR 结构

The ADR base is the ADR root directory. The ADR base can contain multiple ADR homes, where each ADR home is the root directory for all diagnostic data—traces, dumps, the alert log, and so on—for an instance of an Oracle product or component. For example, in an Oracle RAC environment with shared storage and ASM, each database instance and each ASM instance has its own ADR home.

ADR base 是 ADR 的根目录。ADR base 可能包含多个 ADR home，每个ADR home 是一个 Oracle 产品或组件实例的所有的诊断数据的根目录，包括跟踪、 转储、 和警报日志等等。例如，在有共享存储和 ASM 的 Oracle RAC 环境中，每个数据库实例和每个 ASM 实例都有自己的 ADR Home。

Figure 13-8 illustrates the ADR directory hierarchy for a database instance. Other ADR homes for other Oracle products or components, such as ASM or Oracle Net Services, can exist within this hierarchy, under the same ADR base.

图 13-8 说明了数据库实例的 ADR 目录层次结构。其他 Oracle 产品或组件（如 ASM 或 Oracle 网络服务）的 ADR Home 也可以存在于此层次结构中，在相同的 ADR base 之下。

Figure 13-8 ADR Directory Structure for an Oracle Database Instance

Description of "Figure 13-8 ADR Directory Structure for an Oracle Database Instance"

As the following Linux example shows, when you start an instance with a unique SID and database name before creating a database, Oracle Database creates ADR by default as a directory structure in the host file system. The SID and database name form part of the path name for files in the ADR Home.

如下的 Linux 示例显示， 当你在创建一个数据库之前，使用一个唯一的 SID 和数据库名称启动一个实例时，Oracle 数据库在主机文件系统中会将 ADR默认创建为一个目录结构。SID 和数据库名称形成 ADR Home 中的文件路径名称的一部分。

Example 13-1 Creation of ADR

% setenv ORACLE_SID osi

% echo "DB_NAME=dbn" > init.ora

% sqlplus / as sysdba

.

.

.

Connected to an idle instance.

 

SQL> STARTUP NOMOUNT PFILE="./init.ora"

ORACLE instance started.

 

Total System Global Area  146472960 bytes

Fixed Size                  1317424 bytes

Variable Size              92276176 bytes

Database Buffers           50331648 bytes

Redo Buffers                2547712 bytes

 

SQL> SELECT NAME, VALUE FROM V$DIAG_INFO;

 

NAME                  VALUE

--------------------- --------------------------------------------------

Diag Enabled          TRUE

ADR Base              /u01/oracle/log

ADR Home              /u01/oracle/log/diag/rdbms/dbn/osi

Diag Trace            /u01/oracle/log/diag/rdbms/dbn/osi/trace

Diag Alert            /u01/oracle/log/diag/rdbms/dbn/osi/alert

Diag Incident         /u01/oracle/log/diag/rdbms/dbn/osi/incident

Diag Cdump            /u01/oracle/log/diag/rdbms/dbn/osi/cdump

Health Monitor        /u01/oracle/log/diag/rdbms/dbn/osi/hm

Default Trace File    /u01/oracle/log/diag/rdbms/dbn/osi/trace/osi_ora_10533.trc

Active Problem Count  0

Active Incident Count 0

The following sections describe the contents of ADR.

以下各节描述了 ADR 的内容。

Alert Log

警报日志

Each database has an alert log, which is an XML file containing a chronological log of database messages and errors. The alert log contents include the following:

每个数据库都有一个警报日志，它是一个 XML 文件，其中包含按时间排序的数据库信息和错误的日志。警报日志的内容包括如下：

• All internal errors (ORA-600), block corruption errors (ORA-1578), and deadlock errors (ORA-60)

    所有的内部错误 (ORA-600)、 块损坏错误 （ORA-1578) 、和死锁错误 (ORA-60)

• Administrative operations such as DDL statements and the SQL*Plus commands STARTUP, SHUTDOWN, ARCHIVE LOG, and RECOVER

    管理性操作，如 DDL 语句和 STARTUP、SHUTDOWN、ARCHIVELOG、和 RECOVER 等 SQL*Plus 命令

• Several messages and errors relating to the functions of shared server and dispatcher processes

    几个与共享服务器和调度器进程的功能有关的消息和错误

• Errors during the automatic refresh of a materialized view

    物化视图自动刷新过程中的错误

Oracle Database uses the alert log as an alternative to displaying information in the Enterprise Manager GUI. If an administrative operation is successful, then Oracle Database writes a message to the alert log as "completed" along with a time stamp.

Oracle 数据库使用警报日志作为在企业管理器 GUI 中显示信息的一种替代。如果管理操作成功，则 Oracle 数据库向警报日志写入一条带有时间戳的“已完成”消息。

Oracle Database creates an alert log in the alert subdirectory shown in Figure 13-8 when you first start a database instance, even if no database has been created yet. The following example shows a portion of a text-only alert log:

如图 13-8 所示， 当您首次启动一个数据库实例，即使其数据库尚未创建，Oracle 数据库会在 alert 子目录中创建一个警报日志。下面的示例演示一个纯文本警报日志的一部分：

Fri Jun 19 17:05:34 2011

Starting ORACLE instance (normal)

LICENSE_MAX_SESSION = 0

LICENSE_SESSIONS_WARNING = 0

Shared memory segment for instance monitoring created

Picked latch-free SCN scheme 2

Autotune of undo retention is turned on.

IMODE=BR

ILAT =12

LICENSE_MAX_USERS = 0

SYS auditing is disabled

Starting up ORACLE RDBMS Version: 11.2.0.0.0.

Using parameter settings in client-side pfile

.

.

.

System parameters with nondefault values:

  db_name                  = "my_test"

Fri Jun 19 17:05:37 2011

PMON started with pid=2, OS id=10329

Fri Jun 19 17:05:37 2011

VKTM started with pid=3, OS id=10331 at elevated priority

VKTM running at (20)ms precision

Fri Jun 19 17:05:37 2011

DIAG started with pid=4, OS id=10335

As shown in Example 13-1, query V$DIAG_INFO to locate the alert log.

如例 13-1 所示，通过查询 V$DIAG_INFO 来定位警报日志。

Trace Files

跟踪文件

A trace file is an administrative file that contain diagnostic data used to investigate problems. Also, trace files can provide guidance for tuning applications or an instance, as explained in "Performance Diagnostics and Tuning".

跟踪文件是一个管理性文件，其中包含用于调查问题的诊断数据。此外，跟踪文件也可以为优化应用程序或实例提供指导，如"性能诊断与调整"所述。

Types of Trace Files

跟踪文件的类型

Each server and background process can periodically write to an associated trace file. The files information on the process environment, status, activities, and errors.

每个服务器和后台进程可以定期写入一个关联的跟踪文件。这些文件包括进程环境、 状态、 活动、和错误等信息。

The SQL trace facility also creates trace files, which provide performance information on individual SQL statements. To enable tracing for a client identifier, service, module, action, session, instance, or database, you must execute the appropriate procedures in the DBMS_MONITOR package or use Oracle Enterprise Manager.

SQL 跟踪设施还会为单个 SQL 语句创建跟踪文件，以提供性能信息。若要为客户端标识、 服务、 模块、 动作、 会话、 实例、或数据库等启用跟踪，必须执行 DBMS_MONITOR 包中适当的过程，或使用 Oracle 企业管理器。

A dump is a special type of trace file. Whereas a trace tends to be continuous output of diagnostic data, a dump is typically a one-time output of diagnostic data in response to an event (such as an incident). When an incident occurs, the database writes one or more dumps to the incident directory created for the incident. Incident dumps also contain the incident number in the file name.

转储是一种特殊类型的跟踪文件。跟踪往往是诊断数据的连续输出，而转储通常是响应某个事件的一次性诊断数据输出。当事件发生时，数据库会将一个或多个转储写入为事件创建的目录。事件转储还在文件名称中包含了事件号。

See Also:

• "Session Control Statements"

• Oracle Database Administrator's Guide to learn about trace files, dumps, and core files

• Oracle Database Performance Tuning Guide to learn about application tracing

Locations of Trace Files

跟踪文件的位置

ADR stores trace files in the trace subdirectory, as shown in Figure 13-8. Trace file names are platform-dependent and use the extension .trc.

ADR 将跟踪文件存储在 trace 子目录中，如图 13-8 所示。跟踪文件的名称取决于其运行平台，并使用扩展名.trc。

Typically, database background process trace file names contain the Oracle SID, the background process name, and the operating system process number. An example of a trace file for the RECO process is mytest_reco_10355.trc.

通常，数据库后台进程的跟踪文件名称中包含 Oracle SID、 后台进程名称、和操作系统进程号。RECO 进程的跟踪文件的一个示例是mytest_reco_10355.trc。

Server process trace file names contain the Oracle SID, the string ora, and the operating system process number. An example of a server process trace file name is mytest_ora_10304.trc.

服务器进程跟踪文件名称包含 Oracle SID、 字符串 ora 和操作系统进程号。服务器进程跟踪文件名称的一个示例是 mytest_ora_10304.trc。

Sometimes trace files have corresponding trace map (.trm) files. These files contain structural information about trace files and are used for searching and navigation.

有时跟踪文件有相应的跟踪位图 (.trm) 文件。这些文件包含跟踪文件的相关结构信息，并用于搜索和导航。