SharePoint handles some index and statistics work through its own jobs, but the database still needs a DBA. SharePoint content databases need integrity checks, recovery coverage, and a practiced restore path.
Respect SharePoint's Own Maintenance
SharePoint uses its timer jobs and product guidance for index and statistics maintenance. I do not install a generic rebuild-everything plan over content databases without checking the supported SharePoint version and its health rules. The DBA still owns the SQL Server platform and recoverability. Coordinate with the SharePoint administrator before schema changes, maintenance jobs, or database moves. Direct changes to SharePoint tables are outside normal support boundaries. A content database is not an invitation to tune every index by hand.
Document which side owns each task. Ambiguous ownership is how both teams assume the other checked backups. The split should be visible in the runbook and tested through a real restore exercise.
Run Integrity Checks on SharePoint Content Databases
Schedule DBCC CHECKDB for every content database on a cadence that fits size and business criticality. Alert on failures and preserve output. I test the job against large content databases because an overnight CHECKDB can compete with backups and user traffic. If full checks need a longer window, design a staged schedule and record when each database receives full coverage. Do not replace integrity checking with a successful backup. A backup can faithfully preserve corruption.
Use a restored copy for deeper diagnosis if CHECKDB reports errors. Repair commands are not a routine first response. The restore plan and support guidance come before any operation that can lose data.
Back Up SharePoint Content Databases for Real Recovery Goals
Take full backups on a documented schedule and log backups when the database uses full recovery. Large content databases make backup duration, compression, file placement, and restore time important. I check the actual recovery point and recovery time requirements with the SharePoint owner. A daily full backup alone cannot meet a short recovery point objective under full recovery if log backups are missing. Keep the backup chain and encryption keys needed for restore.
Monitor log growth and log_reuse_wait_desc. A full recovery database without regular log backups can grow until storage is exhausted. Pre-size files and use sensible autogrowth increments; tiny repeated growth events do not make the database safer.
Report the SQL-Side Facts Per Database
The query below lists databases whose names match a SharePoint naming pattern. For each one it shows the recovery model, log reuse reason, last good CHECKDB time, and latest full and log backup times. Replace the name filter with your authoritative database list. A name pattern alone is not proof that a database belongs to SharePoint. I add the application owner and restore-test date from an operations register because SQL Server does not record a successful single-site collection restore in these system views.
SELECT d.name, d.recovery_model_desc, d.log_reuse_wait_desc,
DATABASEPROPERTYEX(d.name, 'LastGoodCheckDbTime') AS last_good_checkdb,
fb.last_full_backup, lb.last_log_backup
FROM sys.databases AS d
OUTER APPLY
(
SELECT MAX(backup_finish_date) AS last_full_backup
FROM msdb.dbo.backupset
WHERE database_name = d.name AND type = 'D'
) AS fb
OUTER APPLY
(
SELECT MAX(backup_finish_date) AS last_log_backup
FROM msdb.dbo.backupset
WHERE database_name = d.name AND type = 'L'
) AS lb
WHERE d.name LIKE N'WSS[_]Content%'
ORDER BY d.name;
Rehearse a Single-Site Recovery
A SQL database restore and a SharePoint site collection recovery are different tasks. Work with the SharePoint administrator to restore a content database to an isolated environment and recover one site collection through the supported SharePoint process. Time the full path, including database restore, attachment, permissions, and user validation. I keep the test record with the database name, backup set, site collection, date, and result. Do not infer that a single site can be recovered because RESTORE VERIFYONLY succeeded.
What would you do if one site were deleted today? The answer should name the backup, environment, SharePoint steps, and owner. That is a much stronger recovery plan than "the job was green."
Show Log Capacity Alongside Backups
Recent backup times do not tell the whole story for a large content database. Add log file size, growth setting, and log_reuse_wait_desc to the operational report. A full recovery database whose log backups fail can grow quickly even while its last full backup looks current. I compare growth with SharePoint activity and maintenance jobs. Large uploads, migration batches, or a stuck transaction can change the log pattern. Pre-size the log based on observed work and monitor free space; repeated tiny autogrowth events are a warning.
SELECT DB_NAME(database_id) AS database_name,
name AS file_name, size * 8.0 / 1024 AS file_size_mb,
growth, is_percent_growth
FROM sys.master_files
WHERE type_desc = N'LOG' AND DB_NAME(database_id) LIKE N'WSS[_]Content%'
ORDER BY database_name;The database-name filter is only a sample. Use your reviewed content database inventory for the real report. I keep actual measured sizes in the query result, not in article prose, because every farm is different.
Record the Restore Test Outside the DMV
SQL Server system views can show backup history and last good CHECKDB time. They cannot prove that a user restored and validated one SharePoint site collection. Keep a separate test register with database, site collection, backup set, test date, duration, approver, and outcome. Join that register to the database report if your team maintains it in SQL; otherwise present the two sources side by side. Do not fill the restore-test column with "passed" merely because a backup job ran.
What would the SharePoint administrator need from the DBA during a single-site recovery? Agree on an isolated restore location, permissions, version compatibility, and the handoff point. Rehearse the exact sequence. I have seen a valid database backup sit unused because the application recovery steps were never practiced. The joint test is what turns backup files into an actual recovery capability.
Record the date of the last restore test beside the last backup date. A fresh backup with a restore test from years ago leaves an important gap. I ask the SharePoint owner to validate a real site after recovery, including permissions and key content. The DBA can prove the database opened; the application owner proves the site works.
Review Growth of SharePoint Content Databases With Their Owners
Track content database size, log size, backup duration, CHECKDB duration, and restore-test age. A large content database can meet backup frequency but miss recovery time because restoring it takes too long. I discuss database distribution and site placement with the SharePoint team before the problem reaches an outage. Keep SQL maintenance compatible with product guidance while treating integrity and recoverability as DBA responsibilities.
The shared runbook should say which system checks each item and where evidence lives. SharePoint automation helps with its own housekeeping. It does not remove the need to prove that data can be restored.
Related reading on this blog: SharePoint not Working After Failover to Another Node and Account Added Automatically in SQL Server Used by SharePoint.
A SharePoint timer job is not a backup plan, it is index and statistics housekeeping.
Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.
