I’m a simple guy. I like things simple. I once had a consulting gig with a client who wanted to do something that I thought was quite simple.
But before I tell you what this simple thing is, I respectfully ask that you be seated.
The client entrusted me with the migration of one of their mission critical apps running 8i on HPUX to — drum role please — 9i … on … IBM Mainframe running os390 (z/os). For those who aren’t familiar with this battle–tested industrial–strength hardware, read here. For your added pleasure, read this article about the the mainframe world that came out today on CNN. You can see that it is indeed alive and well.
I had never worked on a mainframe before. Heck, I’m a young lad, and I’ve been brought up to laugh at these old hunks of metal. I was quickly put through mainframe initiation, which is a little odd, because you need to learn that os390 is a Dr. Jekyl/Mr. Hyde kinda apparatus. It’s something like two OSes running simultaneously together (as opposed to simultaneously on the same box but separately). It’s just odd and it took me a while to wrap my mind around it. But I did, and now I am a member–for–life of the reclusive club of mainframers. We wave at each other as we pass on the street.
In any case, the current production environment was composed of HPUX boxes running 8i and 9i. I can’t imagine how expensive the Oracle licensing must have been, but based on the sheer number of machines, I know Oracle was a happy supplier. Which brings me to the central point — unless you’re the one actually paying the bills, you don’t really realize that Oracle is quite expensive. While you do get what you pay for in terms of robust infrastructure, there are ways to lower the cost.
For this client, we were able to shave $600,000 (not just the Oracle license, but also the external costs of maintaining the environment) by migrating just one HPUX machine over to the mainframe with maybe 30 or more to go. All of them were scheduled to move over to the one mainframe with one Oracle license and one environment to manage.
I’m not here to convince you that mainframe is the solution to the world’s Oracle licensing cost problems, but if you’re in the “we have 30 machines each running Oracle” space, then I think it makes sense for you to seriously consider it. Add to that the benefits of all the control you get over the environment, it makes for a compelling story.
P.S.: In case any of you are planning such a migration, one thing I should point out about it: if you use import, then there’s a brutal bug that creates the initial extent of every object in the database with a minimum of 1MB. So, if you have scads of tiny objects taking up a few kilobytes, be prepared to account for this in your space requirement calculations.
P.P.S.: Trivia: Did you know that the government of Canada runs the busiest Oracle–on–mainframe environment in the world? It does!
talking about bringing down license costs – the Solaris 10 container/ zone model will help shave off some per CPU costs if your Oracle Server does not utilize all the CPU resources.
Yeah, it’s pretty significant. Now, imagine you had 10 of these servers and you could move all of your machines’ work to ONE mainframe? While JCL is not my cup of tea, i can see why there are so many people drinking it! It’s saving on a completely differnt scale.
To be clear, you’re running virtual machines on the z/OS, and the cost savings is because you’re eliminating the “base” cost of the other machines? For example, a 32-processor Oracle license on z/OS might be cheaper than 4 16-processor licenses on HPUX, and you can set up 4 virtual machines on the z/OS that, say, pool CPUs to provide each VM with 16 virtual processors?
Hey Mr. Ed. It’s Yes, and No. Yes the base costs have been eliminated, however, the greater cost savings was due to the license. The single multi-CPU license covering all the vm’s vs many licenses was the deciding factor. My understanding was that you could provide each VM with a specific resource set (MIPS), so you can can actually let them have access to an actual number of CPU cycles, as opposed to processors.