25 Things I Wish You Knew About Databases

Oracle will do what you tell it to do. I find that PEBCAK is often the root cause for many issues.
DBAs get paid for performance, but we keep our jobs with recovery.
HA <> DR. If you can’t recover, you can’t keep your job. See previous item.
Memory, CPU, disk, and network are all finite resources. Leave room for growth.
95% of all workloads will run just fine on modest hardware. Don’t listen to fools that architect crazy solutions for edge cases that won’t happen.
Backups. You need them. Store them someplace safe, and on a different server. See number 2.
Maintenance is mandatory. Find, or make a maintenance window.
But you can always blame the network anyway 🙂
Know the RTO and RPO for your applications. See number 2.
Focus on wait events and logical I/O when performance tuning. They help you find the root cause the fastest.
The only way to know your backup succeeded is to test by doing a restore. See number 2.
Build a recovery strategy BEFORE you build a backup strategy. See number 2.
Baseline for performance. Without baselines and metrics you have no idea if something is truly a problem or not.
Keep your transactions short.
Triggers are awful, awful little creatures.
But NULLs are far worse.
If your DBA can’t work a command line, don’t let them touch your data.
Great database performance starts with great database design.
Deadlocks are often the result of application logic and data access patterns. The engine doesn’t just get “tired” and start deadlocking.
Testing against 10, 100, and 1000 rows is not an accurate test against a production workload.
Application code is responsible for 100% of all performance issues. #hardtruth
Keep as many of your servers configured in the exact same way. This saves time troubleshooting.
Data lasts longer than code. Treat it right.
Don’t install services (SSRS, SSIS, SSAS) onto a server “just in case”. Only install the services that are needed.
If your vendor requires the use of the ‘sa’ account, go find another vendor.