By definition, once work has been submitted to the database and before the throughput and response time can be measured, something must be done to process the request. This "something" in the database performance world is called resource usage. In an attempt to over simplify things, there are two types of resource usage--good and bad. The good resources are those that are used in a positive way to produce the results; the bad are those resource usages that get in the way of good resources being used. The good could be actual disk reads that need to be done. The bad could be locks on objects that are in the way of reading data.
The good use of resources can be further broken into two types of usage, normal use and over use. Normal use is the perfect, limited consumption of a resource to produce a result. Over use is the bad side of resource usage where a resource is used beyond the desired amount. Whether a lot of good resources or a lot of bad resources are used, when mapped against time, that usage results in utilization. Typically, the resource hog or bottleneck in the system can be found if one looks at the resource with the largest utilization.
It took from sunup to sundown to put the lights up. The time spent was just over 7 hours. If everything within that seven-hour interval were mapped, time spent eating, talking, and resting would probably be tracked. If more time were spent talking than working, an over usage of a resource would take place, and a bottleneck in the light hanging would occur.
It is common knowledge that databases tend to be temperamental at times, networks go down, disks crash, and even databases crash sometimes. When resources, for whatever reason, take a vacation and inhibit any work from getting done, it is called a resource availability issue. A resource can only be available or unavailable and is measured as the amount of time it is available to work on requests. When a resource is available, it is known as uptime. When a resource is unavailable, it is downtime.
If a lot of holiday cheer were consumed while putting up the lights, several trips to the bathroom would probably be made. These trips resulted in downtime, no pun intended.
Not only do database systems crash, from time to time they produce errors. This has a direct correlation to database reliability. The ability to detect and predict the probability of errors is paramount.
After the seven-hour ordeal of hanging the lights, it is noticed that a few bulbs are out, and a few half-strands are unlit. Do not be the type of database guru that says a few burnt out lights are not noticeable. Take action and engage additional resources to fix the problems, or the problems will persist.
Everyone in the database community slings these terms around; the question is, do they understand them completely? Look at a few scripts to determine where they fit within the framework. At the least, you will understand your system better.
See All Articles by Columnist James Koopmann