Today’s businesses depend heavily on their databases. Should applications and data become unavailable, the entire business may halt. Revenue and customers may be lost and penalties may be incurred. Bad press can have a lasting effect on both customers and stock prices. Certainly, providing continuous data availability is essential for today’s businesses.
The key to making programs fast is to make them do practically nothing!
Chapter 1: Databases with cool sounding names
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.
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.
It’s hard to believe that Microsoft is 41 years old. In that time, its had its ups (think Windows XP with around one billion sales) and its downs (think Windows ME, which lasted for less than 18 months). But one thing that’s clear is Microsoft has cleverly re-invented itself, re-booted and disrupted its own business in a massive way. Some would argue Microsoft is now “cool” again.
We were hiring developers for a large, complicated application. I happened to mention to one of the more promising candidates that the application was fairly write-heavy and we might experience some performance concerns later. This developer, with years of experience and skills across multiple technologies that might have been of use to us, replied “you’re going to either need to shard your database or switch to NoSQL.”
That was enough to guarantee they didn’t get the job.
Before relational databases, all databases were NoSQL. That’s why we have relational 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.
In the beginning was the disk array, and all was empty and raw, and Unix moved over the face of the platters. And the DBA said: Let there be Oracle. And there was Oracle. And the environmental variables were set and the disks were striped and mirrored and the OFA was established, and behold spindle was rent asunder from spindle. And the DBA saw that all was in spec.
And it was day and it was evening of the first day.
And the DBA said: Let there be scripts. And sql.bsq brought forth myriad crawling things upon the face of the array. And catalog.sql brought forth all manner of tables and views that swim unseen beneath the waters. And catproc.sql brought forth all the built-in programs and all the hosts of the air, that the users might be given wings and take fight over the data.
And it was day and it was evening of the second day.
And the DBA said: Let there be tablespaces. And there were tablespaces. And the network administrator looked upon the disk array and did see what the tablespaces had wrought upon the disk arrays, and he did gnash his teeth and seek a new work upon the Internet with an engine of search.
And it was day and it was evening of the third day.
And the DBA created users. Male and female he created them. And he said unto the users: Thou mayest create tables and views as thou wilt. Yea, though mayest create even indexes upon the data. Only meddle not with the system tablespace, for it is a holy place, and on the day wherein thou treadest upon it, on that day thy create session shall surely be revoked. And the serpent crept among the users and whispered to them, saying: Thine roles shall not be revoked. Taste ye all of the system tablespace, for ye shall know of b-trees and hints and ye shall be as DBAs. And the users heeded the serpent and filled the system tablespace with crap. And the instance did crash and the client did wax wroth at the DBA. And the DBA did gnash his teeth and partake of the fruit of the vine, for behold the users were permanent employees and the DBA was but a contractor and could not revoke their create session.
And it was day and it was evening of the fourth day.
And the DBA did set default tablespaces and temporary tablespaces and did lock down all that was upon the face of the array with roles and profiles and all manner of quotas, yea even from the rollback segments even unto the archived redo logs.
And it was day and it was evening of the fifth day.
And the DBA created synonyms and links and did tune the server and apply patches upon the face of the database.
And it was day and it was evening of the sixth day.
And on the seventh day the DBA did rest from all the labors of the creation. And his pager did ring and he ceased from resting and did spend his sabbath on the telephone with Oracle support. And by the time the DBA got through to someone who knew whereof they spake behold it was day and it was evening of the eighth day.
And the DBA waxed wroth.
Now working towards the OCP…