DBCA工具建库，默认会创建3份控制文件。

控制文件管理数据库的状态。

控制文件记录着数据库的名称，数据库的物理布局。


ckpt进程更新控制文件信息，反映系统状态。而这些信息在下一次启动数据库时又会被用来校验数据库的一致性。


数据库的正常运行过程中，控制文件的内容也会时时进行更新，以反映数据库的变换。


日志文件中记录的是redo records，redo records又是由change vectors（改变向量）组成的。每个redo records代表着一个数据块发生的变化。

一个事务会涉及多个数据块内容改变，所以会包含多个redo record。


redo records会记录如下内容：
事务的开始时间
事务的名称
对象名称（比如表名）
数据被更新前的状态，也叫前镜像（before Image）
数据被修改后的状态，也叫后镜像（after Image）
commit标记：事务是否提交（包括commit rollback）



事务生成的redo records最初保存在SGA中的redo log buffer中，很快就会被写到redo log file中，触发这个写操作的原因：
用户执行commit操作
累计的redo log达到1M
redo log buffer使用超过了总容量的1/3


redo record记录了数据的前镜像和后镜像，所有对于只有开始时间而没有提交标志的事务就必须回滚，提交的事务就保持后镜像即可，最终数据库达到了一致性状态。



oracle数据库的日志文件分成两类:联机日志文件和归档日志文件

LGWR进程会不断的向redo log中写入日志内容，LGWR必须确保向组内所有成员的写操作都是成功的。


联机日志是以一种循环的方式工作的，早前记录的日志会被较新的日志覆盖掉，较新的日志最终被更新的内容覆盖。



归档模式下，LGWR进程能够覆盖一组联机日志文件的前提是，这组联机日志已经完成归档。



如果数据库宕机，日志中的内容（包括已经结束和未结束的事务）都要重新应用到数据文件上，这个过程叫做前滚roll-forward。


前滚的结果是吧数据恢复到数据库宕机时的状态，但是数据库宕机时刻，数据库里还有很多没有完成的用户事务-未决事务，对于这些事务，数据库统一做回滚处理，这个过程就叫做回滚roll-back


前滚是利用日志内容完成的，回滚是以undo表空间为基础的。


日志文件（包括联机日志、归档日志）是oracle数据库高可用性的基础。


一个数据库实例使用的联机日志就叫做一个日志线程（redo thread）。
select thread# from v$log;



参数文件是用来存放数据库初始参数配置，比如SGA的大小，控制文件的位置等。

oracle获得参数文件的方法如下：
当前的环境变量ORACLE_SID的值
在$ORACLE_HOME/dbs目录下寻找参数文件，寻找顺序是spfile<ORACLE_SID>.ora spfile.ora init<ORACLE_SID>.ora
可见oracle首先群钊的是数据库的spfile，其次是通用的spfile，最后才是pfile


初始化参数文件中，参数可以分成以下几组：
（1）这组参数必须和数据库的实际情况完全匹配
undo_management
undo_tablespace
db_block_size
db_name
instance_name
(2)这组参数用于指定控制文件的位置
control_files
(3)这组参数是定义目录位置，这些目录用于保存数据库运行过程中产生的一系列日志文件。对于数据库的正常运行而言，只要这些目录存在，oracle用户有权限在这些目录中创建文件就可以了
audit_file_dest
backgroud_dump_dest
core_dump_dest
user_dump_dest
log_archive_dest_1
(4) 完整的初始化参数列表还包括其他很多参数


通过参数文件配置的参数可以分成两种：动态和静态
动态参数是可以在数据库运行起见随时修改，并立即生效；
静态参数虽然可以修改，但是必须重启数据库才能生效；


每个oracle数据库都需要有一个alert日志文件，文件位于参数BACKGROUP_DUMP_DEST指定的目录下，文件名的格式为alert_dbname.log
oracle使用这个文件来记录数据库运行过程中发生的重大事件，比如启动 关闭 日志切换 添加数据文件，启动期间，这个日志中还会记录所有的参数值，
所以管理员可以根据alert日志重建参数文件
运行期间发生的各种错误都会记录于此，在故障诊断阶段这个文件是管理员诊断分析的最佳起点。
grep ORA- alerttestdb.log 查看




trace文件
oracle有3类跟踪文件：内核跟踪文件  后台进程跟踪文件 用户跟踪文件
            core_dump_dest   background_dump_dest  user_dump_dest


内核文件是数据库内核运行中生成的
后台进程跟踪文件是DBWR LGWR这些后台进程产生，通常是在进程运行发生异常时产生，这时不仅会产生trace文件，在alert日志中也会记录
用户跟踪文件更多是由于用户主动触发产生的。比如用户跟踪event 审计数据库，产生的就是用户跟踪文件




数据块变化跟踪文件block change tracking file
oracle利用这个文件记录从上次全量备份以来所有发生变化的数据块。这样rman再做增量备份时，就不必扫描整个数据库，只需通过这个文件就可以找到所有需要备份的数据块。



DBA进行不完全回复的几个步骤：
1 关闭数据库
2 找到最后一次备份的文件，然后从备份中还原所有数据文件restore
3 利用归档日志进行不完全恢复recover，要尽可能的回恢复到执行错误操作之前那个时间点
4 打开数据库，做一个全备

上述2步骤是最耗时且无法跳过的步骤，flashback database使用一种完全不同的架构回避了这个问题，flashback database功能使我们可以快速的把整个数据库倒转到之前的某个时间点，而不必进行耗时的还原操作。


传统的备份恢复依赖于联机日志、归档日志。
flashback database利用了一种新的日志机制，即flashback log。


这种全新的日志文件必须放到一个特殊的目录位置，并且这些文件也是由oracle自动维护的
要想使用flashback database 数据库必须做一些特殊的配置


oracle数据库文件布局方式有两种:用户管理  oracle管理（OMF）
用户管理由DBA决定每个文件放在哪个磁盘，哪个目录，定义文件名以及文件大小。
oracle管理


oracle缺删除表空间时是不会同时删除磁盘文件的。必须drop tablespace test including contents and datafiles;
oracle创建表空间时，必须明确指定数据文件的位置，才能创建成功。
OMF解决了上述两个问题，要想使用OMF，要配置以下3组参数
DB_CREATE_FILE_DEST:定义一个缺省的目录，创建数据文件、临时表空间文件时，如果没有明确的指明文件路径和名称，新文件就被创建在这个目录下；如果定义了这个参数，而没有定义DB_CREATE_ONLINE_LOG_DEST_n参数，则联机日志和控制文件也会创建在这个目录下。
DB_CREATE_ONLINE_LOG_DEST_n（n=1-5）：最多可以定义5个缺省目录，如果创建联机日志、控制文件时没有明确定义文件路径和名称，则文件就会在这些目录下创建，如果定义了多个目录，则自动实现复用multiplexed功能。
DB_RECOVER_FILE_DEST:定义一个缺省目录。在使用rman工具进行备份时，如果没有指明备份集的格式，则备份文件保存在这个目录下。归档日志的自动管理也是使用这个目录。和DB_CREATE_ONLINE_LOG_DEST_n参数，则联机日志和控制文件也会创建在这个目录下


使用OMF后，创建数据文件或日志文件时就不再需要考虑文件位置 大小等属性，OMF会自动保证这些文件被创建到预定义的目录下。同时在删除表空间或日志组时这些文件也就同时删除了。

读书笔记