SCCM DB question

Hi All,
Firstly I know very little about DB's so please be kind.
We are currently running SCCM 2007 SP2 R3 with FEP 2010 intergrated. SCCM's DB is running on SQL 2005 SP4. This has been running fine (just the normal issues) for over 2 years now.
I am using the SCCM task backup to backup the site to another server.
 
What has me concerned is I happened to look at the Site System Status for the primary site, while the main DB is only 14.5GB, the transaction log size is currently 726.9GB!!? That seems a little excessive to me. Now the server has been busy today so I'm going to monitor it and see if it a) shrinks, b) stabalizes or c) get bigger?!
 
I've been reading up a little and found a lot of people moaning that their transaction logs were over 10GB so I'm guessing something is wrong.
 
Could anyone shed any light on this, is it normal? (I don't think so). Suggestions to reduce or reset the logs? If it's not normal any idea why it's happened?
As always thanks :)

EDIT: As far as I know all the DB settings are STD as set by the initial install, nothing has been manually set. 
 
 

Holy crap, that seems really high!!!  I'm looking at mine right now, while my DB is only about 1GB which obviously means your environment is probably much bigger than mine, my transaction log is only about 380MB.  I can't really shed any light on the best way to fix that, only because I'm not really a SQL guy, just wanted to say that does not sound normal at all.

:) Something similar went through my head when I saw how big it was?!

Here's a thought.....do you have a SQL job running periodically that cleans up the DB, shrinks the logs, etc???  I know that on my Primary Site Server, we have those jobs running every night.

I have all the task turned on in [Primary > Site Maintenance > Tasks] apart from 'Delete Aged Client Access License Data' and 'Summarize Client Access License Weekly Usage Data'
 
If you mean a separate task setup to run directly against the SQL itself no, we were told that if we did anything directly with the DB then MS would not support us?!

This is TRANSACTION LOG for sure, not TEMPDB?  Man, I think that's pretty serious.  All data gets into the DB by way of the TxLog.  Until it writes data there, it cannot commit it to the DB.  Why can't the main DB keep up?  What's slowing it?  A slow disk subsystem?  An AV scanner?  

Hi Again,
Right the SQL 2005 is running on the same box as SCCM.
The SCCM console says' [Site_Name] Transaction Log'
The main DB also says 'Total: 14.5GB, Free: 315.9MB' but it is set to automatically grow and there is plenty of disk space to grow into.
 
Brian, I'll double check the box, but it was originally horribly over spec'd and it never seems to struggle. In fact normally it looks like it's not doing anything :)
So I think it's a config problem?! . . . maybe.
I'll ask our DB guys to have a look, they had previously been banned due to the obviously wrong information we'd been given.
 
I've attached a screenshot of the settings on the SCCM DB, maybe people could shout back with any differences from their own. Like I said this is a default installation, maybe we missed something in the documentation.

 
As always, thanks for your help.

Ok, I think I'm getting to the bottom of this now but I'd like to know how we got into this situation.
Firstly thanks to everyone for their help.
The DB is running in Full recovery not Simple mode, so that 765GB transaction log is all transactions since we put SCCM in!!
I've got one of our DBA's to truncate the log files and he has shrunk them down to 10GB (which is still 99% free). So this is now manageable.
 
The last question really is as this was a default install, the SCCM installer set the DB to 'Full recovery' not Simple. Should we have changed this? If so could anyone point out in the documentation where it is?
It would seem that the SCCM backup doesn't truncate the logs before backup which makes sense if it should be in Simple mode.
 
If I can find anything in the white papers of MS documentation I will do as Ryan suggested and set to Simple. If it's not in the documentation then I wonder how many other SCCM DB's are out there like ours?!

Well that's pretty good enough for me. I'll watch till this time next week then change the mode to simple. If anyone does find this written down please post it here.
 
Thanks again to everyone!!

That explains it.  And I'm not sure the CM docs bother to mention it because you can still restore from a full backup set.  The point of a full for SQL guys is that you could say I need to restore at a certain point in time.  That part CM doesn't do.  So there is no point in doing a full.  Simple also has the benefit of allowing that Txlog to be flushed and get small again.

Thanks Brian, I'll get my new friendly DBA to look at that tomorrow :)