MODULE 6

Historical Inter-System
Replication

Historical data is transferred between sites by the Datapump application. Unlike the
RealTime replication server, Datapump is only used for replication between systems.

NOTE For information about replication between Historical services, refer to Historical
Service Replication (Module 5).

Any Historical data that is inserted or modified at the hot service on a system is replicated
to the other system(s).

NOTE There may be one or more destination systems, depending on the configuration
of the OASyS DNA. For instance, a system might have an emergency backup system and
a decision support system.

The applications that use Historical insert data only at the hot service. When the data
source system changes as a result of dual-host failover, or as a result of a DistribuSys mode
switch, there may still be many outstanding updates. These updates continue to be
replicated even though the source system is no longer controlling the datapoints. If the
source system is down, these updates will be replicated upon recovery of the system. Also
at this time, data collected at the new source system during the failure will be sent to the
recovered system to resynchronize the databases.

Datapump is configured on a per-table basis so that subsets of the tables in a database can
be transferred to a destination system. For instance, the timeline..collect table does not
need to be transferred to a decision support system if only hourly timeline data is required.

WARNING Datapump is configured using Telvent tools and predefined configurations.

Under no circumstances should the commands to configure Datapump be used directly.
If manual commands are issued to modify Datapump, these commands will be lost if
the system is ever reinstalled or recovered after a failure. Issuing manual commands to
modify Datapump could also result in inconsistencies and cause replication to fail. To
modify Datapump configuration, contact your Telvent representative.

Datapump maintains a constant connection to both the source and destination databases.
It performs small, frequent scans of key tables in the Historical database to extract
modifications. A key table is a small table of keys that acts as a queue for data that needs
to be transferred. Data transfer through the open connection imposes a small, constant
load on the network. A connection failure generates an alarm. For a complete list of
Datapump alarms, refer to Summary of Messages and Alarms - Datapump (Module 15) in
the Operation and Control Reference.

OASyS DNA SCADA Suite Baseline Document Revision 1.2

Proprietary and Confidential to Telvent
-2 Historical Services Configuration and Administration Reference - Baseline

6.1 Troubleshooting Replication Failures

Troubleshooting information is presented here for the following topics:

System not replicating.

Data inconsistent at destination site.

System Not Replicating

If the system is not replicating, check the status of the system to verify that a hot Historical
service exists at the destination system. Use the NMC to check service states for the source
and destination systems. For more information about the NMC, refer to Network
Configuration Guide.
If a destination system is expected to be unavailable for an extended period of time, then
replication to that system should be disabled. Otherwise, the key tables used to replicate to
that destination system continue to grow. The utility DPLongTermOutage is used to disable
and enable replication to systems that are unavailable. The syntax is:

DPLongTermOutage [-h] -D <destinSystem> -o { on | off }

Where the parameters are:

-h Display help text.

-D <destinSystem> Disables/enables replication from this source system to the destination sys-
tem. The XOS Datapump Summary shows valid destination system names.
-o If outage = on (-o on}, disable replication.
If outage = off (-o off}, enable replication.

When replication is enabled, the DPLongTermOutage utility displays information about the
last successful replication to the destination system. This information may be used,
together with the DPResync utility, in order to sychronize tables after the long-term
outage.

Another source of information for troubleshooting can be found in the XOS Datapump
Summary comment field.

The Telvent\log\DPdirect.log file on the source system may also indicate the source of
the replication problem.

If you are unable to restore the system, contact your Telvent representative.

Data Inconsistent at Destination system

If you suspect that the data at one system differs from the data at another system, use the
DPResync (datapump synchronization) utility to compare the tables and, optionally, to
correct the data differences between the two systems. The syntax is as follows:

DPResync -S <source service> -D <destination service>

-b <begin date> [-e <end date>][-y <level>][-j <level>]
[-f <datafile>] [-T] [-h]

OASyS DNA SCADA Suite Baseline Document Revision 1.2

Proprietary and Confidential to Telvent
Module - Historical Inter-System Replication -3

Where the mandatory parameters are:

-S <source service> Uses the same format as the DPutil -S option:

[system:[RDBMS:]][userid/passwd@]service
Typically only the service name is specified, such as, the RDB server
name.
For full description, execute "DPutil -h"
-D <destination service> Uses the same format as the -S option.
-b <begin date> date in seconds GMT or as a time string
in the format: "mm/dd/yyyy hh:mm:ss"

Where the optional parameters are:

-e <end date> Date in seconds GMT or as a time string in the format:

mm/dd/yyyy hh:mm:ss.
Defaults to now (current time).
-y <level> Defaults to -y1
If <level> = 1 Check for differences in the keys between the
source and destination.
If <level> = 2 Same as level 1 but DPFill is called to resolve dif-
ferences.
If <level> = 3 Check for diffences in all columns.
-j <level> Perform an integrity update between the source and destination.
If <level> = 0 do inserts only.
If <level> = 1 do inserts and deletes.
If <level> = 2 do inserts, updates and deletes.
If <level> = 3 do inserts, updates (if required) and deletes.
-f <datafile> Name of file that describes the tables to synchronize. Defaults to:
C:\PROGRA~1\Telvent\scripts\Datapump\DPResyncData_<System-
Name>.txt
-T Run in test mode; do not actually execute against the source or destina-
tion.
-h Display usage message

EXAMPLES comparing keys on source and destination:

DPResync -S NYCXIS -D NECXIS -b 1012539600 -e 1012626000 -f

DPResyncData_NYC_to_NEC.txt -y 1
DPResync -S NYCXIS -D NECXIS -b "02/27/2002 00:00:00" -e "02/28/2002
00:00:00" -y 1
DPResync -S NYCXIS -D NECXIS -b "Feb/27/2002 00:00:00" -e "now" -y 1

EXAMPLE resynchronizing in reverse time order:

DPResync -f datapump_resync_filelist.txt -S TGLHIS1 -D TGLDSS1 -j 1

-b "05/24/2003 00:00:00" -e "05/17/2003 00:00:00"

NOTE To prevent comparison and synchronization activities during times that may
already have high system activity, DPResync halts processing at 5 minutes before the
top of hour, and then continues processing again at 15 minutes past the top of hour.

OASyS DNA SCADA Suite Baseline Document Revision 1.2

Proprietary and Confidential to Telvent
-4 Historical Services Configuration and Administration Reference - Baseline

The DPResync utility uses other utilities to perform the synchronization or comparisons in
the background. A log file is produced to record the output of these utilities. Upon
completion, the Telvent\log\datapump_resync.log file contains a record of the
operations that were performed and their success or failure status. The last line in the log
file is always Done.

The DPCreateResyncDatafile utility creates the data file used by DPResync. The data
file that is created, includes information such as table names, whether the table contains a
time field and, if so, how many seconds of data should be processed at a time, and whether
the table is periodically cleaned up. The data file can be modified to add optional where
clause information, for example, custodyType = shared. This information allows the
DPResync utility to optimize comparison and sychronization activities while reducing
interference with normal operations, for example, minimizing database locks. The syntax
is:

DPCreateResyncDatafile [-f <filename>] [-D <destinSystem>] [-o <order>] [-

v] [-h]
Where the optional parameters are:

-f <filename> Creates the data file describing tables replicated from this source system.
The files are created in the directory:
C:\PROGRA~1\Telvent\scripts\Datapump
Defaults to filename: DPResyncData_<SystemName>.txt.
-D <destinSystem> Creates a data file that only contains tables that are configured for repli-
cation from this source system to the destination system.
This option also adds the destination system name to the default data file-
name.
For example, if no filename parameter is specified but a destinSystem is
specified, then the file created is:
DPResyncData_<SystemName>_to_<destinSystem>.txt
-o <order> If order = asc, order the file using priority ascending.
If order = desc, order priority descending.
(desc is used by deletion scripts.)
Default: asc
-v Prints progress messages.
-h Display usage message

6.2 Checking Datapump Status

You can check the status of the Datapump at any time using DPutil. The syntax is as
follows:

DPutil -S source -D destination -d database -t table [-r] [-R] [-i] [-I]

[-K] [-e]

-r
Prints a summary that contains the same information as in the XOS datapump
summary.

-R
Prints all the datapump column values that are important to the configuration of the
data transfer including the status columns returned using the -r option.

OASyS DNA SCADA Suite Baseline Document Revision 1.2

Proprietary and Confidential to Telvent
Module - Historical Inter-System Replication -5

-i
Prints the Datapump entries that failed or are in transit.

-I
Prints the Datapump entries that failed.

-K
Prints the the number of rows queued up in each configured key table. It gives you an
idea of whether the transfer is working or if it is backing up.

-e
Print the datapump events for past 24 hours.

-S source
Identifies the source connection (the default is MS:(local)). The source is specified as:

[system:[RDBMS:]][userid/password@]service

System is specified when you want to only see information for a particular destination
system. RDBMS can be SYB, FILE, BINFILE, ORA, ODBC, or MS. Use DPutil -h to
obtain the list of RDBMS types available on your system.

For example: -S ORA:metso/metso@ORA8

-D destination
Identifies the destination connection (the default is XISB). The destination is specified
in the same manner as the source.

-d database
Identifies the database that contains the table to be compared between systems.

-t table
Identifies the table to be compared between systems.

For additional information about the Datapump application, refer to the Operation and
Control Reference.

OASyS DNA SCADA Suite Baseline Document Revision 1.2

Proprietary and Confidential to Telvent
-6 Historical Services Configuration and Administration Reference - Baseline

OASyS DNA SCADA Suite Baseline Document Revision 1.2

Proprietary and Confidential to Telvent