Skip to main content

Software  >  Tivoli  >  CCR2  > 

CCR2

A publication for the IBM System z software community

Tivoli software


Making IMS backup and recovery more efficient
from CCR2, Issue 10 - 2007

Bob Magid, Lead Architect for IBM IMS Tools, was interviewed for this feature.

Image copies help you recover a database after a data loss or programming mistake, and can also be useful for processing IMS data offline. Recovery technology has evolved to make image copies much faster and less resource intense, with substantial benefit over change accumulation. That means it’s time to reevaluate the way you prepare for database recovery.

Today’s FlashCopy and SnapShot storage technologies support extremely fast replication with minimal impact on IMS resources. If you need to recover your database, these image copies can deliver dramatically faster recovery time compared to a traditional change accumulation approach.

FlashCopy and SnapShot technology also simplifies IT operations, because they involve less tape handling than change accumulation and allow for more streamlined job control language (JCL).

Change accumulation was designed to speed recovery by processing database logs far in advance of a recovery event. In a data sharing environment with multiple systems accessing an IMS database, change accumulation gathers and sequences the online and batch IMS logs to collect all database changes in time order, so they are ready to use for recovery.

To recover the IMS database with change accumulation, the database administrator can rebuild the database starting with the last full image copy, apply the most recent change accumulation, and add any subsequent change logs created after the change accumulation.

As an insurance policy, the change accumulation process is resource intensive – too much so for some IT organizations. As an alternative, advanced copy services in IMS High Performance Image Copy for z/OS (HPIC) version 4 makes more frequent image copies practical by taking advantage of SnapShot capabilities in RAMAC Virtual Array (RVA) devices and FlashCopy (FLC) capabilities in IBM TotalStorage Enterprise Storage Server (ESS) and IBM Total Storage DS8000 devices. HPIC causes almost no disruption to your IMS resource for concurrent (fuzzy) copy, and only minimal disruption for non-concurrent (non-fuzzy) copy.

As an added benefit, HPIC can store its reports in the IBM IMS Tools Knowledge Base for z/OS. IBM developers are working to develop the IMS Tools Knowledge Base into a hub with details about IMS resources and tools that can drive autonomic processes and further increase your IT organization’s efficiency.

DUMP produces standard HPIC format
IBM High Performance Image Copy for z/OS (HPIC) offers two options via the global HPIC FASTIC parameter: DUMP and COPY. DUMP produces a queued sequential access method (QSAM) image copy format. COPY generates an exact replica of a virtual storage access method (VSAM) or overflow sequential access method (OSAM) database data set.

The HPIC DUMP image copy works like the image copy utility included in IMS, but replaces the IMS base utility processing with the DFSMSdss DUMP command. HPIC DUMP is compatible with other HPIC features, such as dual copy, compression, pointer checking/space monitoring and stacking. You can recover data sets using IMS standard recovery features or the IMS DataBase Recovery Facility for z/OS (DRF).

With this FASTIC option, HPIC takes an IMS database data set and passes it through HPIC advanced copy services to produce an image copy data set. (See Figure 1).

Figure 1: HPIC DUMP process
Figure 1: HPIC DUMP process

Producing an image copy using HPIC DUMP generates a data set faster than using a traditional IMS image copy, so your database maintains greater availability. In addition, you can recover a database much faster than you could with a change accumulation.

COPY generates fast recovery HPIC format
HPIC’s second image copy format option produces a recovery image optimized for the fastest recovery. Using the DFSMSdss COPY command, instead of the DFSMSdss DUMP command, a fast-recovery image copy takes a virtual storage access method (VSAM) or overflow sequential access method (OSAM) database data set, passes it through the HPIC advanced image copy services and produces an exact replica of the original data set in its original VSAM or OSAM format. (See Figure 2).

Figure 2: HPIC COPY process
Figure 2: HPIC COPY process

In addition, the VSAM or OSAM output image copy generates the same format as the IMS 10 fast replication Image Copy 2 format, which allows for seamless recovery using IMS 10 standard recovery features. The HPIC fast-recovery image copy is registered as a standard SMS offline (SMSOFFLC) non-fuzzy or online (SMSONLC) fuzzy image copy.

IMS 8 and IMS 9 register the HPIC fast-recovery VSAM or OSAM output image copy as an SMS non-concurrent image copy (SMSNOCIC) or an SMS concurrent image copy (SMSCIC). To recover the database with IMS 8 or 9, you’ll need to use the HPIC recovery function or IMS Database Recovery Facility for z/OS (DRF), instead of the standard IMS 8 or 9 recovery functions.

Key findings
IBM conducted performance tests comparing change accumulation and HPIC image copies. The study environment used IMS version 9, IMS Database Recovery Facility for z/OS (DRF) version 3, IMS High Performance Image Copy for z/OS version 4.1 (HPIC) and IMS High Performance Change Accumulation Utility (HPCA) version 1.4. The test used a 24-area IMS Fast Path Data Entry Database (DEDB) exceeding 1,000 transactions per second in a two-way IMSplex.

Key backup results include (see also Chart 1 and Chart 2):

  • Elapsed time: The average FlashCopy HPIC image copy had an elapsed time of just 0.7 seconds, dramatically faster than a typical IMS change accumulation. Two FlashCopy jobstreams, each with 12 areas, took a combined 37 seconds of elapsed time, while change accumulation for the same DEDB took dramatically longer – seven minutes and 21 seconds.
  • CPU load: FlashCopy had only minimal impact on IMS resources – less than a 3 percent decrease in transaction performance. The FlashCopy took about 2.5 seconds of CPU time, compared to more than 200 seconds of CPU for change accumulation.
  • I/O impact: Another metric, execute channel programs (EXCP) also showed dramatic benefit for FlashCopy backup. FlashCopy for the two areas took 4,000 EXCPs while change accumulation took 1.1 million.

FlashCopy backup
FlashCopy (HPIC) Elapsed time (seconds) CPU (seconds) Service Request Block (seconds) Total EXCPs
AREA 1-12 20 .52+
.60
IEESYSAS
.02+
.01
IEESYSAS
2,072
AREA 13-24 17 .49+
.59
IEESYSAS
.02+ .01
IEESYSAS
1,997
Chart 1: FlashCopy backup test results

Change accumulation backup
HPCA Elapsed time (mm:ss) CPU (seconds) Service Request Block (seconds) Total EXCPs
HPCA14 and CA140001 07:21 00:30.36+
02:54.41
2.81+
2.21
1,095,246
Chart 2: Change accumulation backup test results

When you need to recover an IMS database, time is of the essence. Key recovery results from this test include (see also Chart 3):

  • Elapsed time: Recovery using the FlashCopy took about half the time as with change accumulation. FlashCopy recovery was complete in seven minutes and 28 seconds, while the same recovery using an image copy and change accumulation as input to Database Recovery Facility (DRF) took 13 minutes 19 seconds.
  • CPU load: Using DRF, FlashCopy recovery took about a quarter of the CPU resources as change accumulation: about 3.5 minutes of CPU for FlashCopy versus about almost 16 minutes for change accumulation.
  • I/O impact: Recovery with a FlashCopy took about 61,000 execute channel programs, an indicator of I/O impact, while change accumulation took less, about 40,000. In these tests, this statistic was the only one that indicated more resources consumed for FlashCopy.

Database Recovery Facility (DRF)
Type Elapsed time (mm:ss) CPU (mm:ss) Service Request Block (seconds) Total EXCPs
DRF with Flashcopy 07:28 00:26.59+
00:60.44
(10 FRX addrspc)
.44+
115.93
(10 FRX addrspc)
60,544
DRF with Change Accumulation 13:19 11:52+
03:30
(FRX1-10)
.30+ 27.87
(FRX1-10)
39,775
Chart 3: Database Recovery Facility (DRF) test results

These IBM tests demonstrate on a small scale the benefit of using IMS High Performance Image Copy for z/OS V4.1 on one database. Extrapolating the results to hundreds of databases in an enterprise multiplies the benefits many times.

Try FlashCopy yourself on a small scale
As transaction processing grows, workloads will continue to grow. IBM’s IMS recovery study revealed compelling reasons to reconsider your recovery strategy to take advantage of the FlashCopy and SnapShot capabilities that may already be built into your storage assets.

You can start on a small scale with a single high update activity database to determine the resource utilization savings and recovery acceleration you could gain with a phased migration to IMS High Performance Image Copy for z/OS.

For more information:

IMS High Performance Image Copy for z/OS
IMS Tools Knowledge Base for z/OS
IMS version 10
IMS Database Recovery Facility for z/OS
IBM TotalStorage
Return to CCR2 Home Page

Related links
The Mainstream
Business journal for the System z community
Tivoli Beat
Weekly updates on the IBM service management perspective
IBM software for System z
The power to drive an enterprise
IBM Tivoli software
Intelligent management software for the on demand world
Tivoli Software Global User Group Community
Join your peers in our information and community hub
Open Process Automation Library
OPAL is Tivoli's worldwide online catalog with hundreds of technically validated, production ready IT Service Management integrated extensions provided by IBM and IBM Tivoli Business Partners.
Contact IBM
Considering a purchase?
Request a quote
Email IBM

Or call us at:
877-426-3774
Priority code:
109HJ03W




eNewsletter
Free eNewsletters!
Publications for the IBM Tivoli and System z communities
Learn more

Tivoli Beat
Hot off IBM Press: Implementing ITIL Change and Release Management. Tivoli Beat: Jan, 13
Click here for weekly insight on IT Service Management solutions

More offers