ORACLE存储结构之文件

最新推荐文章于 2024-03-09 07:00:00 发布

c4tch

最新推荐文章于 2024-03-09 07:00:00 发布

阅读量776

点赞数 1

文章标签： oracle 数据库

本文链接：https://blog.csdn.net/weixin_43869703/article/details/126538059

版权

详记ORACLE物理存储之文件

数据文件

在操作系统级别，Oracle 数据库将数据库数据存储在称为数据文件的结构中。每个 Oracle 数据库必须至少有一个数据文件。‘系统和用户数据’，默认以 ‘DBF’ 为扩展名

每个表空间由一个或多个数据文件组成（1对多）
数据库的数据集中存储在位于数据库的每个表空间中的数据文件中（数据总量）
一个段可以跨一个或多个数据文件，但不能跨多个表空间。（1对多）
随着时间的推移，表空间中对象的更新和删除可能会创建一些空白空间，这些空白空间单独不够大，无法重新用于新数据。这种类型的空白空间称为碎片可用空间。(产生碎片)

永久和临时数据文件

永久表空间包含持久性模式对象。永久表空间中的对象存储在数据文件中；
临时表空间仅在会话期间包含模式对象

临时文件类似于永久数据文件，但以下情况除外：

1.永久数据库对象（如表）从不存储在临时文件中。

2.临时文件始终设置为模式，这意味着它们永远不会为它们生成重做。媒体恢复无法识别临时文件。NOLOGGING

3.不能将临时文件设为只读。

4.不能使用该语句创建临时文件。ALTERDATABASE

5.创建临时文件或调整临时文件大小时，并不总是保证为指定的文件大小分配磁盘空间。在 Linux 和 UNIX 等文件系统上，临时文件被创建为稀疏文件。在这种情况下，不是在创建文件或调整大小时分配磁盘块，而是在首次访问磁盘块时分配磁盘块。

在线和离线数据文件

每个数据文件都处于联机（可用）或脱机（不可用）状态。
可以通过使单个数据文件或临时文件脱机或联机来更改它们的可用性。在脱机数据文件联机之前，数据库无法访问这些文件。

由于多种原因，您可能会使数据文件脱机，包括执行脱机备份或阻止损坏。如果数据库无法写入数据文件，则该数据库会自动使该数据文件脱机。

offline数据文件 
非归档 offline drop/offline for drop 
归档下才能不加drop 只用offline

offline表空间 归档和非归档都一样，只加offline

误删数据文件后可以使用该方法离线数据文件使数据库正常好用

实验（非归档模式下）：

------脱机联机数据文件
--模拟意外断电，或者使用了删除命令导致数据文件处于不可用异常
alter database datafile '/home/oracle/omf_data/ORCLCDB/E67BD90ED17718CBE055000000000001/datafile/o1_mf_ts_pdbc_khv9szn0_.dbf' offline drop;

--通过sqlplus管理员登录 恢复数据文件
recover datafile '/home/oracle/omf_data/ORCLCDB/E67BD90ED17718CBE055000000000001/datafile/o1_mf_ts_pdbc_khv9szn0_.dbf';

--将数据文件上线
alter database datafile '/home/oracle/omf_data/ORCLCDB/E67BD90ED17718CBE055000000000001/datafile/o1_mf_ts_pdbc_khv9szn0_.dbf' online;


------脱机联机表空间
//脱机
alter tablespace TS_PDBC offline;

//中间可以对数据库进行维护工作，执行对表空间的脱机备份等

//联机
alter tablespace TS_PDBC online;

表空间脱机后，他的数据文件也会随之脱机


-------移动数据文件，在Oracle 12C之前版本中，数据文件的在线重命名与位置的变动，都需要在数据文件处在offline状态下进行，现在可以在线操作
alter database move datafile '/home/oracle/omf_data/ORCLCDB/E67BD90ED17718CBE055000000000001/datafile/o1_mf_ts_pdbc_khv9szn0_.dbf' 
to '/home/oracle/omf_data/ORCLCDB/E67BD90ED17718CBE055000000000001/datafile/bak.dbf';

控制文件

数据库控制文件是仅与一个数据库关联的小型二进制文件。每个数据库都有一个唯一的控制文件，但允许使用多个相同的副本。

控制文件包含如下信息：

数据库名称和数据库唯一标识符 （DBID）
数据库创建的时间戳
有关数据文件、联机重做日志文件和存档重做日志文件的信息
表空间信息
RMAN 备份

用途

包含有关打开数据库所需的数据文件、联机重做日志文件等的信息

包含数据库未打开时必须可访问的元数据。包含恢复数据库所需的信息，包括检查点（checkpoint)，检查点进程至少每三秒钟在控制文件中记录一次有关联机重做日志中检查点位置的信息

检查点的作用：
1）保证数据库的一致性，这是指将脏数据写出到硬盘，保证内存和硬盘上的数据是一样的。
2）缩短实例恢复的时间，实例恢复要把实例异常关闭前没有写到硬盘的脏数据通过日志进行恢复。如果脏块过多，实例恢复的时间也会过长，检查点的发生可以减少脏块的数量，从而减少实例恢复的时间。


--查看控制文件
select * from v$controlfile;
--列出所有参数的位置和状态信息
select * from v$parameter;
--列出控制文件中记录的部分信息
select * from v$controlfile_record_section;

--列出控制文件的名字、状态、位置等
SHOW PARAMETER CONTROL_FILES;

联机重做日志

恢复最关键的结构是联机重做日志，它由两个或多个预分配的文件组成，记录对数据库所做的修改，比如插入，删除，更新数据等，对这些操作都会记录在联机重做日志里。在实例发生故障后，联机重做日志文件使 Oracle 数据库能够恢复尚未写入数据文件的已提交数据。（写入数据文件的数据，在日志文件里面会清除吗？）

服务器进程将每个事务同步写入重做日志缓冲区，然后 LGWR（Log Writer）进程将其写入联机重做日志。联机重做日志的内容包括未提交的事务以及架构和对象管理语句。LGWR写日志是顺序写，这就解释了一个Orace Server只能有一个LGWR进程，不能像DBWR那样可以有多个，否则就无法保证顺序写的机制，而且可能会产生锁的问题。

个人理解
LGWR负责将日志缓冲内容写到磁盘的在线重做日志文件或组中,DBWn(数据库写进程)将dirty块写到磁盘之前（已提交但是未写入数据文件，这就是redo保存的内容，就能解释前面的问题了），所有与buffer修改相关的redo log都需要由LGWR写入磁盘的在线重做日志文件(组)，如果未写完，那么DBWn会等待LGWR