YashanDB 恢复
本文内容来自 YashanDB 官网，原文内容请见 https://doc.yashandb.com/yashandb/23.3/zh/%E6%95%B0%E6%8D%AE%E5%BA%93%E7%AE%A1%E7%90%86/%E5%A4%87%E4%BB%BD%E6%81%A2%E5%A4%8D/SQL%E5%91%BD%E4%BB%A4%E5%A4%87%E4%BB%BD%E6%81%A2%E5%A4%8D/%E6%81%A2%E5%A4%8D.html
操作说明
使用本方式执行恢复时，要求当前数据库实例处于 NOMOUNT 状态。
执行恢复操作的数据库版本需与生成备份集的数据库版本完全一致。
共享集群部署中，只能在主集群上执行恢复操作（即其角色必须为 MASTER_ROLE，可查询视图 V$INSTANCE 的 INSTANCE_ROLE 字段可获得集群中每个实例的角色属性）。
恢复命令仅 SYS 用户才可执行，恢复语法详细说明请参考开发手册RESTORE DATABASE和RECOVER DATABASE。
恢复
# 全量恢复
示例
全量恢复属于完全恢复，成功后可以直接打开当前数据库，对于共享集群需要依次启动其他备集群（查看共享集群启停）。
恢复备份集的并发度默认设置为 2，当备份集数据量大或希望提升恢复效率时，可增大并发度，并发度范围为[1-8]。
如果备份集是加密生成的备份集，在恢复时还需要指定解密密码。
示例
# 基于 tag 增量备份集的连续恢复
在执行增量备份集恢复时需注意如下事项：
假如零级增量备份指定 tag 为 incr_0，普通一级增量备份指定 tag 为 incr_1_1，incr_1_2... （按顺序发起备份）：
当指定 tag 为 incr_1_2 的一级增量备份恢复时，必须保证 tag 为 incr_0 的零级增量备份以及 tag 为 incr_1_1 的普通一级增量备份备份文件保存目录存在且完整，否则将会触发 YAS-00313 错误。
假如零级增量备份指定 tag 为 incr_0，累积一级增量备份指定 tag 为 incr_1_1，incr_1_2... （按顺序发起备份）：
当指定 tag 为 incr_1_2 的一级增量备份恢复时，必须保证 tag 为 incr_0 的零级增量备份备份文件保存目录存在且完整，否则将会触发 YAS-00313 错误。
假如零级增量备份指定 tag 为 incr_0，累积一级增量备份指定 tag 为 incr_1_1，普通一级增量备份指定 tag 为 incr_1_2，累积一级增量备份指定 tag 为 incr_1_3，普通一级增量备份指定 tag 为 incr_1_4... （按顺序发起备份）：
当指定 tag 为 incr_1_4 的一级增量备份恢复时，必须保证 tag 为 incr_0、incr_1_3 的增量备份备份文件保存目录存在且完整，否则将会触发 YAS-00313 错误。
当指定 tag 为 incr_1_3 的一级增量备份恢复时，必须保证 tag 为 incr_0 的零级增量备份备份文件保存目录存在且完整，否则将会触发 YAS-00313 错误。
Note：
相比较原始的备份集恢复，基于 tag 的增量备份集恢复新增两个语法关键字：INCREMENTAL 和 NOREDO，INCREMENTAL 可单独出现，NOREDO 必须和 INCREMENTAL 成对出现。
INCREMENTAL：指定该关键字，恢复完成之后数据库处于 nomount 状态，若要拉起数据库，需要先将数据库拉起至 mount 状态，再执行 recover、open。
NOREDO：指定该关键字，数据库处于不完整恢复，恢复完成之后数据库处于 nomount 状态，不恢复备份集中的 redo 和归档文件，该数据库不可拉起正常使用，若在最后一次恢复增量备份集后要拉起数据库正常使用，不可使用该参数。 如果连续增量备份集中包含 slice 文件，连续 restore 必须严格按照备份生成顺序 restore，若未遵守该规则，可能导致 slice 文件丢失。 如果 restore 失败使用同一个备份集重复 restore，可能会因为已存在 slice 文件导致 restore 失败，这种情况下只能通过手动清除对应 slice 文件后继续执行 restore。
示例
基于 tag 的增量备份集恢复首次必须恢复 LEVEL 0 的备份集，指定 NOREDO 参数可加快恢复速度。
Note：
在此基线恢复成功的基础上，可连续恢复同一数据库的增量备份集。
Note：
最后一次恢复时不可指定 NOREDO 参数。
Note：
执行 RECOVER DATABASE 完成恢复后不可再执行增量备份集恢复。
# 指定时间点恢复
本功能只适用于单机部署的数据库恢复。
示例
本示例执行指定时间点恢复，属于不完全恢复，成功后需重置 redo 时间线。
until time 的时间格式可以为：
'2021-12-09 19:35:55'：此格式需要与当前会话的 DATE_FORMAT 参数所指定格式匹配。TO_DATE('2021-12-09 19:35:55','yyyy-mm-dd hh24:mi:ss')：使用 TO_DATE 函数转换。TO_TIMESTAMP('2021-12-09 19:35:55','yyyy-mm-dd hh24:mi:ss')：使用 TO_TIMESTAMP 函数转换。
SCN 值可通过动态视图获取：
Note：
当 LSC 表在备份集后生成了不可变数据文件时，在以下场景可能导致恢复后该 LSC 表存在数据不一致现象：
数据库原来的不可变数据文件全部存在，但是使用老的时间点恢复，此时该 LSC 表会多出部分不可变数据文件。
数据库原来的不可变数据文件被清理，使用基于时间点的恢复，LSC 表可能丢失存储在不可变数据文件中的数据。
使用恢复场景
场景 1：数据库无法启动
可能发生原因：
控制文件损坏或丢失
系统关键数据文件损坏或丢失
在线日志文件损坏或丢失
恢复方式：
建议采取全量恢复。
场景 2：表误操作
可能发生原因：
delete 或 update 误操作导致表数据被删除或修改
truncate 导致表数据被清空
drop 导致表被删除
恢复方式：
若能及时发现误操作导致数据丢失，建议采取闪回的方式恢复表数据（参考 UNDO_RETENTION/UNDO_FORCE_RETENTION 具体含义）。
delete 或 update 误操作，若 undo 被覆盖，则恢复不一定成功。闪回指令为：
若无法使用闪回的方式恢复，建议采取指定时间点恢复，恢复到表误操作之前的时间点。
场景 3：主备模式下，主库崩溃时备库自动提升为主库，搭建新备库
可能发生原因：
主库操作系统崩溃
数据库关键文件被误删除
网络原因导致无法连接至主库
恢复方式：
若数据量大，建议采用全量恢复的方式重建备库；否则可以采用 build database 方式重建备库。
场景 4：数据迁移
可能发生原因：
主库系统崩溃，需要进行异机恢复
数据库克隆
恢复方式：
全量恢复和指定时间点恢复都能完成数据库恢复，需按照具体要求选择恢复方式。
常见问题
恢复到与备份集不同的数据库文件或日志文件路径（例如 HA 架构中的主备复制）时，需要先设置 DB_FILE_NAME_CONVERT 和 REDO_FILE_NAME_CONVERT 两个配置参数指定文件路径转换。
单机部署中，若 $YASDB_DATA/dbfiles 目录下存在数据库文件，执行恢复将触发 YAS-00311 错误；共享集群部署中则要求+DG0 目录（安装时默认的第一个磁盘组名称，调整为其他值时此处相应修改）下不存在数据库文件，否则将触发 YAS-00311 错误。
Note：
$YASDB_DATA/archive 为存储归档文件的默认目录，若要执行 PITR 恢复操作，需保留该目录下的归档文件，以保证 PITR 恢复操作正常恢复。若要执行全量恢复且仅恢复备份集中的内容，则需要清空归档目录下的文件，否则执行 RECOVER 操作可能回放残留归档文件中的数据，导致实际恢复出的数据与备份集中的不一致。
版权声明: 本文为 InfoQ 作者【YashanDB】的原创文章。
原文链接:【http://xie.infoq.cn/article/5afd13e36ab006c0705938e16】。文章转载请联系作者。
全自研国产新型大数据管理系统 2022-02-15 加入
还未添加个人简介
评论