As Max mentioned the alert probably fired just prior to the log growing/needing to grow. SCOM collects transaction log free space % although I am not sure at what threshold the alert will fire.
here is a quick example to show you what state tempdb is probably in when you get these alerts but no log file growth.
first create a database, set recovery to full, and back it up
create database tlogspace
on(name=tlogspace_dat,
filename='c:\temp\tlogspace.mdf',
size=4MB)
log on (name=tlogspace_log,
filename='c:\temp\tlogspace.ldf',
size=1MB);
go
alter database tlogspace set recovery full;
go
backup database tlogspace to disk='nul';
go
now switch to that database, create a table, and run DBCC sqlperf(logspace) to check the size oand free space in your log file.
use tlogspace
go
create table data(id int identity(1,1), col varchar(8000))
dbcc sqlperf(logspace)
On my system I have logfile size of 0.9921875 and log space used (%) of 48.4245. Now insert some data into the table and run DBCC sqlperf(logspace) again. On my system 45 rows inserted gave desired results(number of rows inserted may need to be adjusted).
insert into data(col)
select replicate('a',8000)
go 45 --may need to adjust number
dbcc sqlperf(logspace)
This time, the DBCC sqlperf output should show that log size is the same but log space used is just under 100%. In this case, SCOM would probably fire an alert that log space is low. There is no more activity going on to cause the log file to grow and (in this example) no tlog backup to free up used space. tempdb is in simple recovery, so your active transaction probably used up most of the available space and did not release it but there was not enough activity in tempdb to trigger log file growth thus causing the alert fire.
cleanup database when finished
use master
drop database tlogspace
I had a similar problem: I did not have replication but once I used Memory Optimized table as a test, database in Simple recovery mode, but my transaction logs weren't truncated. Manual truncation, even right after a full backup, gave the error:
Cannot shrink log file X because the logical log file located at the end of the file is in use.
A manual checkpoint failed:
Msg 41315, Level 16, State 4, Line N
Checkpoint operation failed in database X.
A manual checkpoint only succeeded right after restarting the SQL Service, which would lead to a 4 hour In Recovery state because of my Multi Tb database size. I also tried to set the autogrowth to a specific size, but it all ended up doing the same: fill up the transaction logs until no space was left.
Finally, after days and nights trying and researching, I found the solution for my problem by installing the Cumulative Update 3 for SQL Server 2014 SP1
Best Answer
I've seen this occur when the file growth setting is set too high, so the growth event takes too long. Obviously this depends on your storage environment and performance details.
In my case, the 10% default growth rate was fine when the database was small, but at some point when the database got huge enough that the growth event took over 30 seconds, which was long enough that the original query timed out and rolled back. The rollback then cancelled the growth event, until the application re-tried the same query, and we got an endless loop.
So check your growth rates, or just pre-size your tempdb to a larger size.