You can run this query to see what your database recovery model is, when backups were made, and what type. You should see [Type] = "L" for Log Backups
DECLARE @database_name nvarchar(256) = N'MyDatabaseName'
--
SELECT D.recovery_model_desc, D.name
FROM master.sys.databases AS D
WHERE D.name = @database_name
--
SELECT TOP 500 WITH TIES
BS.backup_start_date,
BS.type,
[Size KB]=CONVERT(int, BS.backup_size/(1024)),
BS.database_name
FROM msdb.dbo.backupset AS BS
WHERE 1=1
AND BS.database_name = @database_name
ORDER BY BS.backup_start_date DESC
Is the database in FULL or SIMPLE recovery model?
If in SIMPLE then your Log Shrink should work, if not something is wrong! It might help to re-start the SQL Service (in case there is an open, orphaned, transaction right at the end of the log file for some reason)
If FULL then what I do is:
Take a LOG Backup
Shrink the LOG file
If the Shrink has not reduced the file by enough then:
Take another LOG Backup
Repeat Shrinking the LOG file again
If this does not shrink it enough then my earlier point applies here too!
You can make a LOG Backup using SSMS by RightClick the Database - Tasks - Backup ... BUT ...
It is critical (for a database in FULL recovery model) that the LOG Backup chain is preserved, otherwise you will not be able to restore for disaster recovery. Thus it is important that wherever you "store" the Log Backup is somewhere where anyone needing to perform disaster recovery can find it - so NOT on the C: drive of your PC!! but on the Server itself is good.
For that reason do NOT change the database from FULL to SIMPLE to work around this - that will also prevent Disaster Recovery.
You need to find out what the cause of your large Log file is. Perhaps your database is in FULL recovery model and there are currently NO Log Backups? If so either:
You do not need FULL recovery mode? You would be happy to restore from the last full backup and lose all the data changes / work SINCE that backup ? If that is the case then SIMPLE may be appropriate
If you DO need to be able to recover to a point-in-time, and want the minimum data loss (quite often "no data loss" in the case of a database corruption) then a) you need FULL Recovery Model and b) you need frequent (no less often than every 10 minutes) Log Backups.