RMAN 系列（一）---- RMAN 体系结构概述
1.3.3 调整SQL
较差的SQL语句操作会对整个数据库和数据库所在的系统产生消极的影响。任何对数据库的消极影响同样会对备份操作产生消极的影响。 我们应当调整SQL 操作， 以减少锁需的I/O数（逻辑上和物理上），并安排在系统空闲时间执行备份操作。
1.3.4 调整环境
要确认备份调度不与I/O密集型数据库操作（如数据加载或报告）冲突。另外，如果备份操作时间过长，就需要考虑使用增量备份策略，同时分析数据库并判断是否存在只读的表空间，这样就不需要经常备份只读的表空间。 如果在归档模式下运行数据库，还可以考虑在不同日期交错备份表空间，以减少整个备份操作的时间， 不过，这个也是以更长的恢复时间为代价的。
1.3.5 调整备份和恢复策略
如果数据库相当大，我们就不能只执行一条backup database命令来备份全部文件集，而应当采用分块备份策略。 可以考虑使用单独的backup tablespace 或者backup datafile命令对可能需要一起还原的相关数据文件进行备份，并且为这些备份分配一个特定的通道，这样可以减少在恢复操作期间交换磁带的次数，可以最快的恢复相关的数据文件。 如：
RMAN>Backup (tablespace tools channel 'ORA_DISK_1') (tablespace system,undotbs,users)
如果要备份一个稍后可能需要恢复的只读表空间，或者要经常对一个表空间执行时间点恢复操作（TSPITR）,就可以执行这样的操作， 这些都是对备份策略的说明。
另一个需要考虑的就是备份策略对恢复操作的影响。 其中，RMAN难以解决的一个文件，就是要使用restore database命令还原一个完成的数据库。 根据使用平台的不同（只针对UNIX 平台，window 情况不一样），必须保证有足够的空间能够用于这个还原操作。 只要有足够的磁盘空间，恢复操作就不会有问题。 但是一旦磁盘磁盘满了，就是一种比较糟糕的情况。
因为还原进程失败时，RMAN会删除在这个还原会话中还原的每个文件。 因此，如果用户花费了2个小时还原了一个数据库数据文件之外的所有文件，而此时磁盘空间耗尽，由于RMAN要删除所有已还原的文件，所以就会前功尽弃，这对DBA来说是不能接受的。
解决这个问题的另一个方案是对每个表空间（或者几个表空间）都使用不同的restore命令，这样就可以以更小的粒度还原数据库数据文件，即使其中一个还原操作失败也不会引起更大的损失。 当然，如果要使用这种操作类型，就应该并行化还原操作，并且利用多个磁盘或磁带，以减少争用和磁带流量问题。 此时，需要运行并行的RMAN会话，每个RMAN 会话还原各自的一组表空间数据。 这种还原操作也是为什么要在同一个通道上备份还原所需的文件群集的一个另一个重要原因，这样我们可以在磁带上快速地读取数据。
刚才说磁盘满的情况是针对Unix的，如果对于Windows，会在启动RMAN 的数据库，数据文件和表空间还原操作前检查可用的空间，这样就不会浪费时间了。