PROVE IT !!If you know it then PROVE IT !! Skill Proficiency Test

Restart After Client or Teradata ARC Failure

If the client system or Teradata ARC Failure happens during an archive, restore, or recovery procedure, restart the operation. Teradata ARC responds to the failure by logging all its sessions off the Teradata Database. The Teradata Database does not journal Teradata ARC statements, therefore Teradata ARC takes no recovery action at logoff. Database locks placed by a utility statement on databases or tables remain intact following a failure.

To restart a utility operation automatically, specify the RESTART runtime option when starting Teradata ARC. The restart log is used to determine the state of the pending operation. Command execution continues using the copy of the original source statement file. Teradata ARC reads the restart log to determine its restart point, then reenters the statement that was being processed at the time of the failure.
 
If a client or utility failure interrupted an archive or restore of database DBC, do not restart the operation.
If an archive or restore of multiple databases including database DBC is interrupted, resubmit the ARCHIVE statement. Or, specify the RESTART option.
 
Restarting an Archive Operation
 
  • Restarting an archive operation causes Teradata ARC to:
  • Reposition the output archive file at the data block indicated in the last restart point recorded in the restart log before the failure occurred.
  • If the AMP configuration changed (AMPs were online before the failure but offline afterward), restart begins with the last table being archived before the failure.
Example
The following example shows the restart of an all-AMPs archive on z/OS.
Note: The RESTART parameter has been added to the EXEC.
Restarting an Archive on z/OS
//DBCDMP1 JOB 1,’DBC OPERATIONS’,REGION=2048K,MSGCLASS=A //DUMP EXEC PGM=ARCMAIN,PARM=’RESTART’
//STEPLIB DD DSN=DBC.AUTHLOAD,DISP=SHR
// DD DSN=DBC.TRLOAD,DISP=SHR
//DBCLOG DD DSN=DBC.ARCLOG.DATA,DISP=OLD
//DUMP100 DD DISP=OLD,DSN=DBC.DUMP100
//SYSPRINT DD SYSOUT=*,DCB=(RECFM=F,BLKSIZE=132,LRECL=132)
//SYSUDUMP DD SYSOUT=*
//SYSIN DD DATA,DLM=##
LOGON DBC,DBC;
ARCHIVE DATA TABLES (DBC) ALL,
   RELEASE LOCK,
   INDEXES,
   FILE=DUMP100;
LOGOFF;
##
 
In this example, the tape with VOLSER=DGJA is mounted at the time that Teradata ARC abends.
Note: When archiving on tape for z/OS, specify the tape level information and all tape volume serial numbers, including the one mounted at the time of the abend.
 
Restarting a Restore Operation
 
  • Restarting a restore operation causes Teradata ARC to:
  • Reposition the input archive file at the data block indicated in the last restart point recorded in the restart log before the failure occurred.
  • If the AMP configuration changed (AMPs are online before the failure but offline afterward), restart begins with the last table being restored before the failure.
  • If a restore of database DBC is interrupted for any reason, perform the entire restoration again, including reinitializing the Teradata Database. Even if the Teradata Database was initialized prior to database DBC restore, initialize it again.
  • If archive of database DBC is interrupted, resubmit the ARCHIVE statement without specifying the RESTART option.
  • Example
For z/OS, the only difference between the original job and the restarted job is to add the RESTART parameter to the PARM statement of the EXEC.
Restarting a Restore on z/OS
 
//DBCRST1 JOB 1,’DBC OPERATIONS’,REGION=2048K,MSGCLASS=A
//RESTORE EXEC PGM=ARCMAIN,PARM=’RESTART’
//STEPLIB DD DSN=DBC.AUTHLOAD,DISP=SHR
// DD DSN=DBC.TRLOAD,DISP=SHR
//DBCLOG DD DSN=DBC.ARCLOG.DATA,DISP=OLD
//DUMP100 DD DSN=DBC.DUMP100,DISP=OLD
//SYSPRINT DD SYSOUT=*,DCB=(RECFM=F,BLKSIZE=132,LRECL=132)
//SYSIN DD DATA,DLM=##
LOGON DBC,DBC;
RESTORE DATA TABLES (PERSONNEL) ALL,
   RELEASE LOCK,
   FILE=DUMP100;
LOGOFF;
##
 
Restarting a Checkpoint Operation
  • When CHECKPOINT writes rows to a journal, the transient journal also keeps a record of these rows. Consequently, if the client or Teradata ARC fails, the results of the checkpoint operation are rolled back by the transient journal.
  • If a Teradata ARC statement specified checkpoints on multiple journal tables, Teradata ARC rolls back only the checkpoint being taken at the time of the client or utility failure.
  • If CHECKPOINT terminates abnormally, all locks placed by Teradata ARC are removed.
  • When Teradata ARC restarts, the CHECKPOINT statement completes.

Add a Comment

Your email address will not be published. Required fields are marked *