Duplicate Catalog Assets After a Second Connection

The symptoms point to overlapping scans of the same database through two catalog connections. The second service account created a separate connection identity, so CDGC treats the same physical objects as new assets with different qualified paths. The 5,500 increase is roughly consistent with a partial or full duplicate scan of the already-onboarded schemas.

Remediation path

• Compare the two connections’ scan scopes. Confirm whether the new connection scans the same schemas or only the schemas the old account could not read.
• Restrict the new connection to the minimum schemas needed for dictionary access, or restrict the old connection to exclude those schemas. Avoid two connections scanning the same object set.
• Re-scan and verify asset counts against a known baseline, not against the inflated 13,900.
• Before removing either connection, export or review stewardship assignments, term links, ratings, and policy associations on the affected assets.

Why not delete the old connection first Deleting it may remove the only assets that carry lineage, glossary links, and steward ownership. The duplicates without lineage are not automatically the “good” copies. The organization should first determine which connection’s assets hold governance metadata, then consolidate scans around that connection. Deleting is a last step, not a diagnostic step.

Lineage that stops at an intermediate schema usually means the scanner could not resolve the objects in that schema. Check, in order:

1. Permissions. The service account may lack access to dictionary views, view definitions, or stored procedures in the intermediate schema. Confirm read access to metadata, not just data.
2. Object type support. Views, synonyms, and stored procedures may need specific scan options. If the intermediate schema is view-heavy, verify that view definitions are being parsed.
3. Scan scope and filters. The intermediate schema may be excluded by a filter, or the new connection may have scanned only a subset.
4. Timing. If the ETL job creates or replaces objects after the 02:00 scan, lineage may resolve against an incomplete state. Align the scan with the ETL completion or run an on-demand scan.
5. Manual lineage. For gaps the scanner cannot resolve, record manual lineage from the ERP column to the finance mart column with a source and review date.

Before rescanning, fix permissions and scope, then run a targeted scan of the intermediate schema rather than a full estate scan. Validate by checking a known column path end to end. Do not certify lineage as complete until the previously missing hop appears or is manually documented.

Deleting the old connection is a metadata destructive action, not a cleanup shortcut. Risks include:

• Loss of lineage history. The old connection’s assets may be the ones with resolved lineage. Deleting it can remove the only trustworthy path from ERP to finance.
• Loss of stewardship and term links. Ratings, glossary associations, policies, and ownership may be attached to the old asset IDs. Those links do not automatically transfer to the duplicate copies.
• Broken audit trail. If the old assets were used in prior impact analyses or regulatory reports, deletion weakens traceability.
• False confidence. Removing duplicates makes search cleaner but does not prove the remaining assets are complete or correctly governed.

The lead should present a consolidation plan, not a deletion request: inventory which connection holds governance metadata, define scan filters to eliminate overlap, identify assets to re-link if consolidation requires new IDs, schedule a controlled rescan, and set a validation checkpoint. The council should approve the target connection and the migration of term/policy links before any deletion. If deletion is still needed, require a backup of governance metadata and a rollback plan.