这次还原打（其实是第二次）时放在晚上开始执行，但是之前发生了一个插曲就是之前为了对接ogg项目有开了归档，而在还原时没有提前注意到这个问题，结果发现到第二天查看时发现服务器很慢慢，自信的以为是进程太多导致的，结果有其他ts反馈说慢的一批啊，这时第一反应告诉我可能不简单喽，我赶紧去查了后台日志，结果发现，磁盘空间不足了，因为设置的有告警，不知道怎么没提醒，我还执行了下自动收缩表空间（自动将使用率不高的表空间做了些收缩）。再细看发现有个目录文件都跑了n多，百分之90是这个导致的。然后因为还有其他事项，就联系其他人先清理了。
有了第一次这个惨痛的教训后，机智的我这次执行时先关闭了归档。第二天发现执行完了 服务器空间也是够的。但是在使用过程中，一旦涉及到多表的联合执行，就会异常缓慢。我去回溯时，发现了一个掉下巴的事情，是这个临时表空间非常小只有200m空间（第一执行时为了处理问题，做了自动收缩表空间）。我联想到因为系统开发有很多二次构建组合语句，要执行很多构建语句，这种类似表间关系都应该在这里执行的，会不会是这个导致的呢.我从后台查看了alert日志，发现如下提示：ORA-39171: Job is experiencing a resumable wait.
ORA-01652: unable to extend temp segment by 128 in tablespace EAS_T_EAS7_STANDARD
ORA-39171: Job is experiencing a resumable wait.
看来就是临表不足导致索引等关联关系，没有完全成功导致的，使用过程缓慢。当时是晚上执行的，没有一直盯着。后续要专门排查表空间时否足够，及时检测日志。
付临表作用：（度娘来的）
临时表空间主要用途是在数据库进行排序运算[如创建索引、order by及group by、distinct、union/intersect/minus/、sort-merge及join、analyze命令]、管理索引[如创建索引、IMP进行数据导入]、访问视图等操作时提供临时的运算空间，当运算完成之后系统会自动清理。
当临时表空间不足时，表现为运算速度异常的慢，并且临时表空间迅速增长到最大空间（扩展的极限），并且一般不会自动清理了。