CHAPTER 6: Data Control Commands

6.1 Introduction

The Data Control Language (DCL) commands provide facilities for data integrity and security. A summary of the available DCL commands is listed below:

Table 6-1: Data Control Language Commands

Command	Description

`START WORK`	Begins a set of commands which do not have a permanent effect on the database until a `COMMIT WORK` command is issued or a `ROLLBACK` command cancels them.
`COMMIT WORK`	Ends the current transaction, making permanent all changes to the database made during the current transaction.
`ROLLBACK`	Reverses the effects of commands in the current transaction allowing you to change your mind or recover from a mistake.
`SAVEPOINT`	Sets a save point in a transaction, starting a nested transaction. A transaction can be rolled back to a save point with the `ROLLBACK` command.
`DISPLAY WORK`	Displays the status of the current transaction, or of transactions in progress affecting the database.

6.2 START WORK

The START WORK command begins a group of commands called a transaction during which changes to the database are not permanently recorded until the transaction is ended, either by committing the changes or cancelling them. The effects of changes made while a transaction is in progress may be seen just like those of normal commands, but the option exists of undoing them if desired.

Also, in the event of a disk, operating system or network crash, transactions will be resolved (either committed or rolled back) by the warm restart facility, so that data integrity is preserved on all databases involved in the transaction. The warm restart facility is described in the Empress: Database Administrator's Guide.

A general introduction to transactions will be found in the Empress SQL: User's Guide.

Syntax

START |WORK |TRANSACTION | [[database:]id [FROM savepoint]]; |

where:

`database`	is the name of the database.
`savepoint`	is the name of the save point in the transaction and must be a string starting with a letter.
`id`	is the transaction id.

Notes

The command:
START WORK;

will start up a transaction. If transaction already been started, Empress will respond with the message: Transaction already in progress.

The command:
START WORK database:id FROM savepoint;

is used to recover transactions that were interrupted by a system failure. It recovers the named transaction to the specified save point within the current user's environment, restarting the transaction so that you can continue working in it. If a save point is not specified, the last (or most up-to-date) defined save point is used. A transaction with no save points cannot be rolled back to a save point. The transaction id and the name of save points can be obtained with the DISPLAY WORK command.

Save points can be set in a transaction with the SAVEPOINT command (starting a nested transaction).

A transaction can either be committed or rolled back. If a transaction is committed, it can only be committed in full, including all nested transactions. A transaction can be rolled back in stages, by rolling back nested transactions (that is, by rolling back to named save points). Use the COMMIT WORK command to commit a transaction, and the ROLLBACK WORK command to roll back a transaction.

The system variable MSTRANSCOMMENT can be used to place a comment on the transaction log. If this variable is set when a transaction is started, the value of the variable is used as a comment on the transaction and can be seen from DISPLAY WORK command. This can be useful if several people are working from the same account and they wish to distinguish their transactions. The comment can be a quoted string up to 64 characters long.

The system variable MSTRANSWARMPROTECT can be used to protect transactions from the automatic warm restart. That is, if system failure occurred in the middle of a transaction and this variable is set, the warm restart utility (empwarm) will ignore this transaction. This feature is useful if the automatic warm restart is included as part of the system re-boot process. During this process, transaction will be rolled back unless a commit command has been issued. By setting this protection from warm restart, long transactions that are interrupted by the system failure can be prevented from roll back. The transaction can be recovered by issuing START WORK database:id FROM savepoint; command manually.

If no database is specified the current default database is assumed. Each transaction has an id that can be determined using the DISPLAY WORK command.

This command must be run on the coordinator (the first database accessed in the transaction), that is, the transaction identification must explicitly or implicitly specify the coordinator of the transaction.

Setting a save point is described as part of the SAVEPOINT command.

Privilege Required

None.

Example

Start a Transaction

Start a transaction, insert data into the personnel table, and commit the change permanently, with the following commands:

START WORK;

It produces the following message:

Starting Transaction

Insert some records and select from the table with:

INSERT personnel SET TO 20, 'Martin', '862-1250', 500; SELECT * FROM personnel;

It shows:

number name phone credit_limit 10 Kilroy 426-9681 $500.00 5 Mosca 544-2243 $750.00 17 Wladislaw 723-6073 $200.00 3 Jones 667-2951 $500.00 8 Peterson 978-6060 $250.00 4 Scarlatti 961-7363 $100.00 20 Martin 862-1250 $500.00

Now, commit the transaction:

COMMIT WORK;

It produces the following message:

Committing Transaction

Nested Transaction

The following sequence of commands starts a transaction, then starts a nested transaction which is later rolled back. The transaction up to the nested transaction (save point) is then committed.

* START WORK; Starting Transaction . . . * SAVEPOINT sp1; Setting Save Point . . . * ROLLBACK WORK TO sp1; Rolling Back to Save Point * COMMIT WORK; Committing Transaction

6.3 COMMIT WORK

COMMIT WORK is used to make permanent all changes to a database made during the current transaction and to end the current transaction. A transaction is initiated by the START WORK command.

Syntax

COMMIT [ |WORK |TRANSACTION |] [[database:]id]; |

where:

`database`	is the name of the database.
`id`	is the transaction id.

Notes

The command:
COMMIT WORK;

is used while in a transaction and commits the transaction (updates all tables permanently). If no transaction is in progress an error message is printed.

Transactions cannot be committed in stages, so all nested transactions are committed by this command.

The command:
COMMIT WORK database:id;

forces the identified transaction to be committed. It can only be typed when not currently in a transaction. All operations in the transaction are made permanent in the database. When run on a coordinator the operations affecting the coordinator and all available participants are committed. When run on a participant only the operations affecting that participant and the coordinator are committed.

If no database is specified, the current default database is assumed. Each transaction has a transaction id that can be determined using the DISPLAY WORK command.

This command cannot be used to contradict the correct resolution of the transaction as printed by the DISPLAY WORK command. For instance, if the correct resolution is to rollback the transaction, the forced COMMIT WORK attempt will fail. Care should be taken, however, if a participant cannot determine whether the transaction should be committed or rolled back. In such a case an incorrect resolution can be forced on the participant. If the DISPLAY WORK at the participant cannot give an unambiguous resolution, contact the coordinator's site and determine what the correct action should be.

If you force a transaction to be committed at a participant the status information for the participant is removed from the participant database. If the coordinator is not accessible, it will not be informed of the final status of the participant. Moreover, the coordinator will not be able to obtain it when communication is re-established. The coordinator will assess this situation as one in which disk corruption may have occurred, and the automatic warm restart utility will not take any action. It will therefore be necessary for you to use manual overrides to force the resolution of the transaction at the coordinator and all other participants. It is extremely important to ensure that manual overrides are used in a consistent manner on all databases involved.

A general introduction to transactions will be found in the Empress SQL: User's Guide.
Recovering transactions from a system crash is discussed in the Empress: Database Administrator's Guide under the chapter Warm Restart.

Privileges Required

None.

Example

Initiate a transaction, change the personnel table, check the change, and commit it permanently with the commands:

   * START WORK;
   Starting Transaction
   
   * UPDATE personnel
        SET phone TO '426-6981'
        WHERE name = 'Mosca';
   
   * SELECT * FROM personnel;
   
   number     name          phone          credit_limit
   
   3          Jones         667-2951       $750.00
   4          Scarlatti     961-7363       $100.00
   5          Mosca         426-6981       $750.00
   8          Peterson      978-6060       $250.00
   9          Jordan        964-3335       $250.00
   17         Wladislaw     811-5110        $10.00
   
   * COMMIT WORK;
   Committing Transaction

6.4 ROLLBACK WORK

ROLLBACK WORK will undo all commands entered in the current transaction, leaving the database as it was before the transaction began. A transaction is initiated by the START WORK command.

Syntax

|ROLLBACK |CANCEL | [ | |WORK |TRANSACTION |] [ | |TO savepoint |[database:]id |]; |

where:

`savepoint`	is the name of the save point in the transaction and must be a string starting with a letter.
`database`	is the name of the database.
`id`	is the transaction id.

Notes

The command:
ROLLBACK WORK TO savepoint;

rolls the transaction back, reversing the operations carried out in the transaction. If the SAVEPOINT option is used, the transaction is rolled back to the save point; the transaction is not ended. The save point must have been set with the SAVEPOINT command. If the SAVEPOINT option is absent, the transaction is completely rolled back, cancelling all operations in the transaction, and the transaction is ended.

The form:.
ROLLBACK WORK database:id;

forces the named transaction to be rolled back. It can only be issued when not currently in a transaction. All operations in the transaction are cancelled for the database. When run on a coordinator the operations affecting the coordinator and all available participants are rolled back. When run on a participant only the operations affecting that participant and the coordinator are rolled back.

This command is invalid if a transaction is not in progress; Empress will respond with the message: No Transaction in progress.

If no database is specified, the current default database is assumed. Each transaction has an id that can be determined using the DISPLAY WORK command.

This command cannot be used to contradict the correct resolution of the transaction as printed by the DISPLAY WORK command. For instance, if the correct resolution is to commit the transaction, the forced ROLLBACK WORK attempt will fail. Care should be taken, however, if a participant cannot determine whether the transaction should be committed or rolled back. In such a case an incorrect resolution can be forced on the participant. If the DISPLAY WORK at the participant cannot give an unambiguous resolution, contact the coordinator's site and determine what the correct action should be.

If you force a transaction to be rolled back at a participant the status information for the participant is removed from the participant database. If the coordinator is not accessible it will not be informed of the final status of the participant. Moreover, the coordinator will not be able to obtain it when communication is reestablished. The coordinator will assess this situation as one in which disk corruption may have occurred, and the automatic warm restart utility will not take any action. It will therefore be necessary for you to use manual overrides to force the resolution of the transaction at the coordinator and all other participants. It is extremely important to ensure that manual overrides are used in a consistent manner on all databases involved.

To restart an interrupted transaction from a save point see the START WORK command.

A general introduction to transactions will be found in the Empress SQL: User's Guide.

Recovering transactions from a system crash is discussed in the Empress: Database Administrator's Guide in the chapter Warm Restart.

Privileges Required

None.

Example

Cancelling a Transaction

The ROLLBACK command is used to undo the effects of two updates made to the personnel table in the following sequence of commands. The intention was to change Mosca's phone and credit_limit, but the WHERE clause was omitted from the update on the phone number by mistake.

* START WORK; Starting Transaction * SELECT * FROM personnel; number name phone credit_limit 3 Jones 667-2951 $750.00 4 Scarlatti 961-7363 $100.00 5 Mosca 426-9681 $750.00 8 Peterson 978-6060 $250.00 9 Jordan 964-3335 $250.00 10 Kilroy 426-9681 $500.00 17 Wladislaw 811-5110 $10.00 * UPDATE personnel SET phone TO '426-6981'; * UPDATE personnel SET credit_limit to 250 WHERE name = 'Mosca'; * SELECT * FROM personnel; number name phone credit_limit 3 Jones 426-6981 $750.00 4 Scarlatti 426-6981 $100.00 5 Mosca 426-6981 $250.00 8 Peterson 426-6981 $250.00 9 Jordan 426-6981 $250.00 10 Kilroy 426-6981 $500.00 17 Wladislaw 426-6981 $10.00 * ROLLBACK WORK; Cancelling Transaction * SELECT * FROM personnel; number name phone credit_limit 3 Jones 667-2951 $750.00 4 Scarlatti 961-7363 $100.00 5 Mosca 426-9681 $750.00 8 Peterson 978-6060 $250.00 9 Jordan 964-3335 $250.00 10 Kilroy 426-9681 $500.00 17 Wladislaw 811-5110 $10.00

Roll Back to a Savepoint

The following sequence of commands starts a transaction, then starts a nested transaction which is later rolled back. The transaction up to the nested transaction (save point) is then committed.

* START WORK; . . . * SAVEPOINT sp1; . . . * ROLLBACK WORK TO sp1; Rolling Back to Save Point * COMMIT WORK; Committing Transaction

6.5 SAVEPOINT

The SAVEPOINT command sets a save point in a transaction. A transaction must be in progress for this command to succeed.

Syntax

SAVEPOINT savepoint;

where:

savepoint is the name of a save point given by the user; it must be a string starting with a letter.

Notes

The command sets a save point within an existing transaction. That is, it starts a named nested transaction.

A transaction can either be committed or rolled back. If a transaction is committed, it can only be committed in full, including all nested transactions. A transaction can be rolled back in stages, by rolling back to named save points.

An interrupted transaction can be restarted at a save point. See the START WORK command.

A general introduction to transactions will be found in the Empress SQL: User's Guide.

Administrative transaction control commands are described in the Empress: Database Administrator's Guide in the chapter Warm Restart.

Privileges Required

None.

Example

The following sequence of commands starts a transaction, then starts a nested transaction which is later rolled back. The transaction up to the nested transaction (save point) is then committed.

   * START WORK;
     .
     .
     .
   
   * SAVEPOINT sp1;
     .
     .
     .
   
   * ROLLBACK WORK TO sp1;
   Rolling Back to Save Point
   
   * COMMIT WORK;
   Committing Transaction

6.6 DISPLAY WORK

DISPLAY WORK command provides status information on the transaction including the transaction ID, any comment on the transaction, the name of the user running the transaction, the date of the transaction, a message if the transaction is protected, the coordinator and each participant of the transaction, any save points in the transaction, and an overall status evaluation of the transaction.

Syntax

`DISPLAY`	`\|WORK \|TRANSACTION`	`\| [ \|`	`\|ON \|`	`\|DB \|database`	`\| [ALL] \|`	`\|]; \|`
			`\| [`	`database:]id`		`\|`

where:

id is a transaction identification.

Notes

The command:
DISPLAY WORK;

can only be used while in a transaction. It displays the status of current the current transaction.

The DISPLAY WORK on the database can only be used outside of a transaction. Without the ALL option, it displays summary information on all of the transactions associated with the current database or with the named database. The summary information includes the transaction identification number, any comment on the transaction, the name of the user running the transaction, the date of the transaction, a message if the transaction is protected, and the coordinator database for the transaction. With the ALL option, full details of every transaction affecting the database are displayed.

The display transaction with the transaction identification number displays full status information on the particular transaction. This command can only be used when not currently in a transaction. The status information includes the transaction ID, any comment on the transaction, the name of the user running the transaction, the date of the transaction, a message if the transaction is protected, the coordinator and each participant of the transaction, any save points in the transaction, and an overall status evaluation of the transaction.

When the automatic warm restart utility is run, or when a DISPLAY WORK command is issued, the status of each transaction is examined and messages printed to the screen. The messages you may encounter are listed below. There are two kinds of messages that can be printed: messages pertaining to individual databases involved in the transaction that are printed beside each database, and messages pertaining to the status of the transaction as a whole.

Transaction Status Messages are:

cancelled
The transaction has been cancelled at the database. Commitment is no longer possible. Status information has been removed from the database.

committed
The transaction has been committed at the database. Rollback is no longer possible. Status information has been removed from the database.

committed phase-1
The transaction is ready to be committed at the database. However, it can still be either committed or rolled back. Status information is still in place at the database.

in progress
The transaction was (and still is) in progress at the database. No commit or rollback instructions were received. Status information is still in place at the database. The transaction cannot be committed.

status unavailable
The database cannot be accessed. This may be due, for instance, to network failures, the disk not being mounted, or not being able to read the database directory. If you are at a participant and the coordinator is not available, you should contact someone at the coordinator's site to confirm the status of the transaction.

status unrecoverable
Status information is missing at the database. This may be due to:

a forced commit/cancel at a participant (which will remove the status information from the participant database)

physical disk corruption of the database; or

manual removal of the status information at the database.

If the status is unrecoverable at the coordinator, you should always contact someone at the coordinator's site to determine what action has been taken on the transaction. Under normal circumstances, status information is retained at the coordinator until the transaction is fully resolved at all databases involved.

Overall Status Messages (per transaction) are:

Transaction ready for cancel
The transaction should be rolled back. If printed at a coordinator, all sites have been polled and are ready. The warm restart utility (run at the coordinator) will rollback the transaction at all sites.

If this message is printed at a participant, it is valid only for the status of the transaction at the participant. There is a possibility that you may rollback to a save point at the coordinator. Run the DISPLAY WORK command at the coordinator to find out if that is possible.

If this message is printed at a participant and if the warm restart utility or the DISPLAY WORK command run at the coordinator reports that a participant is not accessible, there is still a possibility that you may rollback to a save point at the coordinator when communication is re-established.

If you force a rollback at the participant your data will be secure but you will destroy the possibility of rolling back to a save point at the coordinator.

Transaction ready for cancel on all available databases
This message can only be printed at the coordinator for the transaction. The transaction should be rolled back. All sites accessible to the coordinator have been polled and are ready. However, there is at least one site that the coordinator cannot access (the network may be down, the file system not mounted or the database directory unreadable). The warm restart utility will rollback the transaction at all the sites it can access.

You can run the warm restart utility to rollback the transaction at the available sites. As communication is restored with currently unavailable sites, you can run the warm restart utility repeatedly to rollback the transaction at those sites.

If you run the automatic warm restart you may wish to notify someone at the currently unavailable sites of the status of the transaction, if only to ensure that an inappropriate forced action is not taken anywhere. Check the status report generated by the warm restart utility (or the DISPLAY WORK command) for that transaction on future runs. Should a Warning or Error message be generated, you will have to take appropriate action.

There is a possibility that you may rollback to a save point when all participants are accessible to the coordinator. Run the DISPLAY WORK command at the coordinator when communication is re-established.

If you must resolve the transaction at sites currently inaccessible, you can use the ROLLBACK WORK (forced) command at the participant. If you force a rollback at the participant your data will be secure but you will destroy the possibility of rolling back to a save point at the coordinator.

Transaction ready for commit
The transaction should be committed. If printed at the coordinator of the transaction, all sites have been polled and are ready. The warm restart utility (run at the coordinator) will commit the transaction at all sites.

If this message is printed at a participant of the transaction, it is valid only for the status of the transaction at the participant. To determine the status of the entire transaction across all sites, run the DISPLAY WORK command at the coordinator.

If this message is printed at a participant and the participant is not accessible to the coordinator, a warm restart run at the coordinator will not affect the participant. The transaction at the participant will be committed if the warm restart utility is rerun when communication is re-established. If you must resolve the transaction at the participant immediately, you can use the COMMIT WORK (forced) command at the participant.

Transaction ready for commit on all available databases
This message can only be printed at the coordinator for the transaction. The transaction should be committed. All sites accessible to the coordinator have been polled and are ready. However, there is at least one site that the coordinator cannot access (the network may be down, the file system not mounted or the database directory locked). The warm restart utility will commit the transaction at all the sites it can access.

You can run the warm restart utility to commit the transaction at available sites. When communication is restored with the sites currently not accessible, you can run the warm restart utility again to commit the transaction at those sites.

If you must resolve the transaction at sites currently inaccessible, you can use the COMMIT WORK (forced) command at the participant.

Transaction ready for restart or rollback
This message can only be printed at the coordinator for the transaction. The transaction can be rolled back completely or rolled back to a save point. All sites have been polled and are ready. If you run the warm restart utility now it will do a full rollback of the transaction.

You can rollback to a save point using the START WORK (from SAVEPOINT) command at the coordinator. If you wish to rollback to a save point, do not first run the warm restart utility on the coordinator, as this will do a full rollback of the transaction. You can run the warm restart utility after rolling back to a save point, the restarted transaction will not be affected by it.

Transaction status unavailable, resolve at Coordinator database
This message can only be printed when running the warm restart utility or executing a DISPLAY WORK command at a participant of the transaction. The participant cannot determine unambiguously whether the transaction is to be committed or rolled back, and cannot access the coordinator to determine the correct action. The warm restart utility will take no action.

If access to the coordinator will be restored soon, you can wait and run the warm restart at the coordinator later. If you must resolve the transaction at the participant immediately, contact the person responsible at the coordinator's site and have them run the DISPLAY WORK to get the coordinator's status report on the transaction. You can then force the transaction as indicated by the coordinator.

Unknown Transaction
This message can be printed from a DISPLAY WORK command. Either the status information for the transaction is missing, or you have incorrectly typed the identification for the transaction. The warm restart utility will take no action.

Check the identification for the transaction (database name, transaction code). If these are correct, then the status information for the transaction at that database is missing. Try to obtain the status at the coordinator, or, if that is not accessible, at another participant.

If the transaction is recognized at the coordinator but not at the participant then status information is missing at the participant. Follow the instructions for the status report from the coordinator. If the coordinator cannot access the participant, see the Warning status messages; if the coordinator indicates that the transaction should be cancelled, see under Warning; possible corruption, attempt forced cancel at all sites; if the coordinator indicates that the transaction should be committed see, under Warning; possible corruption, attempt forced commit at all sites.

If the transaction is recognized at a participant but not at the coordinator, then status information is missing at the coordinator. See under the message Warning; corruption at Coordinator database.

Unrecoverable error, Participant in conflict with Coordinator
This message can only be printed at the coordinator for the transaction. A conflict has been created between the coordinator and one or more participants of the transaction. Either the coordinator indicates a necessary commit and a participant has had a forced rollback applied to it, or the coordinator indicates a necessary rollback and a participant has had a forced commit applied to it. In either case, the warm restart utility will take no action.

Your data has been corrupted. This situation is a result of a forced commit/rollback applied at a participant when the participant could not determine the correct action unambiguously, and therefore could not veto the (incorrect) forced action. You must use emprecov to restore all databases involved from archives.

To prevent this situation from occurring, always check with the coordinator when a participant cannot determine unambiguously whether to commit or rollback a transaction.

Warning; corruption at Coordinator database
This message can only be printed when the warm restart utility is run on a participant, or when the DISPLAY WORK command is run on a participant. The status information at the coordinator has been lost to disk corruption or has been manually removed. The warm restart utility will take no further action.

If you have forced the transaction at the coordinator then manually removed the status information, you should force the participant in a consistent manner.

If you have not both forced the transaction at the coordinator and manually removed the status information, your data is corrupted. You must use emprecov to restore all databases involved from archives.

Warning; possible corruption, attempt forced cancel at all sites.
The coordinator indicates that the transaction should be cancelled, but status information is missing from a participant. Only a rollback will recover the transaction. The warm restart utility will take no further action.

The missing status information may be due to disk corruption (including having been manually removed) or a forced commit/rollback at the participant. If there has been no forced commit/rollback at the participant, your data has been lost due to disk corruption. You must use emprecov to restore all databases involved from archives.

If there has been a forced commit at the participant, your data is corrupted. You must use emprecov to restore all databases involved from archives. To prevent this situation from occurring, always check with the coordinator when a participant cannot determine unambiguously whether to commit or rollback a transaction.

If there has been a forced rollback at the participant, you should force the transaction to be rolled back at the coordinator and at every other participant. This recovers the transaction.

Warning; possible corruption, attempt forced commit at all sites.
The coordinator indicates that the transaction should be committed, but status information is missing from a participant. Apart from the missing status information, all data is safe. The warm restart utility will take no further action.

The missing status information may be due to disk corruption (including having been manually removed) or a forced commit/rollback at the participant. If there has been no forced commit/rollback at the participant, you should run empclrlk or restart the server at the participant. This clears all locks at the participant. You should also force the transaction to be committed at the coordinator and at every other participant. This recovers the transaction.

If there has been a forced commit at the participant, you should force the transaction to be committed at the coordinator and at every other participant. This recovers the transaction.

If there has been a forced rollback at the participant, your data is corrupted. This can happen if:

the coordinator reached the committed stage and the participant reached the committed phase-1 stage; and

the participant could not access the coordinator to determine whether the transaction should be committed or rolled back; and

a forced rollback was applied at the participant. Since your data is corrupted you must use emprecov to restore all databases involved from archives.

To prevent this situation from occurring, always check with the coordinator when a participant cannot determine unambiguously whether to commit or rollback a transaction.

Privileges Required

None.

Example

An example of displaying the current transaction is:

   * START work;
   Starting Transaction
   
   * UPDATE personnel (phone) VALUES ('426-6981')
        WHERE name = 'Mosca';
   
   * SAVEPOINT sp1;
   Setting Save Point
   
   * DISPLAY WORK;
   
   Transaction ID: 681589298
   User: docs
   Date: 11 Dec 1991 10:18:08
   Database:
   /usr/docs/repairs -- in progress
   
   Save Points:
   sp1
   
   * UPDATE personnel SET phone to '426-6982'
     WHERE name = 'Mosca';
   
   * SAVEPOINT sp2;
   Setting Save Point
   
   * DISPLAY WORK;
   
   Transaction ID: 681589298
   User: docs
   Date: 11 Dec 1991 10:18:08
   Database:
   /usr/docs/repairs -- in progress
   
   Save Points:
   sp1
   sp2
   
   * ROLLBACK TO sp1;
   Rolling Back to Save Point
   
   * DISPLAY WORK;
   
   Transaction ID: 681589298
   User: docs
   Date: 11 Dec 1991 10:18:08
   Database:
   /usr/docs/repairs -- in progress
   
   Save Points:
   sp1

   *