Appendix A. Top 25 DBA worst practices

While there may be some disagreement on best practices, there is usually no argument on worst practices, some of which are listed below (in no particular order):

1.  Not considering service-level agreements (SLAs) when designing a database environment and/or not considering the need for scheduled downtime for various maintenance activities, such as the installation of service packs.

2.  Defining “disaster” too narrowly and not simulating/practicing a disaster recovery (DR) plan. Having a DR plan is fine, but how do you know it will work (and several people can follow it) when required?

3.  Designing a storage system from a capacity perspective alone.

4.  Assuming a storage area network (SAN) will meet/exceed performance requirements. Just because SANs are (typically) expensive, it does not mean the storage design process can be skipped.

5.  Failing to track-align disk partitions and/or formatting them with the default allocation unit size (4K).

6.  Using RAID 5 volumes for write-intensive applications.

7.  Failing to validate an I/O subsystem for performance and validity before production implementation.

8.  Virtualizing/consolidating SQL Server instances and databases without consideration of the scalability, licensing, support, administration, and performance profile implications.

9.  Installing service packs, cumulative updates, or hotfixes without reading the release notes and/or not installing them in a test environment first.