Dealing with a wide variety of databases, platforms and versions is a reality for many companies. While it would be nice to be able to have one platform to handle all tasks necessary within an organisation, the reality is that different needs require different solutions. As a result, we create (or at least are forced to work with) diverse systems.
A variety of systems can be great for providing solutions which might not be easily available within one database platform. Unfortunately, this diversity also can bring unwanted complexity to the database management process. When a system becomes too complex, it can sometimes feel like you are losing track of the needs and goals of the organisation. While solving one problem, another problem occurs in a different database, which behaves entirely differently than the one you are working on.
Problems start to snowball, and you feel like you are losing your grasp over the multitude of systems.
In order to address this, we need to step back and make a list of the various things that can go wrong.
As many in the therapeutic fields state, “the first step is recognising that you have a problem.”
Okay, you’ve already reached that point (otherwise why would you be reading this?). So let’s get to the second step; at this point we need to figure out and document what the problems are; we can’t get started solving problems unless we know where they exist, right? Only after we understand what the pitfalls are in our database management process can we begin to map out solutions.
Complex Environment
We often don’t have the option of having our entire of array of databases running the same platform, or even if we do, they are likely not all running the same system. You may have systems any combination of SQL Server, Oracle, Sybase, PostgreSQL, MySQL or more (not to mention MongoDB or other NoSQL databases).
We could also be hosting different instances on different virtual servers; often in multiple locations. Each of these platforms may have useful tools for tracking down these problems, but they don’t all work for all systems. Simply trying to keep track of everything slows pretty much everything down.
Ineffective Use of DBA Time
Your DBAs may be spending a lot of time fixing a small, but pesky problem, but miss the fact that there’s a larger systemic problem that may be more important in the long run.
For example, maybe there is an annoying problem where an index keeps getting dropped on one particular table. One of your DBAs sees this, and rebuilds it, and moves on to something else. It gets dropped again the next day, and another DBA fixes this. Or maybe it gets dropped in the middle of the night, and nobody knows why; it happens silently, but the system has slowed down and the next day time gets wasted trying to find the cause.
While working on individual problems, it may be missed that there’s a fundamental issue with the database structure itself. Perhaps a larger fix, which may take a little more time, may solve the problem once and for all. While this might be caught by someone paying attention at a specific time, it’s quite easy to miss these, so the same work gets repeated over and over again.
Troubleshooting Time
Often, as is described above, it’s difficult to see what happened. The DBA is staring at the problem without seeing a larger picture of why it occurred, so he or she spends a lot of time trying to track down the root cause. There’s no overview so unless detailed notes are kept (in ways that everyone understands), the same process will likely need to be repeated each time it occurs.
Firefighting Becomes The Main Focus
Instead of being able to perfect a particular database, there’s little time for planning, tuning, and much less redesigning databases as putting out fires as they occur becomes a daily activity. Simply the process of having to take your attention away from a project can slow you down in exponential ways.
Even if a fix is quick, the time and energy spent solving problems (especially if they are complicated ones) can be extremely distracting. Simply getting back into the groove on the original project takes time, and it becomes even worse if something else goes down on a different system, server, or DB instance.
At the end of the day, there is virtually no time to do any preventative maintenance or improve the overall flow of your procedures. Even if you manage to come up with a few good scripts that can handle some of this, one that will work on Oracle will not work on SQL Server, and definitely not on PostgreSQL. The complexity itself becomes the enemy.
Finding Answers
The first step is to remember these two words:
Don’t Panic.
Simply understanding where the problems are can go a long way to helping you find solutions, and we are already partly there. Most of problems associated with complexity tend to stem from each other.
What you need is overview.
One of the main problems in a complex system is not knowing what is happening to all of your systems at once. It is the classic problem of only seeing the trees, but not the entire forest.
If we can find a way to step back and see the entire forest at once, patterns will begin to appear. Ideally it would be great to have the ability to have only the responsibility to pay attention to the larger picture without getting stuck in the mud of individual issues, however as we know, that’s typically not an option.
Also, even then, you’d still need a way of viewing all of these issues at once, rather than poring through logs just to find patterns. See where I’m going here?
The main point is that you need to be able to see what is going on you need is a good tool. Software that can enable you to take a step back. Maybe this isn’t your primary role, but if problems can be spotted before they arise, then half of your problem is solved.
This tool needs to be able to examine multiple systems and platforms at once. Instead of jumping from one tool to another, each of which has a different interface, functionality, and with varying options for customisation; it’s best to have something that can give you a high-level view of all of your systems.
Once we have this, the rest of the problems start to solve themselves. If we can spot problems before they exist, there’s better communication and less need for firefighting.