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
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"
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 的特定信息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
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 IMMEDIATEThe 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.
此查詢顯示當前實例的啟動時間。不同的開始時間顯示此實例不同於之前已關閉數據庫的那個實例。
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
A database instance provides user access to a database. This section explains the possible states of the instance and the database.
實例啟動和關閉概述數據庫實例提供了用戶對數據庫的訪問。此部分說明了實例和數據庫可能存在的狀態。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:
當數據庫從關閉狀態推進到打開狀態時，會經歷以下幾個階段：
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.
實例已啟動，但尚未與某個數據庫相關聯。"實例是如何啟動的"解釋了這一階段。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.
實例已啟動，並且通過讀取控制文件，來與數據庫相關聯 （請參閱"控制文件概述"）。數據庫對用戶是關閉的。 "數據庫是如何裝載的"解釋了這一階段。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 數據庫管理員指南》了解如何使用 SRVCTLDatabase 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 和 SYSOPERWhen Oracle Database starts an instance, it performs the following basic steps:
當 Oracle 數據庫啟動一個實例時，它執行以下基本步驟：
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
參數將覆蓋該默認行為）
Reads the parameter file to determine the values of initialization parameters
2. 讀取參數文件，以確定初始化參數值
Allocates the SGA based on the initialization parameter settings
3. 基於初始化參數設置，分配 SGA
Starts the Oracle background processes
4. 啟動 Oracle 後台進程
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 數據庫管理員指南》了解如何使用服務器參數文件來管理初始化參數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 真正應用集群管理和部署指南》關於如何將單個數據庫和多個實例一起使用的詳細信息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" "數據修復"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 數據庫管理員指南》了解如何在只讀模式下打開數據庫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"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 數據庫自動執行以下步驟：
Database closed
數據庫關閉
The database is mounted, but online data files and redo log files are closed.
數據庫仍處於裝載狀態，但數據文件和聯機重做日志文件已被關閉。
"How a Database Is Closed" explains this stage.
"數據庫是如何關閉的"解釋了這一階段。
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.
"數據庫是如何卸載的"解釋了這一階段。
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 數據庫管理員指南》了解如何關閉數據庫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
數據庫行為
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 命令
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.
數據庫的關閉操作是在數據庫停機中的一個隱含步驟。該操作的性質取決於數據庫停機是正常還是非正常的。
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.
這一階段中，該數據庫是關閉的，且無法進行正常操作訪問。在數據庫關閉後，控制文件仍保持打開狀態。
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 數據庫自動執行。
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 數據庫關閉數據庫的控制文件。這個時候，實例仍將保留在內存中。
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 數據庫管理員指南》關於關閉數據庫的更詳細的信息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)"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
確保在一致的關閉過程中所有已提交的數據都被寫入磁盤
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 中的全局檢查點信息
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.
實例恢復是將聯機重做日志中的記錄應用到數據文件，以重建最近檢查點之後所做更改的過程。當管理員嘗試打開一個之前以不一致方式關閉的數據庫時，會自動執行實例恢復。
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"
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
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 timeThe 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
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 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 數據庫提供了許多初始化參數，以優化其在不同環境中的操作。只需要顯式設置幾個參數，因為其默認值對大多數情況已經足夠。
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.
數據庫管理員可能會對可變參數特別感興趣，因為他們可以使用這些參數來提高數據庫性能。
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
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
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
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
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
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 (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。
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 infrastructureThe 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 0The following sections describe the contents of ADR.
以下各節描述了 ADR 的內容。
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=10335As shown in Example 13-1, query V$DIAG_INFO to locate the alert log.
如例 13-1 所示，通過查詢 V$DIAG_INFO 來定位警報日志。
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".
跟蹤文件是一個管理性文件，其中包含用於調查問題的診斷數據。此外，跟蹤文件也可以為優化應用程序或實例提供指導，如"性能診斷與調整"所述。
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
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) 文件。這些文件包含跟蹤文件的相關結構信息，並用於搜索和導航。
