DBA Tasks
| Task |
Reason |
Period |
| dbcc checkdb, checkcatalog, checkalloc |
I consider these the minimal dbcc's to ensure the integrity of
your database |
If your SQL Server permits, daily before your database dumps. If
this is not possible due to the size of your databases, then try the
different options so that the end of, say, a week, you've run them all.
|
| Disaster recovery scripts - scripts to rebuild your SQL Server in
case of hardware failure |
Always be prepared for the worst. Make sure to test them. |
|
| scripts to logically dump your master database, that is bcp the
critical system tables: sysdatabases, sysdevices, syslogins, sysservers,
sysusers, syssegments, sysremotelogins |
You can selectively rebuild your database in case of hardware failure |
Daily |
| %ls -la disk_devices |
A system upgrade is known to change the permissions. |
After any change as well as daily |
| dump the user databases |
CYA |
Daily |
| dump the transaction logs |
CYA |
Daily |
| dump the master database |
CYA |
After any change as well as daily |
| System 11 and beyond - save the $DSQUERY.cfg to tape |
This is the configuration that you've dialed in, why redo the work? |
After any change as well as daily |
| update statistics on frequently changed tables and sp_recompile |
To ensure the performance of your SQL Server |
Depending on how often your major tables change. Some tables are
pretty much static (e.g. lookup tables) so they don't need an update
statistics, other tables suffer severe trauma (e.g. massive
updates/deletes/inserts) so an update stats needs to be run either
nightly/weekly/monthly. This should be done using cronjobs. |
| create a dummy SQL Server and do bad things to it: delete
devices, destroy permissions... |
See disaster recovery! |
When time permits |
| Talk to the application developers. |
It's better to work with them than against them. |
As time permits. |
| Learn new tools |
So you can sleep! |
As time permits. |
| Read c.d.s |
Passes the time. |
Priority One! |