Oracle 20C官方文档-Concepts(Part V-1)

Oracle 20C官方文档-Concepts(Part V-1)

Part I Oracle Relational Data Structures

Part II Oracle Data Access

Part III Oracle Transaction Management

Part IV Oracle Database Storage Structures

Part V Oracle Instance Architecture

---1 Oracle Database Instance

---2 Memory Architecture

---3 Process Architecture

---4 Application and Oracle Net Services Architecture

Oracle实例体系结构

Oracle Instance Architecture

这一部分描述了Oracle数据库实例的基本结构体系。

This part describes the basic structural architecture of the Oracle database instance.

本部分包括以下章节：

This part contains the following chapters:

•Oracle数据库实例

• Oracle Database Instance

•内存体系结构

• Memory Architecture

•进程体系机构

• Process Architecture

•应用程序和Oracle网络服务体系结构

• Application and Oracle Net Services Architecture

Oracle Database Instance

本章解释了Oracle数据库实例的性质、与实例关联的参数和诊断文件，以及在实例创建和数据库的打开和关闭过程中会发生什么。

This chapter explains the nature of an Oracle database instance, the parameter and

diagnostic files associated with an instance, and what occurs during instance creation and the opening and closing of a database.

注意:

就本章而言，除非另有说明，“数据库”一词是指多租户容器数据库(CDB)

Note:

For the purposes of this chapter, the term "database" refers to a multitenant

container database (CDB) unless otherwise noted.

本章包括以下章节：

This chapter contains the following sections:

(1)数据库实例的介绍

• Introduction to the Oracle Database Instance

(2)数据库实例启动和关闭的概述

• Overview of Database Instance Startup and Shutdown

(3)检查点

• Overview of Checkpoints

(4)实例恢复

• Overview of Instance Recovery

(5)参数文件

• Overview of Parameter Files

(6)诊断文件

• Overview of Diagnostic Files

Oracle数据库实例介绍

Introduction to the Oracle Database Instance

数据库实例是管理数据库文件的一组内存结构。

A database instance is a set of memory structures that manage database files.

在物理级别，CDB是由CREATE DATABASE语句创建的磁盘上的一组文件。一个CDB包含一个或多个用户创建的pdb。PDB在属于CDB的整个数据文件集中包含自己的数据文件集。数据库实例管理与CDB及其pdb关联的数据，并为它们的用户提供服务。

At the physical level, a CDB is a set of files on disk created by the CREATE DATABASE

statement. A CDB contains one or more user-created PDBs. A PDB contains its own set of data files within the overall set of data files that belongs to the CDB. The

database instance manages the data associated with the CDB and its PDBs and

serves their users.

每个正在运行的CDB至少与一个Oracle数据库实例关联。因为实例存在于内存中，而数据库(最狭义的术语)是磁盘上的一组文件，所以一个实例可以没有数据库而数据库可以没有实例而存在。

Every running CDB is associated with at least one Oracle database instance. Because an instance exists in memory and a database (in the narrowest sense of term) is a set of files on disk, an instance can exist without a database and a database can exist without an instance.

数据库实例结构

Database Instance Structure

启动实例时，Oracle数据库分配一个称为系统全局区域(SGA)的内存区域，并启动一个或多个后台进程。

When an instance is started, Oracle Database allocates a memory area called the

system global area (SGA) and starts one or more background processes.

SGA有多种用途，包括:

The SGA serves various purposes, including the following:

(1)维护内部数据结构，使多进程和线程同时访问从磁盘读取的数据块缓存

•Maintaining internal data structures that many processes and threads access

concurrently Caching data blocks read from disk

(2)在将重做数据写入联机重做日志文件之前缓冲重做数据

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

(3)存储SQL执行计划

• Storing SQL execution plans

在一台计算机上运行的Oracle进程共享SGA。Oracle进程与SGA关联的方式因操作系统而异。

Oracle processes running on a single computer share the SGA. The way in which

Oracle processes associate 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数据库实例的主要组件。

The following graphic shows the main components of an Oracle database instance.

Figure 13-1 Database Instance 

See Also:

• "Overview of the System Global Area (SGA)"

• "Overview of Background Processes"

数据库实例配置

Database Instance Configurations

Oracle数据库在单实例配置或Oracle Real Application Clusters（Oracle RAC）配置中运行。这些配置是互斥的。

Oracle Database runs in either a single-instance configuration or an Oracle Real

Application Clusters (Oracle RAC) configuration. These configurations are mutually

exclusive.

在单实例配置中，数据库和数据库实例之间存在一对一的关系。在Oracle RAC中，数据库和数据库实例之间存在一对多的关系。

In a single-instance configuration, a one-to-one relationship exists between the

database and a database instance. In Oracle RAC, a one-to-many relationship exists between the database and database instances.

Figure 13-2 Database Instance Configurations

无论是在单实例还是Oracle RAC配置中，数据库实例一次只与一个数据库关联。您可以启动一个数据库实例并挂载(将该实例关联到)一个数据库，但不能同时挂载两个数据库到同一个实例。

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.

Note:

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

This chapter discusses a single-instance database configuration unless

otherwise noted.

多个实例可以在同一台计算机上并发运行，每个实例访问自己的数据库。例如，一台计算机可以托管两个不同的数据库:prod1和prod2。一个数据库实例管理prod1，而另一个实例管理prod2。

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.

See Also:

Oracle Real Application Clusters Administration and Deployment Guide for

information specific to Oracle RAC

读/写和只读实例

Read/Write and Read-Only Instances

每个数据库实例都是读/写或只读的。

默认的读/写数据库实例可以处理DML并支持来自客户机应用程序的直接连接。相反，只读数据库实例可以处理查询，但不支持修改DML(更新、删除、插入和合并)或直接客户端连接。

Every database instance is either read/write or read-only.

A read/write database instance, which is the default, can process DML and supports direct connections from client applications. In contrast, a read-only database instance can process queries, but does not support modification DML (UPDATE, DELETE, INSERT, and MERGE) or direct client connections.

Note:

除非本手册另有说明，否则对数据库实例的所有引用都是读/写实例。

Unless stated otherwise in this manual, all references to database instances

are to read/write instances.

在以前的版本中，所有数据库实例(除非它们访问了备用数据库)都是读/写的。从Oracle数据库12c版本2(12.2)开始，只读和读/写实例可以在单个数据库共存。这种配置对于同时查询和修改数据的并行SQL语句非常有用，因为读/写和只读实例都可以查询，而读/写实例可以修改。

In previous releases, all database instances—unless they accessed a standby

database—were read/write. Starting in Oracle Database 12c Release 2 (12.2), read

only and read/write instances can coexist within a single database. This configuration is useful for parallel SQL statements that both query and modify data, because both read/write and read-only instances can query, while the read/write instances modify.

与读/写实例不同，只读实例具有以下特征:

Unlike read/write instances, read-only instances have the following characteristics:

(1)只能打开已被读/写实例打开的数据库

•Can only open a database that has already been opened by a read/write instance

(2)禁用许多后台进程，包括不需要的检查点和归档进程

• Disable many background processes, including the checkpoint and archiver

processes, which are not necessary

(3) 可以挂载禁用的重做线程，也可以挂载不带任何联机重做日志的线程

要将实例指定为只读，请将INSTANCE_MODE初始化参数设置为READ_ONLY。参数的默认值是READ_WRITE。

• Can mount a disabled redo thread or a thread without any online redo log

To designate an instance as read-only, set the INSTANCE_MODE initialization parameter

to READ_ONLY. The default value of the parameter is READ_WRITE.

See Also:

• "Overview of Background Processes" to learn more about the checkpoint

and archiver background processes

• "Overview of the Online Redo Log"

• Oracle Database Reference to learn more about the INSTANCE_MODE initialization parameter

数据库实例的持续时间

Duration of a Database Instance

数据库实例在使用STARTUP命令时开始，在终止时结束。

A database instance begins when it is created with the STARTUP command and ends

when it is terminated.

在此期间，数据库实例可以将自己与一个且只能与一个数据库关联。而且，实例只能挂载数据库一次，只能关闭数据库一次，只能打开数据库一次。在关闭或关闭数据库之后，必须启动另一个实例来挂载和打开该数据库。

During this period, a database 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.

The following table illustrates a database instance attempting to reopen a database

that it previously closed.

Table 13-1 Duration of an Instance

数据库实例的标识

Identification of a Database Instance

多个数据库实例可以驻留在一个主机上。因此，必须要有指定要访问具体哪个实例的方法。

Multiple database instances can reside on a single host. Therefore, you must have a

means of specifying which instance you want to access.

Oracle最优灵活体系结构（OFA）规则是为确保Oracle安装的良好组织而创建的一组配置准则。本节中的示例假设是一个OFA架构。

Oracle Optimal Flexible Architecture (OFA) rules are a set of configuration guidelines

created to ensure well-organized Oracle installations. The examples in this section

assume an OFA architecture.

本节包含以下主题

This section contains the following topics:

Oracle基本目录

Oracle主目录

Oracle系统标识符(SID)

• Oracle Base Directory

• Oracle Home Directory

• Oracle System Identifier (SID)

See Also:

Oracle Database Installation Guide for Linux for an overview of the OFA

数据库基本目录

Oracle Base Directory

Oracle基本目录存储是Oracle产品的二进制文件。

The Oracle base directory stores the binaries for Oracle products.

Oracle基本目录是Oracle数据库安装所有者的数据库主目录。主机上可以安装多个Oracle数据库，也可以安装多个Oracle数据库软件。

The Oracle Base directory is the database home directory for Oracle Database

installation owners. There can be many Oracle Database installations on a host, and

many Oracle Database software installation owners.

下面的示例显示了操作系统用户帐户Oracle的Oracle基本目录:

The following example shows the Oracle base directory of the operating system user account oracle:

/u01/app/oracle

在前面的路径中，/u01/是挂载点，/u01/app/是应用软件的子目录

In the preceding path, /u01/ is the mount point, and /u01/app/ is the subtree for

application software.

See Also:

Oracle Database Installation Guide for Linux for an overview of the Oracle

base

Oracle主目录

Oracle Home Directory

Oracle home是Oracle数据库的软件位置目录。

The Oracle home is the software location for an Oracle database.

您必须为每次新安装的Oracle数据库软件指定一个新的Oracle主目录。从Oracle数据库20c开始，Oracle home是只读的。Oracle home存储二进制文件等静态文件。

You must specify a new Oracle home directory for each new installation of Oracle

Database software. Starting in Oracle Database 20c, the Oracle home is read-only.

The Oracle home stores static files such as binaries.

默认情况下，Oracle主目录是Oracle基（Oracle_base）目录树中的子目录。您可以在同一台主机上，在单个Oracle基础内的不同Oracle主目录中多次安装此版本或更早版本的数据库软件。不同版本、不同用户帐户拥有的多个数据库可以同时共存。

By default, the Oracle home directory is a descendent within the Oracle base

(ORACLE_BASE) directory tree. You can install this release, or earlier releases of the

database software, more than once on the same host, in different Oracle home

directories within a single Oracle base. Multiple databases, of different versions and

owned by different user accounts, can coexist concurrently.

下面的示例显示了三个不同Oracle home的完整路径名，它们都位于相同的Oracle基本目录/u01/app/Oracle 中:

The following example shows the full path names of three different Oracle homes, all within the same Oracle base directory of /u01/app/oracle/:

/u01/app/oracle/product/19.3.0/dbhome_1

/u01/app/oracle/product/19.3.0/dbhome_2

/u01/app/oracle/product/20.1.0/dbhome_1

Oracle 基目录 (/u01/app/ Oracle )后面的路径名包括产品发布号(例如19.3.0)和Oracle home相对目录(例如dbhome_1)。/u01/app/oracle/product/19.3.0/目录包含两个单独的oracle home: dbhome_1和dbhome_2。

The part of the path name after the Oracle base (/u01/app/oracle/) includes the

product release number (for example, 19.3.0) and Oracle home relative directory (for example, dbhome_1). The /u01/app/oracle/product/19.3.0/ directory contains two separate Oracle homes: dbhome_1 and dbhome_2.

Oracle base home (ORACLE_BASE_HOME)目录位于ORACLE_BASE/homes/home_name中，它存储特定于Oracle home的动态文件。由所有人共享的Oracle基本配置目录(ORACLE_BASE_CONFIG)在Oracle库中存储特定于实例的动态文件。

The Oracle base home (ORACLE_BASE_HOME) directory, which is located in ORACLE_BASE/homes/home_name, stores dynamic files specific to an Oracle home. The Oracle base configuration directory (ORACLE_BASE_CONFIG), which is shared by all

Oracle homes in an Oracle base, stores instance-specific dynamic files.

在下面的例子中，第一个路径是Oracle home，第二个路径是这个Oracle home的Oracle base home:

In the following example, the first path is an Oracle home, and the second path is the Oracle base home for this Oracle home:

/u01/app/oracle/product/20.1.0/dbhome_1

/u01/app/oracle/homes/dbhome_1

See Also:

Oracle Database Installation Guide for Linux for an overview of the Oracle home

Oracle系统标识符(SID)

Oracle System Identifier (SID)

系统标识符(SID)是特定主机上Oracle数据库实例的唯一名称。

The system identifier (SID) is a unique name for an Oracle database instance on a

specific host.

在UNIX和Linux上，Oracle数据库使用SID和Oracle home值创建共享内存的密钥。另外，Oracle数据库默认使用SID来定位初始化参数文件，该文件定位相关文件，比如数据库控制文件。

On UNIX and Linux, Oracle Database uses the SID and Oracle home values to create a key to shared memory. Also, Oracle Database uses the SID by default to locate the initialization parameter file, which locates relevant files such as the database control files.

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

On most platforms, the ORACLE_SID environment variable sets the SID, and the

ORACLE_HOME variable sets the Oracle home. When connecting to a database instance, clients can specify the SID in an Oracle Net connection or use a net service name. Oracle Database converts a net service name to an ORACLE_HOME and ORACLE_SID.

特定于实例的文件单独存储在Oracle库中。名称包含SID的文件位于Oracle基本配置目录(ORACLE_BASE_CONFIG)的dbs子目录中。由于这种分离，您可以使用现有Oracle home中的软件创建数据库，然后使用新Oracle home中的软件启动该数据库的实例。

Instance-specific files are stored separately in the Oracle base. Files whose names

include the SID reside in the dbs subdirectory of the Oracle base configuration

directory (ORACLE_BASE_CONFIG). Because of this separation, you can create a

database using software in an existing Oracle home, and then start an instance for this database using software that resides in a new Oracle home.

See Also:

• "Service Names"

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

数据库实例启动和关闭的概述

Overview of Database Instance Startup and Shutdown

数据库实例提供用户对数据库的访问。实例和数据库可以处于不同的状态。

A database instance provides user access to a database. The instance and the

database can be in various states.

实例和数据库启动概述

Overview of Instance and Database Startup

通常，手动启动一个实例，然后挂载并打开数据库，使其对用户可用。可以使用SQL*Plus启动命令、Oracle Enterprise Manager (Enterprise Manager)或SRVCTL命令来执行这些步骤。

Typically, you manually start an instance, and then mount and open the database,

making it available for users. You can use the SQL*Plus STARTUP command, Oracle

Enterprise Manager (Enterprise Manager), or the SRVCTL utility to perform these

steps.

要使用Oracle Net启动数据库实例，必须满足以下条件:

1 数据库被Oracle Net侦听器静态注册

2 您的客户端使用SYSDBA特权连接到数据库。

侦听器创建一个专用服务器，该服务器可以启动数据库实例。

下图显示了数据库从关闭状态到打开状态的过程。

• To start a database instance using Oracle Net, the following must be true:

The database is statically registered with an Oracle Net listener.

• Your client is connected to the database with the SYSDBA privilege.

The listener creates a dedicated server, which can start the database instance.

The following graphic shows the database progressing from a shutdown state to an

open state.

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.

Table 13-2 Steps in Instance Startup

See Also:

• "The Oracle Net Listener"

• "Overview of Control Files"

• Oracle Database Administrator’s Guide to learn how to start an instance

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

以管理员权限连接

Connection with Administrator Privileges

数据库启动和关闭是影响特别大的管理选项，仅限具有管理员权限连接到Oracle数据库的用户使用。

Database startup and shutdown are powerful administrative options that are restricted to users who connect to Oracle Database with administrator privileges.

普通用户无法控制Oracle数据库的当前状态。根据操作系统的不同，下列条件之一为用户建立管理员权限:

Normal users do not have control over the current status of an Oracle database.

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 special system privileges, and the database uses password

files to authenticate database administrators over the network.

即使数据库未打开，下列系统特权仍可让使用者使用数据库实例:

The following special system privileges enable access to a database instance even

when the database is not open:

• SYSDBA

• SYSOPER

• SYSBACKUP

• SYSDG

• SYSKM

上述特权的控制在数据库本身之外。当使用SYSDBA系统特权连接到数据库时，处于SYS拥有的模式中。当作为SYSOPER连接时，处于公共模式中。SYSOPER特权是SYSDBA特权的子集。

Control of the preceding privileges is outside of the database itself. When you connect to a database 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.

See Also:

• "SYS and SYSTEM Schemas"

• Oracle Database Security Guide to learn about predefined administrative

accounts

• Oracle Database Administrator’s Guide to learn about system privileges

• Oracle Database Installation Guide to learn more about operating

system privilege groups

如何启动实例

How an Instance Is Started

当Oracle数据库启动一个实例时，它将分阶段进行。

各阶段如下:

When Oracle Database starts an instance, it proceeds through stages.

The stages are as follows:

1. 在特定于平台的默认位置中搜索服务器参数文件，如果没有找到，则搜索文本初始化参数文件(使用SPFILE或PFILE参数指定启动将覆盖默认行为)

1. Searches for a server parameter file in a platform-specific default location and, if

not found, for a text initialization parameter file (specifying STARTUP with the SPFILE

or PFILE parameters overrides the default behavior)

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

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

3.根据初始化参数设置分配SGA

3. Allocates the SGA based on the initialization parameter settings

4. 启动Oracle后台进程

4. Starts the Oracle background processes

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

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

alert log in valid parameter syntax

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

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.

See Also:

Oracle Database Administrator’s Guide to learn how to manage initialization

parameters using a server parameter file

如何装载数据库

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.

如果Oracle数据库允许多个实例并发地挂载同一个数据库，那么CLUSTER_DATABASE初始化参数设置可以使数据库对多个实例可用。数据库行为取决于设置:

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:

•如果第一个挂载数据库的实例的CLUSTER_DATABASE参数为false(默认值)，那么只有这个实例可以挂载数据库。

•如果第一个实例的CLUSTER_DATABASE为true，那么如果其他实例的CLUSTER_DATABASE参数设置为true，则可以装载数据库。可以装载数据库的实例数量受创建数据库时指定的预定最大值的限制。

• If CLUSTER_DATABASE is false (default) for the first instance that mounts a

database, then only this instance can mount the database.

• If CLUSTER_DATABASE is true for the first instance, then other instances can mount

the database if their CLUSTER_DATABASE parameter settings are set to true. The

number of instances that can mount the database is subject to a predetermined

maximum specified when creating the database.

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

如何打开数据库

How a Database Is Opened

打开装载的数据库可使其用于正常的数据库操作

Opening a mounted database makes it available for normal database operation.

任何有效用户都可以连接到打开的数据库并访问其信息。通常，数据库管理员会打开数据库以使其可供一般使用。

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.

打开数据库时，Oracle数据库将执行以下操作

When you open the database, Oracle Database performs the following actions:

•在数据库先前关闭时，如果一个表空间处于离线状态，那么当数据库重新打开时，该表空间及其相应的数据文件将处于离线状态

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

If a tablespace was offline when the database was previously shut down, then the

tablespace and its corresponding data files will be offline when the database

reopens. 

•如果存在多个undo表空间，那么UNDO_TABLESPACE初始化参数指定要使用的undo表空间。如果未设置此参数，则选择第一个可用的undo表空间。

• 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.

•打开在线重做日志文件

• Opens the online redo log files

See Also:

• "Online and Offline Tablespaces"

• Oracle Database Backup and Recovery User’s Guide to learn more about 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.

写入数据文件或联机重做日志文件。但是，数据库可以执行恢复或更改数据库状态的操作，而不会生成重做。例如，在只读模式下:

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:

1 数据文件可以离线和在线。但是，不能使永久表空间permanent tablespaces脱机

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

tablespaces offline.

2 离线数据文件和表空间可以被恢复。

• Offline data files and tablespaces can be recovered.

3 控制文件对于数据库状态的更新仍然可用。

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

4 使用CREATE Temporary TABLESPACE语句创建的临时表空间是读/写的。

• Temporary tablespaces created with the CREATE TEMPORARY TABLESPACE

statement are read/write.

5 对操作系统审计跟踪、跟踪文件和警报日志的写操作可以继续。

• 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 Data Guard Concepts and Administration

数据文件检查

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:

Oracle Database 2 Day DBA for an overview of backup and recovery

数据库和实例关闭的概述

Overview of Database and Instance Shutdown

在一个典型的用例中，手动关闭数据库，使其在执行维护或其他管理任务时对用户不可用。可以使用SQL*Plus工具执行 SHUTDOWN命令或Enterprise Manager来执行这些步骤。

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.

下图显示了从打开状态到一致关闭的过程。

The following figure shows the progression from an open state to a consistent

shutdown.

Figure 13-4 Instance and Database Shutdown Sequence 

每当打开的数据库被一致关闭时，Oracle数据库都会自动执行以下步骤。

Oracle Database automatically performs the following steps whenever an open

database is shut down consistently.

Table 13-3 Steps in Consistent Shutdown

在实例失败或SHUTDOWN ABORT过程中，Oracle数据库不会执行前面的所有步骤，会立即终止实例。

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

See Also:

Oracle Database Administrator’s Guide to learn how to shut down a database

关机模式

Shutdown Modes

具有SYSDBA或SYSOPER权限的数据库管理员可以使用SQL*Plus shut down命令或EM关闭数据库。SHUTDOWN命令具有决定关闭行为的选项。

A database administrator with SYSDBA or SYSOPER privileges can shut down the

database using the SQL*Plus SHUTDOWN command or Enterprise Manager. The

SHUTDOWN command has options that determine shutdown behavior.

下表总结了不同关机模式的行为。

The following table summarizes the behavior of the different shutdown modes.

Table 13-4 Database Shutdown Modes 

可能的关闭语句有:

The possible SHUTDOWN statements are:

• SHUTDOWN ABORT

此模式适用于紧急情况，例如其他关闭方式都失败了。这种关机方式是最快的。但是，此数据库的后续打开可能需要更长的时间，因为必须执行实例恢复以使数据文件保持一致。由于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.

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.

Note:

在PDB中发出的SHUTDOWN ABORT等同于在CDB级别发出的SHUTDOWN IMMEDIATE

In a PDB, issuing SHUTDOWN ABORT is equivalent to issuing SHUTDOWN

IMMEDIATE at the CDB level.

• SHUTDOWN IMMEDIATE

此模式是仅次于abort的最快模式。Oracle数据库将会终止任何正在执行的SQL语句，并断开用户连接。活动事务被终止，未提交的更改被回滚。

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 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 Administrator’s Guide to learn about the different

shutdown modes

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

command

如何关闭数据库

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

当数据库在关闭过程中使用了除ABORT之外的任何选项而关闭时，Oracle数据库将SGA中的数据写到数据文件和在线重做日志文件中。

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.

然后，数据库关闭在线数据文件和在线重做日志文件。任何离线表空间的离线数据文件已经被关闭。当数据库重新打开时，任何脱机的表空间都保持脱机状态。

Afterward, 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. 

在此阶段，数据库已关闭，无法进行正常操作。数据库关闭后，控制文件保持打开状态。

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

如果发生SHUTDOWN ABORT或异常终止，则打开数据库的实例和数据库将立即关闭。

If a SHUTDOWN ABORT or abnormal termination occurs, then the instance of an open

database closes and shuts down the database instantaneously.

在异常关闭时，Oracle数据库不会将SGA缓冲区中的数据写入数据文件和重做日志文件。随后重新打开数据库需要实例恢复，而Oracle数据库将会自动执行实例恢复。

In an abnormal shutdown, 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.

如何unmount数据库

How a Database Is Unmounted

关闭数据库后，unmount数据库，将其与实例分离。

unmount数据库后，Oracle数据库关闭数据库的控制文件。此时，数据库实例保留在内存中。

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 database instance remains in memory.

如何关闭实例

How an Instance Is Shut Down

数据库关闭的最后一步是关闭实例。当数据库实例关闭时，SGA停止占用内存，后台进程终止。

The final step in database shutdown is shutting down the instance. When the database instance shuts down, the SGA ceases to occupy memory, and the background processes terminate.

在不寻常的情况下，数据库实例的关闭可能不会干净地发生。内存结构不能从内存中删除，或者一个后台进程不能终止。当前一个实例的残余存在时，后续实例启动可能失败。在这种情况下，可以强制新实例启动，方法是删除前一个实例的剩余部分，然后启动一个新实例，或者发出SHUTDOWN ABORT语句。

In unusual circumstances, shutdown of a database 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.

在某些情况下，进程清理本身可能会遇到错误，这可能导致进程监视器(PMON)或实例终止。动态初始化参数INSTANCE_ABORT_DELAY_TIME指定延迟内部生成的实例失败的时间。这个延迟给了你一个回应的机会。当延迟终止启动时，数据库将向警报日志写入一条消息。在某些情况下，通过允许隔离某些数据库资源，实例可以避免终止。

In some cases, process cleanup itself can encounter errors, which can result in the

termination of process monitor (PMON) or the instance. The dynamic initialization

parameter INSTANCE_ABORT_DELAY_TIME specifies how many seconds to delay an

internally generated instance failure. This delay gives you a chance to respond. The

database writes a message to the alert log when the delayed termination is initiated. In some circumstances, by allowing certain database resources to be quarantined, the instance can avoid termination.

See Also:

• Oracle Database Administrator’s Guide for more detailed information

about database shutdown

• Oracle Database Reference to learn more about the

INSTANCE_ABORT_DELAY_TIME initialization parameter

检查点的概述

Overview of Checkpoints

在一致性关闭数据库、实例恢复和Oracle数据库操作中，检查点是一个重要的机制。

A checkpoint is a crucial mechanism in consistent database shutdowns, instance

recovery, and Oracle Database operation generally.

有以下相关含义:

The term has the following related meanings:

1 指出检查点位置的数据结构，也就是重做流中的SCN，实例恢复必须从这里开始。检查点位置由数据库缓冲区缓存中最老的脏缓冲区决定。检查点位置充当重做流的指针，并存储在控制文件和每个数据文件头中。

• A data structure that indicates the checkpoint position, which is the SCN in the

redo stream where instance recovery must begin 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. 

2 将database buffer cache中的脏数据写入到磁盘

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

See Also:

"System Change Numbers (SCNs)"

检查点的目的

Purpose of Checkpoints

Oracle数据库使用检查点来实现多个目标。

目标包括：

•减少实例或介质故障时恢复所需的时间

•确保数据库定期将缓冲区缓存中的脏缓冲区写入磁盘

•确保数据库在一致关机期间将所有提交的数据写入磁盘

Oracle Database uses checkpoints to achieve multiple goals.

Goals include the following:

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

• Ensure that the database regularly writes dirty buffers in the buffer cache to disk

• Ensure that the database writes all committed data to disk during a consistent

shutdown

当Oracle数据库启动检查点时

When Oracle Database Initiates Checkpoints

检查点进程(CKPT)负责将检查点写入数据文件头和控制文件。

The checkpoint process (CKPT) is responsible for writing checkpoints to the data file headers and control file.

检查点在各种情况下都会出现。例如，Oracle数据库使用以下类型的检查点:

Checkpoints occur in a variety of situations. For example, Oracle Database uses the

following types of checkpoints:

• 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:

1数据库一致性关闭

2执行ALTER SYSTEM CHECKPOINT命令

3 执行ALTER DATABASE BEGIN BACKUP命令

– Consistent database shutdown

– ALTER SYSTEM CHECKPOINT statement

– Online redo log switch

– ALTER DATABASE BEGIN BACKUP statement

• Tablespace and data file checkpoints

表空间和数据文件检查点

数据库将在特定目标之前重做所修改的所有缓冲区写入磁盘。表空间检查点是一组数据文件检查点，每个数据文件对应一个表空间。这些检查点出现在各种情况下，包括将表空间设置为只读或脱机、收缩数据文件或执行ALTER TABLESPACE BEGIN BACKUP命令。

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.

• Incremental checkpoints

增量检查点

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

An incremental checkpoint is a type of thread checkpoint partly intended to avoid

writing large numbers of blocks at online redo log switches. DBW checks at least

every three seconds to determine whether it has work to do. When DBW 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.

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

Other types of checkpoints include instance and media recovery checkpoints and

checkpoints when schema objects are dropped or truncated.

See Also:

• "Checkpoint Process (CKPT)"

• Oracle Real Application Clusters Administration and Deployment Guide

for information about global checkpoints in 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

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

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 RAC数据库有多个重做线程，每个数据库实例有一个重做线程。

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.

当提交事务时，日志写进程(LGWR)将内存中剩余的重做条目和事务SCN都写到在线重做日志。但是，为了提高写入效率，数据库写入器(DBW)进程将修改后的数据块写入数据文件不是马上触发的。因此，未提交的更改可能暂时存在于数据文件中，而提交的更改尚未存在于数据文件中。

When a transaction is committed, log writer process (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.

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

If an instance of an open database fails, either because of a SHUTDOWN ABORT

statement or abnormal termination, then the following situations can result:

•事务提交的数据块没有写入数据文件，写入了在线重做日志中。这些更改必须重新应用到数据文件。

• 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 data files.

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

• 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 (DBW)" and "Database Buffer Cache"

• "Introduction to Data Concurrency and Consistency"

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

When Oracle Database Performs Instance Recovery

是否需要实例恢复取决于重做线程的状态。

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数据库在以下情况下自动执行实例恢复:

Oracle Database performs instance recovery automatically in the following situations:

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

•Oracle RAC数据库不是所有实例都失败。实例恢复由配置中幸存的实例自动执行。

• 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.

• Some but not all instances of an Oracle RAC database fail. Instance recovery is

performed automatically by a surviving instance in the configuration.

SMON后台进程执行实例恢复，自动应用在线重做。不需要用户干预。

The SMON background process performs instance recovery, applying online redo

automatically. No user intervention is required.

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

实例恢复使用检查点来确定哪些更改必须应用于数据文件。检查点位置确保每个提交的SCN低于检查点SCN的更改都保存到数据文件中。

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.

下图描述了在线重做日志中的重做线程。

The following figure depicts the redo thread in the online redo log.

Figure 13-5 Checkpoint Position in Online Redo Log 

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

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.

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

reapplies all changes recorded in the online redo log to the data files.

由于联机重做日志包含撤消数据，前滚也会重新生成相应的撤消段。前滚将继续执行尽可能多的联机重做日志文件，以便及时将数据库前滚。前滚之后，数据块包含在线重做日志文件中记录的所有提交的更改。这些文件还包含了未提交的更改，这些更改可以在失败之前保存到数据文件中，也可以记录在联机重做日志中并在缓存恢复期间引入。

Because the online redo log contains undo data, 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.

前滚之后，必须撤消未提交的任何更改。Oracle数据库使用检查点位置，这保证了SCN低于检查点SCN的每个提交的更改都保存在磁盘上。Oracle数据库应用undo块来回滚在失败之前写入或在缓存恢复期间引入的数据块中未提交的更改。此阶段称为回滚或事务恢复。

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.

下图说明了前滚和后滚，这是从数据库实例故障中恢复所需的两个步骤。

The following figure illustrates rolling forward and rolling back, the two steps necessary to recover from database instance failure.

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

Oracle数据库可以根据需要同时回滚多个事务。所有在失败时处于活动状态的事务都被标记为已终止。与等待SMON进程回滚终止的事务不同，新事务可以回滚各个块本身以获得所需的数据。

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.

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 

要启动数据库实例，Oracle数据库必须读取服务器参数文件(建议这样做)或文本初始化参数文件(遗留)。这些文件包含一组配置参数。

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.

要手动创建数据库，必须使用参数文件启动实例，然后发出create database语句。因此，即使数据库本身不存在，实例和参数文件也可以存在。

To create a database manually, you must start an instance with a parameter file and

then issue a CREATE DATABASE statement. Thus, the instance and parameter file can

exist even when the database itself does not exist.

初始化参数

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数据库提供了许多初始化参数来优化其在不同环境中的操作。必须显式地设置其中的几个参数，因为默认值通常是足够的。

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 usually adequate.

初始化参数的功能组

Functional Groups of Initialization Parameters

初始化参数分为不同的功能组。

Initialization parameters fall into different functional groups.

大多数初始化参数属于以下一组:

Most initialization parameters belong to one of the following groups:

1命名实体(如文件或目录)的参数

2为进程、数据库资源或数据库本身设置限制的参数

3影响容量的参数，如SGA的大小(这些参数称为变量参数)

• 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)

变量参数对于数据库管理员来说特别重要，因为他们可以使用这些参数来提高数据库性能。

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. 

通常，您必须仅设置和调优大约30个基本参数才能获得合理的性能。基本参数设置特征，如数据库名称、控制文件的位置、数据库块大小和undo表空间。

Typically, 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.

在极少数情况下，可能需要修改高级参数以获得最佳性能。高级参数使dba能够调整Oracle数据库的行为以满足独特的需求。

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.

Oracle数据库在数据库软件提供的启动器初始化参数文件中提供值，或由数据库配置助手（DBCA）创建的值。可以编辑这些Oracle提供的初始化参数并添加其他参数，具体取决于您的配置和计划如何优化数据库。对于参数文件中未包含的相关初始化参数，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 (DBCA). 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.

See Also:

• Oracle Database 2 Day DBA to learn how to create and manage a

database with DBCA

• 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

服务器参数文件是初始化参数的存储库。

服务器参数文件具有以下关键特征:

1只有Oracle数据库读写服务器参数文件。

2一个数据库只有一个服务器参数文件。此文件必须驻留在数据库主机上。

3服务器参数文件是二进制的，不能被文本编辑器修改。

4存储在服务器参数文件中的初始化参数是持久的。在数据库实例运行时对参数所做的任何更改都可以在实例关闭和启动期间保持不变。

A server parameter file is a repository for initialization parameters.

A server parameter file has the following key characteristics:

• Only Oracle Database reads and writes to the server parameter file.

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

database host.

• 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.

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

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.

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

文本初始化参数文件是包含初始化参数列表的文本文件。

这种类型的参数文件是参数文件的遗留实现，具有以下关键特征:

1在启动或关闭数据库时，文本初始化参数文件必须与连接到数据库的客户机应用程序位于同一主机上。

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

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

4 ALTER SYSTEM对初始化参数值的更改仅对当前实例有效。您必须手动更新文本初始化参数文件，并重新启动实例，以便了解所做的更改。

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.

• 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.

文本初始化参数文件包含一系列键值对，每行一个。

例如，初始化参数文件的一部分可以如下所示:

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:

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

.

.

.

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

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 in Figure 13-7. A server parameter file solves the problem of the proliferation of parameter files.

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.

下表总结了这些差异。

The following table summarizes the differences.

ble 13-5 Static and Dynamic Initialization Parameters 

静态参数包括DB_BLOCK_SIZE、DB_NAME和COMPATIBLE。动态参数分为仅影响当前用户会话的会话级参数和影响数据库和所有会话的系统级参数。例如，MEMORY_TARGET是系统级参数，而NLS_DATE_FORMAT是会话级参数。

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.

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

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:

• 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 apply 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:

在更改Oracle数据库引用中描述为不可修改的参数值时，必须指定SPFILE。

You must specify SPFILE when changing the value of a parameter

described as not modifiable in Oracle Database Reference.

• SCOPE=BOTH

Oracle数据库将更改写入内存和服务器参数文件。这是数据库使用服务器参数文件时的默认值。

Oracle Database writes changes 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 invalid values from being written to the server parameter file.

See Also:

• Oracle Database Globalization Support Guide to learn how to choose a locale with the NLS_LANG environment variable

• 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数据库包含一个故障诊断基础设施，用于预防、检测、诊断和解决数据库问题。问题包括关键错误，如代码错误、元数据损坏和客户数据损坏。

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.

高级故障诊断基础设施的目标如下:

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

1主动发现问题

2检测到问题后，限制损害和中断

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

4通过支持对跟踪文件进行分区来提高可管理性，允许用户定义每个块的大小和要保留的最大块数，并在达到用户指定的磁盘空间限制后禁用跟踪

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

• Detecting problems proactively

• Limiting damage and interruptions after a problem is detected

• Reducing problem diagnostic and resolution time

• Improving manageability by enabling trace files to be partitioned, allowing user to

define the size per piece and maximum number of pieces to retain, and disabling

tracing after a user-specified disk space limit is reached

• Simplifying customer interaction with Oracle Support

See Also:

Oracle Database Administrator’s Guide to learn how to manage diagnostic files

自动诊断库

Automatic Diagnostic Repository

自动诊断存储库(ADR)是基于文件的存储库，用于存储数据库诊断数据，如跟踪文件、警报日志、DDL日志和健康监视器报告。

Automatic Diagnostic Repository (ADR) is a file-based repository that stores

database diagnostic data such as trace files, the alert log, DDL log, and Health Monitor reports.

ADR的主要特征包括:

Key characteristics of ADR include:

•统一的目录结构

•一致的诊断数据格式

•统一的工具集

• Unified directory structure

• Consistent diagnostic data formats

• Unified tool set

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

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

ADR位于数据库外部，这使Oracle数据库能够在物理数据库不可用时访问和管理ADR。数据库实例可以在创建数据库之前创建ADR。

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

问题和事件

Problems and Incidents

ADR主动跟踪问题，这些问题是数据库中的关键错误。

ADR proactively tracks problems, which are critical errors in the database.

严重错误表现为内部错误，如ORA-600或其他严重错误。

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为每次发生创建一个时间戳事件。事件由数字事件ID唯一标识。当事件发生时，ADR向企业经理发送事件警报。严重错误的诊断和解决通常从事件警报开始。

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在达到一定的阈值后对事件的产生进行防洪处理。一个洪水控制的事件生成一个警报日志条目，但不生成事件转储。通过这种方式，ADR会通知您一个严重的错误正在发生，而不会给系统带来过多的诊断数据。

Because a problem could generate many incidents in a short time, ADR applies flood control to incident generation after certain thresholds are reached. A flood-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.

See Also:

Oracle Database Administrator’s Guide for detailed information about the

fault diagnosability infrastructure

ADR结构

ADR Structure

ADR的基础是ADR根目录。

The ADR base is the ADR root directory.

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

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 Oracle ASM, each database instance and each Oracle ASM instance has its own ADR home.

图13-8说明了数据库实例的ADR目录层次结构。其他Oracle产品或组件(如ASM或Oracle Net Services)的ADR home也可以存在于相同的ADR库中

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

图13-8 Oracle数据库实例的ADR目录结构

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

如下面的Linux示例所示，当您在创建数据库之前使用惟一的SID和数据库名启动一个实例时，Oracle数据库在主机文件系统中默认创建ADR作为目录结构。SID和数据库名构成ADR主文件路径名的一部分。

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.

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> COL NAME FORMAT a21

SQL> COL VALUE FORMAT a60

SQL> SELECT NAME, VALUE FROM V$DIAG_INFO;

NAME VALUE

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

Diag Enabled TRUE

ADR Base /d1/3910926111/oracle/log

ADR Home /d1/3910926111/oracle/log/diag/rdbms/dbn/osi

Diag Trace /d1/3910926111/oracle/log/diag/rdbms/dbn/osi/trace

Diag Alert /d1/3910926111/oracle/log/diag/rdbms/dbn/osi/alert

Diag Incident /d1/3910926111/oracle/log/diag/rdbms/dbn/osi/incident

Diag Cdump /d1/3910926111/oracle/log/diag/rdbms/dbn/osi/cdump

Health Monitor /d1/3910926111/oracle/log/diag/rdbms/dbn/osi/hm

Default Trace File /d1/3910926111/oracle/log ... osi/trace/

osi_ora_6825.trc

Active Problem Count 0

Active Incident Count 0

警报日志

Alert Log

每个数据库都有一个警报日志，它是一个XML文件，包含按时间顺序排列的数据库消息和错误日志。

Every database has an alert log, which is an XML file containing a chronological log of database messages and errors.

警报日志内容包括以下内容:

1所有内部错误(ORA-600)，坏块错误(ORA-1578)，死锁错误(ORA-60)

2管理操作，如SQL*Plus命令启动、关闭、归档日志和恢复

3与共享服务器和dispatcher进程的功能相关的一些消息和错误

4在自动刷新物化视图时出现的错误

The alert log contents include the following:

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

errors (ORA-60)

• Administrative operations such as the SQL*Plus commands STARTUP, SHUTDOWN,

ARCHIVE LOG, and RECOVER

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

dispatcher processes

• Errors during the automatic refresh of a materialized view

Oracle数据库使用警报日志作为在Enterprise Manager GUI中显示信息的替代方法。如果管理操作成功，则Oracle数据库将一条消息连同时间戳写入警报日志，并显示为“completed”。

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数据库也会在图13-8所示的alert子目录中创建一个警报日志。这个文件是XML格式的。跟踪子目录包含一个纯文本的警告日志，其中的一部分出现在下面的示例中:

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.

This file is in the XML format. The trace subdirectory contains a text-only alert log, a

portion of which appears in the following example:

Fri Nov 02 12:41:58 2014

SMP system found. enable_NUMA_support disabled (FALSE)

Starting ORACLE instance (normal)

CLI notifier numLatches:3 maxDescs:189

LICENSE_MAX_SESSION = 0

LICENSE_SESSIONS_WARNING = 0

Initial number of CPU is 2

Number of processor cores in the system is 2

Number of processor sockets in the system is 2

Shared memory segment for instance monitoring created

Picked latch-free SCN scheme 3

Using LOG_ARCHIVE_DEST_1 parameter default value as /disk1/oracle/dbs/arch

Autotune of undo retention is turned on.

IMODE=BR

ILAT =10

LICENSE_MAX_USERS = 0

SYS auditing is disabled

NOTE: remote asm mode is local (mode 0x1; from cluster type)

Starting up:

Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit

Production

With the Partitioning, Advanced Analytics and Real Application Testing

options.

.

.

.

Using parameter settings in client-side pfile

System parameters with nondefault values:

processes = 100

sessions = 172

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

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

DDL日志

DDL Log

DDL日志具有与警报日志相同的格式和基本行为，但只包含DDL语句和详细信息。数据库将DDL信息写入自己的文件，以减少警报日志中的混乱。

The DDL log has the same format and basic behavior as the alert log but contains

only DDL statements and details. The database writes DDL information to its own file to reduce the clutter in the alert log.

DDL日志记录是DDL文本，可选地添加了补充信息。每个DDL语句有一条日志记录。DDL日志存储在ADR主目录的log/ DDL子目录中。

DDL log records are DDL text, optionally augmented with supplemental information.

One log record exists for each DDL statement. The DDL log is stored in the log/ddl

subdirectory of the ADR home.

Trace Files 跟踪文件 

跟踪文件是包含用于调查问题的诊断数据的文件。此外，跟踪文件可以为应用程序或实例的调优提供指导。

A trace file is a file that contains diagnostic data used to investigate problems. Also,

trace files can provide guidance for tuning applications or an instance.

See Also:

Oracle Database 2 Day + Performance Tuning Guide

Types of Trace Files 跟踪文件类型

每个服务器和后台进程都可以周期性地写入相关的跟踪文件。这些文件包含有关流程环境、状态、活动和错误的信息。

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

SQL跟踪工具还创建跟踪文件，这些文件提供关于单个SQL语句的性能信息。可以通过各种方式启用对客户端标识符、服务、模块、操作、会话、实例或数据库的跟踪。例如，可以在DBMS_MONITOR包或设置事件中执行适当的过程。

The SQL trace facility also creates trace files, which provide performance information on individual SQL statements. You can enable tracing for a client identifier, service, module, action, session, instance, or database in various ways. For example, you can execute the appropriate procedures in the DBMS_MONITOR package or set events.

See Also:

• "Session Control Statements"

• Oracle Database Administrator’s Guide to learn about trace files, dumps,

and core files

• Oracle Database SQL Tuning Guide to learn about application tracing

Locations of Trace Files 跟踪文件位置

ADR将跟踪文件存储在跟踪子目录中。跟踪文件名依赖于平台，并使用扩展名.trc。

ADR stores trace files in the trace subdirectory. Trace file names are platform

dependent and use the extension .trc.

通常，数据库后台进程跟踪文件名包含Oracle SID、后台进程名和操作系统进程号。RECO进程的一个跟踪文件示例是mytest_reco_10355.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、字符串ora和操作系统进程号。服务器进程跟踪文件名的一个例子是mytest_ora_10304.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.

有时跟踪文件具有相应的跟踪元数据文件，这些文件以扩展名.trm结尾。这些文件包含数据库用于搜索和导航的称为跟踪映射的结构信息。

Sometimes trace files have corresponding trace metadata files, which end with the

extension .trm. These files contain structural information called trace maps that the

database uses for searching and navigation.

See Also:

• "Figure 13-8"

• Oracle Database Administrator’s Guide to learn how to find trace files

跟踪文件的分割

Segmentation of Trace Files

当跟踪文件大小受到限制时，数据库可以自动将其最多分割为五个段。段是与活动跟踪文件同名的独立文件，但是附加了段号，如ora_1234_2.trc。

When the trace file size is limited, the database may automatically split it into a

maximum of five segments. Segments are separate files that have the same name as the active trace file, but with a segment number appended, as in ora_1234_2.trc.

每个段通常是MAX_DUMP_FILE_SIZE设置的限制的20%。当所有段的合并大小超过限制时，数据库将删除最旧的段(尽管不会删除第一个段，因为它可能包含有关进程初始状态的相关信息)，然后创建一个新的空段。

Each segment is typically 20% of the limit set by MAX_DUMP_FILE_SIZE. When the

combined size of all segments exceeds the limit, the database deletes the oldest

segment (although never the first segment, which may contain relevant information

about the initial state of the process), and then creates a new, empty segment.

See Also:

Oracle Database Administrator’s Guide to learn how to control the size of

trace files

Diagnostic Dumps 诊断转储 

诊断转储文件是一种特殊类型的跟踪文件，它包含关于状态或结构的详细时间点信息。

A diagnostic dump file is a special type of trace file that contains detailed point-in

time information about a state or structure.

跟踪往往是诊断数据的连续输出。相反，转储通常是响应事件的一次性诊断数据输出。

A trace tends to be continuous output of diagnostic data. In contrast, a dump is

typically a one-time output of diagnostic data in response to an event.

跟踪转储和事件

Trace Dumps and Incidents

大多数转储都是由事件引起的。

Most dumps occur because of incidents. 

当发生事件时，数据库将一个或多个转储写入为该事件创建的事件目录。事件转储还在文件名中包含事件编号。在事件创建期间，应用程序可以将堆或系统状态转储作为操作的一部分。在这种情况下，数据库将转储名称附加到事件文件名，而不是默认的跟踪文件名。例如，由于进程中的事件，数据库创建文件prod_ora_90348.trc。事件中的转储生成文件prod_ora_90348_ent_id。是事件的数字ID。作为事件的一部分创建的堆转储操作生成堆转储文件prod_ora_90348_ent_id_dump_id。其中dump_id是跟踪转储的数字ID。

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. During incident creation, an application may take a heap or system state dump as part of an action. In such cases, the database appends the dump name to the incident file name instead of the default trace file name. For example, because of an incident in a process, the database creates file prod_ora_90348.trc. A dump in the incident generates the file prod_ora_90348_incident_id.trc, where incident_id is the numeric ID of the incident. A heap dump action created as part of the incident generates the heap dump file prod_ora_90348_incident_id_dump_id.trc, where dump_id is the numeric ID of the trace dump.