There are abundant information on how to shrink a growing Transaction log, from frequent log backups, to changing the RECOVERY from FULL to SIMPLE and truncate. A daily background job takes care of this process and it's working fine. By now, most people know how and why Transaction Log works. There is a complete explanation here.
I have a misbehaving application that, somehow, create a growing transaction log by not releasing, not sure if it's not committing or not closing or what, at the end of the (whatever) action.
It doesn't look like there is data loss or inconsistencies and not any unusual situation on the DB.
Upon restarting SQLSERVER show the database in 'recovery mode' for a while and then back to normal.
DBCC LOGINFO, shows over 100 entries, all of them with 'Status=2' so I understand, they are in use. Interesting but on some entries, the 'filesize' is even larger that the Database itself!
The subject database on
SELECT name,log_reuse_wait_desc,recovery_model_desc FROM sys.databases show log_reuse_wait_desc as 'NOTHING' and recovery_model_desc as 'FULL'
My question is: Is there any method, documented or not, to 'read' the log file and find what table, application, data or whatever info is on the VLF to help finding the culprit application?