4

ORA-55378 left a great answer to my question:

Does a high number of SDE_state_lineages slow performance?

But, I realized I don't really understand what lineage length means and how it affects performance? Using the example on this ESRI technical article:

VERSION NAME              LINEAGE LENGTH
------------------------- --------------
TOM.WORKORDER_I0C6531     21
TOM.EDITOR_TB             25
ERIK.WORKORDER_I910313    78
BRENT.DESIGN_F831         92
BRENT.DESIGN_F831_ALT_1   94
BRENT.DESIGN_F831_ALT_2   95
SDE.MAPPING_DEFAULT       138
SDE.LANDBASE              169
SDE.DEFAULT               249
ERIK.EDITOR_EH            275
STEVE.EDITOR_SM           289

What do these lineage lengths actually mean? What is the significance of a length of 289?

Improve this question

2 Answers 2

Reset to default
6

A lineage length of 289 indicates 289 states participate in that lineage. If this is after a compress operation, this indicates there are 289 states that cannot be compressed together to collapse that lineage without affecting the versioned table structure. A likely cause of this is that there are versions that directly reference those states. You can see what state a version currently points to in the sde_versions table.

Edit: If there are active connections, including published map/feature services, there may also be state locks that prevent the compress operation from shrinking the lineage.

Improve this answer
4
  • Would 402 be considered high? I'm trying to get an idea of what is considered too high for a lineage length. We are having pretty severe performances issues and are trying to pinpoint the problem. At this very moment our DEFAULT has a lineage length of 402. So to view our DEFAULT version it needs to query all the lower states? But what about if all the version between that one have never been edited or reconciled? It seems to me like this shouldn't be a problem?
    – geogeogeo
    Commented Sep 11, 2014 at 23:22
  • @geogeogeo My understanding is that long state trees can have major impacts on performance but I think you are now asking a new question so if your original question has been answered I think you should accept it and ask a new one.
    – PolyGeo ♦
    Commented Sep 11, 2014 at 23:29
  • @geogeogeo You may have asked this as a separate question already, but it seems like your workflow is to create new versions on a regular basis while your DEFAULT version is constantly being edited. Whichever state DEFAULT points to at the time of version creation, that version will point to that state and thus block it from being compressed until that version is reconciled or deleted.
    – ORA-55378
    Commented Sep 11, 2014 at 23:40
  • @ORA-55378 okay, that makes sense. Thanks!
    – geogeogeo
    Commented Sep 11, 2014 at 23:49
0

Having a large number of lineages definitely impacts performance. Every database query will be aware of each and every lineage. Effecting overall performance between ArcGIS and the geodatabase. This can be resolved by running a compress more frequently to shrink the lineage length and remove unreferenced states.

This KB article describes the impact of a large number of lineages.

http://support.esri.com/fr/knowledgebase/techarticles/detail/35500

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.