SQLFriend,

I suspect that your problem is because the transaction logs are not being
successfully backed up.  A common misunderstanding is that a BACKUP DATABASE
backs up the logs also, so nothing more needs to be done.  But, in order to
allow the log space to be reused it is also necessary to do BACKUP LOG
commands, so that the log is backed up separately from the database.  (So,
if you discover this problem in your setup, once you clear the log problem
then you should be able to prevent future occurances.)

In order to actually shrink the 26 GB log file, you may need to run these
steps more than once.

DBCC SHRINKFILE('DBNameLog',20)
BACKUP LOG DBName WITH TRUNCATE_ONLY
DBCC SHRINKFILE('DBName_Log',20)

Since the open rows are in the last section of the log file, you have to
patiently wait for the active part of the log to roll back to the front of
the log file.  After than the TRUNCATE_ONLY will work.  Switching the
database to the SIMPLE recovery model has the same effect as the truncate.

Once your log is shrunk and (if that is what you want) the database is
restore to FULL recovery model, do a database backup to reestablish a
starting point for the log backups, then start regularly running the log
backups.

If  you were already doing separate log backups, but the log is full because
of some enormous transaction that messed up everything for you, you should
still do the database backup once you have recovered the space.

RLF