Monday, April 25, 2011

Innovator-C: Put Your Money Where Your Mouth Is

I've been talking a pretty big game about Innovator-C and how you can use it in production even though some Growth Edition and Ultimate Edition features are not available and the amount of memory and CPUs you can use are limited.

2 weeks ago that talk stopped being just talk and became reality as we turned up our first Innovator-C HDR pair of production database engines.

The server ain't big (1 Quad Core CPU, 2GB SHMTOTAL and RAID10 over 4 disks), but it cranks out 4 million transactions and 500,000 new session requests per day (and the box is bored and typically 99% idle).

This database was a perfect fit for Innovator-C. The data set isn't so large that we need to worry about partitioning data and it is all OLTP so not having PDQ isn't show stopper. Recovery Time Objective would have been nice, but using the CKPTINTVL isn't a big deal. The only thing I'm really sad about not having is Direct I/O for cooked chunks, but whatever. I can live without it (just don't understand why this is disabled in Innovator-C).

Innovator-C can be used in production for free which makes for a pretty good ROI and a low cost per transaction for us.

$0.00 / 4 million transactions / day is a pretty good number and is sure to put a smile on the face of your company's bean counter(s).

After the migration we noticed performance improvements in the app that now runs on a dedicated engine and in the apps that run on the old server because the load is now shared by 2 servers.

As you might expect with Informix, the migration was painless. During our most recent meeting my boss announced to the team, "You may have not noticed, but we migrated the API databases to a new set of servers two weeks ago and there haven't been any issues. Is that right? None? That is surprising, you would expect something would come up with a migration this big. Good job guys."


  1. Hey, 4 million trs / day seem nice for a free database software!

    By 4 million transactions / day do you mean atomic SQL transactions, or transactions in a business process involving potencially multiple sql transactions and out of transaction queries?

  2. When I say transaction I'm talking about the number of commits, which can involve multiple SQLs but typically is a single insert, update or delete in my environment.