Oracle+11g+笔记(9)-控制文件及日志文件的管理
9、控制文件及日志文件的管理
Oracle 数据库包含有三种类型的物理文件,分别是数据文件、控制文件和日志文件,其中数据文件是用来存储数
据的,而控文件和日志文件则用于维护和保障 Oracle 数据库的正常运行。 所以保证控制文件和日志文件的可用性
和可靠性是确保 Oracle 数据库正常、可靠运行的前提条件。
9.1 控制文件
控制文件是 Oracle 数据库最重要的物理文件,每个 Oracle 数据库都必须有一个控制文件。在启动数据库实例
时,Oracle 会根据初始化参数定位控制文件,然后 Oracle会根据控制文件在实例和数据库之间建立关联。若控制
文件被损坏,则整个 Oracle 数据库将无法启动。
9.1.1 多路复用控制文件
为了提高数据库的可靠性,至少要为数据库建立两个控制文件,并且分别保存在不同的磁盘中进行多路复用,这样
可以避免由于单个设备故障而无法启动数据库的危险,该管理策略被称为多路复用控制文件。换句话说,多路复用
控制文件是指在系统不同的位置上同时维护多个控制文件的副本,在这种情况下,如果多路复用控制文件其中的某
个磁盘发生物理损坏导致控制文件损坏,数据库将被关闭,此时就可以利用另一个磁盘中保存的控制文件来恢复被
损坏的控制文件,然后再重新启动数据库,达到保护控制文件的目的。在这种情况下,不需要对数据库进行介质恢
复。
在初始化参数CONTROL_FILES
中列出了所有多路复用的控制文件名。Oracle 将会根据CONTROL_FILES
同时修改
所有的控制文件,但只读取其中第一个控制文件中的信息。在整个数据库运行期间,如果任何一个控制文件变为不
可用,那么实例就不能再继续运行。
1、CONTROL_FILES 参数
如前所述,系统通过 CONTROL_FILES
参数定位并打开控制文件,如果需要进行多路复用控制文件,就必须先更改
CONTROL_FILES
参数。CONTROL_FILES
参数的更改需要使用 ALTER SYSTEM
语句:
alter system set control_files=
'D:\app\zhangshixing\product\11.2.0\oradata\eygle\CONTROLO1.CTL',
'D:\app\zhangshixing\product\11.2.0\oradata\eygle\CONTROL02.CTL',
'D:\app\zhangshixing\product\11.2.0\oradata\eygle\CONTROL03.CTL,
'E:\app\zhangshixing\product\11.2.0\oradata\CONTROL04.CTL'
scope=spfile;
其中,前3个控制文件是创建数据库时创建的,第4个控制文件是用户新添加的,并且位于不同的磁盘上,目前还
没有创建该文件,需要关闭数据库来创建。
2、复用控制文件
对CONTROL_FILES
参数进行设置后,需要创建对应的控制文件,达到复用控制文件的效果,其具体操作过程如
下:
Step1
: 退出SQL*Plus
,关闭数据库。
Step2
:打开 Windows的服务窗口,在其中找到相关的服务,即OracleDBConsoleSID
和OracleServiceSID
服
务,将这些服务停止。
Step3
:将原有控制文件复制成新添加的控制文件。
Step4
:重新启动数据库,对数据字典 V$CONTROLFILE
进行查询来确认添加的控制文件是否启用,语法如下,运
行结果如图所示。
SELECT name FROM v$controlfile;
9.1.2 控制文件的创建
在一般情况下,若使用了复用控制文件,且将各个控制文件分别存储在不同的磁盘中,则全部控制文件丢失或损坏
的可能性将非常小。如果数据库的所有控制文件全部丢失或损坏,唯一的补救方法就是手工创建一个新的控制文
件。
手工创建控制文件是使用CREATE CONTROLFILE
语句来实现的。其语法格式如下。
Create controlfile
Reuse database orcl
Logfile
Group 1 ('E:\app\administrator\oradatalorcl\redo01.log' size 10m),
Group 2 ('E:\app\administrator\oradatalorcl\redo02.log' size 10m),
Group 3 ('E:\app\administrator\oradatalorcl\redo03.log' size 10m),
Datafile
'E:\app\administrator\oradatalorcl\example01.dbf'
'E:\app\administrator\oradatalorcl\sysaux01.dbf'
'E:\app\administrator\oradatalorcl\system01.dbf'
Noresetlogs
Maxlogfiles 50
Maxlogmembers 3
Maxinstances 6
Maxdatafiles 200
Archivelog;
下面将对控制文件的创建过程进行介绍。
# step1 查看数据库中所有的数据文件和重做日志文件的名称和路径
# 显示日志文件语句如下
select member from v$logfile;MEMBER |
-------------------------------------------+
D:\APP\ZHANGSHIXING\ORADATA\ORCL\REDO03.LOG|
D:\APP\ZHANGSHIXING\ORADATA\ORCL\REDO02.LOG|
D:\APP\ZHANGSHIXING\ORADATA\ORCL\REDO01.LOG|
# 显示数据文件语句如下
select name from v$datafile;NAME |
-----------------------------------------------------------+
D:\APP\ZHANGSHIXING\ORADATA\ORCL\SYSTEM01.DBF |
D:\APP\ZHANGSHIXING\ORADATA\ORCL\SYSAUX01.DBF |
D:\APP\ZHANGSHIXING\ORADATA\ORCL\UNDOTBS01.DBF |
D:\APP\ZHANGSHIXING\ORADATA\ORCL\USERS01.DBF |
D:\APP\ZHANGSHIXING\ORADATA\ORCL\EXAMPLE01.DBF |
# 显示控制文件语句如下
select name from v$controlfile;NAME |
----------------------------------------------------------+
D:\APP\ZHANGSHIXING\ORADATA\ORCL\CONTROL01.CTL |
D:\APP\ZHANGSHIXING\FLASH_RECOVERY_AREA\ORCL\CONTROL02.CTL|
# Step2 关闭数据库,如果数据库处于打开状态,则可以采取正常模式关闭数据库
connect sys/sysroot as sysdba;
shutdown immediate;
# Step3 在操作系统下备份所有的数据文件和重做日志文件。在使用CREATE CONTROLFILE语句创建新的控制文件时,如果操作不当可能会损坏数据文件和日志文件,因此,需要先对其进行备份。
# Step4 启动数据库实例,但是不加载数据库,加载数据库时,实例将会打开控制文件,无法达到新创建控制文件的效果。
startup nomount
# Step5 利用步骤1得到的文件列表,执行CREATE CONTROLFILE命令创建一个新的控制文件
Create controlfile
Reuse database "orcl"
Logfile
Group 1 'D:\APP\ZHANGSHIXING\ORADATA\ORCL\REDO01.LOG',
Group 2 'D:\APP\ZHANGSHIXING\ORADATA\ORCL\REDO02.LOG',
Group 3 'D:\APP\ZHANGSHIXING\ORADATA\ORCL\REDO03.LOG'
Datafile
'D:\APP\ZHANGSHIXING\ORADATA\ORCL\SYSTEM01.DBF',
'D:\APP\ZHANGSHIXING\ORADATA\ORCL\SYSAUX01.DBF',
'D:\APP\ZHANGSHIXING\ORADATA\ORCL\UNDOTBS01.DBF',
''D:\APP\ZHANGSHIXING\ORADATA\ORCL\USERS01.DBF',
'D:\APP\ZHANGSHIXING\ORADATA\ORCL\EXAMPLE01.DBF'
Maxlogfiles 50
Maxlogmembers 3
Maxinstances 6
Maxdatafiles 200
Noresetlogs
noarchivelog;
提示:如果数据库的某个联机重做日志文件同控制文件一起丢失,或者在创建控制文件时改变了数据库的名称,则
必须在CREATE CONTROLFILE
语句中使用RESETLOGS
子句,重置数据库的联机重做日志文件的内容。如果使用了
RESETLOGS
子句,则必须使用步骤8对数据库进行恢复。
# Step6 在操作系统下,对新建的控制文件进行备份。
# Step7 编辑初始化参数CONTROL_FILES,使其指向新建的控制文件。如果在控制文件中修改了数据库的名称,还需要
# 修改DB_NAME参数来指定新的数据库名称,使用语句如下:
alter system set control_files=
'D:\APP\ZHANGSHIXING\ORADATA\ORCL\CONTROL01.CTL',
'D:\APP\ZHANGSHIXING\FLASH_RECOVERY_AREA\ORCL\CONTROL02.CTL'
scope=spfile
# Step8 根据情况,如果需要可以对数据库进行恢复。否则直接执行步骤9。当丢失了某个联机日志文件或数据文件时,则# 需要对数据库进行恢复。
# Step9 打开数据库,若没有执行恢复过程,则可以下面的方式正常打开数据库
alter database open;
如果在创建控制文件时使用了 RESETLOGS
语句,则可以按下面的方式,即以恢复方式打开数据库。
alter database open resetlogs;
现在,新的控制文件已经创建成功,并且数据库已经被新创建的控制文件打开。
9.1.3 控制文件的备份与恢复
为了提高数据库的可靠性,降低由于丢失控制文件而造成灾难性后果的可能性,DBA 需要经常对控制文件进行备
份。特别是当修改了数据库结构之后,需要立即对控制文件进行备份。
9.1.3.1 控制文件的备份
备份控制文件需要使用到 ALTER DATABASE BACKUP CONTROLFILE
语句。有两种备份方式:一种是备份为二进制
文件,另一种是备份为脚本文件。
# 下面的语句可以将控制文件备份为一个二进制文件,即复制当前的控制文件
alter database backup controlfile to 'd:\backup_controlfile\control_09-05-25.bkp';
# 下面的语句可以将控制文件备份为可读的文本文件
alter database backup controlfile to trace;
将控制文件以文本形式备份时,所创建的文件也称为跟踪文件,该文件实际上是一个 SQL 脚本,可以利用它来重
新创建新的控制文件。跟踪文件的存放位置由参数USER_DUMP_DEST
决定。
show parameter user_dump_dest
SQL> show parameter user_dump_destNAME TYPE VALUE
------------------------------------ ----------- ------------------------------
user_dump_dest string d:\app\zhangshixing\diag\rdbms\orcl\orcl\trace
SQL>
9.1.3.2 控制文件的恢复
当控制文件执行备份后,即使发生磁盘物理损坏,只需要在初始化文件中重新设置CONTROL FILES
参数的值,使
它指向备份的控制文件,即可重新启动数据库。
现在假设参数CONTROL_FILES
所指定的某个控制文件被损坏,该控制文件的目录仍然可以访问,并且有这个控制
文件的一个多路复用副本,可以直接将其副本拷贝到对应目录,无需修改初始化参数,其具体操作步骤如下:
# Step1关闭数据库
connect sys/sysroot as sysdba;
shutdown immediate;
# Step2 通过操作系统命令使用一个完好的镜像副本覆盖掉被损坏的控制文件
# Step3 重新启动数据库
startup
如果因为永久性介质故障的原因,不能访问CONTROL_FILES
参数指定的某个控制文件,并且有这个控制文件的一
个多路复用副本,那么需要修改初始化参数将控制文件指定到新的可访问位置上,其相应的操作步骤为:
# Step1 关闭数据库实例,使用操作系统命令将当前控制文件的镜像副本复制到一个新的可访问位置。
# Step2 编辑初始化参数CONTROL_FILES,用新的控制文件的位置替换原来被损坏的位置。
# Step3 重新启动数据库。
startup
9.1.4 控制文件的查询与删除
9.1.4.1 控制文件的查询
控制文件是一个二进制文件,其中被分隔成许多部分,分别记录各种类型的信息。每一类信息称为一个记录文档
段。控制文件的大小在创建时即被确定,其中各个记录文档段的大小也是固定的。
当对控制文件中的信息进行查询时,需要使用系统提供的数据字典视图。与控制文件信息查询相关的数据字典视图
如表所示。
# 对视图 V$CONTROLFILE_RECORD_SECTION 的查询
select type,record_size,records_total,records_used from v$controlfile_record_section;TYPE |RECORD_SIZE|RECORDS_TOTAL|RECORDS_USED|
----------------------------+-----------+-------------+------------+
DATABASE | 316| 1| 1|
CKPT PROGRESS | 8180| 11| 0|
REDO THREAD | 256| 8| 1|
REDO LOG | 72| 16| 3|
DATAFILE | 520| 100| 11|
FILENAME | 524| 2298| 15|
TABLESPACE | 68| 100| 8|
TEMPORARY FILENAME | 56| 100| 1|
RMAN CONFIGURATION | 1108| 50| 0|
LOG HISTORY | 56| 292| 24|
OFFLINE RANGE | 200| 163| 0|
ARCHIVED LOG | 584| 28| 0|
BACKUP SET | 40| 409| 0|
BACKUP PIECE | 736| 200| 0|
BACKUP DATAFILE | 200| 245| 0|
BACKUP REDOLOG | 76| 215| 0|
DATAFILE COPY | 736| 200| 1|
BACKUP CORRUPTION | 44| 371| 0|
COPY CORRUPTION | 40| 409| 0|
DELETED OBJECT | 20| 818| 1|
PROXY COPY | 928| 246| 0|
BACKUP SPFILE | 124| 131| 0|
DATABASE INCARNATION | 56| 292| 2|
FLASHBACK LOG | 84| 2048| 0|
RECOVERY DESTINATION | 180| 1| 1|
INSTANCE SPACE RESERVATION | 28| 1055| 1|
REMOVABLE RECOVERY FILES | 32| 1000| 0|
RMAN STATUS | 116| 141| 0|
THREAD INSTANCE NAME MAPPING| 80| 8| 8|
MTTR | 100| 8| 1|
DATAFILE HISTORY | 568| 57| 0|
STANDBY DATABASE MATRIX | 400| 31| 31|
GUARANTEED RESTORE POINT | 212| 2048| 0|
RESTORE POINT | 212| 2083| 0|
DATABASE BLOCK CORRUPTION | 80| 8384| 0|
ACM OPERATION | 104| 64| 6|
FOREIGN ARCHIVED LOG | 604| 1002| 0|
通过查询,可以获取控制文件中各个记录文档段的基本信息,包括记录文档段的类型、文档段中每条记录的大小、
记录文档段中能存储的条目数等。
9.1.4.2 控制文件的删除
如果控制文件的位置不再适合时,可以从数据库中删除控制文件,其操作过程为:
# Step1 关闭数据库(shutdown)。
# Step2 编辑初始化参数CONTROL_FILES,使其中不再包含要被删除的控制文件的名称。
# Step3 重新启动数据库(startup)。
以上操作仅仅是将对应控制文件名称从初始化参数中去掉,并没有从磁盘上物理的删除对应文件。若需要,则可以
从数据库中删除控制文件后,使用操作系统命令来删除不需要的控制文件。
注意:删除控制文件时,数据库必须一直拥有两个或两个以上的控制文件,否则数据库将无法启动。
9.2 日志文件
日志文件也称为重做日志文件,是保证数据库安全和数据库备份与恢复的文件,是数据库安全和恢复的最基本的保
障。管理员可以根据日志文件和数据库备份文件,将崩溃的数据库恢复到最近一次记录日志时的状态。日志文件的
管理策略和数据库的备份恢复策略是数据库管理员首先要考虑的问题。
9.2.1 日志组和日志成员
在一个 Oracle 数据库中,至少需要两个重做日志文件组,每组包含一个或多个重做日志成员,一个重做日志成员
物理地对应一个重做日志文件。在现实作业系统中为确保日志的安全,基本上对日志文件采用镜像的方法。在同一
个日志文件组中,其日志成员的镜像个数最多可以达到5个。
通常,DBA 会在创建数据库时按照计划创建所需要的重做日志组和各个组中成员日志文件。但是在一些特殊情况
下,需要通过手工方式为数据库添加新的重做日志组或成员,或是改变重做日志文件的名称和位置,以及删除重做
日志组或成员。
9.2.2 创建重做日志组及其成员
每个 Oracle 数据库都至少需要拥有两个重做日志文件,当一个重做日志文件被写满后,后台进程 LGWR
开始写入
下一个重做日志文件;当所有日志文件都写满后,LGWR
进程再重新写入第一个重做日志文件中。当前正被使用的
一组重做日志文件称为联机重做日志文件。
LGWR
进程结束对当前重做日志文件的使用,开始写入下一个重做日志文件时,称为发生了一次“日志切换”。通常
情况下,在当前的重做日志文件被写满时才会发生日志切换。但是,DBA 可以根据自己的需要通过手工方式强制
进行日志切换。在切换日志时,Oracle 实例将被迫暂停工作,直到LGWR
得到可以使用的重做日志文件为止。
如果发现LGWR
经常处于等待状态,就要考虑为其添加日志组及其成员。要创建新的重做日志组和成员时,用户必
须具有ALTER DATABASE
系统权限。一个数据库最多可以拥有日志组的数量受到参数MAXLOGFILES
的限制。
9.2.2.1 创建重做日志组
要创建联机重做日志文件的新组,可以使用带ADD LOGFILE
子句的ALTER DATABASE
语句。
# 向数据库添加了一个新的重做日志组,
SQL>alter database add logfile ('e:\app\administrator\oradata\orcl\redo04.log','f:\oradata\log\redo04b.log')
Size 10m;
新增的重做日志组具有两个成员,每个成员文件的大小均为10MB。一般情况下,日志文件的大小在10MB到
50MB之间,Oracle默认的日志文件大小为50MB。
在上述的示例中没有为ALTER DATABASE ADD LOGFILE
语句指定GROUP
子句,这时 Oracle 会自动为新建的重做
日志组设置编号,一般在当前组号之后递增。也可以显式地利用GROUP
子句来指定新建的重做日志组的编号。
# 创建新的日志组,并将新的日志组指定为第4组
alter database add logfile group 4(’e:\app\administrator\oradata\orcl\redo004.log',
'f:\oradata\log\redo004b.log') size 10m;
使用组号可以更加方便地管理重做日志组,但是,对日志组的编号必须为连续的,不要跳跃式地指定日志组编号,
否则会耗费数据库控制文件中的空间。
如果要创建一个非复用的重做日志文件,则可以使用如下的语句:
alter database add logfile 'e:\app\administrator\oradata\orcl\redo01.log' reuse;
如果要创建的日志文件已经存在,则必须在ALTER DATABASE
语句中使用REUSE
子句,覆盖有的操作系统文件。
在使用了 REUSE 的情况下,不能再使用SIZE
子句设置重做日志文件的大小,重做日志文件的大小将由已存在的
日志文件的大小决定。
9.2.2.2 创建日志成员文件
在某些情况下,不需要为数据库创建一个新的重做日志组,只需要为已经存在的重做日志组添加新的成员日志文
件。例如,由于某个磁盘发生物理损坏,导致日志组丢失了一个成员日志文件,这时就需要通过手工方式为日志组
添加一个新的日志成员文件。
为重做日志组添加新的成员,需要使用带ADD LOG MEMBER
子句的 ALTER DATABASE
语句。
# 为第1组添加了一个新的成员日志文件
alter database add logfile member 'f:\oradata\log\redo01b.log' to group 1;
此外,也可以通过指定重做日志组中的其他成员的名称,以确定要添加的成员所属的重做日志组。
# 为第2组添加一个新成员
alter database add logfile member 'f:\oradata\log\redo02b.log' to ('e:\app\administrator\oradata\orcl\redo02.log');
9.2.2.3 重新定义和重命名日志成员
在重做日志文件创建后,有时还需要改变它们的名称和位置。例如,原来系统中只有一个磁盘,因此重做日志组中
的所有成员都存放在同一个磁盘上;而后来为系统新增了一个磁盘,这时就可以将重做日志组中的一部分成员移动
到新的物理磁盘中。
修改重做日志文件的名称和位置的具体操作步骤如下:
# Step1 关闭数据库。
connect sys/sysroot as sysdba
shutdown
# Step2 在操作系统中重新命名重做日志文件,或者将重做日志文件复制到新的位置上,然后再删除原来位置上的文件。
# Step3 重新启动数据库实例,加载数据库,但是不打开数据库。
startup mount;
# Step4 使用带RENAME FILE子句的ALTER DATABASE语句重新设置重做日志文件的路径和名称
SQL>alter database rename file
'e:\app\administrator\oradata\orcl\redo03.log',
'e:\app\administrator\oradata\orcl\redo02.log',
'e:\app\administrator\oradata\orcl\redo01.log'
to
'e:\app\administrator\oradata\orcl\redo03a.log',
'e:\app\administrator\oradata\orcl\redo02a.log',
'e:lapp\administrator\oradata\orcl\redo01a.log';
# Step5 打开数据库。
alter database open;
# Step6 备份控制文件。
# 重新启动数据库后,对联机重做日志文件的修改将生效。通过查询数据字典V$LOGFILE可以获知数据库现在所使用的重
# 做日志文件
select member from v$logfile;MEMBER |
-------------------------------------------+
D:\APP\ZHANGSHIXING\ORADATA\ORCL\REDO03.LOG|
D:\APP\ZHANGSHIXING\ORADATA\ORCL\REDO02.LOG|
D:\APP\ZHANGSHIXING\ORADATA\ORCL\REDO01.LOG|
9.2.2.4 删除重做日志组及其成员
在某些情况下,DBA 也许希望删除重做日志的某个完整的组,或减少某个日志组中的成员使其更加对称。如果发
生存放日志文件的磁盘损坏,就需要删除该损坏磁盘的日志文件,以防止Oracle 将重做记录写入到不可访问的文
件中。
(1)、删除成员日志文件
在删除成员日志文件时要注意以下几点:
-
删除成员日志文件后,可能会产生各个重做日志组所包含的成员数不一致。在删除某个日志组中的一个成员
后,数据库仍然可以运行,但是如果一个日志组只有一个成员文件,如果这个成员文件被破坏,数据库将会崩
溃。
-
每个重做日志组中至少要包含一个可用的成员。那些处于无效状态的成员日志文件对于Oracle 来说都是不可
用的。可以通过查询
v$LOGFIIE
数据字典视图来查看各个成员日志文件的状态。 -
只能删除状态为 INACTIVE 的重做日志组中的成员文件。如果要删除的成员日志文件所属的重做日志组处于
CURRENT 状态,则必须执行一次手工日志切换。
-
如果数据库处于非归档模式下,在删除成员日志文件之前,必须确定它所属的重做日志组已经被归档。
要删除一个成员日志文件,只需要使用带DROP LOGFILE MEMBER
子句的ALTER DATABASE
语句。
# 删除4号日志组的第2个成员
alter database drop logfile member 'e:\app\administrator\oradata\log\redo04.log';
(2)、删除整个日志组
如果某个重做日志组不再需要使用,可以将整个日志组删除。删除一个日志组时,其中的成员文件也将被删除。在
删除日志组时,需要注意如下限制:
-
无论日志组中有多少个成员,一个数据库至少需要两个日志组。
-
只能删除处于INACTIVE状态的日志组。如果要删除CURRENT状态的重做日志组,必须执行一个手工切换日
志,将它切换到INACTIVE状态。
-
如果数据库处于归档模式下,在删除重做日志组之前必须确定它已经被归档。可以查询
V$LOG
数据字典视图。
# 查看是否已经对日志组进行过归档
select group#,archived,status from v$log;GROUP#|ARCHIVED|STATUS |
------+--------+--------+1|NO |CURRENT |2|NO |INACTIVE|3|NO |INACTIVE|
要删除一个重做日志组,需要使用带有DROP LOGFILE
子句的 ALTER DATABASE
语句。
alter database drop logfile group 4;
上述语句只是在数据字典和控制文件中将重做日志组的记录信息删除,并不会物理地删除操作系统中相应的文件,
这需要手工在操作系统中将相应的文件删除。
9.2.2.5 清空重做日志文件
在数据库运行过程中,联机重做日志文件可能会因为某些原因而损坏,如果出现了这种情况,数据库最终将会由于
无法将损坏的重做日志文件归档而停止。如果发生这种情况,可以在不关闭数据库的情况下,手工清空日志文件中
的内容,以避免出现数据库停止运行的情况。
清空重做日志文件就是将重做日志文件的内容全部初始化,这相当于删除该重做日志文件,然后再重新创建。在清
空一个重做日志组时,将同时清空该组中所有成员日志文件。要清空一个重做日志文件或日志文件组,只需要使用
带有CLEAR LOGFILE
子句的 ALTER DATABASE
语句。
# 清空2号日志组中的成员文件
alter database clear logfile group 2;
在执行上述语句时必须注意如下两种情况,在这两种情况下不可能清空重做日志:
-
如果仅有两个日志组。
-
被清空的重做日志文件组处于 CURRENT状态。
如果要清空的重做日志文件组尚未归档,则必须使用 UNARCHIVED
子句,避免Oracle 对该重做日志文件组进行归
档。
# 清空未归档的2号日志组中的成员文件
alter database clear unarchived logfile group 2;
9.2.2.6 查看重做日志文件信息
对于DBA 而言,可能经常要查询日志文件,以了解其在使用中的情况。要了解Oracle 数据库的日志文件信息,可
以查询如表所示的数据字典视图。
9.2.3 设置日志自动存档功能
Oracle 数据库有两种日志模式,第一种是非归档日志模式(NOARCHIVELOG
),第二种是归档日志模式
(ARCHIVELOG
)。其中,非归档日志在切换日志时,原日志文件的内容会被新的日志内容所覆盖。而对于归档日志
模式而言,Oracle 会首先对原日志文件进行归档存储,且在归档未完成之前不允许覆盖原日志。
9.2.3.1 归档模式的切换
安装Oracle11g
时,数据库是运行在非归档模式下,从而避免对创建数据库的过程中生成的重做日志进行归档。
当数据库开始正常运行后,就可以将它切换到归档模式下,保证数据库中数据的完全恢复。这时需要将数据库在归
档模式与非归档模式之间进行切换,使用带有ARCHIVELOG
或NOARCHIVELOG
子句的 ALTER DATABASE
语句。
在Oracle 11g
版本中,默认情况下,归档日志会存放到快速恢复区所对应的目录中,并按照特定的格式生成归档
日志文件名。当想要将归档日志放在默认的路径下时,只需执行 ALTER DATABASE ARCHIVELOG
语句,其操作步
骤如下。
# Step1 关闭数据库。
shutdown
# Step 2 重新启动实例,但不加载数据库
startup mount
# Step3 使用 ALTER DATABASE 语句将数据库切换到归档模式,然后再打开数据
alter database archivelog;
alter database open;
# Step4 使用如下的语句查看数据库是否已经处于归档模式
archive log list;
可以看出,数据库已经被置于归档模式,并且已经启用了自动归档,以及归档的重做日志等信息。
9.2.3.2 归档日志信息查询
(1)、归档目标
当归档重做日志时,要确定归档日志文件的保存位置,这个保存位置叫做归档目标。
归档目标由初始化参数DB_RECOVERY_FILE DEST
决定。DBA可以为数据库设置多个归档目标,不同的归档目标最
好存放在不同的磁盘中。
归档目标的设置由设置初始化参数 LOG_ARCHIVE DEST_n
来完成,其中n为1到10的整数,即可以为数据库指定1
到10个归档目标。在进行归档时,Oracle 会将重做日志组以相同的方式归档到每一个归档目标中。设置归档目标
时,既可以指定本地系统作为归档目标(使用LOCATION
关键字),也可以选择远程数据库作为归档目标(使用
SERVICE
关键字)。
# 将归档目标指定为本地系统
alter system set log_archive_dest_1='location='f:\oradata\archive';
# 使用 SERVICE关键字将归档目标指定为远程数据库
alter system set log_archive_dest_2='service='QSY';
其中,QSY
是一个远程备用服务器的服务名。
(2)、ARCHIVE LOG LIST命令
在SQL*Plus
中使用 ARCHIVE LOG LIST
命令,可以显示当前数据库的总体归档信息。
SQL> ARCHIVE LOG LIST
数据库日志模式 非存档模式
自动存档 禁用
存档终点 USE_DB_RECOVERY_FILE_DEST
最早的联机日志序列 23
当前日志序列 25
(3)、数据字典视图查询
如果需要查询更详细的归档信息,需要对系统包含归档信息的数据字典视图进行查询,与其相关的数据字典视图表
所示。
# 通过查询V$DATABASE视图来获知数据库是否处于归档模式
select log_mode from V$DATABASE;LOG_MODE |
------------+
NOARCHIVELOG|
# 查询所有归档目标信息,使用V$ARCHIVE_DEST 视图
select DESTINATION,BINDING ,TARGET ,STATUS from V$ARCHIVE_DEST;DESTINATION |BINDING |TARGET |STATUS |
-------------------------+---------+-------+--------+
USE_DB_RECOVERY_FILE_DEST|MANDATORY|PRIMARY|VALID ||OPTIONAL |PRIMARY|INACTIVE||OPTIONAL |PRIMARY|INACTIVE||OPTIONAL |PRIMARY|INACTIVE||OPTIONAL |PRIMARY|INACTIVE|
# 查询已经启动的 ARCn 进程的状态,使用 V$ARCHIVE_PROCESSES视图
select * FROM V$ARCHIVE_PROCESSES;PROCESS|STATUS |LOG_SEQUENCE|STATE|
-------+-------+------------+-----+0|STOPPED| 0|IDLE |1|STOPPED| 0|IDLE |2|STOPPED| 0|IDLE |3|STOPPED| 0|IDLE |4|STOPPED| 0|IDLE |
9.2.4 监视日志工作
在重做日志文件中记录了数据库中曾经发生过的所有操作,当对重做日志进行了归档,所有已经执行的操作都将被
记录在案。DBA 可以利用这些归档日志将数据库恢复到任意的状态,还可以利用 LogMiner
工具对日志进行分
析,以便对数据库操作进行跟踪和统计分析。
9.2.4.1 LogMiner
LogMiner
分析工具实际上是由一组PL/SQL
包和一些动态视图(Oracle
内置包的一部分)组成,其主要用途如
下:
-
可以离线跟踪数据库的变化,而不会影响在线系统的性能,当数据库发生逻辑错误时,获取发生错误的确切时
间或SCN。
-
回退数据库的变化,回退特定的变化数据,减少
POINT-IN-TIME RECOVERY
的执行。 -
优化和扩容计划:可通过分析日志文件中的数据以分析数据增长模式。
-
监控特定表所做的异动。
-
追踪特定用户的行为。
系统基于LogMiner
对Oracle
日志进行分析,实现数据恢复和数据异常修改追查,以供部门或更高层管理人员对
数据库运作进行监督管理。
LogMiner
提供如下动态视图,用户可以像使用其他视图一样进行查询。
-
V$LOGMNR_CONTENTS
显示日志存储的所有信息,用户从此视图中提取所有数据库的变化信息。 -
V$LOGMNR_DICTIONARY
显示有关LogMiner
字典文件的信息,显示的信息包括数据库名称和状态信息。 -
V$LOGMNR_LOGS
显示有关指定的日志文件的信息,每个日志文件的信息占一行。 -
V$LOGMNR_PARAMETERS
显示有关可选的LogMiner
参数的信息,包括启动和结束系统更改码(SCNS)以及启动和结束时间。
LogMiner
以独享的方式运行,上述视图只有在LogMiner
启动后,才有数据供用户使用,其他会话不能查看上述
视图中的内容。
9.2.4.2 LogMiner的安装
要安装LogMiner
工具,就必须先运行两个脚本:dbmslm.sql
和 dbmslmd.sql
,其所在目录是 :
D:\app\zhangshixing\product\11.2.0\dbhome_1\RDBMS\ADMIN
,且必须均以SYS 用户身份运行。其中第一
个脚本用来创建DBMS_LOGMNR
包,该包用来分析日志文件;第二个脚本用来创建 DBMS_LOGMNR_D
包,该包用来
创建数据字典文件。
start D:\app\zhangshixing\product\11.2.0\dbhome_1\RDBMS\ADMIN\dbmslm.sql
start D:\app\zhangshixing\product\11.2.0\dbhome_1\RDBMS\ADMIN\dbmslmd.sql
SQL> conn sys/sysroot@orcl as sysdbaSQL> start D:\app\zhangshixing\product\11.2.0\dbhome_1\RDBMS\ADMIN\dbmslm.sql程序包已创建。授权成功。同义词已创建。SQL> start D:\app\zhangshixing\product\11.2.0\dbhome_1\RDBMS\ADMIN\dbmslmd.sql程序包已创建。同义词已创建。SQL>
(2)、数据字典的创建
创建字典文件的目的就是让 LogMiner
引用所涉及到的内部数据字典,提供它们实际的名字而不是系统内部的对
象编号。数据字典文件是一个文本文件,用于存放表及对象ID号之间的对应关系。当使用字典文件时,它会在表
名和对象ID号之间建立一对应的关系。如果要分析的数据库中的表有变化,则会影响到数据库的数据字典也发生
变化,这时就需要重新创建字典文件。
如果想要使用字典文件,数据库至少应该处于 MOUNT
状态。然后执行 DBMS_LOGMNR_D.BUILD
过程将数据字典信
息提取到一个外部文件中。其具体操作过程如下:
# Step1 确认设置了初始化参数UTL_FILE_DIR,并确认 Oracle对该目录拥有读写权限,然后启动实例,显示参数
# UTL_FILE_DIR的语句如下
SQL> show parameter utl;NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
create_stored_outlines string
utl_file_dir string
SQL>
提示:参数UTL_FILE_DIR
指定的目录主要用于存放 DBMS_LOGMNR_D.BUILD
过程所产生的字典信息文件。若未设
置该参数,则可以通过如下的语句修改:
alter system set utl_file_dir='f:\oradata\log' scope=spfile;
# Step2 重启数据库(STARTUP)。由于UTL_FILE_DIR参数不是一个动态参数,在为其设置参数值后还需要重新启动
# 数据库来使其生效。
# Step3 执行 PL/SQL 过程 DBMS_LOGMNR_D.BUILD创建字典文件。
execute dbms_logmnr_d.build(dictionary_filename=>'f:\oradata\log\sqltrace.ora',
dictionary_location=>'e:\oradata\log');
9.2.4.3 指定待分析的日志文件列表
在使用LogMiner
进行日志分析之前,必须指定它将对哪些重做日志文件进行分析,LogMiner
可以一次对多个重
做日志文件进行分析。
执行 DBMS_LOGMNR.ADD_LOGFILE
过程可以指定要分析的重做日志文件。利用该过程可以依次添加多个重做日志
文件,或删除已经添加的重做日志文件。下面是指定重做日志文件列表的具体操作步骤:
# Step1 确保数据库例已经启动(STARTUP)
# Step2 通过指定 DBMS_LOGMNR.ADD_LOGFILE 过程的 NEW 选项来创建重做日志文件列表。
# 以下代码将建立一个重做日志文件列表,并向其中添加一个重做日志文件。
SQL>execute dbms_logmnr.add_logfile(logfilename=>'e:\app\administrator
\oradata\orcl\redo01a.log',options=>dbms_logmnr.new)
# Step3 根据需要,使用 ADDFILE 选项继续向列表中添加其他的重做日志文件。
# 比如,利用下面的语句向列表中添加重做日志文件。
SQL>execute dbms_logmnr.add_logfile(logfilename=>'e:\app\administrator\oradata\orcl\redo02a.log',options=>dbms_logmnr.addfile)
# Step4 如果需要,还可以通过指定 DBMS LOGMNR.ADD LOGFILE 过程的REMOVEFILE 选项来删除重做日志文件。
# 下述代码将重做日志文件 REDO02A.LOG从日志文件列表中删除。
SQL>execute dbms_logmnr.add_logfile(logfilename=>'e:\app\administrator\oradata\orcl\redo02a.log',options=>dbms_logmnr.removefile)
提示:DBMS_LOGMNR.ADD_LOGFILE
过程的 OPTIONS
各选项意义为,NEW
表示创建一个新的日志文件列表;
ADDFILE
表示向列表中添加日志文件;REMOVEFILE
与 ADDFILE
相反,表示在列表中删除日志文件。
9.2.4.4 启动 LogMiner
为LogMiner
创建了字典文件,并且指定了要分析的重做日志文件列表后,就可以启动 LogMiner
开始分析日志
文件了。执行 DBMS_LOGMNR.START_LOGMNR
过程将启动 LogMiner
。启动 LogMiner
进行日志分析的操作过程
为:
# Step1 执行DBMS_LOGMNR.START_LOGMNR过程启动LogMiner。执行该过程时,需要在参数DICTFILENAME中指定一# 个已经建立的字典文件。
execute dbms_logmnr.start_logmnr(dictfilename=>'f:\oradata\log\sqltrace.ora');
提示:如果不指定字典文件,那么生成的分析结果中将使用Oracle
内部的对象标识和数据格式,这些数据的可读
性非常差。指定字典文件后,Oracle
会将内部对象标识和数据类型转换为用户可读的对象名称和外部数据格式。
# Step2 如果没有为DBMS_LOGMNR.START_LOGMNR 过程指定其他参数,在分析的结果中将包含重做日志文件的所有
# 内容,因此,还需要对数据进行过滤。
DBMS_LOGMNR.START_LOGMNR
过程提供了基于分析日志时间和SCN的参数。
STARTSCN/ENDSCN
,表示定义分析的起始、结束SCN。STARTTIME/ENDTIME
,表示定义分析的起始、结束时间。
【例】执行 DBMS_LOGMNR.START_LOGMNR
过程,分析2009年1月1日到2009年5月31日的数据。
execute dbms_logmnr.start_logmnr(dictfilename=>'f:\oradata\log\sqltrace.ora',
starttime=>to_date('01/01/2009 00:00:00','dd/mm/yyyy hh:mi:ss'),
endtime=>to_date('05/31/2009 23:59:59','dd/mm/yyyy hh:mi:ss'));
9.2.4.5 分析日志文件
到现在为止,已经分析得到了重做日志文件中的内容。动态性能视图V$LOGMNR_CONTENTS
中包含 LogMiner
分析
得到的所有的信息。分析的结果中包含了执行的SQL语句数据库对象名、会话信息,回退信息以及用户名等。
# 查看 hr 对 employees 表进行过的操作
select sql_redo,sql_undo from v$logmnr_contents where Username='hr' and seg_name='employees';
# 查看最近一段时间对 employees 表进行过的操作
select timestamp,username,session_info,sql_redo,sql_undo from v$logmnr_contents where
seg_name='employees';
需要注意的是,动态性能视图V$LOGMNR_CONTENTS
中的分析结果仅在运行过DBMS_LOGMNR.START_LOGMNR
的会话
的生命期中存在。因为所有的LogMiner
分析结果都存储在PGA
内存中,所有其他的进程是看不到它的。同时,随
着进程的结束,分析结果随之消失。
9.2.4.6 结束 LogMiner
为正确地结束LogMiner
会话,可以使用 DBMS_LOGMNR.END_LOGMNR
过程。
execute dbms_logmnr.end_logmnr;
过程 DBMS_LOGMNR.END_LOGMNR
将终止日志分析务,并且释放PGA
内存区域,分析结果也将随之不再存在。若没
有执行该过程,则LogMiner
将保留所有它分配的资源直到LogMiner
的会话结束为止。