Use multiple Oracle instances in the same machine instead of multiple virtualized hosts in the same machine.

Intro

I read an article in Computer Sweden today where Kappahl couldn’t do virtualization of their Oracle databases because of expensive licence costs. (article in swedish) In this article, I would like to offer a simple and cheap option to Oracle virtualization.

Why virtualization?

Organizations want to virtualize their Oracle databases for many reasons, one being to reduce license costs. Other reasons include reducing hardware costs and making it easy to add new databases.

Simply put, hardware virtualization is basically about exchanging many physical servers for a single big server.

Illustration of virtualization

You may prefer the wikipedia definition of virtualization, but mine is short, sweet and simple.

The alternative solution

Instead of doing Oracle virtualization using VMWare or Oracle VM, you can install several Oracle instances in a single Oracle installation, in a single machine. This is not what people usually mean when they say virtualization, but you get many of the benefits this way, and it will reduce your Oracle license costs!

Pros

• Still easy to start/stop individual instances
• Still easy to add/remove individual instances
• Still easy to configure memory and disk usage per instance
• No need to learn/buy any virtualization technique

Cons

• All instances will run on the same Oracle binaries, meaning all will run on the same Oracle version (some may consider this a benefit, when you’ve reached it…)
• All Oracle instances will run on the same OS.

Real world experience

I have seen this work very well, especially for testing and development installations. Virtualization of databases in a production environment may not be as common, but there’s no reason it shouldn’t work there aswell.

I am for hire

If you want my help with your Oracle environment – don’t hesitate to contact me!

FUNCTION getFullName(iUserId IN INTEGER) RETURN VARCHAR2
IS
BEGIN
   --TODO: Implement this
   RETURN "";
END getFullname;

Instead of writing it like that, consider using a table.column definition as type for your parameter! This way, if you change your table, you will not also have to change your code!

Example:

FUNCTION getFullName(iUserId IN SIGNUP.ID%TYPE) RETURN VARCHAR2
IS
BEGIN
   --TODO: Implement this
   RETURN "";
END getFullname;

Now, if you for some reason change the ID column in the SIGNUP table to be something other than INTEGER, you can leave the code as is! Much more DRY!

I currently have an assignment where there is a large PLSQL code base. It’s been developed actively for about 12 years and works quite well. I am not saying it’s flawless, but quite mature. There’s lots of room for improvement and lots of dead code that needs to be removed.

Some of the plsql is called from the Java DAO layer of a front-end web application, but most of it is used for backoffice functionality. The parts that are accessed from the Java layer are tested through integration tests based on JUnit, but the large part that is only used from the backoffice has no unit test coverage.

Doing something about it

I’ve known about the utPLSQL framework for many years, but never gotten around to actually use it in a Continuous Integration environment. I decided it was time to do something about it and started by adding the installation of utPLSQL to the already in place automated database reinstallation build. The installation part was quite easy, I just dropped the utPLSQL install scripts into our own source control repository and made it part of our db install. Uninstalling utPLSQL was a bit tricker since it creates public synonyms and those are not dropped when the Oracle db user/schema is dropped. (And that’s how we “uninstall” our other schemas normally.) And if I let those public synonyms stay there, I would get errors on the next install. So I simply need to create a small script that dropped those public synonyms as part of the uninstall/install (reinstall ) process.

After utPLSQL was part of our db installation, I created a couple of sample utPLSQL tests and tried them out. No problems there. I could run them from the SQL prompt without problem. But what I really wanted was to make them part of the build process in Hudson. So I started writing a JUnit test that would wrap the utPLSQL tests and then it would be runnable from Hudson.

After I while it struck me that I was writing something that someone else had probably written already and after a quick google I found the maven-utplsql-plugin. (insert holy graal sound here) Since we use Maven for the builds, this seemed like a perfect match. However, there were some pitfalls.

Some pitfalls

The maven-utplsql-plugin is currently not available in any public Maven repository. So, I had to download it and install it add it manually to our local Maven repo. The only problem was that our Maven repo was setup not to accept SNAPSHOT releases, and since we didn’t want to change that, I had to HACK the source files in the zip file and replace SNAPSHOT with STABLE in order for our Maven repo to accept the new artifact. In fact, this may lead to that I have to do some contributions to the dev team of the maven-utplsql-plugin to get it up to a RELEASE version and maybe even up on a public repository?

The happy ending

Finally, I added a new task to our db-reinstall profile in Maven. The new task simply calls the plugin which runs the tests. SUCCESS!

My sources

This guy got around to doing this a lot sooner than me: http://www.theserverlabs.com/blog/2009/05/18/continuous-integration-with-oracle-plsql-utplsql-and-hudson/

Here’s the Maven plugin for utplsql: http://code.google.com/p/maven-utplsql-plugin/

The utPLSQL project: https://sourceforge.net/projects/utplsql/

Hoping it will give me some good insights and opportunities related to a BI project at Expekt.com.

Will let you know if Oracle are evil bastards or just misunderstood capitalists.