Does a high number of Sde _ state _ lineages slow performance?
Does a high number of SDE_state_lineages slow performance? In our SDE database, the SDE_state_lineages table has around 200,000 records, the SDE_states has around 900, and our SDE_versions table has around 1,300 records. We’ve been having performance issues lately.
How is the sde.state _ lineages table used?
The SDE.STATE_LINEAGES table is used to store a database state lineage in a normalized form. This provides a faster method for obtaining a state lineage and the ability to join the table as a predicate clause in a versioned query. Previous releases of ArcSDE stored the state lineages as an additional binary attribute (BLOB) in the SDE.STATES table.
How does the length of a lineage affect performance?
Performance can be impacted by the length of the version’s lineage, because of the number of states that must be joined between the sde.state_lineages table and the delta tables.
Is there a high number of Sde _ state?
The answer is yes that the number of rows in the sde_state_lineages table directly impacts performance of the geodatabase. 200k rows is not considered “alot” but that is relative to your available resources and assuming there are no versioning issues that would require a diagnose/repair. Continue to compress often.
How does the length of a version lineage affect performance?
Performance can be impacted by the length of the version’s lineage, because of the number of states that must be joined between the sde.state_lineages table and the delta tables. HowTo: Report the length of a version lineage in Oracle http://support.esri.com/fr/knowledgebase/techarticles/detail/35500
How to find number of States in SQL Server lineage?
Here’s the query from that page rewritten for SQL Server: This will tell you exactly how many states each version’s lineage contains. This applies to transactional versions as well as replica system versions. You can also adjust this query to find versions that point to the same state as other versions; see #1.