重做日志和闪回日志
- 格式:doc
- 大小:111.50 KB
- 文档页数:2
目录第一章 Oracle 11g 介绍......................................... 错误!未定义书签。
第二章 ORACLE 11g 的体系结构................................... 错误!未定义书签。
第三章 ORACLE 11g 的数据库管理................................. 错误!未定义书签。
第四章 ORACLE 11g 的表空间管理................................. 错误!未定义书签。
第五章 ORACLE 11g 的表管理..................................... 错误!未定义书签。
第六章 ORACLE 11g 的数据查询................................... 错误!未定义书签。
第七章 ORACLE 数据的基本操作................................... 错误!未定义书签。
第八章索引 ................................................... 错误!未定义书签。
第九章视图 ................................................... 错误!未定义书签。
第十章 PL/SQL基础............................................. 错误!未定义书签。
第十一章存储过程与函数........................................ 错误!未定义书签。
第十二章触发器 ............................................... 错误!未定义书签。
第十三章游标 ................................................. 错误!未定义书签。
Oracle10g的目录结构在安装ORACLE的时候,需要设置Oracle根目录(oracle base directory),Oracle主目录(oracle home directory)和Oracle清单目录(oracle invertory directory)这三个目录,如下图所示,这里我们设置Oracle主目录为c:\oracle\product\10.1.0\Db_1。
如果一台计算机上首次安装Oracle 10g并使用默认设置时,根目录(ORACLE_BASE)的默认位置是c:\oracle\product\10.1.0。
Oracle主目录(ORACLE_HOME)指向根目录的下一级目录,即%ORACLE_BASE%\Db_1。
如果在同一台主机的同一个根目录下安装多个产品或安装了第2次,则Oracle_Home主目录会以db_n的形式出现,即Db_2、Db_3等。
由于安装设置(如安装类型)和安装环境(如是否有其他Oracle数据库)的不同,文件目录结构也可能不同。
我这里安装完成后,其目录结构为:Oracle根目录(Oracle Base Directory)是Oracle的顶级目录,第一次安装Oracle 时,Oracle Universival Installer会提示创建这个目录。
在“注册表”中查找“oracle_base”可以查看oracle的根目录。
Oracle主目录(Oracle Home Directory)是安装特定的oracle产品的目录,单独的oracle产品或者不同版本的oracle数据库,都必须指定一个单独的oracle home目录,oracle home directory必须为oracle base directory 的一个子目录。
Oracle Universival Installer 会提示你指定主目录的路径,默认为ORACLE_BASE/Db_1。
MySQL-重做⽇志redolog-原理【redo log buffer】【redo log file】-原理⽬录:1.重做⽇志写⼊过程图2.相关知识点汇总图3.redo_log_buffer 原理4.redo_log_file 原理1. 重做⽇志写⼊过程:2. 相关知识点汇总:3. redo log buffer 原理重做⽇志缓冲(redo log buffer)是Innodb存储引擎的内存区域中的⼀部分。
【重做⽇志信息--(1)-->redo log buffer--(2)-->重做⽇志⽂件】在(2)中涉及知识:<1>.关于innodb_log_buffer_size的⼤⼩:(默认8M)mysql> show variables like 'innodb_log_buffer_size%';+------------------------+---------+| innodb_log_buffer_size | 8388608 |+------------------------+---------+8388608(Byte)/1024/1024=8M重做⽇志缓冲不需要设置的太⼤,只要保证每秒产⽣的事务量在缓冲⼤⼩范围之内。
因为每秒都会刷新缓冲到⽇志⽂件。
8M⾜够了。
<2>.在以下三种情况下,会将重做⽇志缓冲中的内容刷新到外部磁盘的重做⽇志⽂件中。
1. Master Thread 每⼀秒将重做⽇志缓冲刷新到重做⽇志⽂件;2. 每个事务提交时会将重做⽇志缓冲刷新到重做⽇志⽂件;3. 当重做⽇志缓冲池剩余空间⼩于1/2时,重做⽇志缓冲刷新到重做⽇志⽂件。
4. redo log file 原理<1>.重做⽇志介绍⽇志⽂件名:1.innodb_log_group_home_dir参数指定的⽬录下有两个⽂件:ib_logfile0,ib_logfile12.该⽂件被称为:重做⽇志⽂件(redo log file),记录Innodb存储引擎的事务⽇志。
ASM自动存储管理技术经历多个年头,目前已经广泛使用于各个领域的数据库存储解决方案。
谈到ASM相信大家可能会参杂着熟悉而陌生的感觉,熟悉在于目前大家使用的11g rac中基本都是使用ASM,陌生在于大家平时可能只是基本的使用,对asm了解并不全面,例如:数据库实例是怎么和asm交互和分工的、ASM存在哪些特性、数据库各种文件是怎样放于asm存储中、它的元数据怎么存放等等。
开始接下来我带大家重新全面认识ASM:Oracle10g之前,存储设备的使用情况(在UNIX或者LINUX环境中)如下:●操作系统上安装逻辑卷管理器(LVM);●通过LVM将多个磁盘做成卷组;●在卷组上划分逻辑卷(logical volume);●在逻辑卷上创建文件系统;●Rac环境下需要第三方共享集群软件。
1、Oracle10g之后引入的专用文件系统ASM,为数据库文件的管理提供了很好的支持;2、DBA 能够完全在Oracle 框架内执行许多任务。
利用ASM来将一组磁盘转换成一个高可伸缩的和高性能的文件系统/卷管理器;3、磁盘组提供了直接作为原始设备来访问这个空间,并仍提供文件系统的便利性和灵活性的好处。
RAC环境下的asm结构:ASM的出现是为RDBMS管理文件存储1、ASM中的适合存放文件类型包括:数据文件datafile、控制文件controlfile、重做日志redolog、归档日志archivelog、闪回日志flashback log、spfile、RMAN备份以及block tracking file、datapump文件2、注意ASM不会替代RDBMS去实施IO读写,很多对这一点存在误解,认为RDBMS发送IO request给ASM,ASM去做真正的IO操作,这是错误的。
3、ASM只负责将存储空间地址返回给RDBMS,真正的IO还是由RDBMS进程去完成,和不用ASM的裸设备一样4、因此ASM不是IO的中间层,也就不存在因为ASM而出现所谓的IO瓶颈ASM实例ASM instance的主要任务之一就是管理ASM metadata元数据。
MySQL事务日志与崩溃恢复机制解析数据库系统是现代应用领域中必不可少的一部分,它承载着大量的业务数据。
然而,由于各种原因,数据库在运行过程中可能会出现崩溃情况,这将导致数据的丢失和一系列的问题。
为了保证数据库的可靠性和数据的完整性,数据库管理系统(DBMS)必须具备一定的崩溃恢复机制。
本文将详细解析MySQL数据库中的事务日志和崩溃恢复机制。
一、事务与事务日志事务是数据库管理系统中的基本操作单元,它由一系列的数据库操作语句组成,要么全部执行成功,要么全部回滚,保证了数据库的一致性和完整性。
在MySQL 中,事务日志用于记录事务执行的过程和状态,以便在发生崩溃时进行崩溃恢复。
1. 事务日志的类型MySQL中的事务日志包括两种类型:重做日志(Redo Log)和回滚日志(Undo Log)。
重做日志用于记录已经执行的事务对数据库的修改,而回滚日志则用于撤销未提交的事务对数据库的修改。
重做日志的作用主要在于当数据库因为崩溃导致数据丢失时,通过事务日志中记录的修改操作,来重新执行事务,将数据库恢复到崩溃前的状态。
回滚日志则用于保证事务的原子性和一致性,当事务执行失败或者回滚时,通过回滚日志中的记录来撤销已经执行的事务对数据库的修改。
2. 事务日志的格式事务日志通常以磁盘文件的形式存在,MySQL中的事务日志文件名通常以"InnoDB log"开头,后面跟着一串数字和扩展名。
事务日志文件由一系列的日志块组成,每个日志块的大小通常为512字节。
每个日志块由多个日志记录组成,每个日志记录包含了一个事务对数据库的修改操作,如插入、删除、更新等。
日志记录中除了保存了对数据库的修改操作,还包含了一些元信息,如事务ID、操作类型等。
二、崩溃恢复机制1. 崩溃的定义崩溃是指数据库系统在运行过程中突然停止或者遇到严重错误导致无法继续执行的情况。
MySQL数据库的崩溃可以分为软件崩溃和硬件崩溃两种情况。
Oracle重做日志文件管理技巧Oracle重做日志文件管理技巧重做日志文件是Oracle数据库中一种非常重要的日志文件,也是其一个很有特色的功能。
重做日志文件会纪录对于数据库的任何操作,如利用DML语句或者DDL语句对数据进行更改,或者数据库管理员对数据库结构进行更改,都会在重做日志中进行记录。
可见,当数据被意外的删除或者修改,我们可以利用重新日志文件进行恢复;当出现例程失败或者介质失败的情况下,也可以利用日志文件实现例程恢复或者介质恢复。
所以说,我们若能够管理好重做日志文件的话,对于保障数据库数据的安全是非常重要的。
下面笔者谈谈管理好Oracle数据库日志文件的几点经验技巧,或许,能够给大家在重做日志文件的管理中带来一些启示。
一、合理确定重做日志文件的存放位置我们知道,当数据库内部数据丢失或者被意外更改的情况下,数据库管理员可以利用重做日志文件实现数据库数据的恢复工作。
当数据库出现意外事故,如硬盘物理损坏、数据丢失时怎么办?我们第一个就会想到利用数据库重做日志对数据进行恢复。
可是当数据库重做日志跟数据库数据文件放在同一个硬盘的话,很明显,当硬盘损坏的时候,数据文件将跟日志文件共赴黄泉。
此时,连天皇老子都救不了我们。
所以,此时,我们就有必要把重做日志文件跟数据库数据文件放在两个不同的硬盘上面。
此时,任何一个硬盘若发生损坏,我们都可以凭借另外一块硬盘的数据,来挽回损失。
如存放数据文件的硬盘损坏时,我们就可以利用存放在另外一块硬盘上的数据重做日志文件进行修复,挽回损失。
鸡蛋不能放在同一个篮子里,故重做日志文件与数据文件也不要放在同一块硬盘上。
那时非常危险一个动作。
其实,这个重做日志文件就跟数据库的备份文件类似。
我们在对数据库进行备份的时候,都知道需要进行异地备份。
可惜的是,很多数据库管理员,在进行Oracle数据库管理的时候,没有注意到这一点,结果当出现问题的时候,就来不及了。
故,对于数据重做日志文件,保存时,要跟数据库备份文件一样,进行异地保存。
Redo日志重做日志文件(REDO LOGFILE)又被称为事务日志文件(TRANSACTION LOGFILE)。
它对ORACLE 数据库来说是至关重要的。
ORACLE中每执行一条更新操作时,都会引起数据库的变化,因此都会生成一定数量的重做日志,他们将被记录到重做日志文件中。
以便在数据库出现例程失败或介质故障时,可以利用重做日志文件来恢复数据库。
一、重做日志文件概述重做日志文件是ORACLE三类文件中最为复杂的一类。
在ORACLE 10G安装完毕后,会自动创建3个重做日志文件。
重做日志文件主要以重做记录的形式记录、保存对数据库所作的修改(或事务)。
如果在一段时间内只对数据库进行了查询操作,则不产生重做日志记录信息。
如果对一个表的数据进行了修改,并完成了事务的提交,这时数据文件只存储修改后的数据,但重做日志文件中要记录两类数据:一类是修改前的数据;一类是修改后的数据。
所以重做日志文件的管理方式与数据文件的管理方式有所不同。
(一)重做日志文件的作用与目的重做日志文件在数据库的恢复过程中起着非常重要的作用,可以用来进行例程和介质恢复,以及事务的撤销。
1.数据库运行不正常,如由于断电而出现的例程失败,或者是由于磁盘损坏而出现的介质失败时,都能够实现例程恢复或介质恢复。
其中介质恢复需要借助于归档日志文件;2.数据库运行正常时,由于不正确的删除或修改了某条记录、某个表,甚至表空间时,能够实现事务的撤销。
在撤销时要借助于撤销表空间或撤销段。
(二)重做记录重做日志文件是由一条一条重做记录组成的,重做记录(REDO RECORD)是有一个个修改向量(CHANGE VECTOR)组成的。
每个修改向量记录了对数据库中的某个数据块所作的修改。
重做记录记录了可以用来对数据可进行恢复的所有修改的数据,包括回退段。
因此,重做日志文件同样也会保护回退数据。
当使用重做日志文件来进行数据库恢复时,ORACLE将读取其中的重做记录(包括其中的修改向量),并且将这些修改用于相关的块中。
闪回日志和重做日志的区别有:
首先从功能方面,闪回日志,仅作用于闪回数据库;而重做日志作用可大了,这里就不在赘述了(网上可以查查)。
然后是记录的连续性,闪回日志是不连续的定期记录块前向,而重做日志则做持续性记录。
从对象范围而言,闪回日志只记录更改后的数据,而重做日志则记录数据库所有活动,包括DDL操作。
*上述两点可从上图看出
从创建与维护,初始中,闪回日志既无需DBA创建也不用DBA维护,它由OMF自动于闪回恢复区所指定的目录中创建。
并通过分配储存位置给予空间。
从目标性质方面,使用闪回日志还原至块前向,而重做日志则执行前滚介质恢复。
从原理上,闪回日志不是由常规的日志写进程(LGWR)写入,而由RVWR(一个单独为闪回日志写进程而使用的)(Recovery Writer)写入,重做日志当然由日志写进程执行写入。
另一方面,在9i和10g(不包括11g)中闪回日志不能和重做日志一样进行自动归档,而是由单独的日志组记录,循环使用。
并且闪回日志不能进行手工更改(除非禁用掉闪回数据库,系统自动删除所有闪回日志文件),无法作用于DDL 操作。
使用时配合重做日志、控制文件执行还原。
并且闪回日志可用性并不像重做日志那样强,如果必要时系统会自动删除闪回日志文件,以获得足够空间为其它事务提供工作区。
最后一点是闪回日志是块级记录,因而效率不如重做日志。
写入相当的更改记录自然更浪费空间。