Stelo + IBM Db2 for i

IBM Db2 databases can generate large datasets, but Stelo can handle large-scale data 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. 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.

Stelo is responsive to database schema changes without disrupting production systems. Alter, Add and Drop schema changes are replicated automatically. In the event of all other DDL Alter processing, the user will be notified of the change to be resolved. There are many levels of notification, including email and log access, so you can tailor alerts to your preference.

Yes, Stelo uses only standard IBM i commands and APIs to interact with the journal receiver and will not interfere with other applications. We have numerous customers using Stelo’s software with high availability (HA) products such as Vision Solutions MIMIX, IBM DataMirror, IBM Infosphere CDC, Trader's QUICK-EDD, and MaxAVA HA. The main issue customers have is deciding if they want to use *AFTER only imaging; this decision forces Stelo’s software to be exposed to reorganization.

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.