Fall 2023: Shadowbase Delivery News

Chris Capitolo, Senior Manager of Product Delivery

New and Improved Method of Replicating SQL/MP Key-sequenced SYSKEY Tables

HPE NonStop Shadowbase Version 6.801 includes a new method for replicating an exact copy of a SQL/MP key-sequenced table that contains a SYSKEY. In order to understand the impact of the new method, it first may help to understand the old method that used to be the only option.

The Old Method

In previous versions of Shadowbase, replicating an exact copy of an MP SYSKEY table required Shadowbase in the Guardian environment on the source system to connect to Shadowbase in the OSS environment on the target system. It also required the user to configure TCP/IP between the two systems, and OSS and ODBC/MX on the target system in order to complete the configuration. Below is a diagram showing what this old method looked like:

The Old Method

The reason this configuration was required for these MP tables was due to the fact that users wanted their MP SYSKEY tables to be an exact match between the source and target system. The problem was that when SYSKEY value ‘123’ was inserted on the source, it was impossible to replicate that insert with the same exact SYSKEY value ‘123’ into the target table using the SQL/MP engine. As a result, users could not maintain an exact copy of the target table using the standard Shadowbase NonStop to NonStop replication environment. Fortunately, there was a workaround to allow users to specify the value for their MP SYSKEYs, which was to access the MP table via SQL/MX. Users could then set up Shadowbase on their target system in the OSS environment to connect into SQL/MX. Then, by using Shadowbase NonStop to Other Servers replication, they could generate a configuration to replicate the MP SYSKEY events into OSS on the target system, which would then get sent into the SQL/MX environment via ODBC/MX. Finally, the event would get applied to the target MP table with the exact SYSKEY value intact.

If that all sounds a little complicated, you are not alone! Depending on your environment, you may have had the majority of your SQL/MP tables being replicated from source to target over an Expand connection between the two systems, and all of the Shadowbase processes running in the Guardian space. If even one SYSKEY table needed to be included in that environment, this method of replicating the table would introduce TCP/IP, OSS, ODBC and SQL/MX into the configuration, all of which needed to be configured properly. It could present a challenge when users were not already familiar with these NonStop components, so configuration often proved to be difficult.

The New Method

Fortunately, the new method for replicating these tables eliminates the complications presented in the old method. Using this new method, Shadowbase still relies on SQL/MX to insert the exact SYSKEY value into the target table, but it now operates at the Guardian level using a new Shadowbase-managed server process to help coordinate the work (see the diagram below).

The New Method

This time, the Shadowbase configuration can be very similar to the rest of the replication threads going from source to target:

• The Consumer now spawns a new process called SBMXSERV that handles the MX operations.
• As the Consumer receives the replicated change data events made to the source MP SYSKEY table, it passes those events to SBMXSERV, which connects into SQL/MX and inserts the MP row with the exact SYSKEY value intact.
  • No more TCP/IP, OSS or ODBC/MX required!
• In addition, this new Consumer thread can be configured right alongside all the other replication threads for a single Shadowbase environment, rather than having a special configuration that used OSS and ODBC.

This Shadowbase enhancement provides users with a much easier method to replicate MP SYSKEY tables. Please refer to the softdoc for the relevant Shadowbase release or the Shadowbase manuals for more information on how to begin implementing this configuration.