Let's face it, managing a database environment can be very difficult to do. Who amongst you as a database administrator (DBA) has constantly found yourselves reacting to each situation that occurs? The table runs out of storage near budget time, and when fixing it, you find there is no room left on the disk to expand the tablespace the table is in. By now, you are in a panic mode, trying to find some place to put the data file in, but there isn't any room left (anywhere). Why didn't we buy some more disk when we had the chance? Have you asked yourself this question? That's right, you never had time to request it, because you were too busy fixing problems.
As a database administrator, you will find that you are constantly fire fighting, sometimes controlling the blaze but never putting it out. Only by moving to a proactive environment can you overcome the burdens and inefficiencies of the reactive environment you might be in, and in doing so, enter an optimally controlled and managed one. Such an environment offers many benefits, including a reduction in database downtime, a finely tuned database and an improvement in productivity.
So, why the need to always react? The answer is found in the work practices of the environment. Taking a step back and then looking at how you are doing your work is the first step, but more on this later. Let's first have a look at why this situation has occurred.
With the need to cut back on resources and increase productivity, the workload of the DBA can be cut first, because it is seen as not directly benefiting the client. With the resources cut right back, only activities which are seen to be important can be focused on.
Let's have a look at two typical scenarios that are most likely to be encountered:
The users of an application have complained bitterly to management about its slow performance. Management is now asking you to drop everything and fix it as a matter of high urgency. This means spending a large amount of time tracking the problem. This involves looking to see there is a problem with the tuning of the application, a problem with the tuning of the database, or if there is insufficient machine capacity. In all cases, it is up to you to find where the fault is, and this takes time.
A table modification change is urgently required in the production database. The users are in desperate need of it. As the DBA, you were just told to implement the change and take it for granted that it will not impact the database. As it is urgent, there is no time to properly review what is happening in the upgrade. The next day the discovery is made that the upgrade has forced some tables to dramatically increase in size, and there is a critical shortage of free space left, and this now has to be addressed.
In both cases, time and effort is being spent doing extra work, which could have been prevented with the right amount of planning.
So, to do your job properly requires a fundamental change in how you do your work, with the aim to become proactive. The goals are simple but can be difficult to implement:
Anticipate and prevent problems before they occur
Optimally tune the database
Optimally manage storage
Optimally tune the network
Minimize impact to the database
There are numerous challenges following such goals. Optimally managed resources ensure that the environment is efficiently tuned and managed. Also, an optimally managed environment ensures that your resources are used efficiently and cost effectively.
Minimizing impact to the database involves reducing the amount of maintenance that is applied to the database. This, in turn, will ensure that there is an increase in uptime for the database and reduce the risk of an error; especially, an error resulting from fatigue caused by working on the database at odd hours of the night.