In Sql Server, I've found that, after i mark a database as read only, its existing large transaction log remains. To repair this I must place it to writeable, then dbcc shrinkfile around the log file, then place it read-only again.
What's using a transaction log when the database is read only? It is possible to reason it does not just get erased/flushed?
In case your database continues to be entirely recovery mode, the log won't shrink with no proper backup. You need to switch your read-only database to simple recovery.
Also, the log file is required if you ever choose to remove/attach this database. As noted here:
In comparison, for any read-only database, the log can't be reconstructed since the primary file can't be up-to-date. Therefore, whenever you fasten a read-only database whose log is not available, you must supply the log files or files in the FOR ATTACH clause.
There's no use for any transaction login a read-only db :-) Presuming you're past some time you no more worry about the transactions completed to populate it. I imagine it isn't flushed because that wouldn't be good default behavior, let's suppose you desired to return to write mode? Or else you discovered throughout read-only operation that there is an issue and also you required to make use of the logs?