轻松掌握什么是数据的物理（存储）结构

数据结构在计算机中的表示（映像）称为数据的物理（存储）结构 它包括数据元素的表示和关系的表示

物理结构 即oracle数据库使用的 *** 作系统文件结构 对于数据库物理结构文件 不同的oracle版本 不同的 *** 作系统平台上有不同的存储目录结构

winnt　| d:oracleproduct oradataDB_NAME * *(oracle g)d:orantdatabase* *(oracle oracle ) Unix | /home/app/oracle/product/ /oradata/DB_NAME/* * ( g)/home/app/oradata/db_name/* *( i i)

数据库的物理结构文件按其作用可以分为三类

数据文件

日志文件

控制文件

一 数据文件

数据文件用来存储数据库的数据 如表 索引等 读取数据时 系统首先从数据库文件中读取数据 并存储到SGA的数据缓冲区中 这是为了减少I/O 如果读取数据时 缓冲区中已经有要读取的数据 就不需要再从磁盘中读取了 存储数据时也是一样 事务提交时改变的数据先存储到内存缓冲区中 再由oracle后台进程DBWR决定如何将其写入到数据文件中

查询数据文件的信息

sql>select * from dba_data_files或 sql>select * from v$datafile (此数据字典包含文件的动态信息)

一个数据文件只与一个数据库相联系 数据文件的大小是可以改变的 可以通过以下语句查询表空间的空间空闲量

sql>select * from dba_free_space

修改数据文件的大小

sql>alter database datafile "d: df dbf" resize m

数据库文件的自动扩展特性 请看下面的例子:

sql>alter tablespace tbs add datafile "d: df dbf" size m autoextend on next m maxsize m sql>alter database mydb datafile "d: df dbf" "d: df dbf" autoexetend off sql>alter database mydb datafile "d: df dbf" "d: df dbf" autoexetend on next m maxsize unlimited

二 重做日志文件

重做日志文件记录对数据库的所有修改信息 它是三类文件中最复杂的一类文件 也是保证数据库安全与数据库备份与恢复有直接关系的文件

日志文件组与日志成员

在每一个oracle数据库中 至少有两个重做日志文件组 每组有一个个或多个重做日志文件 即日志成员 同一组中的成员是镜像关系 它们存储的内容是一模一样的 Oracle在写日志时 以一个日志组为逻辑单位写入 只在将日志都写入日志组中的每个成员文件中后 写日志才完成

日志工作原理

Oracle有多个日志文件组 当一个日志文件组中所有的成员所有的成员同时被写满数据时 系统自动转换到下一个日志文件组 这个转换过程称为日志切换

当日志切换后 会给前一个日志组编一个号 用于归档日志的编号 这个编号称为日志序列号 此编号由 开始 每切换一次 序列号自动加 最大值受参数MAXLOGHISTORY限制 该参数的最大值为

当oracle把最后一个日志组写满了以后 自动转向第一个日志组 这时 再向第一个日志组写日志的时候 如果数据库运行在非归档模式下 这个日志组中的原有日志信息就会被覆盖

使用以下语句查询日志文件信息

sql>select * from v$log

相关字段说明如下

GROUP#:日志文件组号

THREAD#:日志文件线程号 一般为 双机容时为

SEQUENCE#:日志序列号

BYTES:日志文件大小

MEMBERS:该组的日志成员个数

ARC:该组日志信息是否已经完成归档

STATUS:该组状态（CURRENT:表示当前正在使用的组 NACTIVE:表示非活动组 ACTIVE:表示归档未完成）

FIRST_CHANGE#:系统改变号SCN 也叫检查点号

FIRST_TIME:系统改变时间

DBA可以使用下列命令进行强制日志切换

sql>alter system switch logfile

NOARCHIVELOG/ARCHIVELOG

NOARCHIVELOG是非归档模式 如果数据库运行在这种模式下 当日志切换时 新切换到的日志组中的日志信息会被覆盖 ARCHIVELOG:归档模式 如果数据库运行在这种模式下 日志会被归档存储 产生归档日志 且在未归档之前 日志不允许被覆盖写入

要确认数据库的归档方式 可以查询数据字典v$database:

sql>select log_mode from v$database

要了解归档日志的信息 可以查询数据字典v$archived_log

要将数据库改为归档模式

a alter database archivelog

b 设置初始化参数LOG_ARCHIVE_START=TRUE

c 设置归档文件目标存储路径 LOG_ARCHIVE_DEST=C:ORAARCHIVE

d 设置归档文件命名格式参数 LOG_ARCHIVE_FORMAT="ORCK%T%S ARC" 这个格式中的%S表示日志序列号 自动左边补零 %s表示日志序列号 自动左边不补零 %T表示日志线程号 左边补零 %t表示日志线程号不补零

e 重新启动数据库

CKPT进程(检查点进程)

CKPT进程保证有修改过的数据库缓冲区中的数据都被写入到数据文件 日志文件 数据文件 数据库头和控制文件中都有写入检查点标记 数据库在恢复时 只需提供自上一个检查以来所做的修改 检查点完成时系统将更新数据库数据库头和控制文件

参数LOG_CHECKPOINT_TIMEOUT决定一个检查点发生的时间间隔 LOG_CHECKPOINT_INTERVAL决定一个检查需要填充的日志文件块的数量 检查点号 也称系统改变号(SCN) 它标识一个检查点 可以通过v$log查询日志文件的检查点信息 通过v$datafile查询数据文件的检查点信息 通过v$database查询数据库头的检查点信息 三个地方的检查点号相同 如果不同 说明发明数据库不同步 此时数据库肯定无法正常启动

增加与删除日志文件组 日志成员(详细语法请参考oracle文档)

alter database [database] add logfile [group integer] filespec[ [group alter database [database] add logfile ( ) alter database [database] drop logfile [grout integer] alter database　[database] add logfile member "filespec" [reuse] to group integer alter database [database] drop logfile member "filename" "filename" alter database [database] rename file "filename" to "filename

"

清除日志文件数据

alter database [database] clear [unarchived] logfile group integer|filespec

三 控制文件

控制文件是一个二进制文件 用来描述数据库的物理结构 一个数据库只需要一个控制文件 控制文件的内容包括

数据库名及数据库唯一标识

数据文件和日志文件标识

数据库恢复所需的同步信息 即检查点号

控制文件由参数control_files指定 格式如下

control_files=("home/app/ /control ctl" "home/app/ /control ctl")

参数中各个文件是镜像关系 也就是说 几个文件中只要有一个文件完好 数据库就可以正常运行

以下语句查询控制文件的信息

sql>select * from v$controlfile

如果控制文件损坏或丢失 数据库将终止并且无法启动 所以 要对控制文件进行镜象 手工镜像步骤如下

a 关闭数据库

b 复制控制文件

c 修改参数文件 加入新增的控制文件位置描述

d 重新启动数据库

另外注意 控制文件中还包含几个服务器参数的设置 如果修改这些参数的值 刚需要重新创建控制文件 这些参数是

MAXLOGFILES:最大日志文件个数

MAXLOGMEMBERS:最大日志成员个数

MAXLOGHISTORY:最大历史日志个数

MAXDATAFILES:最大数据文件个数

MAXINSTANCES:最大实例文件个数

所有修改数据库结构的命令都会引起控制文件的改变 同时出会记录在oracle跟踪文件中 跟踪文件的名称为alter_SID log 路径如下

d:oracleproduct adminDB_NAMEdumpSIDALRT log(unix是alter_SID ora)

也可以在参数文件中指定跟踪文件的存储路径 后台进程跟踪文件目录由参数background_dump_dest指定 用户跟踪文件位置由参数user_bdump_dest指定 如

lishixinzhi/Article/program/SQL/201405/30847

Log File物理结构

从 ib_logfile0和 ib_logfile1这两个文件的物理结构可以看出，在Log Header部分还是有些许差异的， ib_logfile0会多一些额外的信息，主要是checkpoint信息。

并且每个Block的单位是512字节，对应到磁盘每个扇区也是512字节，因此redo log写磁盘是原子写，保证能够写成功，而不像index page一样需要double write来保证安全写入。

我们依次从上到下来看每个Block的结构

Log File Header Block

Log Goup ID，可能会配置多个redo组，每个组对应一个id，当前都是0，占用4字节

Start LSN，这个redo log文件开始日志的lsn，占用8字节

Log File Number，总是为0，占用4字节

Created By，备份程序所占用的字节数，占用32字节

另外在ib_logfile0中会有两个checkpoint block，分别是 LOG_CHECKPOINT_1/ LOG_CHECKPOINT_2，两个记录InnoDB Checkpoint信息的字段，分别从文件头的第二个和第四个block开始记录，并且只在每组log的第一个文件中存在，组内其他文件虽然没有checkpoint相关信息，但是也会预留相应的空间出来。这里为什么有两个checkpoint的呢？原因是设计为交替写入，避免因为介质失败而导致无法找到可用的checkpoint的情况。

Log blocks

请点击输入图片描述

log block结构分为日志头段、日志记录、日志尾部

Block Header，占用12字节

Data部分

Block tailer，占用4字节

Block Header

这个部分是每个Block的头部，主要记录的块的信息

Block Number，表示这是第几个block，占用4字节，是通过LSN计算得来的，占用4字节

Block data len，表示该block中有多少字节已经被使用了，占用2字节

First Rec offet，表示该block中作为第一个新的mtr开始的偏移量，占用2字节

Checkpoint number，表示该log block最后被写入时的检查点的值，占用4字节

---