Ejecuta dos o tres veces la instrucción CHECKPOINT. Esto asegurará que todas las páginas de memoria se han escrito en el fichero de datos.
Luego haz un BACKUP LOG WITH TRUNCATE_ONLY para que trunque el registro de transacciones.
Posteriormente ejecutas DBCC SHRINKFILE indicando el nombre del fichero del log a reducir.

(En la ayuda puedes ampliar información sobre estos dos mandatos).

Eliminar el fichero para que se genere de Nuevo (Esta solución es demasiado drástica, emplearla solo si falla la anterior):

Pon la base de datos en modo "single user".
Ejecuta CHECKPOINT dos o tres veces. Esto asegurará que todas las páginas de memoria se han escrito en el fichero de datos.
Asegúrate de que no hay conexiones abiertas a la base de datos, con lo que no puede haber transacciones a medio ejecutar.
Utiliza sp_detach_db para desconectar dicha base de datos.
Elimina el fichero de log.
Utiliza sp_attach_db para reconectar la base de datos. SQL Server creará un nuevo fichero de log.

¡¡¡ IMPORTANTE !!!
Si no ejecutas el proceso completamente y en este orden, podrías tener problemas de consistencia de información en el fichero de datos.
Por ejemplo, si apagas el equipo sin más, SQL Server no ha tenido tiempo de volcar las páginas de datos de la memoria al disco. Al reiniciar SQL Server, el problema será corregido utilizando la información contenida en el registro de transacciones, pero si este no está presente, el archivo de datos se dará por bueno, y podría ser realmente inconsistente.

Otro detalle importante a tener en cuenta es que el log no se limpia nunca completamente, ya que siempre hay operaciones internas que SQL Server necesita mantener en él.

Causas habituales del crecimiento del Log.

Si el log ha crecido mucho es porque SQL Server lo ha necesitado. Esto es debido a una de las siguientes causas:

Eso es lo que normalmente sucede y se debería ajustar la estrategia de backup para hacer copias del log más a menudo.
Si el crecimiento del log se debe a una ejecución (insert, update, delete) que afecta a un gran número de registros, bien por haber lanzado un proceso de actualización masiva o porque alguien ha ejecutado una consulta mal formada, que habría que detectarla (y darle un tirón de orejas al que la haya enviado).

Las copias completas de la base de datos no truncan el registro de transacciones. Utiliza una estrategia de copia de seguridad que mezcle copias completas de la base de datos con copias del registro de transacciones.

Puedes detectar las consultas enviadas a SQL Server con el Profiler.

No debes borrar el registro de transacciones manualmente salvo causa de fuerza mayor. Lo que debes hacer es diseñar una estrategia de copia de seguridad que sea acorde con el volumen de transacciones que tiene tu sistema.

Problemas habituales que impiden reducir el tamaño del Log.

Los pasos para truncar el Transaction log pueden no ser tan obvios como pueda parecer:

El registro de transacciones está compuesto por al menos dos registros virtuales (VLF = Virtual Log Files). El truncado del registro de transacciones se realiza VLF a VLF. Si sólo tienes dos registros virtuales y te ocupan todo el fichero no podrás truncarlo, aunque dudo que cada VLF llegue a ocupar mucho espacio. (Para ampliar información sobre este punto, consulta en la ayuda 'Trucar el Registro de transacciones', encontrarás información detallada y un gráfico muy explicativo).

Al ejecutar una instrucción DBCC SHRINKFILE solo se le indica a SQL Server que se quiere reducir el tamaño físico del fichero de LOG. Si el último VLF está al final del log, aunque el resto del fichero esté vacío, no se podrá truncar el fichero, ya que SQL Server sólo puede reducirlo recortando por el final.

Supongamos que hay una estrategia de copia de seguridad que incluye copias completas y copias del log. En este caso son las copias del log las únicas que truncan el registro de transacciones, por lo que si se ha ejecutado o no DBCC SHRINKFILE, el registro no se truncará lógicamente hasta que se haga una copia de seguridad del log (o se ejecute BACKUP LOG TuBase WITH TRUNCATE_ONLY).

Sin embargo si el último VLF no está completo, no se podrá truncar, por lo que se tendrá que forzar su llenado. Al ejecutar DBCC LOGINFO(TuBase) se obtendrá una lista de VLF, si te fijas en la columna Status, 2 significa que no está activo o que al menos no es reutilizable. Envía alguna actualizaciones nulas (UPDATE TuTabla SET Campo1 = Campo1, por ejemplo) y vuelve a ejecutar el comando DBCC LOGINFO hasta que veas que hay algún otro VLF con status 2.

Ahora si que se puede ejecutar el BACKUP LOG para truncar el LOG y tras esto SQL
Server podrá recortar el fichero físicamente eliminando uno o más VLFs.

Enlaces con información de Microsoft sobre el tema.

INF: Cómo reducir el registro de transacciones de SQL Server.

A consultar en los Books On Line y ampliar información:

DBCC SHRINKFILE
DBCC SHRINKDATABASE
DBCC LOGINFO
BACKUP LOG
sp_attach_db
sp_detach_db

Para cualquier tipo de sugerencia, colaboración o comunicación, diríjanse a

webmaster@helpdna.net