Setting aside for the moment your original issue (high log semaphore contention), and the decision to use ALS, and focusing (for now) on just the long rollback issue ...
Can you tell us anything about the transaction that gets rolled back? For example, how long is the transaction open before it gets rolled back, how much of the log is in use just before the rollback is issued, why is the transaction rolled back, how long does the rollback take to complete?
------------
For the database in question, could you run the following and post back here with the results:
use <dbname>
go
select @@maxpagesize
go
sp_logiosize
go
Next, is your database log bound to a specific cache? If you're not sure you can run the following ...
sp_helpcache
go
... and look for the database's log in the list. (If not sure what I'm talking about, post back here with the output from sp_helpcache - preferably as a *.txt attachment if it's a fairly large list.) I would also be interested in knowing if the entire database is bound to a cache ... again, look for an entry in the output from sp_helpcache for your database.
If the log (or entire database) is bound to a cache, please run the following and post back here with the results:
sp_cacheconfig '<name_of_cache_your_log_is_bound_to>'
go
sp_helpcache '<name_of_cache_your_log_is_bound_to>'
go
I'm going to assume the caches named 'tempdb*' are used solely for managing your temporary databases. You've also got a 5GB cache named workdb_log ... but I can't tell what's bound to this cache.
I'm wondering if your rollback issue could be due to a cache management issue, eg, a sizeable chunk of the log gets flushed to disk and a subsequent rollback is delayed while the old log pages are read from disk. This scenario can happen if the the cache that the log resides in isn't large enough to hold all recent activity so older pages get flushed to disk, then when a rollback occurs those older pages have to be re-read from disk, eg:
- if your database's log is sharing a cache with other objects, then those other objects could be flushing your log pages to disk
- if your database's log has a cache all to itself but the cache is not large enough to hold all log activity dating back to the oldest open transaction, then the older pages could get flushed to disk
----------------
It may also help if you could run a sp_sysmon session (and post the results here - again, as an attachment) that encompasses one of these lengthy rollbacks.