It appears that you have several issues, all of which perhaps may stem from the ever growing size of the database. It is possible that the database's EventLog table is rapidly filling up with the logging of errors such as the one that occurred when you tried to access the Admin --> Event Viewer. The database's SiteLog table is also a good candidate for easily becomming much too large, particularly if you have an active site and are retaining site visit information for more than a few days or if the scheduled job to purge this table is not running propery.  Likewise with the ScheduleHistory table. There is also the database's transaction log which can grow rapidly if database backups are not done regularly and the transaction log truncated.

Here's a link to a recent blog post by Sebastian which discusses database maintenance such as truncating the EventLog and SiteLog tables, backup and truncation of the database transaction log: http://www.dotnetnuke.com/Resources/B...

Regarding the error that was shown when you tried to access the Event Viewer, it appeared to be related to compression and whitespace filtering. I would suggest that under Host -->Host Settings, Advanced Settings you temporarily set compression to "No Compression" and uncheck the box "Use whitespace filter" to see if that error goes away.

---

Bill, WESNet Designs
Team Lead - DotNetNuke Gallery Module Project (Not Actively Being Developed)
Extensions Forge Projects . . .
Current: UserExport, ContentDeJour, ePrayer, DNN NewsTicker, By Invitation
Coming Soon: FRBO-For Rent By Owner

Troy,

This is indeed a huge ScheduleHistory table! It appears that the Purge Schedule History job has not been enabled to run regularly or is not running properly. Navigate to Host --> Scheduler and be sure that the Purge Schedule History job is enabled. The default frequency is 1 day. Click on the edit pencil beside this job to make changes if necessary.

Regarding the frequency of the Purge Log Buffer, Purge Module Cache and Messaging Dispatch, the 1 minute frequency is the default. I would check that each has a value of 10 or less for the Retain Schedule History setting. Once the Purge Schedule History job is enabled and working, that frequency should not be a problem.

Although it is a bit dated, the following article by Mitchel Sellers should help to explain some of the scheduler jobs and suggest best performance settings: http://www.mitchelsellers.com/blogs/a...

I would also enable the Purge Site Log job with a default frequency of 1 day. How many or over what period of time site log entries are retained is set in Host-->Settings, Advanced Settings, Other Settings.

There is no scheduled job available to purge the EventLog table so that one needs to be either done manually on a regular basis after looking through the Event Viewer for any errors or by running an externally scheduled SQL job. I think Mitchel either had or has a module available for free to do just that.

---

Bill, WESNet Designs
Team Lead - DotNetNuke Gallery Module Project (Not Actively Being Developed)
Extensions Forge Projects . . .
Current: UserExport, ContentDeJour, ePrayer, DNN NewsTicker, By Invitation
Coming Soon: FRBO-For Rent By Owner

Just submitted that last post and I realized the Sebastian addressed the transaction log in his post... I had to skip that piece of the maintenance because I don't have the logname of my transaction log.  I attempted to run the script using 'lampley' (the name of the db) but it failed.  Any ideas how I can dig out the logname? 

I'm hosted with Netwok Solutions.  To say that Network Solutions is less than helpful would be an understatement, I asked them to give me the name of the logfile a few weeks back and the tech told me that it doesn't have a name!  I laughed and asked to be transferred to his supervisor... then the supervisor refused to give it to me because I am not allowed to have access to it!  Rediculous! 

Troy