Create user-schema to make management of state tree more efficient?

[MarkChilcott]

Hi Peoples,

When I access a feature class in an Enterprise Geodatabase that is not registered as versioned – will the version tree and state tree effect performance?

Our PROD database is 99% simple read only feature classes.  There are one or two feature classes that are registered as versioned.  We are considering placing the versioned data into a user-schema geodatabase with the thought that it would make compress back to state zero easier, and thus make management of the instance more efficient.  Ie we would not have to kick all the users off the database to do a successful compress back to state zero – just the schema user.

… or are we overthinking this?

Cheers,

Mark

[George_Thompson]

Hi Mark,

If the feature class is not versioned it should not touch the version or state tree and not impact performance. Moving the data to a user schema geodatabase will not help with the compress either.

If you are not getting a full compress what is your starting and ending state?

Do you have any replicas built from the versioned data?

You may need to review the information on compressing a enterprise geodatabase.

Geodatabase compression—Help | ArcGIS for Desktop 

The compress operation and geodatabases—ArcGIS Help | ArcGIS for Desktop 

http://downloads.esri.com/support/whitepapers/ao_/J9842_GDB_Compress_With_Replicas.pdf 

[AlexanderBrown5]

Mark,

As George indicated, most of your data is not versioned.  It will not impact performance if you only have one or two feature classes registered as versioned; unless you have an enormous number of edits. 

If you are only doing dozens of edits per week for each feature class, it should not be difficult to reconcile, post, delete versions, and compress weekly.  

After doing your reconcile/post and deleting all versions after Default, I would suggest utilizing the ArcPy commands to complete your process.  In simple form:

import arcpy
import time
from arcpy import env

# Set the workspace
workspace = r'Database Connections\SDE_CONNECTION_TO_DATABASE.sde'
env.workspace = workspace

database_name = str(workspace.split('\\')[1])

# Block new connections to the database.
try:
    print 'Blocking connections in %s' % database_name
    arcpy.AcceptConnections(workspace, False)
except (arcpy.ExecuteError, arcpy.ExecuteWarning) as e:
    print e

# wait 120 seconds
time.sleep(120)

# Disconnect all users from the database.
try:
    print 'Disconnecting all users from %s...' % database_name
    arcpy.DisconnectUser(workspace, "ALL")
except (arcpy.ExecuteError, arcpy.ExecuteWarning) as e:
    print e

# Run the compress tool.
try:
    print 'Compressing database...'
    arcpy.Compress_management(workspace)
except (arcpy.ExecuteError, arcpy.ExecuteWarning) as e:
    print e

# Allow the database to begin accepting connections again
try:
    print 'Accepting Connections from %s...' % database_name
    arcpy.AcceptConnections(workspace, True)
except (arcpy.ExecuteError, arcpy.ExecuteWarning) as e:
    print e‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

AcceptConnections—Help | ArcGIS for Desktop 

DisconnectUser—Help | ArcGIS for Desktop 

ListUsers—Help | ArcGIS for Desktop 

You can of course also script your reconcile and post, but many organizations like to go through that process manually to verify/determine any conflicts.

In short, a few versioned feature classes will not adversely affect your databases performance; I would advise against creating a user schema geodatabase for this use case.

~Alex