_disable_logging=true ... why not?

A collegue of mine suggested me that using _disable_logging=true performs a very fast import during database migration with export/import technique. I've already heard in past this parameter but it's not interested me till now. I can easily understand that database operations in NOLOGGING are faster that LOGGING operations. Even if you're in NOLOGGING and NOARCHIVELOG mode oracle generate a minimum redo that in fact requires I/O and CPU time.
It seems that using _disable_logging you're able to not write redologs. Simply redos generated into log buffer are discarded and not written to disk. Of course this is a really dangerous operation! You'll never be able to recover your database and you may experience unrecoverable blocks corruption.
Metalink note 391301.1 says that blocks corrution can occur on any platform, and this is clear.
Is really safe to gain a faster operation loosing completely the data integrity of your database? I'm not sure of it and probably I don't agree with you.

Datamasking considerations and thoughts

Have you ever thought seriously about datamasking? I'm dealing with many issues on datamasking and I think that too much people has not clear ideas about datamasking. Datamasking is not, of course, a way to protect your data from unauthorized access. A user that is authorized to access to a data in a production environment, may have the same permission for testing and preproduction databases. But, you sure have many other persons access data in non productive environment, as programmes, project managers, database administrators, and so on .... and you have to protect you data from them. Also you have to protect data during exports for third party companies that work for you.

I have found on a website of Grid Tools an interesting document called The Mathematics of Datamasking that everybody involved in datamasking activity and projects should read. I've never downloaded or evaluated products of this company but I'm currently having to do with Oracle Datamasking and I think is not really efficient. Oracle Datamasking pack, that's a feature of Enterprise Manager, does not perform an intelligent masking but only replace identified sensitive columns with fake data from dbms_random. This is not correct as any time you try to access to Name column for example, you find only a string similar to DAYEGAGIDAYIDGAYI. It's quite hard to performe any test with users without having this unreadble data. You don't need to use production data of course, but you can replace with consistent data.

The five orders of datamasking described in the first part can summarize all cases need you attention. Second and last part of document explain, using mathematics (that is not an opinion), the cost and effectiveness of datamasking. Any database administrator and security engineer should leverage is own knowledge with this simple paper.