By default, DotNetNuke installations are configured to retain a fair amount of log data - site logs, scheduler logs, and event logs. This is of great importance when debugging a new installation, but in an established installation, this data becomes less important, and more of a liability. In a corporate or intranet installation, the amount of data may not pose as great an obstacle as with installations on shared hosting servers. The amount of data can be limited in three steps, and in doing so, will actually improve the performance of your site.
Side Note:
Some steps require executing SQL in the DotNetNuke database. This can be achieved by using Enterprise Manager (EM) for SQL Server 2000 databases, Management Studio (SSMS) or Query Analyzer (QA) for 2005 databases, or the SQL utility in DNN (Host -> SQL). If using the DNN SQL utility, be sure to check "Run as Script". Your web hosting provider may also offer SQL administration and execution tools.
1. Purge the Database Tables
If your DNN installation has been running for any amount of time, you will have built up log data. You will want to either purge or delete some of the data in these log tables. Consider using one of the following SQL examples.
Example 1.A
truncate table EventLog
go
truncate table ScheduleHistory
go
truncate table SiteLog
go
Example 1.B
delete from EventLog where LogCreateDate < (getdate() - 7)
go
delete from ScheduleHistory where EndDate < (getdate() - 7)
go
delete from SiteLog where [DateTime] < (getdate() - 7)
go
In Example 1.A, the truncate step clears the tables, and, because it does not have to record the transaction in SQL Server, is instantaneous. However, db_owner privileges are required.
In Example 1.B, the delete statement is used to only delete data older than 7 days. Because this operation requires transaction logging by SQL Server, running this statement will take longer than a truncate, and may timeout in a web-based SQL utility.
2. Limit the Event Log
Whether you use the Log Viewer or not, events will be captured unless you instruct your DNN installation not to. Again, this is incredibly useful when installing a new module, or verifying your install, but, as you'll see, it borders on overkill.
Log in as the administrator or host, and navigate to Admin -> Log Viewer. One of two things will happen - either you will see many colorful rows indicating the many events, or you will get a timeout exception. If you get an exception, you will need to purge the EventLog table in the DNN database.
You will also be able to clear the event log by clicking the Clear Log button, or select the events you wish to delete, and click Delete Selected Exceptions.
To configure the event log, and reduce the amount of logging, click Edit Log Configurations at the lower left-hand corner. Here, you can edit the various Log Types. First, you may wish to disable the APPLICATION_START and APPLICATION_END events, especially if you are on a shared web hosting server, where the application can start and stop frequently. Also, the "*" Log Type captures many events, and is enabled by default. This should be disabled or restricted.
Click the Edit button beside each Log Type you wish to configure, and either enable or disable, or configure the history for each event. The DNN Scheduler will purge older data, which will be explained next.
3. Schedule History
The DNN Scheduler controls numerous events, including the various purge jobs by default. To view the Scheduler information, navigate to Host -> Schedule.
If the Site Log is enabled at the Host and Admin levels, the Site Log purge job should be enabled. Click the Edit button next to the Scheduler Type "DotNetNuke.Services.Log.SiteLog.PurgeSiteLog, DOTNETNUKE", and check the Schedule Enabled checkbox. The default settings will purge site logs daily, for information older than that allowed by the Host.
You can also purge the Schedule History by enabling the Scheduler Type "DotNetNuke.Services.Scheduling.PurgeScheduleHistory", or restrict the data kept.