oracle 数据库 批量导入数据后，两天后数据神秘失踪
现在遇到一个特别奇特的问题，因为系统是个比较大型的系统，包含好几个区域的数据
   前两天因为系统上线的需要对就系统数据进行大批量的数据迁移，发现了这个问题，求
高手赐教啊！！！
  问题是这样的，三天前开始 导入旧系统数据，共分为三个区的数据  每个区导入数据大概为 4个G左右
  每次导入完成后，存储过程的日志都会把执行完成的数据量记录下来的。前两天都没发现问题，但是今天发现了个
奇特的问题，之前导入的数据 无故突然开始丢失，人员表数据 丢失上万，单位信息表八百多的数据，现在基本上没有了，还剩下 数十条数据；这也意味着 之前的迁移数据基本废了；
   请问大家这个事情 可能出现的原因都是那些呢？？？ 
  （排除原因1：批量数据迁移未提交；这是不可能的 因为前天导入后 昨天程序里还能查到数据，今天就没有了；）
  （排除原因2：手动删除数据：这是不可能的；没人会做这种事）
 
   现在发现的可能异常： 数据库回滚段一直是满的；前天开始系统数据库服务器备份因为空间不足而发生了异常；但是不知道这会不会影响对数据库数据的迁移结果；


  总之，现在问题就是 之前迁移完成的数据，在今天 陆陆续续消失了…… 
  求解……
------解决方案--------------------
未提交之前,数据在DB Buffer里面(也有可能已经输出到磁盘)，回滚段中的数据使用来rollback的。
如果是磁盘空间不足导致错误，日志里面会有输出的。
查下告警文件吧，告警文件位于BACKGROUND_DUMP_DEST参数指定的目录下，文件名alert_<ORACLE_SID>.log。
------解决方案--------------------

引用:

引用:
排除原因1：批量数据迁移未提交；这是不可能的 因为前天导入后 昨天程序里还能查到数据，今天就没有了
有可能，存在回滚段内和内存中，过了1天，被覆盖了


LOGMINER分析下，确认下是否提交了，还有看看之后是否有谁做了其他的操作了

（排除原因2：手动删除数据：这是不可能的；没人会做这种事）
一切皆有可能，

看看日志里有什么信息


你好，请教……

我越主代庖，帮你解答哈：
1）当数据在迁移的过程中（未提交之前），它是存在于回滚段中的（？？对否）；
答：未提交的事务，oracle会永远放在undo段。
2）然后当迁移脚本执行完毕之后，commit了 那么这是是不是就是在回滚段中进行内部提交的过程了？
答：是的
3）在这时 如果数据库 主数据文件不能扩展（由于硬盘空间的不足造成） ，那么在这时 在回滚段的这些数据该何去何从呢？？
答：undo段的旧值保留，新值拒绝。若有新值请求，会报ora-30036错误。
4）我们已经发现数据库主文件由于所在的磁盘空间不足了（这会不会导致数据文件不能自增长，而导致手动commit之后，后台执行失败 ，但是不给前台提示……）
答：请记住：commit和你的数据文件有多大没啥关系！！！！！commit是写日志，之后DBWn才会增量渐进写数据到数据文件。

你的情况，其实，也有可能是被操作系统给回滚了。在我的生产环境中就遇到过哦。
------解决方案--------------------
先来温习下COMMIT语句处理顺序：
当事务提交时，Oracle分配一个唯一的顺序号SCN(System Change Number)给事务。数据库恢复总是基于该SCN号来进行处理。SCN号是记录在控制文件、数据文件、块头及重做日志文件中。
1．COMMIT处理步骤：
Oracle 在下面情况提交事务：
l       发出一个COMMIT语句。
l       执行DDL语句时。
l       离开Oracle时
Oracle处理COMMIT的顺序是：
1）服务器为每个COMMIT产生一个SCN。使改变永久化。
2）LGWR进程将日志缓冲区数据并带有SCN一起写到重做日志文件。
3）服务器释放表级和行级锁。
4）用户被提示COMMIT完成。
5）服务器使事务已完成。


如果commit了，是会写入到redo日志里的，同时事务就算结束了，如果写磁盘报错，那么数据就会丢失，数据库并不会进行回滚的，但是归档文件里是有数据记录的，前提是开归档，呵呵
我的库经常遇到这个问题，最大文件到达32G了，就会丢失一部分数据，我看到报警后处理后，恢复正常