非DBA人员也可以恢复truncate掉的数据了。。。哈哈
借着本人犯点错误的机会，连错数据库，truncate掉了10张本不想删除的数据
（还好此次错误没照成什么影响，自己负责的小系统刚运行个把月，客户没当回事未追究，万幸啊！若是其他系统后果不堪设想）
自己和自己较了把劲，琢磨2天truncate数据恢复的问题，结果记录下来和大家分享：
或许以后用得着！！（用不到最好。。。。）
先说明，本人是个菜鸟阶段的研发人员，本文章适合非DBA人员。
DBA各种高深的数据恢复手段我们这些外界研发人员真是遥不可及啊！！
当一个小团队压根不存在DBA时，误操作truncate掉了数据怎么办？
可以尝试使用这个工具进行恢复数据。傻瓜式操作。真心的适合研发人员使用。
先说下恢复结果吧：
折腾了两天，数据恢复了90%以上，有一张表未恢复全，最大的还是收获了对这个工具的认识，至少现在个人对truncate的数据恢复有一丁点信心了。因为原来压根就是空白啊。
数据库环境：
oracle 11g
服务器：坑爹的linux
第一次下载使用此软件的同仁啊。强烈建议你详读PRM技术白皮书.pdf。
此工具运行环境要求，jdk1.6以上。
最开始使用的时候，考虑到在linux上运行此软件，所以把全部时间精力都用在linux如何安装jdk以及各种无聊的命令、各种远程工具的使用测试了。
后来读了下技术书（其实技术书里未说明这点，有些地方误导了我），为什么一定要在数据库服务器上运行此工具呢？
后来干脆随便找个数据库dbf文件测试一下，在本地环境（没装oracle）运行，结果恍然大悟，原来在本地运行就可以。
此工具单存的读取数据库dbf文件即可（系统表空间所在的文件+丢失数据所在的文件）。
后来发现：原来的精力都用错方向了，此软件真是傻瓜式操作。
个人建议恢复数据时新建个用户及表结构，使用桥接的方式将数据恢复至数据库中，在常规恢复时，使用可执行文件方式将数据load时，大量数据日期类型会报错，很麻烦。耽误时间。而桥接的方式只需新建表结构，配置个连接就可以直接还原。
好了，总结一下：
1.
此软件只需要单存的读取数据库dbf文件就可以，不依赖于数据库的启动（因为很多数据库操作系统都是linux等在上面运行麻烦至极）。
2.
此点很重要：此次恢复90%的数据而未能全部恢复的原因（truncate数据后，一定要第一时间、第一时间、第一时间将丢失的数据所在的数据库文件复制出来），此次truncate数据后，是第二天才研究明白这个软件然后才把dbf文件拷贝出来使用的。所以照成了部分数据至今不能恢复。（若哪位高手能提供些其他思路挽救未能恢复的数据，不尽感激）
3.
truncate慎用。千万不要连错了数据库。。。。
4.
完整的数据库备份机制才是王道。。
另真心寻求各位DBA们帮助，还有可能找回那些至今未恢复的数据吗 ？？
附件可以下载此软件。
留着吧。万一以后能用到呢。
也可以百度直接搜索。