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.

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?

Designing a storage system from a capacity perspective alone.

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.

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

Using RAID 5 volumes for write-intensive applications.

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

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

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

Installing all SQL Server features on the off chance they may be needed at some point in the future. Doing so increases the attack surface area and results in running unnecessary services that may reduce performance.

Installing multi-instance clusters without considering the resource implications of failover situations.

Creating logins/jobs with elevated privileges. Implementing least privilege can be tough work, but it's essential in locking down a system for maximum security.

Changing configuration values from their default settings without adequate research and/or a detailed change log.

Placing data and transaction logs on the same physical disk(s).

Storing backups on the same disk as the database files.

Relying on autogrow for file sizing, and leaving the tempdb database at its default size.

Not making backups and/or not checking their validity and/or not practicing and documenting various recovery situations. All of these are equally bad.

Leaving the database in the full recovery model without taking transaction log backups.

Implementing database mirroring in high-safety (synchronous) mode without considering network latency and/or transaction log usage from index maintenance.

Not running regular DBCC checks.

Running REPAIR_ALLOW_DATA_LOSS as the primary/default recovery response, and not following up corruption events with a root-cause analysis.

Not evaluating index usage and/or fragmentation levels as part of an index-maintenance routine.

Updating statistics using the default sampling rate after a full index rebuild.

Using SQL Profiler in place of server-side traces, and using it as the primary performance analysis/tuning technique.

Doing manual administration with SQL Server Management Studio. For maximum efficiency and minimal errors, tasks should be scripted and automated, and you should employ appropriate monitoring and alerting mechanisms such as MOM or SQL Agent operators and alerts.