最不负责任的答案，或者一个初级DBA的处理方法：
delete from t where rowid not in (
select min(rowid) from t group by 唯一列 having count(*)>1);问题点简单总结：
你咋不提交
这个表是不是被其他表参照
这个表数据量多少，该方法需要多少执行时间
如果表上亿记录数且需要删除90%以上数据，能成功么
当前库负载或者该表上的前台业务允不允许该操作
在删除的同时又有新的重复数据入库咋办
操作进行到一半，需求人跟你讲他想错了，将删掉的数据找回来
处理思路简单总结：
1° 向需求人询问该问题产生的原因以及该表该字段的具体意义
以自己的经验再次验证该字段是否需要唯一性约束，也方便后期该问题的定责
2° 滤重之前首先添加唯一性约束，延迟生效，保证没有新的重复数据入库
否则有可能洗数据的操作没有问题数据入库的操作快
3° 观察添加唯一性约束之后，对应的业务是否有影响
对应业务的对应代码BUG是否修复，是否引出其他BUG点
当然应该是先修复代码，后数据库洗数据，但是开发是DBA把控不到的
这就要把锅分分清楚，锅不明，不要做
4° 判别表数据量，数据库负载，前台业务特点，确定操作时间窗口
5° 数据备份、数据回滚和数据清洗
备份首先绝对是排在第一位的，数据泵导出备份、RMAN备份等等，要做好最坏打算
其次生成数据回滚语句，最后生成数据清洗语句
可以查出需要滤重的rowid，然后根据rowid查出表数据，生成insert脚本，作为数据回滚
然后根据这些rowid，拼出delete脚本，作为数据清洗
批量插入commit语句，比如每隔100条insert插入一个commit，做分批提交
6° 如果这个表有主外键关系，或者是分区表，或者业务关联性特别复杂
还需要具体问题具体分析，有时候该拒绝的就要学会拒绝
或者理清厉害关系，由你的上司决定是否承受对应风险
当你不想做一些事情的时候，理清问题，夸大风险是个不错的方法
7° 生产洗数据就是耍杂技，无论多么简单的操作都要做好准备
小心谨慎才能让自己职业生涯更长一点
不要害怕，DBA不是高危职业 (^_^)∠※
[TOC]