Common Human Errors as DBA (part 2)


Eliminating Human Error

You must have read my previous post (Part-1) about Common Human Errors as DBA and how to avoid them. Here is another post of the same series. Third error –
Data or Log file Shrinking – sometimes, one may not be checking how much free space is available in data or log files and shrinking databases again and again. Or setting ‘Auto Shrink’ database option to true is equally harmful; this is harmful especially in high transactions environments or with large databases. Remember, if you grow your database by small increments or if you grow it and then shrink it, you can end up with disk fragmentation. Disk fragmentation can cause performance issues in many circumstances. So, to avoid this, you must always have monitoring in place. You can use custom scripts or any other monitoring tool to achieve this task.

Setting database recovery option to ‘Full’ – A common mistake is when recovery option of a database (or Model database) is set to ‘Full’. And a DBA is never taking transaction log backups. In such cases the transaction log file size grows 100 times to actual data due to backup negligence. As a DBA, you must ensure that database recovery model is selected as per or according to requirements. And a backup policy must be planned accordingly. So, to prevent this you can create some weekly or daily checks, some reports, and some job alert.

I will try to post some more Human Errors in last and part 3. Stay connected!

Now, you can follow on Tweeter at @DBATHINGS

  1. […] In continuation of the series of “Common Human Errors as DBA” – here I am posting Third Part of it. You may check others here. Part 1 & Part 2 […]