My employer has a freeware utility you can run on your network to find and document instances of SQL Server. One of SQL Server’s primary advantages is also one of its primary disadvantages – you can spin one up in a manner of minutes.
To grow deals at a company buying our SQL Server software, we’d offer to document their servers for them. They would claim they only had 10-15 instances of SQL running. We’d run our utility and return with closer to 100-150 instances. Oops!
I was recently asked if we had a similar tool for Oracle. I was a bit taken aback, and my gut reaction wasn’t a very good one.
Wait a sec, most orgs know EXACTLY where they have Oracle running
To answer the question though, “No, we do not have such a tool. This is not a primary concern for our Oracle customers.” But, I was curious and really wanted to find out if there was such a tool, or if DBAs worried about such matters.
A quick Google proves mostly unfruitful. I found one promising lead via a blog post in 2005 from Oracle security expert, Pete Finnigan. Unfortunately going to the download page prompts me for a login, although to be fair it is over 6 years old.
So, am I naive to think that it’s much harder to sneak an instance of Oracle database onto a network? A quick Twitter conversation sprouted up, and apparently it does happen. Or at least, production DBAs are rudely awakened to the presence of unknown databases popping up. Oh, and people normally find these databases when the owner sticks their neck out and asks for help.
What do you do after you find them?
To the victor go the spoils? Do you really want ownership of a database that probably hasn’t been well maintained? In terms of job security I would think having more resources in your domain would be a good thing. On the flip side, most Oracle DBAs aren’t exactly short on work.
A lot of sites have an Enterprise agreement with Oracle that allows them to deploy an unlimited number of databases. Users hear this, and then decide to build a local application using Oracle, and the word never makes it to the IT Support team. The company starts to rely on the service this new app is supplying, and all of a sudden IT is now responsible for another database it never even knew about!
Again, this is a scenario I hear over and over in the SQL Server world. Usually it involves 3rd party vendor apps that use SQL Server. But is this problem just as rampant in the Oracle world? Share your horror stories, and better yet, let us know how you audit your Oracle installs. Have a script, use a tool? Don’t be greedy now!