The SLOs create the rules of the game that we are playing. We use the SLOs to decide what risks we can take, what architectural choices to make, and how to design the processes needed to support those architectures.

Debugging is like being the detective in a crime movie where you are also the murderer…

The key to making programs fast is to make them do practically nothing!

why GNU grep is fast

The great liability of the engineer compared to men of other professions is that his works are out in the open where all can see them. His acts, step by step, are in hard substance. He cannot bury his mistakes in the grave like the doctors. He cannot argue them into thin air or blame the judge like the lawyers. He cannot, like the architects, cover his failures with trees and vines. He cannot, like the politicians, screen his shortcomings by blaming his opponents and hope that the people will forget. The engineer simply cannot deny that he did it. If his works do not work, he is damned. That is the phantasmagoria that haunts his nights and dogs his days. He comes from the job at the end of the day resolved to calculate it again. He wakes in the night in a cold sweat and puts something on paper that looks silly in the morning. All day he shivers at the thought of the bugs which will inevitably appear to jolt its smooth consummation.

On the other hand, unlike the doctor his is not a life among the weak. Unlike the soldier, destruction is not his purpose. Unlike the lawyer, quarrels are not his daily bread. To the engineer falls the job of clothing the bare bones of science with life, comfort, and hope. No doubt as years go by people forget which engineer did it, even if they ever knew. Or some politician puts his name on it. Or they credit it to some promoter who used other people’s money with which to finance it. But the engineer himself looks back at the unending stream of goodness which flows from his successes with satisfactions that few professions may know. And the verdict of his fellow professionals is all the accolades he wants.

-Herbert Hoover

Jessica Flack: I believe that science sits at the intersection of these three things — the data, the discussions and the math. It is that triangulation — that’s what science is. And true understanding, if there is such a thing, comes only when we can do the translation between these three ways of representing the world.

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

In security, there is no right or wrong; there is only conformance or non-conformance to agreed procedures.