Dbvisit Replicate 2.9

Dbvisit Replicate 2.9

I am very pleased that we here at Dbvisit are able to say that. We have been working on this release since 2.8 came out. It was a little over a year ago that we released 2.8. The first thing that you will notice is that we called it 2.9.00 vs 2.9. Not a huge change but a few of our developers thought I should be more accurate with what we called it. They did the coding so I thought it only fair.

First we have some things I probably mention at every release. We updated the documents to reflect 2.9.00 new features. We also have incorporated some changes that partners have asked for. We went through all of the support tickets and tried to find out if there were any places in the documents that we could make clearer or that were confusing.

The next step was improving the support package. This is something that we take to heart. We know how important the support package can be when trying to resolve an issue. So with that in mind, we try in improve the package every release. Support analysts are always thinking about ways to improve it. We added more information about current running processes to the support package and we added more things for support personnel to get what they need to help customers resolve issues. Support also sometimes asks for a SQL Trace or a ‘10046 trace’ from our customers. We thought it would be nice if we could add that within the product to turn that on for customers. Especially if they are not very familiar with SQL Trace.

There were a few items that we included in the ‘ease of use area’. We have made some changes in how we clean up some of our repository tables. The DBRSCOMMON_ERRORLOG table can grow quite large, especially for customers who make use of conflict handlers. We have added some automatic cleanup to the code so that customers no longer have to fear this table getting large. Additionally, we have updated our NextSteps.txt document to further clarify TNS_NAMES.

Conflict handlers can be quite useful in certain situations, not just in a bidirectional mode. A few customers and partners have requested something that we thought was great. All conflict handlers have a default option if they are set. Customers told us that it could be useful if they could set a customized default rather than relying on the Dbvisit default. So we included this in 2.9.00.

If a conflict needed to be manually resolved, we always had the method of resolving it and including the number. We made a small change which we think might help people do things faster, that is making a command called ‘Resolve last conflict’. This way they don’t need to type in the number, they just resolve the very last conflict.

We had a number of ‘behind the scenes’ changes that won’t be apparent to end users but I thought I would mention them. We looked deeply at all of our compile methods on the many different platforms. Because we support so many different platforms we need to make sure that the product works the same on each of them. We had a project where we made sure that the code compiled correctly and was the same on all operating systems. It was a long process but worthwhile. We have also increased our automatic QA. We increased the number of test suites that we run as well as have them automate with our build process. We still do a lot of manual testing but we combine that with our auto testing for a more thorough testing process. Combined with this effort, we have fully embraced containers. We have made sure that our software is compatible with Docker and a few other containers. Customers and partners were asking about it and many of our developers and QA team have made great use of containers.

Datatypes are always on our mind here at Dbvisit. Replicate 2.9.00 will support five new datatypes. Temporal (new in Oracle 12c) is now supported, we want to make sure we keep up with new features as Oracle releases them. BINARY_DOUBLE and BINARY_FLOAT were requested by a partner to support them for their application so we now support those datatypes. ROWID has been asked about for a while. It is a strange datatype and one that I will warn customers to be careful about replicating. ROWID is the location of the storage of the actual location of the row. Replicating this location to a target database may not be very useful as the row in question will not likely be located there on the target side. However enough people have asked about it and it is now a supported datatype. Saving the best for last, XML datatype is now supported. I know customers have been asking for it for quite some time. We know that may applications make use of XML and we are happy to say that many of those applications can now be supported with Dbvisit Replicate.

How about new targets? We made some minor tweaks to our support for Oracle on AWS RDS. We have supported that for a few releases but have made some minor internal tweaks to result in a less manual process. We have 2.5 new targets in 2.9.00. You have heard Dbvisit talk about Kafka a lot in the past year or so. We have supported Kafka in 2.8, but we have LOTS of new features and enhancements in 2.9.00.

Kafka is now incorporated into our testing suites and Kafka is a full part of the Dbvisit Replicate family as a target. Tibero, by TMAXSoft is now a supported target. We have had a number of companies ask us about Tibero in the past. Tibero has historically been mostly in the APAC region but are now making a push worldwide. We are excited to have a brand new target.

A third new target for Dbvisit Replicate is PostgreSQL. PostgreSQL is a leader in the open space database market and one that seems to be growing with acceleration. PostgreSQL has long been on our roadmap but we moved it up as more and more partners have told us that PostgreSQL’ popularity seems to be increasing.

So there is a quick rundown of the Replicate 2.9.00 new features. We hope that you will download this version and start testing it out soon. We would love to hear from you on what you think of the new features. Replicate 3.0 coding is under way and we think you will like the changes we are making there as well.

In the next blog I will go into some of the technical aspects of the new features that I mentioned above and show some code snippets and how these features can be used.


by Chris Lawless | Jul 6, 2017 | Data Streaming, Database Replication, Dbvisit, Dbvisit Replicate, Dbvisit Team, Disaster Recovery, Logical Replication, Oracle Databases

Facebook Comments