Hey Tim,

The transaction logs will fill the database space and not the disk space.  This is because an increasing transaction log won't automaticly increase the size of the database the same way that just normal use will.  So if your DB is currently say 10 GB and the transaction log (which is basicly a complete copy of your database) pushes the total DB size above 10GB then there is no space left to write more transactions and an error is generated. Eventually there won't be room enough to write normal data and the transaction log and your site will go down.

I would follow Scotts advice.  You need to find out which stored procedures or schedule is running so much there are tools oout there that will be able to show you.  There might even be messages in your system event log.  Once you know which procedures are the problem figuring out a fix is probably pretty easy. 

I don't know how you have the DB architected, but with big databases like yours the defaults are not really workable.  At the very least the disk configuration should probably be raid 5 and you should be using multiple DB files.  watch the physical size on disk of those files also.  I would probably limit the size to less than 2GB.  All this will just make queries and logging run much faster.  If you have just the default database settings you could be running into time out issues with queries.  I'm not sure how DNN would handle that. deleting the 35GB of log data will probably help you out a little bit.  :)

I isolated my SQL CPU usage to a single processor now, and it is at 100% CPU forever.. like 3 days straight. 

I went to Host->Schedule  and I noticed that the "DotNetNuke.Services.Search.SearchEngineScheduler, DOTNETNUKE"  had durations of 10697.953875 ms   Sometimes it would success, quite often it would not.  The START and END times sometimes were 2 hours apart.

I just disabled that and I am going to restart DNN (and MSSQL) and see if that had any effect.