Top‑Down Multi‑Server Database Count Workflow (POC)

⭐ Why Hierarchical Asset Discovery Is a Best Practice

Taking a top-down approach to mapping database infrastructure delivers immediate benefits to the administration team:

• Maps the Whole Neighborhood: Instead of guessing, this maps your entire server setup from the physical host machines down to individual instances, databases, security schemas, and object totals.
• Spots Server Drift Instantly: By putting your server metrics side-by-side, you can instantly spot when code or versions mismatch between your PROD, STAGE, TEST, and DEV environments.
• Zero Performance Hit: This pipeline counts your stored procedures by checking high-speed internal metadata folders rather than clogging up active transaction memory, protecting your live production workloads from slowdowns.
• Keeps Production Safe: It does all the data-crunching and merging locally on your workstation, so you don't have to build risky, complicated Linked Servers across your production environment.
• Gives You a Clean Baseline: It builds a permanent ledger that lets you easily spot unmerged feature branches, active staging areas, and old junk that is ready to be deleted.

1 Script A: The Topography Mapper

Reads the registry on your host machines to find every single installed SQL instance—especially those hidden or undocumented named instances that nobody told you about.

📄 File Created: 1_Master_Topology_Map.csv — Maps out which physical host machines match up with which SQL engines.

Why it matters: You use this clean list to piece together your connection strings so you know exactly where to point your queries in Step 2.

2 Script B: Granular Object & Schema Counter

Logs into each SQL Engine discovered in Step 1, loops through every user database, maps the schemas, and counts your stored procedures.

📄 File Created: 2_SQL_Topology_Summary.csv — Gives you a high-level table count and procedure count per instance to gauge the scale of a server at a fast glance.

📄 File Created: 3_SQL_Granular_Object_Inventory.csv — Your master flat dataset containing schema names, object names, table row counts, and creation/modification dates.

Why it matters: This is where you play detective. If an object hasn't been touched since 2018 and lives in a [Backup] schema, it's immediate dead weight to delete. If a staging table has 0 rows but was modified last night, it's part of an active midnight job—don't touch it!

3 Script C: Python Analytics Pipeline

Pure SQL outputs flat text grids. Python acts as our report designer. It reads that giant raw file into an ultra-fast in-memory matrix (a DataFrame), handles the cross-server math, and formats it beautifully.

📄 File Created: SQL_Infrastructure_Report.xlsx — Smashes through the server isolation barriers to combine all your separate server counts side-by-side into one page—all without using slow, messy production Linked Servers.

Why it matters: It automatically applies an executive "Steel Blue" styling template with clean fonts (Segoe UI), gridlines, and perfect number alignments. It even features a Decommission Targets tab where you can run a disk usage report to show management exactly how many gigabytes of physical hardware storage you are about to save the company!