Managed and Passive Routing Overview | Teradata Unity - Managed and Passive Routing Overview - Teradata Unity

Teradata® Unity™ User Guide

Product
Teradata Unity
Release Number
16.51
Published
May 2020
Language
English (United States)
Last Update
2020-06-01
dita:mapPath
oic1588030762460.ditamap
dita:ditavalPath
ft:empty
dita:id
B035-2520
lifecycle
previous
Product Category
Analytical Ecosystem

Unity supports two types of routing rules, Managed Routing and Passive Routing. The standard routing rule from versions prior to 15.00 is managed routing.

Use managed routing when you need data synchronization. Use passive routing when running reports or when you do not need data synchronized.

The following table highlights the key differences between managed routing and passive routing.
Managed Routing Passive Routing
Sessions are opened on all available systems, per routing rule definition. The session open command is logged in the Recovery Log. A session is opened on exactly one system, per passive routing rule definition. The session open command is not logged in the Recovery Log.
Sessions can only read and write to those objects that are managed and deployed in data dictionaries.
  • A session can read all objects, whether or not they are deployed in the data dictionary.
  • A session can write to all objects that are not in data dictionaries.
  • [Optional] A session can write to objects in the Deployed Data Dictionary if the Allow Managed Writes check box or the keyword is specified.
Requests are parsed by the Endpoint. Requests are parsed by the Endpoint (so Unity can control writes to managed objects).
Requests go through Unity internal locking mechanism, and are run by the Dispatcher after all locks have been granted. Requests are logged in the Recovery Log. Requests skip Unity internal locking and are sent to the Dispatcher, which then runs them against the database. Requests are not logged in the Recovery Log.
Error code-based retry/resubmit logic only works for read queries (with the limitation that query be the first query in an implicit transaction). Resubmit tries the query on another system where the connection is already open. Error code-based retry/resubmit logic works for both read and write requests, regardless of transaction status and query count within transaction. Resubmit closes the session on current system, opens it on another and tries the query on that system.
A session is no longer available on a system if the system is no longer in the Active state in Unity. The session is recovered at a later time when the system is Active. Once a Ppassive session is opened on a system, it remains Active on the system regardless of the system's state change within Unity. If a request's return code indicates that the session is invalid (for example, due to a system down), the connection is moved to the next system per the routing rule/error code definitions.
Unity performs deadlock detection on managed sessions before the query is sent to the system. Unity performs deadlock detection for passive sessions after the query is sent to the associated system.
Requests update the Transaction Table on the managed systems where the connection is open. Requests do not update the Transaction Table on the managed system where the connection is open.
Loads and exports are allowed. Loads and exports are allowed.
A session close request is logged in the Recovery Log. As with all passive requests, session close requests are not logged in the Recovery Log.