Interrupted Objects | Teradata Business Continuity Manager - Interrupted Objects - Teradata Business Continuity Manager

Teradata® Business Continuity Manager Monitoring and Management Guide

Deployment
VantageCloud
VantageCore
Edition
VMware
Enterprise
IntelliFlex
Product
Teradata Business Continuity Manager
Release Number
1.xx, 2.xx
Published
January 2024
ft:locale
en-US
ft:lastEdition
2024-02-06
dita:mapPath
wmz1639626084071.ditamap
dita:ditavalPath
ft:empty
dita:id
wmz1639626084071
Product Category
Analytical Ecosystem

An object becomes interrupted on a system if a SQL statement succeeds on the active system but fails with an error on the standby system. This mismatch causes objects to become interrupted on the system with the error. Business Continuity Manager replays the SQL statement to attempt recovery. Some errors may recover automatically, although others require manual intervention.

Common reasons for interrupted objects include:
  • A GRANT statement was run on the active system but not on the standby system, causing a permissions violation on the standby system.
  • Standby system running out of perm space for a query.
  • Standby system running out of spool space for a query.
  • An external load job failed and left a load lock on a table on the standby system.
  • An external cleanup script dropped an object on the standby system.

If an object is interrupted on a system, and another SQL statement or session needs to use that object, any other objects used by that session or SQL statement also become interrupted. This is a cascade interrupt. Once the objects or sessions required for this object recover, the cascade interrupts recover as well.

The recovery may take a few attempts, but if no more root cause interrupts occur, the objects become active.