Every product has a story, but DB-Genie's is a little unique. We hope you enjoy this quick history of how DB-Genie was conceived.
DB-Genie came about as a need by two DBA's, myself and Bob Walter. Even though the shop we were working in (a major telecommunications company) had every product under the sun from various vendors and all of those products somewhat addressed our need, they were far from being able to satisfy our requirement.
Our need was to be able to successfully pass a Disaster Recovery test, but at first we didn't realize that. Our application was brand new too. There were over 100 applications in the company that were going to participate in the DR test, but our senior management told us our application was too new to participate. Assuming our efforts would be a total failure at the DR test due to the infancy of our application, our direction was to continue to work on finalizing the development effort. We didn't think much of this at first, so while other applications were ramping up and preparing for the big DR test at Comdisco using all the expensive vendor products, we just kept our heads down doing our DBA work to support the development efforts of our application. We figured that next year maybe we'll get to participate in this widely publicized event called a "DR test".
Soon after we were told to skip the DR test, we were trying to run image copy utilities on a development database that had over 500 tablespaces. Not a huge environment, but not small either. Naturally, we tried using all of the vendor products that were at our fingertips and we quickly realized a major gap in how those products try to create utility strategies. The development team pressured us to be able to back up this development environment and because our expensive vendor products really couldn't support that simple requirement in a timely or efficient manner, we started coding our own scripts to perform the JCL to run the image copies.
We joked often about how simple it should be for these giant software vendors to be able to write a product that creates utility JCL efficiently, while we were writing our own scripts. Once we finished creating our scipt in a few days, in a matter of seconds it created a balanced set of image copy jobs for those 500 tablespaces. We ran the image copy strategy on that development database and it was successful.
As time pressed on, we kept adding functionality to these scripts for every day tasks that a DBA would want to do. Our ongoing comments to each other were, "Would a DBA want to do that? Then let's put it in there.". So we were literally writing a product from the ground up as DBA's, for DBA's and we didn't even know it yet.
Well, that image copy utility strategy went so well for the development effort that we approached our senior management again about the big DR test coming up (in just a couple weeks at that point). We told them that we felt the database was sound for our application and we'd like to participate in the DR test if at all possible. Management told us it was OK and showed us all our options from the vendor software products that we could use in setting up our DR strategy (image copies and recoveries). Knowing that we had already created a set of scripts, we let this discussion go in one ear and out the other. We knew we weren't following instructions from management by using our homegrown scripts, but we were tired of the vendor products and were curious to see how our scripts would perform.
The big day came and we showed up at the DR testing facility as prepared as we could be with the strategy our scripts had created. We knew that days prior we executed a balanced set of image copy and recovery jobs for our application. We had absolutely no idea what was going to happen, but our curiousity was intoxicating. We knew that of the 100 or so applications there with us, only a few were truly revenue generating like our application. So the time requirement that most applications had to be up and running was 48 hours or more. Of the few revenue generating applications, like ours, we only had 24 hours to be back up and operational.
As the test started, we kicked off our recovery jobs. Knowing that we had created our recovery jobs in the exact same order as our image copy jobs and that we coded steps in between each recovery job step to retain tape position, well, our recoveries flew! Our entire application was up and operational in just 8 hours, even though we had 24!
The next week, the post mortem discussions were taking place about the DR test and we heard something we couldn't believe. Not one application was able to be up and running in their required timeframe, except ours. Quickly, very quickly as you can imagine, all the focus was directed at us. "What the heck did you guys do different?" everyone said. They were all asking how we used the vendor products so differently to experience such a different result. We said we didn't use them at all and even though management was not thrilled with that response, they wanted to know more about how we wrote our scripts. We explained how we used load balancing and list processing in that meeting and management said "If you ever sell it, we will buy it".
And you can guess what happened next, DB-Genie was born.