This is an entirely new install of SQL server of an entirely new server. The setup is intended to replace another ageing server and we are in the process of setting up the server environment.
Last Thursday we installed SQL Server and restored the clients database, but there are no [nil, none, not any, zero] client users, management jobs, or scheduled processes configured. Effectively the system is isolated from the world living in its own universe.
On Monday I got a shout from the systems team telling me an out-of-space alert had been raised from the transaction log drive and that it was nearing the top of its 80Gb capacity.
80Gb of transaction log seems like a lot for an untouched SQL database. In a live environment we will have management jobs running to backup the trans log every 15 mins so we will not see the issue.
Obviously something is running to cause SQL to write so much to the trans log. I am curious as to what it might be. Apart from anything else I always assumed that it is user activity and occasional DBA work that causes the translog to grow but it would seem that some part of the growth is due to something else.
Can anyone offer any insight, or suggest how I can analyse the transaction log contents to get a sense of what is happening?
UPDATE: Couple of updates from when I first wrote the question.
Why can't I examine the translog file - it had to be killed to get the space back - not my decision.
There is a VEEEM backup solution in play here. It turns out that the login credentials for VEEEM to access SQL server were not enabled with SQL Server access. The event log shows the VEEEM attempting to log in 4 times them abandoning. The disk space usage graph shows an almost exponential consumption of disk space.