Data recovery - Revision history

Dme: /* Using backout */

2019-08-03T14:54:57Z

Using backout

← Older revision		Revision as of 14:54, 3 August 2019
Line 159:		Line 159:
	<tr>		<tr>
	<td>Manual </td>		<td>Manual </td>
	<td>Using the ~~BACKOUT~~ statement within a request. </td>		<td>Using the <var>[[#backoutStmt\|Backout]]</var> statement within a request. </td>
	</tr>		</tr>
	</table>		</table>
Line 171:		Line 171:
	<li>If there is a file integrity problem</li>		<li>If there is a file integrity problem</li>

	<li>If <var class="product">Model 204</var> is restarting a user who has an active update unit		<li>If <var class="product">Model 204</var> is restarting a user who has an active update unit
	</li>		</li>
	</ul>		</ul>
Line 181:		Line 181:
	<li>The current update unit is backed out automatically.</li>		<li>The current update unit is backed out automatically.</li>

	<li><var class="product">Model 204</var> returns to the terminal command level unless an ON ERROR or ON ATTENTION unit is invoked.		<li><var class="product">Model 204</var> returns to the terminal command level unless an ON ERROR or ON ATTENTION unit is invoked.
	</li>		</li>
	</ul>		</ul>
Line 187:		Line 187:
	Remote updates are backed out automatically when appropriate.</p>		Remote updates are backed out automatically when appropriate.</p>

	===Manual backout===		===<b id="backoutStmt"></b>Manual backout===
	<p>		<p>
	You can backout an incomplete update unit by using the ~~BACKOUT~~ statement. This statement is valid only for updates to transaction backout files. </p>		You can backout an incomplete update unit by using the <var>Backout</var> statement. This statement is valid only for updates to transaction backout files. </p>
	<p>		<p>
	The ~~BACKOUT~~ statement releases the exclusive lock on updated records and backs out the current update unit. No found sets are released and the current record does not change.</p>		The <var>Backout</var> statement releases the exclusive lock on updated records and backs out the current update unit. No found sets are released and the current record does not change.</p>
	<p>		<p>
	After the ~~BACKOUT~~ statement is processed, evaluation continues with the next statement. A message is displayed to the user upon the successful completion of a backout operation.</p>		After the <var>Backout</var> statement is processed, evaluation continues with the next statement. A message is displayed to the user upon the successful completion of a backout operation.</p>
	<p>		<p>
	The ~~BACKOUT~~ statement is supported in remote context. If records on any remote nodes have been updated, the ~~BACKOUT~~ statement causes all remote updates on all remote nodes to be backed out, in addition to any local updates.</p>		The <var>Backout</var> statement is supported in remote context. If records on any remote nodes have been updated, the <var>Backout</var> statement causes all remote updates on all remote nodes to be backed out, in addition to any local updates.</p>

	====Example====		====Example====
	<p>		<p>
	The ~~BACKOUT~~ statement is typically used in data entry applications where a transaction might have to be backed out after it has updated a file (for example, a sales or airline reservations application). </p>		The <var>Backout</var> statement is typically used in data entry applications where a transaction might have to be backed out after it has updated a file (for example, a sales or airline reservations application). </p>
	<p>		<p>
	An example of a request that uses the ~~BACKOUT~~ statement is provided below.</p>		An example of a request that uses the <var>Backout</var> statement is provided below.</p>
	<p class="code">BEGIN		<p class="code">BEGIN
	<b></b>*		<b></b>*
Line 264:		Line 264:
	END *		END *
	</p>		</p>

	==Design considerations for transaction backout files==		==Design considerations for transaction backout files==
	<p>		<p>

JAL: /* Ending a non-backoutable unit */

2014-02-06T17:05:39Z

Ending a non-backoutable unit

← Older revision		Revision as of 17:05, 6 February 2014
Line 132:		Line 132:
	<p>		<p>
	A non-backoutable unit ends when the unit is committed by using the COMMIT statement. Other conditions (such as an END statement in a request or the BACKOUT statement discussed later in this page) also can end an active update unit.		A non-backoutable unit ends when the unit is committed by using the COMMIT statement. Other conditions (such as an END statement in a request or the BACKOUT statement discussed later in this page) also can end an active update unit.
	Refer to [[File integrity ~~and_recovery~~#Update units and transactions]] for a complete list of conditions that start or end an active update unit. </p>		Refer to [[File integrity and recovery#Update units and transactions\|Update units and transactions]] for a complete list of conditions that start or end an active update unit. </p>

	==Using backout==		==Using backout==
	<p>		<p>

JAL: /* Ending a backoutable unit */

2014-02-06T17:04:58Z

Ending a backoutable unit

← Older revision		Revision as of 17:04, 6 February 2014
Line 121:		Line 121:
	<p>		<p>
	A backoutable unit ends when the unit is committed by using the COMMIT statement or is backed out. Other conditions (such as an END statement in a request or the BACKOUT statement discussed later in this page) also can end an active update unit.		A backoutable unit ends when the unit is committed by using the COMMIT statement or is backed out. Other conditions (such as an END statement in a request or the BACKOUT statement discussed later in this page) also can end an active update unit.
	Refer to [[File integrity ~~and_recovery~~#Update units and transactions]] for a complete list of conditions that end an active update unit. </p>		Refer to [[File integrity and recovery#Update units and transactions\|Update units and transactions]] for a complete list of conditions that end an active update unit. </p>

	===Non-backoutable units===		===Non-backoutable units===

JAL: more conversion cleanup

2014-01-17T22:53:05Z

more conversion cleanup

Show changes

Admin: Admin moved page Data Recovery to Data recovery without leaving a redirect: title caps

2014-01-02T21:02:59Z

Admin moved page Data Recovery to Data recovery without leaving a redirect: title caps

← Older revision	Revision as of 21:02, 2 January 2014
(No difference)

Alex: Automatically generated page update

2013-04-20T13:18:08Z

Automatically generated page update

New page

===Overview===
If hardware or software failures occur during the process of updating <var class="product">Model 204</var> files, database integrity problems can arise. These problems result from the fact that updates to a file can require coordinated changes, and a failure can interrupt the process of writing to storage a complete set of these changes. 
Normally in a <var class="product">Model 204</var> installation, the system manager is responsible for the coordination of recovery activity for the installation, and the file manager determines which recovery features are applied to each of the files. 
For a complete description of the <var class="product">Model 204</var> recovery process, refer to the Rocket <var class="product">Model 204</var> File Manager's Guide.
====Transaction back out====
One of the recovery features that can be selected by the file manager is an integrity facility called transaction backout. This facility can reverse the effects of an incomplete transaction (a sequence of file updating operations). 
====Application considerations====
Although the file manager determines whether the transaction backout facility is defined for a file, the application designer must understand the facility's capabilities and requirements in order to ensure file integrity for an application. 
This chapter explains those capabilities and requirements and describes how applications can be designed to ensure file integrity. In particular, see the last section in this chapter for application design considerations.
===Transaction backout===
The transaction backout facility allows <var class="product">Model 204</var> to logically reverse the effects of an incomplete update to a file. 
A backout can be initiated only on incomplete update units; completed update units cannot be backed out. A backout can be automatically performed by <var class="product">Model 204</var> or initiated by the user. 
====FOPT and FRCVOPT parameters====
Transaction backout is an option of the FOPT and FRCVOPT parameters and is enabled or disabled on a file-by-file basis. Refer to the Rocket <var class="product">Model 204</var> Parameter and Command Reference Manual for more information on these parameters.
====Types of backout====
You can use the transaction backout facility to specify two types of files: 
<table>
<tr class="head">
<th>backout
file types </th>
<th>
File options set to...</th>
<th>
Discussion</th>
</tr>
<tr>
<td>Transaction backout </td>
<td>Enable both lock pending updates and backout. </td>
<td>
A transaction can be backed out automatically by <var class="product">Model 204</var> or manually by the application. 
A transaction backout file ensures:
Logical consistency
Data and file integrity,
High degree of data sharing.
</td>
</tr>
<tr>
<td>Non-transaction backout</td>
<td>Disable transaction backout. </td>
<td>
Incomplete updates cannot be automatically reversed. 
Non-transaction backout files cannot be accessed remotely. Attempts to open a non-transaction backout file in remote context fails and generates the following error message: 
<var>M204.1973: NON-TBO REMOTE FILE</var>
</td>
</tr>
</table>
===Update units===
An update unit is any sequence of operations that updates the database and that has a beginning and ending point. One update unit must end before another update unit can begin. 
A request or procedure can have two types of update units:
<table>
<tr class="head">
<th>Update unit type </th>
<th>Discussion</th>
</tr>
<tr>
<td>Backoutable </td>
<td>A backoutable unit consists of updates to transaction backout files using file updating statements (such as STORE RECORD). The unit can either be completed so that it persists in the file, or backed out so that the update is logically reversed in the file. </td>
</tr>
<tr>
<td>Non-backoutable </td>
<td>A non-backoutable unit consists of updates to non-transaction backout files. </td>
</tr>
</table>
====Backoutable units====
Beginning a backoutable unit
A backoutable unit begins at the execution of the first User Language statement that performs an update operation on a transaction backout file. The statements that perform update operations are: 
<ul>
<li>ADD fieldname = value</li>
</li>
<li>CHANGE fieldname TO value </li>
</li>
<li>DELETE EACH fieldname</li>
</li>
<li>DELETE fieldname [= value]</li>
</li>
<li>DELETE RECORD</li>
</li>
<li>DELETE RECORDS</li>
</li>
<li>FILE RECORDS</li>
</li>
<li>INSERT fieldname = value</li>
</li>
<li>STORE RECORD</li>
</li>
</ul>
Ending a backoutable unit
A backoutable unit ends when the unit is committed by using the COMMIT statement or is backed out. Other conditions (such as an END statement in a request or the BACKOUT statement discussed later in this chapter) also can end an active update unit. Refer to the Rocket <var class="product">Model 204</var> File Manager's Guide for a complete list of conditions that end an active update unit. 
====Non-backoutable units====
Beginning a non-backoutable unit
A non-backoutable unit begins with the first User Language statement that performs an update operation on a non-transaction backout file. 
Ending a non-backoutable unit
A non-backoutable unit ends when the unit is committed by using the COMMIT statement. Other conditions (such as an END statement in a request or the BACKOUT statement discussed later in this chapter) also can end an active update unit. Refer to the Rocket <var class="product">Model 204</var> File Manager's Guide for a complete list of conditions that start or end an active update unit. 
===Using backout===
The transaction backout facility performs two types of backouts:
<table>
<tr class="head">
<th>Backout type </th>
<th>Invoked...</th>
</tr>
<tr>
<td>Automatic </td>
<td>
Automatically by a request cancellation
An attention or *CANCEL command without an ON ATTENTION unit
File full condition
User restart. 
</td>
</tr>
<tr>
<td>Manual </td>
<td>Using the BACKOUT statement within a request. </td>
</tr>
</table>
====Automatic backout====
<var class="product">Model 204</var> automatically backs out the current update unit for a transaction backout file under any of the following conditions:
<ul>
<li>If a request is cancelled by <var class="product">Model 204</var> </li>
</li>
<li>If there is a file integrity problem</li>
</li>
<li>If <var class="product">Model 204</var> is restarting a user who has an active update unit </li>
</li>
</ul>
When a request accessing a transaction backout file is cancelled, the following events occur:
<ul>
<li>The user receives a message that explains why the request was cancelled.</li>
</li>
<li>The current update unit is backed out automatically.</li>
</li>
<li><var class="product">Model 204</var> returns to the terminal command level unless an ON ERROR or ON ATTENTION unit is invoked. </li>
</li>
</ul>
Remote updates are backed out automatically when appropriate.
====Manual backout====
You can backout an incomplete update unit by using the BACKOUT statement. This statement is valid only for updates to transaction backout files. 
The BACKOUT statement releases the exclusive lock on updated records and backs out the current update unit. No found sets are released and the current record does not change.
After the BACKOUT statement is processed, evaluation continues with the next statement. A message is displayed to the user upon the successful completion of a backout operation.
The BACKOUT statement is supported in remote context. If records on any remote nodes have been updated, the BACKOUT statement causes all remote updates on all remote nodes to be backed out, in addition to any local updates.
Example
The BACKOUT statement is typically used in data entry applications where a transaction might have to be backed out after it has updated a file (for example, a sales or airline reservations application). 
An example of a request that uses the BACKOUT statement is provided below.
BEGIN
*
* DECREMENT INVENTORY BEFORE MAKING SALE TO CUSTOMER
*
DECLARE %INPUT STRING LEN 70
DECLARE %VINTNER STRING LEN 30
DECLARE %SELECTION STRING LEN 40
*
* ENTER PURCHASER'S SELECTION
*
GETVAL: %INPUT=$READ('ENTER VINTNER/SELECTION:')
IF %INPUT EQ 'QUIT' THEN
STOP
END IF
%VINTNER=$SUBSTR(%INPUT,1,$INDEX(%INPUT,'/')-1)
%SELECTION=$SUBSTR(%INPUT,$INDEX(%INPUT,'/')+1)
FDVINTNER: FD REC=VINTNER AND NAME=%VINTNER
CTVINTNER: COUNT RECORDS IN FDVINTNER
IF COUNT IN CTVINTNER EQ '0' THEN
PRINT 'VINTNER DOES NOT EXIST TRY AGAIN'
JUMP TO GETVAL
END IF
*
* IF SELECTION EXISTS THEN UPDATE RECORD BY DECREASING
* THE AMOUNT ON HAND
*
CTSELECTION: FOR EACH RECORD IN FDVINTNER
FEOSELECT: FOR EACH OCCURRENCE OF SELECTION
IF SELECTION(OCCURRENCE IN FEOSELECT) EQ -
%SELECTION THEN
%ONHAND=ONHAND(OCCURRENCE IN FEOSELECT)
%DECREMENT=%ONHAND-1
CHANGE ONHAND(OCCURRENCE IN FEOSELECT)-
TO %DECREMENT
JUMP TO GETCASH
END IF
END FOR
PRINT 'SELECTION DOES NOT EXIST TRY AGAIN'
JUMP TO GETVAL
END FOR

*
* IF CUSTOMER IS READY TO PROCEED WITH THE SALE, THEN
* COMMIT THE TRANSACTION. IF NOT, THEN BACKOUT RECORD
* UPDATED
*
GETCASH: %CASH=$READ('DID YOU GET CASH/CREDIT CARD FROM -
CUSTOMER Y/N:')
IF %CASH EQ 'Y' THEN
COMMIT
JUMP TO FINISH
ELSE
BACKOUT
PRINT 'INVENTORY WAS NOT UPDATED '
PRINT 'PURCHASE STOPPED'
JUMP TO DONE
END IF
FINISH: PRINT 'TRANSACTION COMPLETED'
PRINT 'THANK YOU'
DONE: *COMMENT
END *

===Design considerations for transaction backout files===
This section identifies the factors to consider when designing an application that uses transaction backout files. 
Transaction backout provides increased file logical consistency over the FIND share lock and FOR loop exclusive lock, and provides increased data sharing over the FIND AND RESERVE exclusive lock. However, effective use of the transaction backout facility depends on careful design and implementation.
====Update requests====
Requests that update transaction backout files cannot access non-transaction backout files in any way. This restriction ensures that all update units for a transaction backout file are logged correctly, can be backed out, and do not overlap with any update units that cannot be backed out.
Non-updating requests can access any type of file, and requests that update non-transaction backout files can read transaction backout files.
====ON ATTENTION units====
ON ATTENTION units should be used within requests to avoid inadvertently backing out an active update unit. If an ON ATTENTION unit is not specified and the user presses one of the ATTENTION identifier (AID) keys at the terminal or enters <var>*CANCEL</var> at a terminal I/O point, then the request is cancelled. The cancellation causes an automatic backout of the current update unit if the request updates transaction backout files. 
====CCATEMP space====
The backout facility must have the necessary information to backout each active update unit in the <var class="product">Model 204</var> run. A log of compensating updates is built for each active unit on the system file, CCATEMP. When the unit ends or is backed out, the log for that particular unit is discarded.
To minimize the amount of CCATEMP space used, update units should be designed to contain only a few file updates. Units of a sizable amount can greatly increase the amount of CCATEMP space used by <var class="product">Model 204</var>. Therefore, update units should be committed frequently to minimize the size of the backout log. 
====Logical inconsistency====
Although transaction backout does increase the logical consistency of a file through the lock pending updates option, logical inconsistency can occur when an update unit is backed out. For example, logical inconsistency can arise when a unit involving DELETE RECORD is backed out because deleted records are not locked by the lock pending updates option. 
Example
The following requests illustrate such a logical inconsistency:
<table>
<tr class="head">
<th>User 1 </th>
<th>User 2</th>
</tr>
<tr>
<td>
BEGIN
</td>
<td>

</td>
</tr>
<tr>
<td>
SMH: FIND ALL RECORDS FOR WHICH
</td>
<td>

</td>
</tr>
<tr>
<td>
 NAME = SMITH
</td>
<td>

</td>
</tr>
<tr>
<td>
 END FIND
</td>
<td>

</td>
</tr>
<tr>
<td>
 FOR EACH RECORD IN SMH
</td>
<td>

</td>
</tr>
<tr>
<td>
 DELETE RECORD
</td>
<td>

</td>
</tr>
<tr>
<td>
 END FOR
</td>
<td>

</td>
</tr>
<tr>
<td>
JNS: FIND ALL RECORD FOR WHICH
</td>
<td>
BEGIN
</td>
</tr>
<tr>
<td>
 NAME = JONES
</td>
<td>
FD.RECS: FIND ALL RECORDS FOR WHICH
</td>
</tr>
<tr>
<td>
 END FIND
</td>
<td>
 NAME = SOLOBY OR -
</td>
</tr>
<tr>
<td>
 FOR EACH RECORD IN JNS
</td>
<td>
 NAME = SMITH OR -
</td>
</tr>
<tr>
<td>
 ADD TYPE = SPECIAL
</td>
<td>
 NAME = SAUNDERS
</td>
</tr>
<tr>
<td>
 .
</td>
<td>
 END FIND
</td>
</tr>
<tr>
<td>
 .
</td>
<td>
 FOR EACH RECORD IN FD.RECS
</td>
</tr>
<tr>
<td>
 .
</td>
<td>
 ADD TYPE = SPECIAL
</td>
</tr>
<tr>
<td>
 .
</td>
<td>
 END FOR
</td>
</tr>
<tr>
<td>
 .
</td>
<td>
FD.SPEC: FIND ALL RECORDS FOR WHICH
</td>
</tr>
<tr>
<td>
 .
</td>
<td>
 TYPE = SPECIAL
</td>
</tr>
<tr>
<td>
 .
</td>
<td>
 END FIND
</td>
</tr>
<tr>
<td>
 .
</td>
<td>
PRT: FOR EACH RECORD IN FD.SPEC
</td>
</tr>
<tr>
<td>
 .
</td>
<td>
 PRINT NAME AND TYPE
</td>
</tr>
<tr>
<td>
 .
</td>
<td>
 END FOR
</td>
</tr>
<tr>
<td>
DEL: BACKOUT
</td>
<td>
END
</td>
</tr>
<tr>
<td>
ALL: FIND ALL RECORDS
</td>
<td>

</td>
</tr>
<tr>
<td>
 END FIND
</td>
<td>

</td>
</tr>
<tr>
<td>
 FOR EACH RECORD IN ALL
</td>
<td>

</td>
</tr>
<tr>
<td>
 PRINT NAME AND TYPE
</td>
<td>

</td>
</tr>
<tr>
<td>
 END FOR
</td>
<td>

</td>
</tr>
<tr>
<td>
END
</td>
<td>

</td>
</tr>
</table>
User 1 deletes the set of records with NAME = SMITH. Although the update unit is not complete, the deleted set of records is not locked. Before user 1's unit completes, user 2 finds the set of records with NAME = either SOLOBY, SMITH, or SAUNDERS. There is no locking conflict because the deleted records are not locked. User 2 adds a field to the found set, prints a report, and ends.
User 1 then decides to backout the unit in progress. The deletion of the SMITH records is in the backed out unit and the SMITH records reappear on the file. However, because the SMITH records do not have the TYPE = SPECIAL field added by user 2, there is a logical inconsistency. The chances of this type of inconsistency can be reduced by keeping units short, especially when the units involve record deletion. If user 1 had a COMMIT statement after the DELETE RECORD loop, no inconsistency would arise unless the backout was automatically activated during that short piece of the user request. It also is likely that the records deleted by an application are meant to be deleted, and a logical inconsistency in a set of records intended for deletion is unimportant.
FILE RECORDS statement
Similar logical inconsistency can occur using the FILE RECORDS statement because FILE RECORDS does not lock any records. For the FILE RECORDS statement, a FIND statement can be used to lock the records to be updated in share mode, or FIND AND RESERVE can be used to lock the records in exclusive mode. If the FIND set is locked exclusively and not released until after the update unit containing the FILE RECORDS statement has ended, then logical inconsistency is prevented. 
====Terminal I/O points====
Terminal I/O points should not be placed between the start of an update unit and the unit's end or backout. This precaution stems from the exclusive lock placed on updated records. If a response is required from a terminal operator either to complete or backout an update unit, there is a possibility that a set of records could be locked for an extended period of time.
[[Category:SOUL]]