The Do’s and Don’ts of DNN Database Maintenance

A DotNetNuke (DNN) website can appear healthy while its database gradually becomes slow, bloated or difficult to recover. Content versions, event logs, abandoned user records, scheduled tasks and third-party modules all leave traces behind. Regular database maintenance keeps the portal responsive and reduces the risk of an avoidable outage.

For Australian organisations, reliability often has a practical business impact. A customer portal serving Sydney during the morning peak may be used by staff in Perth later the same day, while regional offices may depend on slower connections. A well-maintained database helps pages load consistently across those locations and supports teams working across AEST and AEDT.

DNN maintenance also belongs within a wider governance programme. Australian businesses may need to consider the Privacy Act, Notifiable Data Breaches obligations, industry retention rules and security controls aligned with the Essential Eight. Database housekeeping should therefore protect performance without destroying records required for compliance or reporting.

The strongest approach combines automation, testing and human oversight. Routine checks should be predictable, documented and suitable for the organisation’s hosting model, whether the portal runs on Microsoft Azure, a private data centre or infrastructure managed by an Australian IT partner.

Understand what the DNN database contains

Before removing anything, map the database and identify the role of each major table. DNN core tables, module data, portal settings, user profiles, permissions, workflow records and audit information should be treated differently. A table that looks inactive may support a reporting tool or a custom extension used by a finance team in Melbourne or Canberra.

Review database growth over time rather than relying on a single size measurement. Transaction logs, search indexes, event logs and content history can grow quickly on busy portals. Sudden growth may indicate a failed scheduled task, excessive logging, a runaway integration or a module that is repeatedly writing duplicate records.

Document the retention purpose for each category. Keep legally required information, preserve business-critical history and define deletion windows for disposable records. This simple classification prevents a well-intentioned cleanup from creating a compliance problem.

Do schedule backups and test recovery

Create frequent, automated backups that match the portal’s recovery point and recovery time objectives. A nightly backup may suit a low-traffic intranet, while a customer-facing application may require more frequent protection. Store copies separately from the production environment and restrict access to authorised administrators.

A backup is useful only when it can be restored. Test recovery on a non-production server, validate database integrity and confirm that the restored DNN installation can authenticate users, load modules and publish content. Include media files, configuration files, encryption keys and custom code in the recovery plan.

Record the steps in language a support team can follow during pressure. An operations runbook should state who approves a restore, how the database is brought back online and how stakeholders are updated. This is especially valuable when an Adelaide office, a Brisbane partner or an after-hours support provider needs to act quickly.

Don’t make direct changes in production

Avoid deleting rows, changing schemas or editing settings directly in production unless the action has been reviewed and documented. Manual SQL can bypass DNN permissions, module logic and audit trails. A query that appears to remove old accounts may also affect ownership, workflow or personalisation data.

Use a development or staging copy to assess every cleanup script. Take a verified backup first, run the script against representative data and compare row counts before and after execution. Where possible, use supported DNN administration tools, vendor-approved upgrades and controlled migration scripts instead of improvised database edits.

Do not assume that a fast query is a safe query. Test execution plans, watch locking behaviour and schedule heavy maintenance outside important service windows. An Australian retailer may have a quiet period in the early morning, but that window should be checked against Western Australia, Queensland and daylight-saving differences before it is treated as universal.

Keep integrations, modules and content aligned

Third-party modules often create their own tables, indexes and scheduled jobs. Before upgrading or removing a module, check its documentation and export any required configuration. A database cleanup that ignores a custom integration can break CRM synchronisation, payment workflows or document publishing.

Review scheduled tasks and failed jobs as part of routine maintenance. Repeated failures can fill logs, consume processing capacity and create duplicate records. Track the source of each job, its expected frequency and the business owner responsible for resolving errors.

Content workflows deserve the same care. Remove obsolete drafts and expired items only when the business has approved the retention policy. If the portal supports downloadable documents, verify that associated files remain available and that staff can use essential functions; even a related process such as restoring high-resolution printing may depend on reliable document handling around the portal.

Build a practical maintenance checklist

A repeatable checklist turns database administration into a normal operating task rather than an emergency response. Assign ownership, set review dates and keep evidence of completed checks. The following actions provide a sound baseline for many DNN environments:

• Verify recent full and transaction-log backups, then schedule periodic restore tests.
• Review database size, index fragmentation, failed jobs, event logs and unusual query activity.
• Test proposed cleanup scripts in staging and obtain approval before production execution.
• Check DNN core, module and integration compatibility before applying upgrades.
• Confirm that retention, access control and incident procedures reflect Australian privacy and security requirements.

Review the checklist after major portal changes, acquisitions, new integrations or shifts in traffic. A business expanding from a single office in Sydney to teams across Hobart, Darwin and Perth may need different backup windows, support coverage and performance thresholds.

Give your DNN environment a structured health check, validate its recovery process and turn database maintenance into a documented part of operations. Aricie’s DNN expertise, custom software capability and professional training can help Australian organisations keep their portals secure, stable and ready for day-to-day business.