We all know proactive service when we see it. A couple of examples:
Proactive is when you are shopping for a new gadget, but just before you buy it the clerk tells you a special battery is required (even though the box fails to mention it) but is not included. “Would you like one of those as well?”
Proactive is a waiter asking his patrons if anyone has any food allergies so they can instruct the chef to alter a recipe.
When I purchase a car navigation system with installation, and the salesperson tells me that the installation may affect my car warranty so I should consult my dealer, that’s proactive service.
Proactive service is service that helps a customer in advance of a decision. Proactive service provides information instead of conclusions.
Proactive service is empowering.
PROACTIVE VS. REACTIVE
Reactive service disguised as proactive service can be a little harder to identify. When I take my car in for an oil change and the shop lets me know that my brake pads are worn through, it may seem like proactive advice.
Sure, they are providing necessary information I probably wouldn’t have discovered on my own until too late, but it’s not proactive information: the pads are already worn and I have no responsible choice but to replace them right away.
TRULY USEFUL DBA SERVICES
Because it’s my industry, I read a lot about proactive database monitoring and proactive DBA services. Too often the monitoring and services are really reactive services disguised as proactive.
Monitoring the alert log for ORA-00600 errors, monitoring the backup logs for failure, and raising an alarm when a tablespace is 95% full are all forms of reactive monitoring and support.
Don’t get me wrong: Good reactive monitoring is absolutely essential to a well-run database. But it isn’t proactive and shouldn’t be marketed as such. Reporting problems after they have already happened limits your choices.
Following update notes from Oracle and applying a patch to prevent an ORA-00600 is proactive.
Carefully managing space, equipment, and possibly software licensing to help prevent backup failures is proactive.
Monitoring space and segment growth trends (as opposed to arbitrary thresholds) will not only help prevent space problems, but will tell us if 95% full is something we even need to be worried about.
WHY THIS MATTERS
Okay, here’s a pop quiz: Which requires more attention, a 128mb tablespace that is 50% full, or a 2TB tablespace that is 95% full.
Answer? I certainly couldn’t tell with only those numbers, could you?
Without understanding the trend, all we can do is hope to react correctly. Point is, proactive service is preventative and allows for choice.
Reactive service, even though it may well mitigate imminent disaster, is not proactive.
IN DOLLARS AND CENTS
If you are paying for a service that claims to be proactive you should probably take a step back and make sure that’s what you are getting.
Remember the brake pad example above? Proactive service would have been someone (maybe that very shop) telling me three months ago during my last oil change that my pads were getting low and I should replace them at my earliest convenience. See, at that point I still have control and can decide when and where I want to have the pads replaced.
Are you getting that kind of proactive service? If you ask your provider to back up your database, do they ask what the recovery requirements are? If your database undergoes a sudden performance issue, does your DBA have a performance baseline already in place to see what “normal” looks like?
Good reactive service is absolutely necessary. We all want to know if a falling piano is about to flatten us. But if you’re paying for proactive service, just make sure your provider is pointing out the dangling piano a few blocks ahead.
Subscribe to Our Blog
Never miss a post! Stay up to date with the latest database, application and analytics tips and news. Delivered in a handy bi-weekly update straight to your inbox. You can unsubscribe at any time.
Most people will encounter this error when their application tries to connect to an Oracle database service, but it can also be raised by one database instance trying to connect to another database service via a database link.
Imagine over 100 logins on the source server, you need to migrate them to the destination server. Wouldn’t it be awesome if we could automate the process?