Thanks for all downvoters, you did an awsome job :-( but only nonsense combined with no knowledge.
Many of the commenters as well as the other responder claim that there is no reason for separating the log from the database even for reguler HDDs, and really I would not even had to answer them, however I still tried to provide resources below.
However there is another group that agrees that on an HDD it would be beneficial to separate, they still claim that for SSD drives this is no longer needed.
So for them I want to ask "if there is no issue of contention then why a RAID 10? There is no need for stripping anymore! So mirrowing alone would be enough, and of course there is no need for 8 drives, 2x the database size should suffice!".
However the reality is that if something needs a RAID 10 it is the log file!
This is not just because of the issue of sequential vs random (see resources below), but it is actually very crucial once you understand how SSD drives work.
To make a long story short (for a longer description see
http://arstechnica.com/information-technology/2012/06/inside-the-ssd-revolution-how-solid-state-disks-really-work/), an SSD drive is very effecient in reads, and in writing out zeros, however to write out ones it is not so efficient as it has to erase the entire section to write even a single one!
While this is not an issue for general writes, as they are anyway buffered in memory, and written out in page boundaries, it is a major issue for the log file, as the log file is bypassing any cache and instead SQL server blocks until the logs are written to disc!, which means that for each write there will probably be a full section erase.
So to optimize it, I would suggest to dedicate every extra disc (besides 2x the database size, no need for stripping!) for the log file, this way it will be able to process as many as possible in a shorter time frame.
The answer is yes, for three reasons.
1) Random vs Sequential - While it is clear that SSD increased performance dramatically for random writes, still the issue of random vs sequential remains, as can be seen from the following whitepapaers and links:
2) Reliability - There is a strong chance that all SSD drives will fail simultaneously, in which case RAID is no protection, however since an SSD drive used solely for sequential has a different life span this might be your lifesaver
3) Write Contention - The reason for putting logs on its own spindle is not just because of random vs sequential but also because of write contention, as one can see from the fact that it is also recommended to have tempdb on a separate volume which indicates that the issue here is also about write contention.
And this should apply even more for the log file, as writes to the log blocks transactions from being considered commited until it is written to the disk surface.
In fact for the logs you might use regular HDD drives as apr Dell's white paper at http://www.dell.com/downloads/global/products/pvaul/en/ssd_vs_hdd_price_and_performance_study.pdf
Putting tempdb on its own array for spinning discs is recommended by Microsoft, see
and numerous others and it is the general accepted notion in Sql Server, while no one expressed a problem with splitting the array.
Further more the SQL Server team has created the concepts of Filegroup and Partioining partitioning, with the sole intention to be able to move them on a separate array.
And in fact the MSDN at http://msdn.microsoft.com/en-us/library/ms187087(v=sql.105) recommends that there might be a performance benefit from separating the nonclustered index on its own array, (though this shouldn't be taken as a general advice for every situation, only for specific workloads, see more info at http://weblogs.sqlteam.com/dang/archive/2008/08/01/Are-you-a-DBA-Monkey.aspx).
As such it is just a logical extension to say the reason for separation on spinning discs is not just tied to the issue of sequential vs random reads, but to general write contention, something that applies to SSD's as well.
While it might be that some people disagree with that advice and consider that there is no benefit of putting tempdb and its own volume (as Jack Douglas), and you might even claim that there is no benefit from separating the log files (as Mark Storey-Smith), and instead claim that splitting the array is much more worse, still don't forget that this is a new approach going against the general accepted approach suggested by Microsoft and the community, and so far no one has provided links to any benchmark tests to support it.
So my word to all downvoters is, I find it very unethical to downvote a post just because it has a different opinion than yours, especially when 1) your opinion is going against the general accepted theory 2) and it is against the vendors (Microsoft) own documentation 3) and you haven't provided any proof just an opinion.
But in this case it is even more ridiculous, since my post is nothing more than the logical extension to this theory, so one that considers this post to be bed advice needs of course to go back to all posts that advice this theory and downvote them.
Say someone decides that RAID is old school theory and downvotes all posts recommending it, how does this makes sense?