Industry: Radio and television toll collecting agency
Demo and Expert Talk at GEZ: Reduction of DB2 Copy Time by 90%.
GEZ in Cologne have nationwide responsibility for collecting radio and television service charges in Germany. GEZ manages over 42 million users and copes daily with approximately 80,000 letters/faxes, processed electronically, and 14,000 telephone calls. Two years ago they met the challenge to convert the core applications from IMS to DB2. During July 2005 they hosted a z/OS user group meeting onsite where their experiences were discussed.
Amongst other things in this huge conversion project, there was a critical requirement for a copy and migration tool to move and distribute considerable amounts of DB2 data for the test groups. Later, in production, the tool would be required to regularly generate shadow systems for parallel queries and statistical analysis.
BCV5 from UBS Hainer was selected from the tender process and is now in service over a year at GEZ. Initially BCV5 was used to continuously refresh the DB2 test databases and currently in production it now maintains several shadow databases. “We are pleased to have made this decision with BCV5 which has ensured the success of the route taken”, said Bernhard Danneberg, project manager at GEZ. “The product met our expectations fully. Twelve months ago we only knew that we were facing a Europe-wide challenge regarding fast generation of DB2 data copies.” More than 250 external specialists and developers were involved in the overall project, among them 50 IBM consultants.
During the development and test phases GEZ operations had to maintain 27 DB2 subsystems, each with about 40 databases. Twenty (20) of these are bigger than 30GB and 15 have more than 120GB – the 8 core databases contain user data of over 40 million accounts and exceed 1,2 TB.
During the evaluation phase all known vendors of DB2 tools in the z/OS marketplace were asked for proposals. At the end of the review process, BCV5 was the only product which met the stipulated migration requirements. Alternatives either could not achieve the aims from the outset or the vendors, despite their intensive endeavors and full support from GEZ, were not able to demonstrate a successful solution.
The primary condition for the success of the project was the continued availability of the source system during any database migrations/copies. In any one day the system must always have a minimum 22 hours continuous availability. This made BCV5 the only viable solution.
During a discussion period one of the attendees posed a question on the time and effort to prepare a copy. Bernhard responded that “after a half hour hands-on briefing you are able to successfully copy databases”. He continued “Installation isn’t easier with any other product we reviewed on the z/OS market. The BCV5 interface is designed to rapidly achieve success using just a few panels. Some other utilities we reviewed from other vendors had upwards of 70 definition screens.”
Another attendee wanted to know if a copy required the structure and data to be copied collectively? From their own requirements and experiences Bernard was easily able torespond “No. We decide what is to be done. It is important to us to be able to segregate these targets – sometimes we only want to copy the structure, sometimes only data, but mostly both. And we have those options with BCV5.”
Since the initial tests at GEZ over a year ago, BCV5 has delivered more than 450 database copies, partly ad hoc and partly scheduler driven, i.e. about 1.5 copies a day. Execution-time benchmarks of the copies have shown runtimes of 90% less compared to other practices. The copy takes currently just 19 minutes. This significant reduction in migration runtimes ensures compliance with the business continuity requirement of the minimum 22 hours availability of all source systems.
There was enthusiastic discussion amongst the attendees and below is a just an extract from some of the technical questions & answers on the day:
Does GEZ take image copies as sources for copies?
Not currently. As GEZ writes the backups on tape the copy time would take too long. BCV5 is able to use image copies as source data, and as Gerd Hettling from UBS-Hainer explained, it then automatically determines the last written full copies. There is also a function to synchronize full or incremental copies with the aid of the DB2 log. This function is particularly of interest for all those who work in pure 24×7 environments and can not stop the source to gain a clean copy.
What about the renaming of objects?
Yes, this is important and is possible with BCV5. There are panels to specify renaming rules of the target objects.
After a fast copy the RUNSTATS utility may need extensive time to execute. Is there a way to copy the RUNSTATS information as well?
Yes, this function can also be used ‘stand-alone’, i.e. without a preceding copy of objects one can copy ‘runstats’ from a source to a different target system and target renames will be applied.
How does BCV5 treat views and indexes?
Views, triggers, and with some limitations procedures can be copied. Indexes can be copied or automatically recreated at the target system – the latter is particularly helpful for indexes which occur only on the target side.
We heard about significant lowering of the copy time but what about resource consumption?
Very similar to the runtime stats – we see a reduction of around 90% compared with other methods measured in SSU/SRU or CPU seconds. [/slider]