SDE Management - Workflow

468
6
Jump to solution
08-21-2018 06:05 AM
KelseyQuinlan1
New Contributor

Hello, I am fairly new to SDE management and am looking for advice. We will be using Cityworks/Collector to have multiple departments edit GIS data. As a result, I have created a python script to automate the following steps:

1. Disconnect users/ Block Connections

2. Reconcile/ Post/ Delete Versions

3. Compress

4. Clear Workspace Cache

5. Recreate Versions

6. Accept Connections

7. Rebuild Indexes

8. Analyze Datasets

First, I welcome any critique on this workflow. -  I intend to run this after hours on a weekly basis.

Second, I am running into the issue where I am required to (re)register my database prior to republishing any MXDs due to recreating versions - but they all have the same name and permissions so I am at a loss.

We have two database connections and four versions:

.

What am I missing here? Thank you

0 Kudos
1 Solution

Accepted Solutions
JonathanFarmer2
Occasional Contributor III

Hi Kelsey,

I don't think you are missing anything really. 

Your geodatabase maintenance strategy looks good, I see no issues there. The only question I have is, why are you deleting the versions? Are you going for a full compress each time you run this?

I ask because it goes into your second question. Having to re-register all of those child version connections with Server is expected. See this note below that we include on our page on the topic:

"If the database you register contains a versioned geodatabase, ArcGIS Server accesses the version of that data present in the geodatabase version you set for the connection file. If you want ArcGIS Server to access different versions, you must register separate connection files to connect to these geodatabase versions. For example, you may need to register one connection file that accesses the Default geodatabase version and one that accesses a child version."

 

About registering your data with ArcGIS Server—Documentation | ArcGIS Enterprise 

So given that, it seems like deleting the versions each time may not be the best way to proceed. There is a way to get a full compress done without deleting the versions if that is the goal. But getting a full compress done each time you do this is also not necessary.

  1. Reconcile and post all child versions to Default
  2. Re-reconcile all child versions to Default (without posting)
  3. Save edits
  4. Compress

Doing the above will also get you a full compress if that is the desire and also not delete those versions which means you won't need to re-register databases with Server.

Jonathan

View solution in original post

6 Replies
JonathanFarmer2
Occasional Contributor III

Hi Kelsey,

I don't think you are missing anything really. 

Your geodatabase maintenance strategy looks good, I see no issues there. The only question I have is, why are you deleting the versions? Are you going for a full compress each time you run this?

I ask because it goes into your second question. Having to re-register all of those child version connections with Server is expected. See this note below that we include on our page on the topic:

"If the database you register contains a versioned geodatabase, ArcGIS Server accesses the version of that data present in the geodatabase version you set for the connection file. If you want ArcGIS Server to access different versions, you must register separate connection files to connect to these geodatabase versions. For example, you may need to register one connection file that accesses the Default geodatabase version and one that accesses a child version."

 

About registering your data with ArcGIS Server—Documentation | ArcGIS Enterprise 

So given that, it seems like deleting the versions each time may not be the best way to proceed. There is a way to get a full compress done without deleting the versions if that is the goal. But getting a full compress done each time you do this is also not necessary.

  1. Reconcile and post all child versions to Default
  2. Re-reconcile all child versions to Default (without posting)
  3. Save edits
  4. Compress

Doing the above will also get you a full compress if that is the desire and also not delete those versions which means you won't need to re-register databases with Server.

Jonathan

View solution in original post

KelseyQuinlan1
New Contributor

Hello Jonathan,

I appreciate the response. I was under the impression that deleting the versions was a method of getting a full compress. Usually I am left with an End State Count ranging from 3-10 . I followed the process suggested:

  1. Reconcile and post all child versions to Default
  2. Re-reconcile all child versions to Default (without posting)
  3. Save edits
  4. Compress

And I still have an End State Count of 6.  But if getting a full compress each time is not necessary, then it sounds like I don't have to worry. I'm still learning the best practices of managing an SDE. 

Thank you again,

Kelsey

0 Kudos
JonathanFarmer2
Occasional Contributor III

Hi Kelsey,

You are correct, deleting the versions is one method of getting a full compress done. The method I laid out is the other way. If you still have states being referenced after going through this workflow, we'd need to dig deeper into why that is. That may be better handled with a case with Tech Support. 

Full compresses are necessary when you need to unregister a feature class as versioned or maybe you are seeing some performance issues and you want to make sure all your delta tables are empty to rule out something there. There could be a few reasons why you'd want to do it. But there are organizations out there that never get a full compress done because it just isn't possible for them. And that's OK. 

Let me know if I can answer anything else for you!

Jonathan

0 Kudos
MichaelVolz
Esteemed Contributor

Jonathan:

If you have an ArcGIS Server service running that is hitting SDE data wouldn't that prevent your suggested workflow from compressing SDE to state 0, as the mapservice would be holding onto a state?

0 Kudos
JonathanFarmer2
Occasional Contributor III

Hi Michael,

Yes, it would. So that is certainly a possibility here and something to take a look at.

Jonathan

0 Kudos
MichaelVolz
Esteemed Contributor

So the original poster would need to include in his workflow stopping all AGS services hitting SDE at the beginning and then starting all AGS services hitting SDE at the end.  Hopefully, there are no apps hitting these services that would be needed during this maintenance window especially if the workflow takes a decent amount of time to be completed.

0 Kudos