Traceability matrix impact analysis queries timing out on large baseline snapshots

ALM IBM Engineering Lifecycle Management
, , , , , , , ,
1

We’re experiencing severe performance issues when running impact analysis queries on our traceability matrices in ELM 7.0.3. Our automotive project maintains bidirectional traceability for ISO 26262 compliance across ~45,000 requirements, test cases, and work items.

The problem surfaces when querying baseline snapshots for impact analysis. Queries that traverse traceability chains beyond 3 levels timeout after 5+ minutes, making compliance audits impractical.

Current query pattern hitting performance wall:

SELECT artifact_id, link_type, target_id
FROM traceability_links
WHERE baseline_id='BL_2024_Q3'
  AND source_type='requirement'

We’ve verified database indexes exist on baseline_id and artifact_id columns. Server logs show query execution times exceeding 300 seconds for full impact analysis. Our compliance team needs results within 30 seconds for practical audit workflows.

Has anyone optimized database query performance for large traceability sets? We’re particularly concerned about baseline snapshot caching and incremental analysis configuration for ISO 26262 filtering.

2

Thanks for the composite index suggestion. I checked our database schema and we only have individual indexes. Before I propose schema changes to our DBA team, are there any ELM configuration options for traceability query optimization? I noticed the Advanced Properties section mentions cache settings but documentation is sparse on what actually helps with baseline snapshot performance.

3

We had identical timeout problems on our ISO 26262 project with 38K artifacts. The breakthrough was enabling incremental impact analysis in the traceability configuration. Instead of querying the entire baseline snapshot, it caches the traceability graph structure and only recomputes changed branches. This reduced our typical impact analysis from 4 minutes to under 20 seconds. You’ll find the setting under Project Properties > Traceability > Impact Analysis Mode.

4

Building on previous suggestions, here’s a comprehensive optimization approach addressing all your performance bottlenecks:

Database Query Optimization: Implement composite indexes specifically for baseline queries:

CREATE INDEX idx_trace_baseline_composite
ON traceability_links(baseline_id, source_type, artifact_id, link_type)

This covers your exact query pattern. Additionally, partition the traceability_links table by baseline_id to isolate active baseline data from historical snapshots.

Baseline Snapshot Caching: Enable the traceability graph cache in advanced properties:

  • Set `com.ibm.team.traceability.cache.enabled=true
  • Configure com.ibm.team.traceability.cache.baseline.ttl=3600 (1 hour cache lifetime)
  • Increase com.ibm.team.traceability.cache.maxSize=500MB for large artifact sets

This caches the resolved traceability graph structure, avoiding repeated database traversals for the same baseline.

Incremental Impact Analysis: Configure incremental mode in Project Properties > Traceability Configuration:

  • Enable “Incremental Impact Analysis”
  • Set “Maximum Traversal Depth” to 5 levels (your current unlimited depth is killing performance)
  • Configure “Change Detection Threshold” to 100 artifacts to trigger full recalculation

Incremental mode maintains a cached graph and only recomputes affected branches when artifacts change, dramatically reducing query load.

ISO 26262 Compliance Filtering: Optimize compliance-specific queries by:

  1. Creating filtered views for ASIL-level requirements at the database level
  2. Using link type restrictions in the traceability configuration rather than post-query filtering
  3. Implementing custom query templates that include compliance filters in the WHERE clause

Example optimized query structure:

SELECT t.artifact_id, t.target_id
FROM traceability_links t
INNER JOIN artifacts a ON t.artifact_id = a.id
WHERE t.baseline_id = ?
  AND a.asil_level IN ('B','C','D')
  AND t.link_type IN ('satisfies','verifies')

Monitoring and Validation: After implementing these changes, monitor query execution plans using your database’s EXPLAIN functionality. Target execution times should drop to 15-30 seconds for full impact analysis on 45K artifacts. For routine compliance checks, queries should complete in under 10 seconds.

We implemented this exact combination on a 52K artifact automotive project and reduced average impact analysis time from 320 seconds to 22 seconds. The incremental analysis mode was the single biggest improvement, but the composite indexes and caching were essential for baseline snapshot performance.

5

Another factor: ISO 26262 compliance filtering adds significant overhead if you’re applying link type filters in application code rather than the database query. Move your compliance-specific filtering (safety requirements, ASIL levels) into WHERE clauses with proper indexes. Also verify your baseline snapshot retention policy - we’ve seen performance degrade when systems retain 50+ historical baselines without archiving old snapshots.

6

The composite index recommendation is correct but insufficient for baseline snapshots. Your query shows the core problem - filtering by baseline_id forces a full scan of historical data. We solved this by partitioning the traceability_links table by baseline_id ranges. Additionally, create a materialized view that pre-computes common traceability paths for active baselines. This shifts the computational cost from query time to baseline creation time, which is acceptable for compliance workflows.

7

I’ve seen similar timeout issues on large automotive projects. The baseline snapshot query is likely doing full table scans despite indexes. Check if your traceability_links table has composite indexes on (baseline_id, source_type, artifact_id) rather than individual columns. Single-column indexes don’t help much with complex join patterns in impact analysis queries.