When do I need to regenerate code?

You need to regenerate the replication code whenever there are mapping changes. However, triggers and bulk load processor code need to be generated only when a new table is added to replication. Replication processor library code needs to be regenerated whenever a table or field is added or removed.

When do I need to update table or field mapping?

The mapping of tables and fields does not update automatically when schema changes are made to either the source or target database. Once the changes are made to the target SQL schema and after the schema holder is updated, you need to update the mapping to map new tables/fields and to delete mapping of removed tables/fields.

When do I need to update the schema holder?

Anytime a change is made to the target SQL database schema the schema holder database needs to be rebuilt or updated.

How do I contact Pro2 Technical Support?

To report a new issue or update an existing issue, please login to the Progress SupportLink application at http://progresslink.progress.com/supportlink.

If you do not have a SupportLink login, please register at http://progresslink.progress.com/, or if you need immediate assistance please call us directly.

See the support contact page at http://web.progress.com/en/support/contact-support.html

A SupportLink login provides you with the ability to receive exclusive access to the SupportLink Web portal—a single location to access the latest support information, search our knowledge base and manage your support issues 24x7. SupportLink includes:
  • Automated knowledge base searches during support case submission to find potential solutions to your issue.
  • The ability to set case severity level and provide additional details on your business impact to help us quickly resolve your issue.
  • The ability to define and store multiple personalized environments to associate with your support case at the click of a button.
  • The ability to manage all your support cases by easily opening, closing and escalating issues.

What is thread lag?

Thread lag is the replication record's, also known as replqueue, lag time between creation and processing, at a point and time per day, by thread number. When replication record is processed Pro2 reads the interval in minutes between the time the replqueue record was created and when it was processed. Pro2 creates a temp table record with the srcrecord and interval.

After each batch of replqueue records are processed in ReplProc.p and the shutdown check is complete, Pro2 consolidates the data into 1 record per thread, per hour, per day, and writes it to the replp_thread lag table. When the consolidation is complete, Pro2 looks to see if a record already exists for the thread, thread type, and, lagdate = today. Additionally, it checks if the record is within the lag hour or current hour. If no record is found and the record is not locked, Pro2 accumulate the AVERAGE COUNT MAXIMUM MINIMUM for the lag-minutes written during replqueue processing. That information is stored in the replp_threadlag table by date, thread, and thread type. When the data is read by the Thread Lag graph on the Pro2 UI dashboard, the data is summarized by date using all threads, and by extension displays as 1 record per date.

What is the difference between the Pro2 Enterprise View and the Pro2 web user interface?

The pro2 instance is referred to as the traditional replication setup. The newly released enterprise version displays the consolidated details of one or more Pro2 instances. With the help of the enterprise version, the DBA can monitor the activities of all the instances from a single enterprise view. 

What is the version compatibility of the Pro2 Enterprise Eiew?

There are no restrictions on the Pro2 instances or Pro2 enterprise view compatibility. You can connect any version of the Pro2 instance with any version of the Pro2 Enterprise View.

Does the installation of the Pro2 Enterprise View interfere with the Pro2 6.2.x version?

Pro2 6.2.x Instances and Pro2 Enterprise View are installed separately and do not conflict.

Do I need to change my replication policies or triggers?

No. Multi-threaded bulk load only affects how the initial bulk copy is executed. Ongoing change-data replication operates independently.

Can a multi-threaded bulk load run while regular replication is active?

Yes. Bulk load operates on the source-side range scan and target-side write path. Normal change replication continues independently. For full configuration details, see Multi-threaded bulk load.

What happens if I terminate a worker process during loading?

The other workers continue. Pro2 places the in-flight range of the terminated worker in an IN-PROCESS state and automatically retries it when the bulk load runs the next time the bulk load runs.

What happens if the entire bulk-load job is stopped and relaunched?

Relaunching the job triggers automatic recovery. Pro2 skips completed ranges, resumes in-flight ranges from a checkpoint, and processes only remaining work.

How do I monitor progress during a multi-threaded bulk load?

While the load is running, click See Thread level info on the Bulk Load Running Status card to view the progress of each individual worker and the range it is currently processing. When all workers have finished their ranges, the table status changes to COMPLETE and Pro2 displays the final record count.

Are the loaded records identical to the single-threaded version?

Yes. The same per-table procedure writes the rows. Only the dispatch and parallelism are different.

Do I need to regenerate bulk load procedures before using multi-threaded bulk load?

Yes. Run the procedure generator using GEN_PROCS in command-line mode, or select the Generate option in the web UI for all mapped tables, before setting Thread Mode to Multi. The generated procedures include additional parameters required for parallel range processing, which are not present in procedures generated with earlier releases of Pro2.