Oracle数据库学习笔记（三）

最新推荐文章于 2021-04-14 12:47:15 发布

iteye_7742

最新推荐文章于 2021-04-14 12:47:15 发布

阅读量139

点赞数

分类专栏： Oracle 文章标签：数据库运维操作系统

本文链接：https://blog.csdn.net/iteye_7742/article/details/82340683

版权

Oracle 专栏收录该内容

3 篇文章 0 订阅

订阅专栏

Initialization Parameter Files

一个Oracle Instance在启动之前，他必须有一些必要的参数，这些参数称为初始化参数，这些参数保存在一个初始化参数文件中。初始化参数文件就是Oracle在执行启动命令时，这时Oracle会去自动的读取一个初始化参数文件。
初始化参数文件中的参数规定了SGA的SIZE、各个SGA Components的SIZE以及Background Process有几个（即那些启动那些不启动）等信息。

Oracle Instance有两种类型的参数：

显示的参数 ：在参数文件中显示的规定了参数值。
隐式的参数 ：由于Oracle的参数近200个，不可能在参数文件中把参数列全了，如果在参数文件中不体现出来，那么就采用Oracle的默认值。

Oracle Instance的参数文件可以存在多个，可以在启动前去指定Oracle Instance使用哪个参数文件。参数文件里面记录的这些参数，也可以在Oracle Instance运行起来后进行修改，修改的效果不同，有的参数可以修改内存里的参数，有的参数可以把把参数文件和内存中的参数一并修改了，有的参数仅能修改参数文件中的数据。
Oracle Instance有两种类型的参数文件：

静态参数文件 （Static Parameter file PFILE）
持久性服务器参数文件 （Persistent Server parameter file SPFILE）

下图为使用Linux中的oracle用户启动Oracle Instance：

当进入SQL*Plus后输入命令【startup】，这时Oracle就会自动的去读取一个参数文件，并且按照参数文件的规定，启动Oracle Instance。
当Oracle Instance启动起来后，想去查看初始化参数，可以通过Oracle提供的一个视图v$parameter进行查看。下图为该视图的表结构。

下图为查询某一个参数的配置：

使用show parameter命令查询参数的时候可以仅输入命令的前几个字母就行。

在SQL*Plus中可以设置显示模式，例如设置某一列的宽度：
col name format a20 表示name字段显示20个字符
col value format a30 表示value字段显示30个字符

PFILE（Static Parameter file）

PFILE就是一个文本文件，可以使用操作系统自带的文本编辑器去编辑，可以手工进行修改。假设Oracle Instance正在运行，这时修改了PFILE类型的参数文件后，他仅仅是修改了这个参数文件，无法使修改后的参数文件立即生效，只能重启Oracle Instance才可以生效。PFILE在Oracle Instance启动的时候打开。
PFILE在Linux下的缺省目录【$ORACLE_HOME/dbs】，具体可以参考Oracle提供的一个示例文件【init.ora】

      PFILE在Windows下的缺省目录是【$ORACLE_HOME/database】
      Oracle有一个命名惯例，例如：PFILE的惯例就是【initSID.ora】
      一般安装数据库是采用DBCA的方式进行创建（使用该方式创建的数据，在数据库创建完成时，其初始化参数文件也已经创建完毕，使用DBCA的方式默认配置文件为SPFILE），如果需要手工进行安装数据库，并手工去配置初始化参数文件，可以先将其他地方的数据库参数文件拷贝到新安装Oracle的机器上，或者其实在Oracle安装好之后在其目录下有一个提供参考的配置文件实例init.ora文件。需要注意的是拷贝时应注意PFILE的命令惯例。

cp init.ora $ORACLE_HOME/dbs/initdba01.ora

拷贝完成之后，便可以修改初始化参数文件中的参数配置并指定数据库启动时需要读取的初始化参数文件。

需要修改的参数：

db_name 需要修改成与SID相同。
db_block_size 设置Oracle的快的大小一般设置为8192（一般在32位的机器上都设置为8K），如果没有需要新建该属性。
control_files 设置Control文件的路径，需要根据自己的实际情况修改。

由于数据库中自带的init.ora文件是提供与Oracle 8使用的，需要做很多修改，也很容易发生错误，建议最好使用SPFILE的方式。（具体的参数含义可以参考Oracle联机文档）

下图为PFILE Example

SID（Site Identifier）

SID在Oracle中很重要，一个Oracle服务器可以称为一个站点，Oracle在Linux下SGA的表现形式就是共享内存，而共享内存必须有一个unique key（可以理解为内存的实际物理地址的起始地址），SGA通过这个unique key才能attaching到这块共享内存（如果两块共享内存的unique key一样，那么他们就冲突了，如果存在两块共享内存他的unique key一定是不一样的），unique key是由ORACLE_SID和ORACLE_HOME（Oracle软件的安装目录）进行hash得到的数字，作为SGA的unique key。如果环境变量ORACLE_SID或者ORACLE_HOME 设置错误，那么就会引发“ORACLE NOT AVAILABLE ERROR”，同样如果设置错误这两个环境变量，那么就得不到unique key，也就attaching不上共享内存。Windows平台和Linux平台有些不同，Windows的架构是单进程多线程，Oracle在Windows中的表现形式为一个进程中的多个线程，本身线程间的内存就是共享的。Oracle可以在一台服务器上安装好一套Oracle服务器，但可以创建多个数据库，那么数据库之间只能通过SID进行区分（ORACLE_HOME是一致的）。

一般安装Oracle环境变量需要设置一下四个：

ORACLE_BASE Oracle的基目录
ORACLE_HOME Oracle数据库软件的安装目录
ORACLE_SID Oracle的标识名（一般可认为实例名）
PATH=$ ORACLE_HOME/bin: $PATH

SPFILE（Persistent Server parameter file）

SPFILE是从Oracle9版本中引入的，SPFILE就是一个二进制文件，SPFILE不允许手工去维护，只能通过Oracle Server进行维护（一般是通过SQL*Plus输入命令进行修改参数）。SPFILE文件将一直存放于服务器端（例如PFILE并不要求一定在Oracle的dbs目录下，如果是远端启动Oracle Instance那么他就会在客户端去寻找PFILE文件）。Oracle Instance启动或是关闭都可以修改SPFILE里面的东西，修改后都会永久性的存在。利用RMAN（Recovery Manager）进行备份的时候，可以去备份SPFILE文件（RMAN仅能备份SPFILE，对PFILE无作用）。
创建SPFILE可以通过PFILE来创建，假设有一个PFILE，我们就可以根据这个PFILE来创建SPFILE，可以在SQL*plus中输入以下命令：

也可以直接输入【CREATE SPFILE FROM PFILE】，就会自动创建SPFILE到dbs目录下，那么PFILE和SPFILE就会自动按照命名规则取缺省名。
SPFILE可以在Oracle Instance启动前或启动后创建（PFILE和SPFILE之间可以互相转换）。
Oracle有一个命名惯例， SPFILE的惯例就是【spfileSID.ora】

下图为SPFILE Example

在Oracle分布式架构中会出现多个Oracle Instance对应一个Oracle Database。不同的Oracle Instance的区别方式初始化参数文件SPFILE中参数前加上实例名，如果为*则表示适合所有的Oracle Instance。
可以通过以下命令查看SPFILE文件（在Linux中的【strings】命令提取一个二进制文件中的字符串将其显示出来）：

如果需要维护SPFILE中的内容那么就需要登录到安装Oracle的服务器上，利用SQL*plus执行相关的Oracle命令才可以修改SPFILE中的参数值。如下图：

其中<>中的内容是可选项：

<sid=’sid|*’> 前面也提到在Oracle集群中是由多个Oracle Instance对应一个Oracle Database，那么这里如果指明了sid就说明该参数仅针对某个Instance有效。
<scope=memory|spfile|both> 是指本次修改参数的范围，例如PFILE是一个文本文件，可以通过文本编辑器进行修改，修改完成把数据库重启即可。那么在数据库运行期间如果想修改某些参数的内容，这些参数只能保存在内存中，不会把存到PFILE文件中。SPFILE文件中可以选择修改的范围【memory（仅在内存中修改）、spfile（仅在spfile文件中修改）、both（在内存和spfile文件中同时修改）】其缺省选项为both。（如果是采用PFILE启动的scope只能是memory）
<deferred> 参数不是立刻修改，而是在下一次登录的时候才去修改。
<comment=’text’> 表示给修改的参数做的注释。

有时候会发现【dbs】目录下有很多后缀为ora的文件，那么Oracle具体使用那个文件进行初始化操作呢？在Linux操作系统中可以查看一下环境变量ORACLE_SID，Oracle启动要么采用PFILE的方式，要么采用SPFILE的方式，如果在【dbs】目录下符合Oracle参数文件命名惯例并且实例名部分与环境变量ORACLE_SID相同的参数文件则作为Oracle的初始化参数文件。

下面的图片为通过SQL命令修改初始化参数的例子：

Oracle中所有的参数都是存在于v$parameter（下图为v$parameter的表结构）中的，通过alert修改参数时所增加的注释信息就会存储在UPDATE_COMMENT字段中。

在Oracle中的有些参数只能是延迟修改，即使发出了修改参数的命令，当前不生效，在下一次连接进来时才生效，在v$parameter 表中如果字段ISSYS_MODIFABLE值等于deferred就表明，在修改此类参数的时候就必须加上deferred。

具体的修改初始化参数的SQL语句的语法信息可以通过Oracle联机文档查询。

PFILE和SPFILE的区别：

SPFILE可以通过RMAN进行备份，但是RMAN不能备份PFILE
PFILE可以使用任何的文本编辑器去修改，而SPFILE只能通过Oracle Server提供的命令去修改。由于通过命令会去检测语法，所以SPFILE可以提高Oracle的安全性。
如果使用PFILE从远端去启动，是从客户端去读取参数文件，而SPFILE只能保存在Oracle Server端。

SPFILE要比PFILE好一些。

通过以下命令可以实现从SPFILE转换为PFILE，也可以指定创建的文件路径。

Oracle Instance Start or Stop

通过前面的描述存在一个问题，如果Oracle安装目录下的dbs目录下存在多个PFILE和SPFILE文件，怎样确定Oracle Instance启动时使用哪个PFILE或SPFILE。下图为Oracle Instance启动时候寻找并加载初始化参数文件的顺序。

Oracle Instance是通过使用【startup】命令启动的，【startup】命令执行的时候就会读取初始化参数文件，来确定Database Name、SGA SIZE、Control File Path等信息。【startup】命令启动Oracle Instance时寻找并加载初始化参数文件有一个顺序，如果输入【startup】命令优先使用spfileSID.ora，如果不存在spfileSID.ora那么就回去寻找使用Default SPFILE（spfile.ora）,如果未找到Default SPFILE就会去寻找使用initSID.ora文件，如果找不到initSID.ora文件就会去寻找使用Default PFILE（注意Default PFILE不是init.ora）。如果以上前三种文件都找不到的时候，那么就必须在执行【startup】命令的时候手动的指定一个PFILE（也就映射到了Default PFILE）。
下面是在执行【startup】命令的时候手动的指定PFILE，如果在【startup】命令后面指定了PFILE的话，那么优先使用指定的PFILE。需要注意的是可以在【startup】命令后面指定PFILE但是不可以在【startup】命令后面指定SPFILE。

STARTUP PFILE = $ORACLE_HOME/dbs/initdlw.ora

如果想在启动时指定一个SPFILE。可以创建一个PFILE，这个PFILE里面的内容如下图，这样在启动时指定这个PFILE就相当于指定了SPFILE。

SPFILE = /database/startup/spfiledlw.ora

使用ps和ipc命令查看Oracle是否启动，如下图：

下图为dbs中的初始化参数文件：

查询Oracle的环境变量：

根据环境变量以及dbs目录中的文件，发现initdlw.ora和spfiledlw.ora都可以作为Oracle Instance启动文件。但是如果在启动的时候startup后面没有接参数，那么启动时参数文件使用的就是spfiledlw.ora（如下图）。

如果需要在启动的时候指定初始化参数文件，就可以使用前面介绍的startup后接PFILE的方式。下图为创建一个abc123.ora文件，其文件内容如下图：

那么在启动Oracle Instance的时候就可以指定PFILE为abc123.ora，这是实际上使用的还是SPFILE启动。（如果想指定一个非缺省的SPFILE启动，那么就需要创建一个PFILE，在这个PFILE指定SPFILE，在启动的时候去指定这个PFILE）

Who can Start the DB

数据库的启动和关闭是一个非常重大的任务，哪些用户具有启动Oracle Instance的权限可以通过Oracle的联机帮助文档获取信息。

哪些用户能够以管理权限连接到数据库的这些用户才能够有权利执行这个操作。根据操作系统的不同，下面两种情况之一就可以具有对Oracle的管理权限：

如果用户已经拥有了操作系统的特权用户，那么该用户就可以启动和关闭数据库。
如果数据库是基于口令文件的认证（数据库有两种认证：一种是基于操作系统的认证，另一种是基于口令文件的认证。），而且认证成功的用户他同时具有SYSDBA或者SYSOPER这两个权限，那么该用户就可以启动和关闭数据库。

SYSDBA的权限最大，SYSOPER的权限稍小一些，但是他依然可以去启动和关闭数据库。SYSDBA除了可以启动关闭数据库之外，还可以创建数据库、删除数据库。
通过下面的方式进行启动Oracle Instance并没有去输入用户名口令，因为Oracle认为既然该用户可以登录操作系统，也就是说操作系统认为该用户是合法的。所以Oracle就不需要再去认证该用户了。就可以直接输入命令【conn / as sysdba】直接就会连接上来，连接进来执行【startup】命令即可启动数据库。如果是通过远端连接进来的（是指通过远端直接连接数据库）那么这个时候就需要基于口令的认证。

Starting Up a Database

Oracle数据库可以存在于4种状态：

SHUTDOWN ：例如服务器刚启动起来，就是SHUTDOWN状态（Oracle没有启动）。
NOMOUNT ：从SHUTDOWN进入NOMOUNT也就是Instance started（即分配SGA、启动后台进程）
MOUNT ：连接上数据库，但此时仅限于数据库管理员操作数据库。
OPEN ：Oracle数据库可以真正的对外提供服务了。

HOW an Instance is started

当Oracle 数据库启动的时候，他就会去读取初始化参数文件（PFILE或SPFILE），分配内存、启动后台进程，但是没有数据库与他进行连接，启动的时候就会把这些信息写入到日志文件中去，如果在启动过程中出现了问题，可以去参考日志文件去分析问题（也可以根据日志信息中的参数信息去构造一个初始化参数文件），
查看服务器目前处于SHUTDOWN状态，如下图：

接下来输入【sqlplus /nolog】、【conn / as sysdba】这时后台启动了一个连接进程，这时去检查IPCS发现没有内存分配的情况（因为此时还是处于SHUTDOWN状态）。

接下来输入命令【start nomount】这时发现Oracle Instance已经启动（为SGA分配了内存、启动了后台进程），这时没有任何一个数据库与他进行连接（此时已经将初始化参数文件读取进来了），此时便是处于NOMOUNT状态。

此时已经将初始化参数文件读取进来了，就可以通过以下命令查询数据库的初始化参数。并不是所有的参数都可以查询的到，因为有些参数还没有生效。

How a DB is Mounted

Mount的动作就是将一个数据库和一个Instance挂接起来（从NOMOUNT到MOUNT状态，这时需要打开Control File，根据初始化参数文件中的CONTROL_FILE参数去找到Oracle Database的Control File）。首先是找到数据库的Control File，并打开他们，在Control File中又进一步包含了很多信息可以去获取Data File和Redo Log File的相关信息。这个时候数据库还是处于一个关闭状态，这个时候普通的用户并不能去访问数据库，只有管理员才能去访问数据库，管理员可以在这个状态下做一些维护工作（例如：备份、恢复工作）。

如果此时处于NOMOUNT状态，那么可以输入【alter database mount】命令，这时数据库就处于了MOUNT状态。

How a DB is Opened

      进入OPEN状态就是进入了正常工作的状态。Instance会把Control File中指定的这些文件打开（Data File和Redo log File都会被打开）。
      把一个已经挂载的数据库变成打开状态，实际上就是让它处于一个正常工作的状态。现根据Control File里的信息找到Data File和Redo Log File，就是在上次数据库关闭之前，有些表空间处于一个offline（下线状态），那么这时OPEN数据库的时候，那么这些已经处于offline的表空间依然处于offline，可以通过命令将他们变成online（在线状态）。切换成OPEN状态时发现如果没有Data File和Redo Log File那么数据库就会报错。如果此时Data File或Redo Log File出现了损坏或者不存在，那么数据库就是打不开的，那么就需要把它变成MOUNT状态，做一些恢复操作把它恢复到正常状态，才能够将数据库打开。
      输入命令【alter database open】这时数据库就处于了open状态。这时数据库就可以正常的工作了，普通的用户都可以连接进来。

STARTUP command

Oracle Instance的启动命令就是【startup】。如果只输入【startup】命令，就是缺省状态，即：将数据库变成OPEN状态也就是合法的用户可以正常访问的状态。

STARTUP

或在startup命令后面去指定PFILE（使用指定的初始化参数文件去启动数据库）。

STARTUP PFILE=$ORACLE_HOME/dbs/initdlw.ora

startup命令的语法：

参数FORCE：表示强制Oracle启动，有些情况当在Oracle在上次关闭的时候，Oracle没有关闭完整，其表现形式为：数据文件不干净、联机日志文件没有写完整、可能在内存中残留一些东西（例如：IPC资源----共享内存），本次执行startup命令的时候，还是需要使用共享内存，即共享内存需要重新分配，但是此时共享内存已经存在了，那么就会导致数据库启动失败，在此时使用命令【startup force】，就会把所有的历史占用资源全部释放掉，再去启动数据库。
根据前面的描述，通过执行命令【startup nomount】可以把数据库启动到NOMOUNT状态。可以使用以下命令将NOMOUNT状态转换为MOUNT状态。

ALTER DATABASE dlw MOUNT;

或者是把一个Database变成一个只读的状态。如下图所示：

ALTER DATABASE dlw OPEN READ ONLY;

使用命令【alter database】可以将NOMOUNT状态转换为MOUNT状态或者将MOUNT状态转换为OPEN状态，反之则不行。

Restricted Mode

      数据库还有一种状态是Restricted Mode（受限模式），如果数据库管理员将数据库的状态设置为Restricted Mode，那么只能是拥有restrict权限的用户（受限特权的用户），才能够连接到数据库进行操作。Restricted Mode（受限模式）通常用于数据库管理员在维护数据库的时候使用，数据库管理员维护数据库有几种方法：一种是将数据库变为MOUNT状态（但是MOUNT状态执行的命令是有限的），还有一种就是将数据库处于OPEN 状态但是同时处于 RESTRICT状态，在这种状态下只有少数拥有restrict权限的用户才可以连接到数据库进行维护操作。
      Restricted Mode限制新的没有权限的用户登录进来，但是如果一个没有Restricted Mode权限的用户在设置Restricted Mode之前已经登录到了Oracle那么该用户仍然拥有操作数据库的权限，即Restricted Mode不妨碍已经登录进来的用户继续执行操作。
      通过下面的命令将数据变成OPEN状态并且处于RESTRICT状态。

STARTUP RESTRICT

但是如果数据库已经处于OPEN状态，这时执行下面的命令同样可以将数据库变为RESTRICT状态。

ALTER SYSTEM ENABLE RESTRICTED SESSION;

可以参考下面的例子：
启动并登陆到数据库，并创建用户、授权，这时该用户已经具有远程连接的能力。

此时通过该用户远程可以连接到Oracle并且可操作数据库。

此时将数据库设置为RESTRICT状态。

由于前面操作将数据库设置为RESTRICT状态。并且用户仅用于connect和resource权限所以此时无法登陆数据库。

此时使用system用户可以登录，因为system用户具有restrict权限。

使用RESTRICT状态是为了维护数据库，但是此时已经有一些用户连接进来了，这时候想把连接进来的用户踢出去，所有的Session都是放在一张表（v$session）里。下图中选中的会话是后台进程建立的会话（每个后台进程都有一个会话，是内置的）

执行下面的命令可以将SID=141 & SERIAL#=17的这条回话删除。

此时再到客户端执行SQL语句就会报错，如下图：

如果想删除当前会话（自己删自己），会提示无法删除（但是在Unix中试可以自己删除自己的，该操作会导致失去与数据库的连接），如下图所示：

执行下面的命令可以解除Restricted Mode（受限模式），使数据库处于正常状态（OPEN状态）。

Read-only Mode

数据库还有一种状态是Read-only Mode（只读模式），在这种模式下只能做查询，不能做更改，另外也可以做一些管理操作。如果用户做查询操作的时候，需要涉及到一些磁盘操作，必须在Locally Managed Tablespace里面做这个查询操作才能成功，否则查询是失败的。在Read-only Mode（只读模式）下可以把一个Tablespace中的Data File设置为offline或者online状态，但是不能把整个Tablespace设置为offline或者online状态。还可以做一些offline Data File恢复工作。
通过下面的命令将数据READ-ONLY状态。

可以参考下面的例子：
启动数据库，并将数据库设置为Read-only状态。

可以使用普通用户在远程登录，并尝试创建表，数据库提示目前处于只读状态。

Shutting Down the Database

关闭数据库存在几个阶段，与启动数据库是对应的。

Close a Database ：在该阶段是将SGA缓冲区（Database Buffer Cache）里面的数据（脏数据）写到磁盘文件上，保证磁盘文件（Data File 和 Redo Log File）的完整性，然后将处于online状态的Data File和Redo Log File关闭掉。这个时候Data File和Redo Log File都已经关闭掉了，一般的用户已经无法访问了，但是此时Control File仍然处于打开状态。这时管理员可以做一些维护操作。
Unmount a Database ：在该阶段Oracle将Control File关闭掉，但是此时Instance仍然存在，但是这时没有任何一个数据库与他进行连接。
Shut Down an Instance ：在该阶段Oracle将内存释放掉，将后台进程杀掉。

Shut Down Database有以下四种参数：

ABORT ：该模式不允许新用户连接上来（也就是说不允许建立新的连接），对于已经连接上来的用户会话，会强制删除，当用户的事务未执行完毕时将会终止事务并执行回滚操作，但此时数据库文件没有关闭，也没有将缓冲区中的数据写入到磁盘文件，导致会丢失一些数据文件，需要在下一此启动的时候做一些清理工作（Instance Recovery）。该模式一般应用在数据库实在是关闭不了的情况下，在下次启动数据库的时候需要执行Instance Recovery操作（Instance Recovery是由SMON负责的），还有当Oracle Instance Failure（Oracle实例突然宕机）或者是启动时执行的是STARTUP FORCE这种情况下Oracle在启动的时候，都会自动去做Instance Recovery操作，Oracle会使用Redo Log File中的数据，将上一次没有清理干净的事务做一下回滚（用Undo Segment的数据来回滚没有Commit的事务）、资源被释放掉。使用该模式关闭的数据库称为Inconsistent database（不一致的数据库）或dirty database（脏数据库）。

IMMEDIATE ：使用该模式，不允许新用户连接上来（也就是说不允许建立新的连接），对于已经连接上来的用户会话，会强制删除，当用户的事务未执行完毕时将会终止事务并执行回滚操作，该模式会将SGA缓冲区（Database Buffer Cache）中的数据写入到磁盘文件（Data File），并将磁盘文件关闭。

TRANSACTIONAL ：使用该模式，不允许新用户连接上来（也就是说不允许建立新的连接），对于已经连接上来的用户会话，会强制删除，当用户的事务未执行完毕时将会等待事务提交才会继续数据库关闭动作，该模式会将SGA缓冲区（Database Buffer Cache）中的数据写入到磁盘文件（Data File），并将磁盘文件关闭。

NORMAL ：使用该模式，不允许新用户连接上来（也就是说不允许建立新的连接），对于已经连接上来的用户会话，会等待用户自动退出才会继续数据库关闭操作，当用户的事务未执行完毕时将会等待事务提交才会继续数据库关闭动作，该模式会将SGA缓冲区（Database Buffer Cache）中的数据写入到磁盘文件（Data File），并将磁盘文件关闭。

在实践中经常使用IMMEDIATE方式，立即关闭数据库，只是把这些事务回滚掉了，保证数据库关闭是完整关闭、干净的关闭。
使用【shutdown normal】命令关闭数据库可以参考下面的例子：

此时在另外一台主机上，通过SQL*plus远程连接到数据库。

此时，可以通过v$session表查询会话。

此时输入命令【shutdown normal】，这时数据库等待会话退出后才会执行数据库关闭操作。（此时会一直等待下去，直到客户端用户退出）

此时客户端还可以继续做操作。

直到客户端输入【quit】命令，这时数据库才会执行关闭操作。

使用【shutdown transactional】命令关闭数据库可以参考下面的例子

此时在另外一台主机上，通过SQL*plus远程连接到数据库。

此时，通过SQL*plus创建一个表并向该表插入数据。此时这条数据仅在内存了并没有写入到磁盘文件中，因为此时还没有执行【commit】命令。

数据库中有一张表v$transaction，该表记录了当前还没有执行commit的事务。查询该视图，发现还有一个事件是处于ACTIVE状态。

这时在客户端SQL*plus中执行【commit】命令，提交当才的插入操作。这时候再去查刚才的视图，发现刚才处于ACTIVE状态的事件已经消失了。

此时继续插入一条数据（但不执行commit操作）。这时ID为1的这条数据已经写入到了数据文件中了，但是ID为2的这条数据，因为还未执行commit，因此仍然在内存中。

此时执行命令【shutdown transactional】，这时数据库等待事务提交后才会执行数据库关闭操作。

直到客户端输入【commit】命令提交该事务，这时数据库才会执行关闭操作。

Diagnostic Files

目前大部分应用都是Client/Server方式，对于Client/Server方式基本上所有的通讯都是有Client端向Server端发起的，Server端只是等待来自于Client端的请求，所有的处于Server端的后台程序，为了管理和调试都会提供Log File。在Oracle中在源代码里面包含了详细的调试信息，Oracle的Log可以根据设置的Level进行输出（即可以指定输出日志的Level）。
Diagnostic Files （诊断文件）中包含了后台遇到的重大的事件的信息，该文件主要用于帮助数据库管理员进行日常管理。Diagnostic Files是数据库管理员观察和了解Oracle内部运行状态的一个重要的信息来源。

日志文件分为两类：

Alert Log File
Trace File：在Trace File中又分两类一类是Background Trace File，另一类是User Trace File。

下面是Background Trace File和User Trace File的命名规范：

Alert Log File

Alert Log File记录着用户所有的操作，以及重大事情的结果。Alert Log File只有一个文件，每天的操作都可以积累到该文件中（Alert Log File是日积月累的，一旦Oracle启动以后就会创建Alert Log File，该文件的内容是逐渐增长的），并且记录着数据库的错误信息。文件的结构式一个时间戳对应着一个事件，该文件只能被数据库管理员所管理，文件存放的路径由参数BACKGROUND_DUMP_DEST决定。文件名的命名规范是【alertSID.log】。

在Alert Log File中存在一些参数信息，这些参数信息就是PFILE或SPFILE里面的信息。也就是在初始化参数文件里设置的参数，都记录到了Alert Log File里面去了。如果Oracle的PFILE或SPFILE丢失了，那么可以通过Alert Log File里面的这部分内容去构造一个PFILE（构造PFILE的时候需要注意，凡是参数值是字符串的都要加上双引号）。

每次启动Oracle实例的时候都会显示出来下面的信息。高亮选择的地方就代表一次Oracle Instance启动的起点。在此信息之前的信息可以知道上一次shutdown是否是正常的shutdown。

在Alert Log File里面总有一个标志“Starting ORACLE Instance（normal）”这就意味的一个Instance正常启动。那么在他上面的信息可以检查上次关闭是否正常。并且在Alert Log File中把启动时候的初始化参数都记录下来，如果Oracle初始化参数文件丢失或损坏的话，那么就可以使用Alert Log File里面记录的初始化参数信息重新构造一个初始化参数文件。可以参考下面的例子：
通过ps命令查询数据库进程，发现数据库已经启动，如下图：

使用system用户通过SQL*plus工具在本地登录Oracle，如下图：

输入命令【show parameter dump】查询Alert Log File文件的存放路径，如下如：

根据参数值（background_dump_dest），进入该目录，如下图：

通过vi编辑器打开alert_dlw.log文件，从文件的最后一行开始向前查询出现参数的地方，如下图：

将查询出来的参数信息拷贝出来，将这些值和Oracle下面的SPFILE做一下对比，在SPFILE中参数前面都多了一些【*.】（没影响），在SPFILE中的字符串参数值都加上了单引号。

将从Alert File中拷贝出来的参数中参数值是字符串的加上单引号，对于参数control_files的参数值最好在外层加上括号，如下图：

然后将这些内容再拷贝出来，在Oracle的dbs目录下创建一个文件，并将内容复制到该文件中，如下图：

在启动Oracle的时候指定这个新建的PFILE即可。

或者通过PFILE再去创建SPFILE，再通过SPFILE启动都可以。

Background Trace File

Oracle一旦启动一个后台进程，如果进程出现错误，那么他就会把自己的一些Trace信息写入到Background Trace File里面去，文件存放的路径由参数【BACKGROUND_DUMP_DEST】决定。文件名的命名规范是【SID_processname_PID.trc】（只有后台进程遇到错误的时候才会将其写入到Background Trace File中）。Background Trace File是一个进程在生命周期内生成的一个文件，如果一个进程多次启动的话他就会和产生多个不同的文件。（Background Trace File记录着Oracle本身的错误）

User Trace File

如果一个用户连接（Shared Server Mode或Dedicated Server Mode）到后台Oracle，那么后台就会有一个Process与客户端进行连接，如果出现错误，后台进程（Server Process）就会把这个错误信息写入到User Trace File里面去。文件存放的路径由参数【USER_DUMP_DEST】决定。文件的大小由参数【MAX_DUMP_FILE_SIZE】决定。文件名的命名规范是【SID_ora_PID.trc】。除了在用户出现错误的时候将Trace信息记录到User Trace File中，也可以主动的去记录User Trace File，即把任何的操作都记录下来。可以在Session Level和Instance Level两个层面上去做，一般情况下是在Session Level里面做，而不应该在Instance Level里面做。因为如果对一个负荷比较大的数据库，他连接上来的用户会很多，如果每个用户每个动作都要记录下来，那么User Trace File就会急剧的扩大，很可能会把磁盘空间撑爆。

User Trace File记录着单个用户访问数据库的时候，遇到的错误。如果通过命令【ALERT SESSION SET SQL_TRACE = TRUE 】设置User Trace File的参数，那么用户的每一个动作都会被记录下来。可以参考下面的例子：
首先通过命令【lsnrctl start 】将Oracle Listener Process启动起来。如下图：

接着通过【startup】命令将Oracle Instance启动起来。如下图：

如果客户端有一个Connection连接进来，那么在后端必定会有一个进程与之相对应，如下图：

此时，再通过ps查询Oracle的进程发现，已经多出来一个进程【oracledlw (LOCAL=NO)】，表示是远端连接进来的，如下图：

通过输入命令【show parameter dump】查询User Trace File文件的存放路径，如下如：

根据参数值（user_dump_dest）进入该目录，将已经存在User Trace File清空，如下图：

此时在远端的客户端做一些操作，如下图：

再到Oracle服务器端查询，发现仍然没有生成User Trace File，因为目前参数【sql_trace】的参数值仍然为FALSE，而且目前也没有发生错误，所以User Trace File就不会创建，如下图：

此时将参数【sql_trace】改成TRUE，注意这个参数需要在当前Session中设置，如下图：

修改完成后，再用命令【show parameter sql_trace】查询发现，参数值仍然是FALSE，这是因为在当前Session中修改该参数，是无法影响到全局参数设置的，仅对当前Session有效。

此时在远端的客户端做一些操作，如下图：

再到Oracle服务器端查询，发现已经生成User Trace File，如下图：

这时再通过ps命令查询Oracle进程，发现后台进程中负责与客户端进行连接的进程PID与User Trace File的PID一致。

现在通过tail -f命令查看User Trace File（相当于监控该文件），此时在客户端做一些操作，便可以观察该文件的变化，发现User Trace File将文件的解析执行过程都记录下来了，这些关于解析、编译的信息有助于SQL的诊断，如下图：

User Trace File非常有用，他可以精确的跟踪出该会话中每一个命令的详细的信息，SQL_TRACE既可以在Session级别使用，同时也可以使用Oracle的一个包去设置。这些都是在Session级别进行的设置，当然也可以在Instance级别进行设置，在Session级别设置SQL_TRACE的话就会产生大量的Trace信息，那么如果设置Instance级别的时候，那么所有连接上来的用户，他们任何的行为都会被记录下来产生大量的Trace信息，导致Trace信息急剧增加，而且会严重的影响数据库的性能，一般在诊断极其疑难杂症的时候才会去设置Instance的SQL_TRACE参数。一般仅是打开Session的SQL_TRACE参数。问题找到以后再把SQL_TRACE关闭掉。