The Performance Analysis for SQL Server Quest_Performance_Repository transaction log is out of space at 52 GB even though recovery model is simple.
Why would it grow to this size? There are many auto grows from a specific date and time, at which time SC_MSSQL had a last wait type of SOS_SCHEDULER_YIELD and we were running DBCC CheckDB against the Quest_Performance_Repository database.
The reason is most likely due to running DBCC CHECKDB. Unless you stop all the repository managers before running the DBCC CHECKDB, there are still transactions occurring and will cause the log to grow because the DBCC command blocks log truncation until it has finished.
See this page for more info:
It is recommended to stop the QAM Launcher service on the middleware server before running DBCC CHECKDB on the repository database.