www.ibm.comLANDP Webpage

LANDP SHFILE Data - Forward Recovery

Introduction

The LANDP Shared File server provides a high degree of data integrity with its concept of 'units of work.' However, it is wise for you to define a process that protects the data by taking regular back ups of important files. You do not need to back up all the files that the Shared File server uses. However, it is important that you do not lose the files with the DAT extension including LOG.DAT.

To perform a back up you should close the Shared File server using the RF function. This prevents any further updates or deletions. Once you close the Shared File server you can then back up all files with the DAT extension. You do not need to back up the index files (*.ix*).

The basic concept of the Shared File server is that the data is written to flat files that the server holds tightly through the operating system I/O functions. You can use a standard tool, of your choice, to back up or restore the data files. The LANDP Shared File server reads the contents of these files at load time and restores the database to a fit state. This session looks at the back up and restore processes and demonstrates what can happen when various files are missing because they were not backed up.

What you need to know before you begin

This tutorial uses the Shared File configuration that exists for the Installation and Customisation tutorial.

Summary of Steps

The Normal Restoration Process

In order for us to keep this tutorial short and simple we will use a small database. If you have previous run the Installation and Customization tutorial or any of the other Shared File server tutorials you will need to:

The actions listed above create a blank Shared File server for you to work on. We need to add some data records to the Shared File server to create a database for us to back up. Using SVPCPRBN you should add ten records to the database. You should keep the content of the records simple so that you can easily check that the data is correct after we restore it. After adding the records, you should commit the data, end the transaction and close the Shared File server using the RF function.

Now we need to unload LANDP using EHCFREE. This makes sure that the Shared File server does not hold any of its associated files. Create a directory C:\DATABAK and copy into it the files:

You do not need to copy the index files (*.IX*) as the Shared File server can rebuild these at load time. Once you copied the files to the back up location, delete the files from C:\LDPSHFL and the log file from C:\LDP.

If you load LANDP at this point no data files will exist and as no log file exists the Shared File server will not create any new data files.

For you to restore the data from our back up, you need to:

Now the data files and the log file but no index files exist.

What do you see when the Shared File server loader statement is executing?

Which file is being read at load time to recover these files?

Use SVPCPRBN to examine the database after recovery.

Summary

From the above exercise you can see that the LOG.DAT file is vital for the normal back up process. This has all the information regarding the transactions that the Shared File server performed. The Shared File server may take some time to complete the recovery process if the log file contains many transactions. If you take back ups infrequently you may experience long delays if the Shared File server needs to perform a recovery. A decision on how often a back up should be made depends on several factors:-

The restoration of lost data files

After the last exercise your Shared File data files should contain 10 records and you should also have back up copies of these files in C:\DATABAK. In this exercise you will see how a missing data file affects the Shared File server, and how you recover this situation.

First, you will need to create the situation where a data file is missing. You can do this by these steps:

What do you see when the Shared File loader statement is executing?

Which file is being read at load time to recover this file?

Use SVPCPRB to examine the database after recovery. What happens when you use the GN or GP functions? Try adding a record using IS, does it work? What happens if you add a record with the same data as previously entered before the data files were removed?

Summary

When the data files are lost, the Shared File server creates new files when it is loaded. However, these files contain no data. If you attempt to read the contents using the GN or GP functions the Shared File server returns the error code, 'GB.' This return code means that the Shared File server can not find any records. You can add and read back new data records but the original records are lost.

You can see that recreating a new data file, 'LDPDATA.DAT' does not restore the database even though the original log file exists. To use the entries held in the log file, you need to perform another process before you load LANDP.

How to recover the data. Part 1 - The Theory

As already explained above, the data is not recovered if LANDP is reloaded, even though the 'LDPDATA.DAT' is recreated. The next instructions explain how to you can use the log to recover the 'lost' data. These steps explain the process, do not run DBRESTOR at this time.

DBRESTOR will read the back up log file, LOG.OLD, and enter the transactions from this file to the Shared File server. Using DBRESTOR with the /F option will read the current log file, LOG.DAT and enter the transactions from this file to the Shared File Server.

How to recover the data. Part 2 - The Practice

To examine the use of DBRESTOR follow these steps:

Now only the log file, C:\LDP\LOG.DAT, remains. All the data files and index files are lost.

Watch the screen whilst Shared File is loading.

Use SVPCPRB to check the database contents.

Restoration of lost LOG.DAT file

In this exercise, you will examine the effect of the a missing log file, and how you can recover this. First, you need to create the situation where the log file is lost:

When the Shared File loader statement is executing what do you see? Use SVPCPRB to examine the database after loading.

Summary

As you can see, losing the log file does not mean you lose any data. You can create a new log file quickly and the you can access the existing data. The problem is that the new log file contains no entries for past transactions. Therefore, if you lose a data file and the log file it will be impossible for you to recover the data. Even if the back up log file, LOG.OLD, exist you can not fully restore the data file. Therefore, to ensure that no data is lost, you must back up both the data files and the log file on a regular basis.

Summary

As you can see from these exercises, if you lose certain files, a recovery is possible. If you lose all three files and you do not have an back ups then nothing can be done. But the loss of an individual file is not a disaster.

To summarise:

Introduction New to LANDP? Make the most of LANDP Solving LANDP problems Feedback