RetiredDBA.com

Blog covers all things for Microsoft SQL Server

Low hanging SQL Server DBA Technical Debt

So I bumped into some articles on ‘Managing Technical Debt’. It reminded me of my final project before I retired in 2017: clean up SQL Server object technical debt. The list below is some low hanging fruit should help you get started on your DBA technical debt cleanup. Cleaning up DBA technical debt should be an ongoing process especially when reviewing or maintaining older code. When your leaving a position, cleanup your own technical debt, the remaining DBA team members will appreciate it.

Alerts
Delete all non-actionable alerts that were created for one specific error and was never deleted.
Verify all email addresses should still be getting the alert.
Does the sysadmin team need all DBA alerts?
Does the DBA team need to see specific developer alerts?

Documentation
Archive and delete all documents for older versions of tools, internal procedures, SQL scripts, etc.
Most important is to update the on-call lists with the current names and contacts of people and the on-call schedule.

Monitoring tools
Delete any objects from old SQL Server tools.
Upgrade to latest version of current licensed tools.
Determine if any tools can be eliminated / replaced when maintenance contracts are up for renewal.

Scripts
Archive then delete all one-time or unused scripts.

SQL Jobs
Archive then delete inactive SQL jobs unless of course the SQL job should be active
Verify you still need the active SQL jobs
Verify all email addresses should still be getting the SQL job results
Does the sysadmin team need your alerts?
Do you need to see specific developer alerts?

Stored procs
Delete all unused stored procs for special monitoring or alerts or one-time reports.

Reports
Archive then Delete all one-time reports and reports no longer used by any users.
Verify all email addresses receiving reports are sill valid.
Does the DBA team need a copy of any reports?

Here’s some additional articles and points on much deeper DBA technical debt considerations:
T-SQL Technical Debt
Poor design.
Lack of coding standards.
Different conflicting coding standards over time.
A rush to get things done rather than focusing on stability and sustainability.
Non refactoring code as it grows.
Evolving code or environments to just make things work, rather than to make things work well.

Technical Debt
Sacrifice maintainability to meet another requirement.

Technical Debt, Database Design and the Days of Reckoning
Database design and performance technical debt emanates from five basic categories
Missing/incorrect/insufficiently detailed user stories and use cases
Missing/incorrect logical data model.
Missing/incorrect/poorly normalized physical database schema
Missing/insufficient metadata about table columns
Missing/insufficient non-functional specifications captured

Avoid T-SQL Technical Debt using SQL Prompt Code Analysis
SQL Prompt has a Code Analysis feature that discovers code issues and hidden pitfalls as you type.
It also provides code improvement tips and links to advice to made corrective decisions.

Not giving a shit about performance is tech-debt
How much time can you spend perfecting code instead of just shipping?
Can we just fix it when it becomes a problem?
Is buying more hardware cheaper than paying for developers to tune their code?
Is better code harder to read, and will a junior developer be able to work with it?

What’s your worst technical debt story?
Lots of production objects are dead (not used, or wouldn’t compile anymore)
Objects that were supposed to go to production but never did are there
Databases calling objects from other databases in a manydirectional(?) way
Mixed up naming conventions
Lots of dynamic SQL
Lots of quick fixes and hard-coded conditionals

Exit mobile version