数据库备份

备份方式：

物理备份：冷备份（需要关闭数据库，不常用）、热备份（Rman等）
逻辑备份：exp/imp、expdp/impdp

Oracle的恢复

恢复方式：

实例恢复：是一个自动的过程，不需要人工干预
介质恢复：需要手工发出一些命令进行干预

数据文件恢复的步骤：

shutdown关闭数据库
startup mount将数据库启动到mount状态
操作系统读取物理备份的数据文件
数据文件恢复
alter database open 将数据库启动到open状态
shutdown immediate重启数据库

实例恢复 Crash recovery

当数据库因非正常方式关闭后，再次打开时，需要进行实例恢复：

服务器掉电
操作系统死机
实例异常终止
shutdown abort

实例恢复步骤：

读取redo日志的记录，将redo日志中的数据块修改记录从上到下执行一遍
回滚段、数据文件数据段根据redo日志进行了重构
恢复的数据块被打上commit标签
应用完所有的redo项后，数据块和数据文件的状态和数据库关闭前一致
数据库打开，可以进行正常操作
没提交的事务涉及到的数据块将被回滚

Oracle从什么位置开始恢复

四个SCN：

控制文件记录的系统SCN（System Checkpoint SCN）

select checkpoint_change# from v$database;
-- 也可以通过加hint，指出查询的SCN的来源：控制文件记录的系统SCN
select /*+ control_system_scn */ checkpoint_change# from v$database;

控制文件记录的数据文件SCN（Datafile Checkpoint SCN）

select name,checkpoint_change# from v$datafile;
-- 也可以通过加hint，指出查询的SCN的来源：控制文件记录的数据文件SCN
select /*+ control_datafile_scn */ name,checkpoint_change# from v$datafile;

数据文件自己头部的SCN（Start SCN）

select name,checkpoint_change# from v$datafile_header;
-- 也可以通过加hint，指出查询的SCN的来源：数据文件头记录的SCN
select /*+ file_header_scn */ name,checkpoint_change# from v$datafile_header;

控制文件中记录的数据文件结束的SCN（End SCN）。
数据库open状态时，该值为空。在数据库正常关闭时，会将结束的SCN写入。所以如果数据库再次启动时该值为空，说明上次数据库是异常掉电关闭的，是需要做实例恢复的。
```
select name,last_change# from v$datafile;
-- 也可以通过加hint，指出查询的SCN的来源：控制文件记录的结束SCN
select /*+ control_end_scn */ name,last_change# from v$datafile;
```

什么情况下做什么样的恢复：

无需恢复：在数据启动过程中，当System checkpoint SCN、Datafile Checkpoint SCN和Start SCN都相同，数据库可以正常启动，不需要做media recovery
介质恢复（media recovery）：当System Checkpoint SCN、Datafile Checkpoint SCN和Start SCN中有一个不同时，就需要做media recovery
实例恢复（instance recovery / crash recovery）：当控制文件中记录的文件End SCN号为 NULL 时，则需要做instance recovery

为什么需要有系统SCN：

如果一个表空间是只读表空间，则该表空间的数据文件是不可改变的，这个数据文件的SCN也不再发生变化。所以需要有系统SCN去记录当前其他数据文件已经变化后的最大的SCN。

例如：
系统SCN：5881985  系统SCN记录的是最大的SCN

控制文件记录的数据文件SCN：
SYSTEM01.DBF  5881985
SYSAUX01,DBF  5881985
UNDOTBS01.DBF 5881985
TEST.DBF      5881558    只读表空间的SCN不再变化，还是记录的之前的SCN

数据文件头记录的SCN：
SYSTEM01.DBF  5881985
SYSAUX01,DBF  5881985
UNDOTBS01.DBF 5881985
TEST.DBF      5881558    只读表空间的SCN不再变化，还是记录的之前的SCN

End SCN：
SYSTEM01.DBF  5881985
SYSAUX01,DBF  5881985
UNDOTBS01.DBF 5881985
TEST.DBF      5881558    只读表空间的SCN不再变化，还是记录的之前的SCN

从redo日志的什么位置开始恢复：

在某一点，在这一点之前的所有数据，Oracle都已经成功的写入到了磁盘上。

这个位置在 8i 之前称为 full checkpoint，在它之前的所有数据，都已经被写入到了磁盘上。

在8i 之后，出现了 Mini Checkpoints。

full checkpoint 一次会把之前所有的数据都写入磁盘上，如果此时内存中的数据很多，就非常消耗资源。

Mini Checkpoint没有将所有数据都写入磁盘，而是在redo log的中间加了个 Mini Checkpoint，这一点前面的数据量不是很大，先将这一点前面的数据写入磁盘上，然后将Mini Checkpoint向前移动一段，再将这一段的数据写入磁盘，这样每次只需写很小一部分数据到磁盘上。

当Oracle确认需要进行实例恢复时，从控制文件中取的最后一次Checkpoint点作为恢复的起始点（low rba），一直恢复到redo最后一次写入磁盘的位置（on disk rba）。

rba：redo block address。

数据迁移的方式：

逻辑迁移：

dblink
exp/imp
expdp/impdp

物理迁移：

备份/恢复(rman)
传递表空间
Data Guard
streams
Goldengate

数据泵的方式只能在本库进行导入导出，可以选择并行的方式，效率会比exp/imp要高，而且可以通过job控制进度。

传递表空间：把表空间对应的数据文件从数据库里剥离出来，然后追加到另一个数据库里。

例如：A库中有很多数据，按时间进行了分区，每个区对应表空间。一段时间之后，需要把一些过旧的数据保存到另一个离线的数据库里，就可以把这些过旧的数据分区所在的表空间以传递表空间的形式传递到B库中。

expdp system/password dumpfile=expdata.dmp directory=dump_dir transport_tablespace=sales_1,sales_2 transport_full_check=y

impdp system/password dumpfile=expdat.dmp directory=dump_dir transport_datafiles=/aaa.dbf,/bbb.dbf remap_schema=(aaa:bbb) remap_schema=(ccc:ddd)

数据库学习笔记

07-数据备份和恢复及数据迁移

数据库备份

Oracle的恢复

实例恢复 Crash recovery

Oracle从什么位置开始恢复

数据迁移的方式：