

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
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
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:
|
|
Free eNewsletters!
Publications for the IBM Tivoli and System z communities |
|
 |
|
|
|
|