在生产环境的数据迁移中，发生误操作真是很不愿意看到，今天自己总结了一下，从个人的经验来看有以下的几种操作或者是失误导致的问题。有一些错误自己已经犯过。
外键
不管是使用imp/impdp,sqlldr还是使用Insert append的方式导入数据，如果存在外键的约束，在数据导入前最好都设置为disable,要不数据导入的时候很可能发生冲突，因为批量的数据导入很可能开启多个并发进程，如果你不能完全控制导入的先后顺序，最好还是disable掉。
触发器
触发器在数据导入前最好和开发组确认，如果忽略了这个潜在问题，很可能在数据导入之后，会多出来一部分的数据，而且从日志中没有任何错误。
密码的设置
为了杜绝在多个环境中切换带来的问题，最好在一些登录密码的设置上进行严格控制，如果你一边连着测试环境，一边开着生产环境的窗口，不小心把环境混淆的情况下，那就是数据灾难了，而且个人的建议都是通过一些工具，都不要保存密码，这样会提醒你到底连入的是什么环境。
创建临时账户
在数据迁移的时候，如果表的数据都在某一个schema下，个人建议最好创建一个临时的schema，给这个临时的schema赋予指定的权限，比如数据抽取的临时schema只赋予select权限，对于数据加载的临时schema，则只赋予insert的权限。如果你不管三七二十一，在源schema里面做所有的操作，很容易犯低级错误。一旦发生问题，那也是不可挽回的。
关于命令的历史
如果你已经习惯使用ctrl+p，或者上下箭头来运行历史命令，自己不想敲命令的话，一定要小心，
可能上一个命令是nohup命令，那么你一旦操作过快，急急忙忙敲回车的话，也是很严重的问题。
vi可能导致的问题
vi本身不是问题，但是个人建议vi的改动最好还是尽量在另外一个目录下备份一份，改动完成之后从另外的目录copy过来。这样一旦发生问题也能知道是不是改动导致的。
回车和空格
如果你接入一个环境，呈现在你面前的是一个空屏幕，这个时候不要随意按回车键，保守的方式就是空格键，看看是否是光标显示不够完整，有很多时候都是显示的不够完整，但是可能命令已经通过历史记录给调出来了。随意按了回车，就是可能的灾难。
数据备份
数据的备份，这个从系统级，数据库级，表级都可以做一些工作。我在这所说的数据备份，可能更侧重于说表级的备份，如果有足够的空间，可以考虑对很关键数据量大的表做表级备份，如果只是做了exp/expdp的备份，那么一旦出现问题，你还需要大量的时间和系统资源去导入到一个临时的schema或者其他的地方，这个就耗时费力了。可以使用create table xxx nologging的方式，如果表很大，加个并行还是比较快的。
迁移方式
这里想说说大家常用的迁移方式，可能数据量小的时候，使用imp/impdp就可以，数据量稍大一些，impdp或者sqlldr就可以，如果数据量更大，就可以考虑sqlldr或者外部表了。
个人的感觉来说imp/impdp/sqlldr都属于物理级的数据加载，外部表的数据加载才是逻辑级别的。
举几个场景，
如果表很大的情况下，impdp的导入会耗费很多的资源，直到数据完全导入，才是释放Undo资源，一旦发生问题，比如undo资源不足，就会直接报错，这个时候可能会耗费很多的时间和资源。
在数据导入之前，你不可能从imp/impdp的dump文件中查看到表的数据，如果发生数据冲突，也是在数据导入的时候才可能发现,sqlldr可能还可以查看一部分数据，但是不够直观，数据都是行列形式的文件，你不能通过sql语句等形式来检查数据。如果有数据问题，也是在数据导入的过程中才可能发现。
即使你想对数据进行预检查，那么你可能得用Impdp或者sqlldr的形式把数据先加载到一个临时的用户下，那么问题就来了，你得准备足够多的空间资源，而且导入的过程中队系统负载也是很大挑战。在这一点是外部表要更胜一筹，无须准备额外的空间，外部表就更创建一个同义词的感觉一样，加载卸载都是很快的，秒级别的操作。
唯一性约束和主键
如果你在考虑性能的时候，在数据导入前删除了主键和唯一性约束，那么如果存在数据冲突，或者误操作导致数据加载了多次的时候，你就给自己挖了一个坑，到时候出现问题，很难从头查起。个人建议还是保留唯一性约束和主键，尽管性能会打折扣但是也是值得的付出。
网络中断
这个问题自己碰到过几次，如果脚本在运行的过程中发生网络中断，你就会马上崩溃了。这个时候还是保守一些，一些脚本的运行还是考虑使用nohup的形式来。
要不中途发生问题，你都不知道该从哪开始继续。
磁盘空间不足
如果数据导入的过程中发生空间的问题，使用sqlldr的时候你就得仔细的查看日志文件，慢慢一个一个修复吧。最好还是给30%左右的buffer,别自己为难自己。
如果使用外部表的话，可能会有大批的外部表导入失败，那么你就得查看日志，慢慢的手动修复。如果问题比较多，那工作量可想而知。
外键
不管是使用imp/impdp,sqlldr还是使用Insert append的方式导入数据，如果存在外键的约束，在数据导入前最好都设置为disable,要不数据导入的时候很可能发生冲突，因为批量的数据导入很可能开启多个并发进程，如果你不能完全控制导入的先后顺序，最好还是disable掉。
触发器
触发器在数据导入前最好和开发组确认，如果忽略了这个潜在问题，很可能在数据导入之后，会多出来一部分的数据，而且从日志中没有任何错误。
密码的设置
为了杜绝在多个环境中切换带来的问题，最好在一些登录密码的设置上进行严格控制，如果你一边连着测试环境，一边开着生产环境的窗口，不小心把环境混淆的情况下，那就是数据灾难了，而且个人的建议都是通过一些工具，都不要保存密码，这样会提醒你到底连入的是什么环境。
创建临时账户
在数据迁移的时候，如果表的数据都在某一个schema下，个人建议最好创建一个临时的schema，给这个临时的schema赋予指定的权限，比如数据抽取的临时schema只赋予select权限，对于数据加载的临时schema，则只赋予insert的权限。如果你不管三七二十一，在源schema里面做所有的操作，很容易犯低级错误。一旦发生问题，那也是不可挽回的。
关于命令的历史
如果你已经习惯使用ctrl+p，或者上下箭头来运行历史命令，自己不想敲命令的话，一定要小心，
可能上一个命令是nohup命令，那么你一旦操作过快，急急忙忙敲回车的话，也是很严重的问题。
vi可能导致的问题
vi本身不是问题，但是个人建议vi的改动最好还是尽量在另外一个目录下备份一份，改动完成之后从另外的目录copy过来。这样一旦发生问题也能知道是不是改动导致的。
回车和空格
如果你接入一个环境，呈现在你面前的是一个空屏幕，这个时候不要随意按回车键，保守的方式就是空格键，看看是否是光标显示不够完整，有很多时候都是显示的不够完整，但是可能命令已经通过历史记录给调出来了。随意按了回车，就是可能的灾难。
数据备份
数据的备份，这个从系统级，数据库级，表级都可以做一些工作。我在这所说的数据备份，可能更侧重于说表级的备份，如果有足够的空间，可以考虑对很关键数据量大的表做表级备份，如果只是做了exp/expdp的备份，那么一旦出现问题，你还需要大量的时间和系统资源去导入到一个临时的schema或者其他的地方，这个就耗时费力了。可以使用create table xxx nologging的方式，如果表很大，加个并行还是比较快的。
迁移方式
这里想说说大家常用的迁移方式，可能数据量小的时候，使用imp/impdp就可以，数据量稍大一些，impdp或者sqlldr就可以，如果数据量更大，就可以考虑sqlldr或者外部表了。
个人的感觉来说imp/impdp/sqlldr都属于物理级的数据加载，外部表的数据加载才是逻辑级别的。
举几个场景，
如果表很大的情况下，impdp的导入会耗费很多的资源，直到数据完全导入，才是释放Undo资源，一旦发生问题，比如undo资源不足，就会直接报错，这个时候可能会耗费很多的时间和资源。
在数据导入之前，你不可能从imp/impdp的dump文件中查看到表的数据，如果发生数据冲突，也是在数据导入的时候才可能发现,sqlldr可能还可以查看一部分数据，但是不够直观，数据都是行列形式的文件，你不能通过sql语句等形式来检查数据。如果有数据问题，也是在数据导入的过程中才可能发现。
即使你想对数据进行预检查，那么你可能得用Impdp或者sqlldr的形式把数据先加载到一个临时的用户下，那么问题就来了，你得准备足够多的空间资源，而且导入的过程中队系统负载也是很大挑战。在这一点是外部表要更胜一筹，无须准备额外的空间，外部表就更创建一个同义词的感觉一样，加载卸载都是很快的，秒级别的操作。
唯一性约束和主键
如果你在考虑性能的时候，在数据导入前删除了主键和唯一性约束，那么如果存在数据冲突，或者误操作导致数据加载了多次的时候，你就给自己挖了一个坑，到时候出现问题，很难从头查起。个人建议还是保留唯一性约束和主键，尽管性能会打折扣但是也是值得的付出。
网络中断
这个问题自己碰到过几次，如果脚本在运行的过程中发生网络中断，你就会马上崩溃了。这个时候还是保守一些，一些脚本的运行还是考虑使用nohup的形式来。
要不中途发生问题，你都不知道该从哪开始继续。
磁盘空间不足
如果数据导入的过程中发生空间的问题，使用sqlldr的时候你就得仔细的查看日志文件，慢慢一个一个修复吧。最好还是给30%左右的buffer,别自己为难自己。
如果使用外部表的话，可能会有大批的外部表导入失败，那么你就得查看日志，慢慢的手动修复。如果问题比较多，那工作量可想而知。
