Stelo + Oracle

Stelo is designed to make all deployment steps easy and straight forward with many automatic and automated procedures. You can choose which tables, rows, and columns you want to replicate, ensuring that data is replicated efficiently from one datatype to another without complex programing. A typical deployment has you up-and-running in hours, not days.

This is a key area where you can separate the wheat from the chaff. The best replication solutions deploy in under 24 hours. The worst require a week or more of configuration. Deployment time is also a good way to assess reliability. If the initial configuration is complex and time-consuming, you can expect stability and performance problems to arise in the future.

Baseline copies of data should not require more than 24 hours to create unless you are replicating an unusually large amount of data. If initial customizations take a lot of time upfront, you can expect similar lags when customizing in the future as well. High-performance software does not require much tweaking, and you should be wary of the reliability and accuracy of solutions that require extensive reprogramming.

Stelo can handle large-scale data transfers replication with sub-second latency. A single instance can support multiple sources and destinations without additional licensing. The Stelo model is independent of the number of cores of either the source or destination—so you only pay for the capacity required to support the transaction volume. connections. This cost-efficient method merges source data flows into one stream, and then it is applied to any number of subscribing destinations. Stelo delivers enterprise-level performance without enterprise-level cost.

Unlike trigger-based replication software that can consume quite a bit of production resources, Stelo is built to have a near-zero impact on production databases. It’s deployed on an intermediate server between the source and destination databases, resulting in virtually no resource drain on production infrastructure.

We encourage customers to configure Stelo’s software to create the destination tables on SQL Server and MySQL. In part, this is to ensure the proper mapping of change data captured on the IBM i system and the destination table. Also, if your high availability (HA) software utilizes *AFTER images only for capturing change data, then Stelo’s software must rely upon a synthetic column (the Relative Record Number or "RRN") to uniquely identify the row in the destination table, and it is unlikely that the Oracle JD Edwards (JDE) tool would provide this column. Therefore, it is best to allow Stelo to create the destination, including this column for each table. Alternatively, if the HA software configures *BOTH images in the journals then we can dispense with the RRN column and just utilize any unique index (including a primary key) to identify rows.

Another issue that should be addressed in the planning stage is the use of Unicode datatypes on the destination SQL Server. We strongly encourage customers to use NCHAR/NVARCHAR data types for SQL Server, as this provides the greatest fidelity when mapping data from IBM i EBCDIC to Windows and other non-EBCDIC environments. Our recommendation is to allow Stelo to create the tables and exploit UNICODE data types, and then use the tool to create any additional indexes.