the real answer is "it all depends" on Database size, performance characteristics, infrastructure to name just a few things. SAN? Discrete HD? Locally attached? Data criticality? You will probably not want to do "normal" redundancy (3 copies of each block) with a 100TB database as it will require 300TB worth of storage where as you could do RAID5 or RAID6 and only lose 20%. (100TB data - 120TB storage using RAID5 etc...)
Do a LOT of reading in the concepts manuals before you start.
External redundancy does not provide more disk capacity than ASM. Its an option you may consider if you wish to rely exclusively on data redundancy provided by your storage system (SAN). In which case your available storage devices (LUN) may also not be suitable to set up ASM redundancy.
RAID5 or RAID6 are generally not recommended for high performance database since write speed is typically that of a single drive. Also keep in mind that recovery of a drive failure is the slowest. RAID5 and 6 are for home users, unless you have a storage controller with special hardware that was specifically designed to overcome some of the RAID5 performance issues. Your best performance and redundancy option is raid 10, which is mirrored striping at the cost of 50 % capacity loss.
ASM is not a software RAID, which many people seem to think. Please see the ASM documentation. Simply put, ASM has several advantages over typical RAID solutions and works on the bases of file extents, using the free disk space of disk failure groups for I/O balancing and redundancy. ASM, unlike conventional fixed RAID options, enable you to add additional storage capacity without the need to destroy any existing data volumes.
ASM External Redundancy = RAID 0 on top of whatever protection you already have in place.
If you have no external protection then External Redundancy = nothing + RAID 0 = RAID 0.
If your LUNs were carved up on the SAN as RAID 10 for maximum performance or RAID 5 because you don't care about performance, and you put three of those LUNs into an ASM diskgroup with External Redundancy, then ASM will create extents evenly across all three LUNs, then go back and fill the extents with data (write stripe 0, 1, 2, wrap around and write stripe 3, 4, 5, wrap around ...) and here's the fun part within each LUN the SAN will perform its RAID, so you get stripes over stripes and performance might (but not always) suffer. RAID 10 + 0 = ???
By now you might have realized putting just one LUN in an ASM diskgroup negates the "always stripe everything" mentality of ASM.
The benefit of External Redundancy can sometimes be efficiencies in the SAN's RAID system. This is not always true. Since every system is different you'll have to test it both ways using a typical workload from your application, and see if the app is faster when you use the SAN or ASM's RAID. A while back we tested no ASM over SAN RAID 0 then again with RAID 10 and got a 15% perf hit. We then tested ASM External Redundancy versus ASM Normal Redundancy and got a 10% perf hit. For that customer the database ran faster using ASM's redundancy.
A few clarifications on the information you received earlier ...
ASM Normal Redundancy does not make "three copies of each block", it makes "two copies of each stripe". ASM High Redundancy makes three copies of each stripe. There is no option in ASM to mirror at the block level.
RAID 5 consumes a lot more than 20% of the capacity. It is as high as 33% of each device plus 100% of each spare device so in a RAID 5 (3+1) configuration you lose the capacity of two devices, exactly the same amount of capacity as RAID 1 or RAID 10. SAN vendors create really wide RAID 5 groups to reduce lost space, but increases the risk of full outage due to double drive failures. RAID 6 addresses the issue and tolerates double drive failures, but there's a significant performance penalty.
The statement "ASM is not software RAID" is interesting. There are only three choices: hardware, firmware, and software RAID. ASM is clearly not hardware or firmware RAID so that only leaves software RAID. Although ASM is not part of the o/s which is one general criteria (very outdated) for s/w RAID, it does use the server's CPU and RAM rather than on-chip resources characteristics of software RAID. To be political we'll just say it meets most but not all of the criteria for s/w RAID. A lot of storage appliances use s/w RAID as well.
RAID systems, software or hardware, work at the basis of disk and block levels with a fixed stripping size accross all RAID membes. For instance, in a RAID 1 scenario, the smallest disk defines the maximum capacity. ASM works on the basis of free space available in disk failure groups and knows about Oracle databaes files to set fine or coarse grained stripping.
If you use only 2 disk failure groups for ASM with normal redundancy, then the effective capacity management is the same as in RAID 1, however, if you use 3 disks, it starts to be different.
Therefore, to my understanding, ASM is not a software RAID, because it defines redundacy and striping based on free space and file level, and not on a disk level.
External redundancy - doesn't have failure groups and thus is effectively a no-mirroring strategy
Normal redundancy - provides two-way mirroring of all extents in a disk group, which result in two failure groups
High redundancy - provides three-way mirroring of all extents in a disk group, which result in three failure groups