重做日志和闪回日志
闪回日志和重做日志的区别有：
首先从功能方面，闪回日志，仅作用于闪回数据库；而重做日志作用可大了，这里就不在赘述了（网上可以查查）。
然后是记录的连续性，闪回日志是不连续的定期记录块前向，而重做日志则做持续性记录。
从对象范围而言，闪回日志只记录更改后的数据，而重做日志则记录数据库所有活动，包括DDL操作。
*上述两点可从上图看出
从创建与维护，初始中，闪回日志既无需DBA创建也不用DBA维护，它由OMF自动于闪回恢复区所指定的目录中创建。
并通过分配储存位置给予空间。
从目标性质方面，使用闪回日志还原至块前向，而重做日志则执行前滚介质恢复。
从原理上，闪回日志不是由常规的日志写进程（LGWR）写入，而由RVWR（一个单独为闪回日志写进程而使用的）（Recovery Writer）写入，重做日志当然由日志写进程执行写入。
另一方面，在9i和10g（不包括11g）中闪回日志不能和重做日志一样进行自动归档，而是由单独的日志组记录，循环使用。
并且闪回日志不能进行手工更改（除非禁用掉闪回数据库，系统自动删除所有闪回日志文件），无法作用于DDL 操作。
使用时配合重做日志、控制文件执行还原。
并且闪回日志可用性并不像重做日志那样强，如果必要时系统会自动删除闪回日志文件，以获得足够空间为其它事务提供工作区。
最后一点是闪回日志是块级记录，因而效率不如重做日志。
写入相当的更改记录自然更浪费空间。
oracle数据库闪回
而闪回技术提供了从逻辑错误中恢复的更有效和更快的方法，多数情况下，在用这种技术进行恢复时数据库仍然联机并对用户可用。此外，闪回技术允许选择性地复原某些对象。使用传统的技术，从某种意义上说某有选择，只能恢复整个数据库。
SQL> conn rocky/rocky
已连接。
SQL> select * from emp;
EID NAME SEX ID
---------- ---------- ----- ----------
aa bb B 11
闪回数据库
闪回数据库的条件
1、 数据库日志系统必须在归档模式下。
2、 如果丢失了一个数据文件，或者由于某种原因不能使用特定的数据文件，则不能使用闪回数据库进行恢复。
3、 如果已经在想闪回的时间范围内复原或重建了一个控制文件，则不能使用闪回数据库特性。
4、 不能闪回一个数据库到RESETLOGS操作之前。
def hykdddd
defgdbbea hykdddd
SQL>
注意：回收站中的对象只能进行查询，任何的DML操作将不起作用。
恢复被删除的表
只要回收站中列出被删除的表，就可以使用命令恢复它。
FLASHBACK TABLE table_name TO BEFORE DROP
还有：
清除整个回收站：purge recyclebin
除回收站中的单个表：purge table test_drop
上述命令将从USERS表空间中删除单一用户scott的所有对象（以及存在于其他表空间中的所有依赖对象）。
ORACLE11g试题答案(陈冬亮)
目录第一章 Oracle 11g 介绍......................................... 错误!未定义书签。
第二章 ORACLE 11g 的体系结构................................... 错误!未定义书签。
第三章 ORACLE 11g 的数据库管理................................. 错误!未定义书签。
第四章 ORACLE 11g 的表空间管理................................. 错误!未定义书签。
第五章 ORACLE 11g 的表管理..................................... 错误!未定义书签。
第六章 ORACLE 11g 的数据查询................................... 错误!未定义书签。
第七章 ORACLE 数据的基本操作................................... 错误!未定义书签。
第八章索引 ................................................... 错误!未定义书签。
第九章视图 ................................................... 错误!未定义书签。
第十章 PL/SQL基础............................................. 错误!未定义书签。
第十一章存储过程与函数........................................ 错误!未定义书签。
第十二章触发器 ............................................... 错误!未定义书签。
第十三章游标 ................................................. 错误!未定义书签。
Oracle目录结构
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-原理
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存储引擎的事务⽇志。
rman备份与恢复数据库
再执行BACKUP DATABASE指令备份整个数据库。
(1)使用数据库用户名和密码登陆RMAN
D:\>rman target system/oracle@orcl
(2)在RMAN执行程序中，通过客户端指令关闭数据库，
然后从RMAN加载数据到MOUNT状态。
RMAN>shutdown immediate
RMAN>startup mount
(3)使用BACKUP DATABRMAT参数说明备份的全库
（3）将数据库处于归档模式。
使用BACKUP DATABASE联机备份整个数据库
RMAN>backup database；
在备份整个数据库时，其实就是备份了数据文件，
其中包含了当前的控制文件和参数文件。而重做日志文件或归档日志文件
因此oracle建议创建单独的恢复目录，
这样可以更好的发挥RMAN提供的新特性。
快闪恢复区（flash recovery area）
快闪恢复区是存储与备份和恢复数据文件以及相关信息的存储区。
快闪恢复区保存了每个数据文件的备份，
增量备份，控制文件备份，以及归档重做日志备份。
信息库既可以存储在数据库的控制文件中，
也可以存储在恢复目录中。
在oracle中默认先将RMAN信息库写入控制文件，
如果存在恢复目录则需要继续写入到恢复目录。
使用控制文件的不足是控制文件中记录RMAN信息库的空间有限
当空间不足时可能被覆盖掉。
（2）控制文件
（3）数据库文件和控制文件的映像副本
（4）归档日志文件
云和恩墨大讲堂- ASM详解
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事务日志与崩溃恢复机制解析
MySQL事务日志与崩溃恢复机制解析数据库系统是现代应用领域中必不可少的一部分，它承载着大量的业务数据。
然而，由于各种原因，数据库在运行过程中可能会出现崩溃情况，这将导致数据的丢失和一系列的问题。
为了保证数据库的可靠性和数据的完整性，数据库管理系统（DBMS）必须具备一定的崩溃恢复机制。
本文将详细解析MySQL数据库中的事务日志和崩溃恢复机制。
一、事务与事务日志事务是数据库管理系统中的基本操作单元，它由一系列的数据库操作语句组成，要么全部执行成功，要么全部回滚，保证了数据库的一致性和完整性。
在MySQL 中，事务日志用于记录事务执行的过程和状态，以便在发生崩溃时进行崩溃恢复。
1. 事务日志的类型MySQL中的事务日志包括两种类型：重做日志（Redo Log）和回滚日志（Undo Log）。
重做日志用于记录已经执行的事务对数据库的修改，而回滚日志则用于撤销未提交的事务对数据库的修改。
重做日志的作用主要在于当数据库因为崩溃导致数据丢失时，通过事务日志中记录的修改操作，来重新执行事务，将数据库恢复到崩溃前的状态。
回滚日志则用于保证事务的原子性和一致性，当事务执行失败或者回滚时，通过回滚日志中的记录来撤销已经执行的事务对数据库的修改。
2. 事务日志的格式事务日志通常以磁盘文件的形式存在，MySQL中的事务日志文件名通常以"InnoDB log"开头，后面跟着一串数字和扩展名。
事务日志文件由一系列的日志块组成，每个日志块的大小通常为512字节。
每个日志块由多个日志记录组成，每个日志记录包含了一个事务对数据库的修改操作，如插入、删除、更新等。
日志记录中除了保存了对数据库的修改操作，还包含了一些元信息，如事务ID、操作类型等。
二、崩溃恢复机制1. 崩溃的定义崩溃是指数据库系统在运行过程中突然停止或者遇到严重错误导致无法继续执行的情况。
MySQL数据库的崩溃可以分为软件崩溃和硬件崩溃两种情况。
Oracle重做日志文件管理技巧
Oracle重做日志文件管理技巧Oracle重做日志文件管理技巧重做日志文件是Oracle数据库中一种非常重要的日志文件，也是其一个很有特色的功能。
重做日志文件会纪录对于数据库的任何操作，如利用DML语句或者DDL语句对数据进行更改，或者数据库管理员对数据库结构进行更改，都会在重做日志中进行记录。
可见，当数据被意外的删除或者修改，我们可以利用重新日志文件进行恢复;当出现例程失败或者介质失败的情况下，也可以利用日志文件实现例程恢复或者介质恢复。
所以说，我们若能够管理好重做日志文件的话，对于保障数据库数据的安全是非常重要的。
下面笔者谈谈管理好Oracle数据库日志文件的几点经验技巧，或许，能够给大家在重做日志文件的管理中带来一些启示。
一、合理确定重做日志文件的存放位置我们知道，当数据库内部数据丢失或者被意外更改的情况下，数据库管理员可以利用重做日志文件实现数据库数据的恢复工作。
当数据库出现意外事故，如硬盘物理损坏、数据丢失时怎么办?我们第一个就会想到利用数据库重做日志对数据进行恢复。
可是当数据库重做日志跟数据库数据文件放在同一个硬盘的话，很明显，当硬盘损坏的时候，数据文件将跟日志文件共赴黄泉。
此时，连天皇老子都救不了我们。
所以，此时，我们就有必要把重做日志文件跟数据库数据文件放在两个不同的硬盘上面。
此时，任何一个硬盘若发生损坏，我们都可以凭借另外一块硬盘的数据，来挽回损失。
如存放数据文件的硬盘损坏时，我们就可以利用存放在另外一块硬盘上的数据重做日志文件进行修复，挽回损失。
鸡蛋不能放在同一个篮子里，故重做日志文件与数据文件也不要放在同一块硬盘上。
那时非常危险一个动作。
其实，这个重做日志文件就跟数据库的备份文件类似。
我们在对数据库进行备份的时候，都知道需要进行异地备份。
可惜的是，很多数据库管理员，在进行Oracle数据库管理的时候，没有注意到这一点，结果当出现问题的时候，就来不及了。
故，对于数据重做日志文件，保存时，要跟数据库备份文件一样，进行异地保存。
redo 日志相关
Redo日志重做日志文件(REDO LOGFILE)又被称为事务日志文件(TRANSACTION LOGFILE)。
它对ORACLE 数据库来说是至关重要的。
ORACLE中每执行一条更新操作时，都会引起数据库的变化，因此都会生成一定数量的重做日志，他们将被记录到重做日志文件中。
以便在数据库出现例程失败或介质故障时，可以利用重做日志文件来恢复数据库。
一、重做日志文件概述重做日志文件是ORACLE三类文件中最为复杂的一类。
在ORACLE 10G安装完毕后，会自动创建3个重做日志文件。
重做日志文件主要以重做记录的形式记录、保存对数据库所作的修改(或事务)。
如果在一段时间内只对数据库进行了查询操作，则不产生重做日志记录信息。
如果对一个表的数据进行了修改，并完成了事务的提交，这时数据文件只存储修改后的数据，但重做日志文件中要记录两类数据:一类是修改前的数据；一类是修改后的数据。
所以重做日志文件的管理方式与数据文件的管理方式有所不同。
(一)重做日志文件的作用与目的重做日志文件在数据库的恢复过程中起着非常重要的作用，可以用来进行例程和介质恢复，以及事务的撤销。
1.数据库运行不正常，如由于断电而出现的例程失败，或者是由于磁盘损坏而出现的介质失败时，都能够实现例程恢复或介质恢复。
其中介质恢复需要借助于归档日志文件；2.数据库运行正常时，由于不正确的删除或修改了某条记录、某个表，甚至表空间时，能够实现事务的撤销。
在撤销时要借助于撤销表空间或撤销段。
(二)重做记录重做日志文件是由一条一条重做记录组成的，重做记录(REDO RECORD)是有一个个修改向量(CHANGE VECTOR)组成的。
每个修改向量记录了对数据库中的某个数据块所作的修改。
重做记录记录了可以用来对数据可进行恢复的所有修改的数据，包括回退段。
因此，重做日志文件同样也会保护回退数据。
当使用重做日志文件来进行数据库恢复时，ORACLE将读取其中的重做记录(包括其中的修改向量)，并且将这些修改用于相关的块中。
RMAN技术在ORACLE 10g数据库中的应用
算法后就可以用你的私人密匙解密再把它发送给服务器。用这种方
ACLE9i 相比， OraclelO 的Rman 新功能 g 体现在以 下几个方面:
1、增量备份 执行增量备份的最重要的原因是: 与数据仓库环境关联起来， 在该环境中许多操作都是在 NOLOGGING 模式下执行的，并且数据 更改不会涉及到存档的日志文件。因此，不可能发生介质恢复。考 虑到今天的数据仓库的巨大规模，以及其中的大部分数据并没有发 生改变的事实，就会知道执行完全备份既不值得又不实际。相反， 在 RMAN 中执行增量备份是一个理想的选择。 在 RM 备份进行时，每个数据文件中的每个块都被读人内 AN 存并检查，以确定自上次备份以来其内容是否曾被改变，只有那些 自上次备份以后发生改变的块才会被真正写人备份设备。这项功能 使 RMAN 备份上一次同级别或者更低级别的增量备份以后发生变化 的数据块。例如，在第一天执行了一次全备份 (level- 0 ) ，在第二、 三天执行了两次增量备份 (level- 1) 。后面两次备份仅仅备份在第一 天和第二天之间变化的数据块、第二夭和第三天之间变化的数据块，