Select to view content in your preferred language

Please explain why I should use geodatabase replication instead of SQL database replication.

1955
2
02-10-2017 02:39 PM
ChrisMathers1
Frequent Contributor

ELI5 (for you redditors): I have an environment where we have a single production database and two publication databases which make up our  AGS Site. The two publication servers are children of the production environment with one way replication only. The minimal web based editing is done directly to the production environment.

While there are mechanisms to pass a schema change from parent to child, new feature classes have to either go into a new replication or the existing one has to be dropped and rebuilt which is annoying with a lot of tables. We keep running into situations where "register existing data", even when a feature class has been manually equalized by deleting the data in the child and appending from the parent immediately before setup, fails to register the data and changes in the parent result in problem records in the child. This happens on both publication servers with several feature classes every time the replications are recreated. Because no changes are made to the data in the publication environment its not clear why its not recommended to use SQL replication instead of esri replication.

I understand that if editing was happening in both places there could be conflicting OID created which would cause problems with network datasets, annotation, etc. which used the OID field to connect records. I know its a highly developed system but the in built geodatabase replication always seems cumbersome to deal with. Being that we have a single production database, which we are unlikely to grow out of anytime soon, we won't be in a situation where a single child is subscribed to multiple parents and we would have to deal with setting up identity ranges and such. All of our normal schema management, adding/dropping fields/tables, happens in ArcCatalog so there wouldnt be any conflict with table and field registration tables in the geodatabase.

0 Kudos
2 Replies
MartinAmeskamp
Frequent Contributor

Hi Chris,

we have a number of customers on ArcGIS 10.2.1 that use a seperate viewing database in addition totheir primary editing database. Some of them use Esri geodatabase replication, others use database mechanisms (mostly Oracle). Both methods are viable, here are some considerations from our experience:

  • Changing the replica definition with GDB replication can be a complex process. We find that the schema change propagation mechanisms tend to be a bit unstable with large schemas, so we generally recreate the replica when there are siginificant schema changes.
  • While the replication process itself is fairly mature, we did run into a couple of bugs involving geometric networks that were very difficult to identify, reproduce and fix (all known problems have been fixed in 10.2.1 UTUP 7).
  • We typically have a mix of versioned and non-versioned data in our databases, so when we us GDB replication, this has to be supported by some way of replicating non-versioned data - we use Oracle Materialized Views and Database Links for this purpose.
  • When using SQL/Database replication technology, I suggest copying the whole database (e.g. using export/import) rather than using differential methods (like Materialized Views) in order to avoid confusion with versioning information.

Martin

0 Kudos
ChrisMathers1
Frequent Contributor

Thanks for the reply. I would probably use transactional replication covering the entire database so we dont have any potential to break geodatabase functions accidentally. We have MSSQL for all three databases. If production wasn't ~16.5GB  I would just do a snapshot every night. Right now we replicate nightly but that is a large file to move every day.

0 Kudos