1、Oracle11g数据库数据量有50T，每天增量50g左右，该如何制定备份方案，如何验证备份的有效性？
50T的数据也不大，运营商的地市级市数据基本都在100T以上了，只要备份环境允许的话，也能在12h内备份完成。
以一次全备份来算，在12h内备份完成，那么平均备份速度最低是
5010241024/12/3600=1210MB/S
按照LTO 5 drive的速度（140MB/S）来算，备份最低的drive数量：1210/140=9
为了保障dive尽量保持最大IO，建议额外关注几点：
1，datafile较小的话，聚合成较大的bakcup piece
2，调整read/write blocksize减少读写次数，可酌情调整至MB大小
3，调整备份脚本，一个channel对应一个backup session，每个channel尽量保障只有一个大块backup piece写入
4，关闭备份软件和drive的多路复用功能，保证每个dive上只有一个session写入
5，备份尽量走单独的HBA卡，不要和业务或存储共用
备份策略的话，一个完整的备份周期肯定是FULL+INCR+INCR比较符合实际情况，如果条件允许Synthetic Full也是一个很不错的选择。归档看需求，4h或者6h备份频率都可以。
相关案例：
某地市数据库，大概数据量90T，备份从4块独立的16 GB HBA走，每块HBA绑2个LTO 5物理drive，备份起8个channel，每个channel对应一个bakcup piece，每个bakcup piece都聚合为500 GB，R/W blocksize为2MB，多路复用关闭。
2、Oracle的数据库备份，一般采用数据泵将库和数据备份，这样安全吗？一般是各一个周备份一次。
安全这个词在这里的定义比较模糊。
1.expdp/impdp是逻辑备份，备份的过程中也可以使用加密从而保证数据的安全。
2.也正是因为这种方式是逻辑备份，不论你才用多久的时间间隔来备份，两次备份过程中有数据丢失都无法通过这种方式恢复到数据丢失的那一刻。
想要保证数据可以恢复到任意时刻建议使用rman；如果每隔一段时间想要保存一下数据某时间点的快照的话，使用数据泵和rman都行。
3、如何设计oracle数据库的备份与恢复的时间窗口？都需要做都那些方面的考虑？
先说备份，需要着重考虑几点：
1，备份方式：根据实际数据保护需要，确定备份方式，一般都是FULL+INCR。条件允许就全FULL。其次就是备份频率，一个FULL后追加多少个INCR，归档多久备份一次。
2，备份时间窗口：备份的过程中对生产业务（数据库）压力是很大的，所以首先应该规划备份的时间窗口，一般都在晚上。
3，备份流量路径：确定了备份时间窗口，就想想备份的流量怎么走。LAN-FREE备份好说，LAN备份就要特别留意了，备份前先拉着网络的哥们交流下感情，最终确定好流量路径，不要影响其他业务。
4，数据保留、克隆：对于重要的数据，不仅需要备份，最好克隆一份。出入库看实际需求了。
恢复一般在单独的恢复环境，所以没什么需要特别注意的。
4、RMAN备份和数据泵备份的比较，适用范围？
RMAN是oracle推荐的数据保护工具，在备份恢复上，RMAN能够借助备份数据恢复一段时间范围内某个时间点数据库的状态。此外RMAN在备份恢复的校验上更加严格，最大程度保护数据的完整性、一致性以及适用性，同时也方便备份恢复的统一管理。
EXP/EXPDB，在oracle的定位中，只是一个数据迁移的手段。在备份恢复上，数据泵只能利用备份数据来恢复一个时间点上的数据库状态，无法借助备份数据在一段时间内自由选择恢复点。在严格的意义说，数据泵备份并不能说是一种有效的数据保障措施，这更像是一种临时的保底操作。
5、Oracle数据库备份及恢复那种方式更简单！更快捷？exp/imp 还是rman或是其他方式？
应该按照系统的RTO的要求上来看，逻辑导出和RMAN配合使用，exp的方式因为要放到本地或者放到本地之后上传到服务器，这种比较占用磁盘空间，但是在一些跨平台恢复上exp又是可以的。rman主要还是防止逻辑错误，搭配备份软件，进行数据的集中管理较多。
集中化备份管理来说，rman是最有效也是最可靠的方式。exp、expdb虽然操作简单，对于数据的持续性保护太弱了~
6、ORACLE数据库该如何设定防范逻辑错误的备份策略和备份方案？
逻辑错误有很多中解决办法，使用备份恢复是最有效的一种，但是大多时候并不是最优的一种方法。
如果要使用备份等话，那就建议保留所有的归档日志，除了备份恢复，还可以使用Oracle数据库的闪回功能，比如：闪回查询，闪回表，闪回事务和闪回数据库等操作。
7、很多时候Oracle备份或恢复都是由oracle结合第三方备份软件完成，在备份恢复的过程当中时不时的会遇到备份恢复的速度比预想的要差很多，如何定位是oracle设置的问题还是备份软件的方面的原因？
性能排查无外乎源、路径、目标这三点，第三方备份软件可以看做在“路径”上的管理员，调度数据从源到目标。
源端问题，存储问题就从存储读直接写到null看读速度，写就直接生产随机数据写存储。
路径问题，从源内存直接生产随机大数据写备份介质（drive一般不会有性能瓶颈）或者直接做rman的validate验证恢复
目标端问题，drive一般只需检查物理状态。AFTD文件类型设备检查其存储性能问题，方法如上。
8、针对不同业务系统采用的数据库备份策略是怎么样的？定期恢复验证的周期为多久？
备份方式无外乎FULL INCR Synthetic Full
备份环境极好，只用FULL备份，恢复速度最快。
备份环境稍好，FULL +INCR +Synthetic Full，恢复速度适中。
备份环境有限，FULL +INCR +INCR，恢复速度一般。
对于FULL+INCR（Synthetic Full）这种方式，INCR次数不建议太多（INCR较大的数据库建议INCR次数不超过3），否则恢复速度会大打折扣。
现在厂商还宣传一种特殊的备份方式：Virtual synthetic full backup
这种备份方式，利用传统的FULL+INCR进行，Virtual synthetic full backup时在备份介质上将FULL +INCR整合成一个相当于实际的FULL对外提供恢复服务。
恢复验证周期，一般一个季度内至少挑选各类型备份恢复一次。
恢复环境好，恢复验证频率可以为一个月一次，每次都真实恢复。
恢复环境稍好，适当降低恢复验证频率，挑选重要系统备份真实恢复，其余做oracle validate恢复或者scan tape。
恢复环境一般，在连续的多个备份周期内至少能对一个完整周期的备份进行oracle validate恢复或者scan tape。
9、一个数据库实例下面有十几个用户，如何实现分用户备份各自的数据，不用一个一个exp?各用户如何实现并发备份？
Oracle Rman无法实现分用户备份，但可以折中处理：备份用户对应的所有表空间数据。
Oracle Rman是通过channel和复用来实现并发备份的，具体语法参考RMAN手册。
10、在三地两中心的双活结构中，oracle的数据库双活如何进行安装部署，在这种情况下还有数据库备份的必要性吗？ODG和ADG在这种数据库备份环境中该如何操作呢？
数据库双活了更需要数据库备份，否则数据库逻辑错误，一损俱损，都没得恢复了。。ORACLE备份不就是RMAN或者数据泵，备到存储或磁带，保持一份最新的数据，防治数据库逻辑错误。
多活只能保障单边故障下业务还可以online（高可用），但对于数据逻辑错、历史数据审查、历史数据分析等问题，多中心多活的结构框架依旧无法克服。
的确，从另外一方面，数据库双活了，应用同样需要双活。切换时还需要考虑是直接切换到异地的机房，还是在原机房进行恢复。
11、Oracle 备份保留参数主要是两个：一个是保留的天数，另一个是保留的副本数。那么这两种情况具体有什么区别，在什么场景下使用什么样的参数设置呢？
前者主要考虑的方面是：想要把数据库恢复到历史的哪一个时间点；后者主要考虑的方面是：要针对备份如何做冗余
Configure retention policy to recovery window of N days;
表示备份保留N天，即表示oracle可以保证还原到N天内的任意时间点。
CONFIGURE RETENTION POLICY TO REDUNDANCY n
表示备份保留N份。
区别就是基于恢复窗口的保留策略纬度不同，看你的具体需求 磁盘窨 备份策略 来选择不同的参数设置
12、大家的Oracle备份环境中，是否建设有Catalog数据库用于存放备份记录啊？还是直接使用的控制文件？在备份和恢复中，Catalog的主要优势在哪？哪些是必要因素说明必须要建设Catalog数据库？
1.rman的备份信息默认是存放在目标数据库的控制文件中的,存放时间由control_file_record_keep_time参数控制,默认是7天;同时,也可以把rman的备份信息保存到一个独立的数据库中,叫做recovery catalog;
2.使用recovery catalog可以保存更长时间的备份信息,当目标数据库的控制文件丢失时非常有用;
3.recovery catalog可以保存多个目标数据库的备份信息,可以保存RMAN stored scripts(类似于存储过程,就是一系列rman脚本);另外如果想要试用永久保留备份的话,必须使用catalog;
4.如果只是简单的备份管理需求的话,建议使用控制文件即可,因为如果使用recovery catalog的话,意味着还要对其它的数据库做备份管理,Licence费用;所以,只有在使用recovery catalog带来的好处比较大时才使用。
13、Oracle 有很多表和视图用于性能分析和故障诊断，哪些表可以用于备份恢复异常时的性能诊断？
select s.status as "备份状态",
b.INPUT_TYPE as "备份类型",
to_char(b.START_TIME,'yyyy-mm-dd hh24:mi:ss') as 总的开始时间,
to_char(b.end_time, 'yyyy-mm-dd hh24:mi:ss') as 总的结束时间,
trunc(b.ELAPSED_SECONDS/60,0) as 耗时多少分钟,
b.INPUT_BYTES_PER_SEC_DISPLAY "in_sec/s",
b.OUTPUT_BYTES_PER_SEC_DISPLAY "out_sec/s",
trunc((s.END_TIME-s.START_TIME)2460,0) "单个文件备份用时(分)",
to_char(s.START_TIME, 'yyyy-mm-dd hh24:mi:ss') as "开始备份时间",
to_char(s.END_TIME, 'yyyy-mm-dd hh24:mi:ss') as "结束备份时间",
s.OPERATION as "命令",
trunc(s.INPUT_BYTES/1024/1024,2) as "INPUT-M",
trunc(s.OUTPUT_BYTES/1024/1024,2) as "OUTPUT-M",
s.OBJECT_TYPE as "对象类型",
s.MBYTES_PROCESSED as "百分比",
s.OUTPUT_DEVICE_TYPE as "设备类型"
from v$rman_status s,v$rman_backup_job_details b
where to_char(s.START_TIME, 'yyyy-mm-dd hh24:mi:ss') < to_char(sysdate,'yyyy-mm-dd hh24:mi:ss')
and to_char(s.END_TIME, 'yyyy-mm-dd hh24:mi:ss') > to_char(sysdate-7,'yyyy-mm-dd hh24:mi:ss')
and s.COMMAND_ID=b.COMMAND_ID
order by s.START_TIME desc ;
select s.status as 备份状态,
trunc((s.END_TIME-s.START_TIME)2460,0) "备份用时(分钟)",
to_char(s.START_TIME, 'yyyy-mm-dd hh24:mi:ss') as 开始备份时间,
to_char(s.END_TIME, 'yyyy-mm-dd hh24:mi:ss') as 结束备份时间,
s.OPERATION as 命令,
trunc(s.INPUT_BYTES/1024/1024,2) as "INPUT/M",
trunc(s.OUTPUT_BYTES/1024/1024,2) as "OUTPUT/M",
s.OBJECT_TYPE as "对象类型",
s.MBYTES_PROCESSED as 百分比,
s.OUTPUT_DEVICE_TYPE as "设备类型"
from v$rman_status s
where to_char(s.START_TIME, 'yyyy-mm-dd hh24:mi:ss') < to_char(sysdate,'yyyy-mm-dd hh24:mi:ss')
and to_char(s.END_TIME, 'yyyy-mm-dd hh24:mi:ss') > to_char(sysdate-7,'yyyy-mm-dd hh24:mi:ss')
order by s.START_TIME desc ;
14、现有数据库为oracle rac，想搭建一套完全实时互备的数据库，能做DataGuard吗？如果可以那么scanip 和VIP、sid和原库能保持一致吗？如不行那么有什么能实现以上功能？
完全可以在现有环境下搭建adg。
scanip，VIP，sid都不能一致，但是数据库唯一名必须一致，这是adg的配置条件。
15、如果Orace数据库的RAC在建设的时候，归档没有放在共享或者ASM上，只是在单边存放，那么这种的Oracle数据库备份大家一般都怎么做？两边都备份？还是mount NFS？哪种更好些？
归档还是建议放在共享存储上，不太建议单边存放。一是方便管理，二是简化备份流程。
若是单边存放，只能在每个节点上单独备份各自的归档。
对于归档数据量较大的场景，不太建议NFS。如果允许，能共享尽量共享
