Tag Archives: Replication
Geodatabase replication works in both connected and disconnected environments. Which of these environments is most appropriate for your replication requirements depends on what type of network you have and the speed of that network.
What’s the difference between connected and disconnected replication again?
Well Lenny, let’s take a look: Continue reading
In a previous blog post, we blogged about an important replication issue that was found in ArcGIS 10.0. We have recently released a patch for this issue and it is recommended anyone using replication at ArcGIS 10.0 install this patch. More information about the patch, including the download, can be found here.
Customers who plan to use ArcGIS 10 with geodatabase replication need to be aware of an issue that causes synchronization to fail. Full details are available in Knowledge Base article 37896.
ESRI is working on a fix that should be available soon. For update on status, you can use bug number NIM058231—Upgrading geodatabases with replicas to version 10 causes synchronization process to fail.
We will keep you posted via this blog post as updates become available.
New at ArcGIS 10 is the ability to map replicated feature classes and tables in the parent replica to those in the child. What this means is, at 10, a replicated feature class can have a different name in the child replica than it does in the parent.
This can be done in two ways. One scenario is during replica creation, you can set the names of the feature classes and tables being created in the child to be different from the names in the parent. The second scenario is when you are creating a replica pair by registering existing data hosted on two different geodatabases. In this case you can define a mapping between a feature class in one geodatabase to an identical feature class in a second geodatabase that has a different name.
This has been requested functionality since we introduced replication at 9.2 and there are numerous situations where this might be useful. This sounds more complicated than it actually is, so I’ll focus on a couple specific examples in this post to get the point across.
Re-naming feature classes on the child replica
One of the more applicable scenarios for this new functionality is when you are replicating a subsection of data from your geodatabase. You may not want the data being distributed to the child replica to be labeled the same as it is in the parent. You are now able to change the name of the replicated feature class during replica creation so that the data on the child is labeled more appropriately.
For example, a common type of dataset used for census or taxation purposes is the US states and counties polygons. In this example, these datasets are named US_States and US_Counties respectively. But if you’re working in the California department, you only need the data for your region. So you create a replica which contains a subset of the data from the nation-wide geodatabase. Since these datasets no longer represent the states and counties for the entire United States, you’ll want to re-label them to something more appropriate like California and California_Counties.
You make this name change during replica creation in the create replica wizard. Make sure the ‘Show advanced options…’ check box is checked.
By default, the feature classes created in the child replica are given the same names as the original feature classes they were replicated from:
Editing the target name, we can change the target feature class names to something more appropriate.
Mapping feature classes in one replica to feature classes in another
Another situation where schema mapping can be useful is when you have your data distributed already in two locations and simply want to register them as a replica pair. If the schemas match you can map the feature classes and tables in one replica to feature classes and tables in the other replica which may have different names.
This is also done in the create replica wizard, this time you choose Register with existing data only. Again, make sure the ‘Show advanced options…’ check box is checked.
In the dialog where you choose which items to replicate, under the Target Name column you now have a combo box containing potential feature classes you can map to. In this example we are mapping the California_Counties feature class in one replica to the US_Counties feature class in a second replica.
This may seem like a fairly trivial enhancement, but it allows you to create child replicas with feature class names appropriate for their designed use, as well as define replicas on existing data without having to change dataset names to match in both geodatabases.
The geodatabase replication team has added an enhancement to one-way replication at ArcGIS 10 that allows you to use archiving to track replica changes instead of versioning.
When this option is active, the geodatabase will track changes in the archive table instead of using the adds and deletes tables associated with versioning. So when synchronizing replicas, the sync process references the archive table to determine what edits have been made and sends those changes to the relative replica.
Why would you want to do this?
Well, a common administrative task when managing a versioned geodatabase is to compress the geodatabase to remove redundant data and take entries in the adds and deletes tables common to all versions and merge them into the base table. This makes your geodatabase perform better as drawing and querying processes will have less data to cycle through.
When using geodatabase replication, system versions are created behind the scenes to facilitate the synchronization process. Due to these system versions, you need to synchronize regularly in order to achieve an effective compress. So effective version management relies on effective replication management.
However, when archiving is used to track replica changes, no system versions are created. Therefore, the compress process is not affected, making version management and replication management independent. This also allows the synchronization schedule to be more flexible, so this is a good option to keep in mind when creating a one-way replica.
To set up one-way replication with archiving, your source data must have archiving enabled (so it needs to be in an ArcSDE geodatabase and be registered as versioned) and you have to create your replica off of the DEFAULT version.
To enable this option when creating a replica in ArcMap, run the Create Replica wizard by clicking the Create Replica button on the Distributed Geodatabase toolbar.
Then click Use archiving to track changes for 1 way replication on the advanced options panel of the wizard.
This week ESRI hosted the annual Developer Summit down in Palm Springs. The geodatabase team was there to answer user’s questions, announce a few of the 9.4 projects that are in the works, and give several technical sessions.
I’ve gathered the slides from our presentations to post up here on the blog. Click on the thumbnails below to view PDFs of the various presentations.
Here’s a heads up on a couple items of note regarding replication:
There is a new 9.3 SP1 geodatabase replication patch. This patch addresses cases where replica system versions are not being removed when they should be during a connected synchronization. We recommend that all who use geodatabase replication with ArcGIS 9.3 install this Patch.
There is also a new article that describes timeouts and data limitations when replicating with geodata services over the internet. Anyone replicating with geodata services over the internet should review this document.
There is new documentation available which talks about some best practices when using the compress command while also employing geodatabase replication. Compress is a process run periodically by an ArcSDE administrator to reduce the size of the geodatabase and improve performance. Replicas in the ArcSDE geodatabase can affect the compress process. This paper describes best practices for achieving an effective compress when there are replicas.
It is recommended that you first have an intermediate understanding of ArcSDE, versioning and replication before reading the paper.
To have a look at the paper, click HERE
Last week I was in Palm Desert at the annual EGUG conference. While sitting in on a presentation I noticed that for a lot of the questions being asked, users were being directed to developer samples found online. I realized that while these samples are readily available, it was clear that not everyone knew about them or where to get them.
So I talked to Larry Young, who had moderated the session, and he put together the following list of developer samples that could prove helpful:
- One to many labels – label features based on attributes in a one to many relationship (i.e., multiple stacked labels per feature)
- Valence display – customer renderer to display the number of edges connected to a junction
- Batch snapping – snaps all selected features based on the current snapping environment
- Jumper extension – automatically creates a half circle in a line feature when it crosses another line feature in the same class
- Rotate symbol – rotates a point feature symbol based on the orientation of the line the symbol is snapped to
- Delete junctions with edge – deletes orphan junctions that are not connected to anything when an edge feature is deleted
- Merge network features – merges selected edge features
- Domain sort – sorts the current domain
- Manage versions – gives tree/hierarchal view of versions
- Next upstream device trace task – custom trace task to find next upstream junction from a specified class
- Find domain references – find places where a domain is currently being used
- Trace results window – allows results from multiple traces to be stored, displayed, and converted to a selection set
- Loop Construct – sketch tool used to construct a loop around a broken pipe segment
- Flow by digitized direction – sets the flow direction of a geometric network based on digitized direction of edge features
- Flow direction tool – sets the flow direction of individual network elements
- Geodatabase designer – arccatalog toolset for export/import gdb schema. Includes capabilities to copy domains, etc.
More information on geodatabase replication has recently been added to the help system and to KB articles. This should help address some of the more commonly asked questions. The following describes the new information and where to find it:
Replicating with relationship classes where the primary key is the objectid column
There are some factors to bear in mind when replicating data where there are relationship classes that use the ObjectID column as the primary key. The 9.3 desktop help has been updated to describe this in more detail.
Loading data while preserving globalids
In some use cases, it is necessary to transfer data before creating replicas. Here it is important to make sure that the GlobalID values remain consistent. A new how to article has been added that describes use cases where data needs to be transferred before creating replicas and how to preserve the GlobalIDs when doing so.
Using replica creation and synchronization events
Geodatabase replication can be extended where custom behavior is associated with the replica creation or the replica synchronization process. For example, you may want to extend synchronization to copy additional rows from application specific non-versioned tables. A new article has been written thet describes extending replica synchronization in addition to the existing one that describes how to extend replica creation.
New technical articles
A number of new technical articles have been added recently including one that talks about how to effectively compress a geodatabase with replicas. These are listed under geodatabase replication technical articles.