Abort of Archive, Backup, or Restore

Soft Abort with Option -g stop

The system waits until all active copy processes (for example, cpio, dd, cp, copy) have finished before stopping the archive, backup, or restore and performing a clean-up. This leaves the database in a clean state. Any files that are being processed when the abort command is issued are completely copied before the abort takes effect. Therefore, the abort takes longer, up to several minutes.

This kind of abort is especially useful for native backups or restores, such as with cpio, dd, cp, copy, compress, uncompress, and the SAP SBT (RMAN) backup library.

If you are using third party backup tools such as BACKINT ( backup_dev_type = util_file|util_file_online|util_vol|util_vol_online) or third party SBT backup libraries ( backup_dev_type = rman_util|rman_disk|rman_stage), a soft abort does not usually work. This is because it is not possible to prematurely terminate an active BACKINT or backup-library call. Since the backup or restore is usually processed in a single call, it is usually almost finished (apart from the writing of profiles and logs) before an abort can take effect.

Normal Abort with Option -g kill

This sends a terminate signal to the running processes of BRARCHIVE, BRBACKUP, or BRRESTORE, which causes the tool to immediately try to stop active copy processes or BACKINT or RMAN calls. However, this is not always possible, especially if the backup or restore is not running in a separate process group, because of the danger of also aborting other processes.

On Windows, if the backup was started from the DBA Planning Calendar, such an abort might also affect SAP processes . On UNIX,, if the backup was started with a CRON job, a Not owner error might occur. For more information about a possible solution to this problem, see SAP Note 1129197 . Otherwise you must manually abort the processes using the kill command on UNIX or the Task Manager on Windows.

BRARCHIVE, BRBACKUP, or BRRESTORE normally clean up, so that the database is left in a clean state after the abort.

Hard Abort with Option -g term

This sends a kill signal to the running processes of BRARCHIVE, BRBACKUP, or BRRESTORE, which causes an immediate abort without clean-up. Active copy processes or BACKINT or RMAN calls continue running. If required, you must manually stop these with the kill command on UNIX or the Task Manager on Windows. The database remains in the state it was in at the time of the abort. To restart the database after an aborted offline backup, you can use the following BRSPACE command:

brspace -c force -f dbstart -s open -f

To reset the backup status of the tablespaces after an aborted online backup, you can use the following BRSPACE command:

brspace -c force -f tsalter -a endback -t all_ts