Caglar Ozenc · 6x Microsoft Data Platform MVP · Istanbul
I find where your database is stuck by measuring, not by guessing.
I founded DMC Bilgi Teknolojileri. For more than fifteen years I have worked on performance, high availability and cost in enterprise SQL Server environments. Every claim on this page has a link you can open and check.
- 6xMicrosoft Data Platform MVP, active
- 15+years of SQL Server database administration
- 272technical articles since 2013
- 4engines: SQL Server, PostgreSQL, MySQL, MongoDB
What does database consulting actually cover?
Database consulting means finding out why a running system does not behave the way you expect, and then fixing it. I do that work on SQL Server, PostgreSQL, MySQL and MongoDB, with most of the weight on SQL Server. On your own servers, on Azure, or across the hybrid setups where both are in play.
When should you get in touch?
Most of the questions I receive open with one of the four sentences below. Under each one is where I look on the first day.
-
"The application is not as fast as it used to be."
The first place to look is wait statistics, the most expensive queries and the index maintenance history. Whether the slowness sits in the database, the disk or the application code usually separates out in the first round of measurement.
-
"We have backups but we do not know if we can restore."
Taking a backup does not mean you can come back from it. A real restore runs on a separate server, its duration is recorded, and the acceptable data loss and downtime end up in writing.
-
"The Azure bill grows every month."
We work out which resource spends what. The part that swells the bill is usually idle capacity, a service tier chosen higher than needed, and test environments nobody remembered to switch off.
-
"Should we move to SQL Server 2025?"
That depends on your environment. What the current version costs you and what the new one would gain you gets measured against your own workload, and the decision comes after that.
Areas of work
-
SQL Server performance tuning
Slow queries, a server that locks up, an application that slows as it grows. We find and fix the cause through execution plans, wait statistics and index design.
-
High availability and disaster recovery
Always On availability group setup, failover testing, backup design. A backup that runs is not enough on its own, so the time it takes to actually come back from one gets measured and written down alongside everything else.
-
Azure and hybrid data
Azure SQL, SQL Managed Instance and Azure Arc Data Services. Managing on-premises servers from one place, planning a move to the cloud, bringing the cost down.
-
SQL Server 2025 and AI
Upgrade assessment, vector search, the DiskANN index, and what RAG really costs on the database side.
Everything covered one by one in a performance engagement
- Redesigning the database schema and data structures
- Table and database partitioning
- Query optimisation and rewriting
- Removing indexes that hurt performance, indexing correctly
- Reviewing joined and recursive queries
- Execution plan analysis
- Reviewing isolation level usage
- Transaction management
- Tracking down and resolving deadlocks
- Examining disk and memory reads
- Reviewing temporary table usage
- CLR performance work
- Wait statistics and resource bottlenecks
- The time impact of backup and maintenance jobs
How does an engagement run?
There are four steps and the order does not change: measure, report, apply, verify.
-
Measurement
The environment gets written down: version and build, hardware, database size, transaction volume, wait statistics, the most expensive queries. Without this step every answer is a guess.
-
Findings report
What was found, which measurement it rests on and in what order it will be handled, all in writing. Work with large impact and low risk goes first.
-
Applying the changes
Changes go to a test environment first, then to production in a controlled way. The way back from every step is known before it is taken.
-
Verification
The same measurements run again and the before and after comparison is shared. If the improvement cannot be shown as a number, the work is not finished.
How do I touch your systems?
Letting a consultant near your production database is a matter of trust. Let the limits be written down from the start.
- Work starts with read only access. Diagnosis does not need write permission. The collection scripts I use are public and readable line by line, so you see what I am about to run before I run it.
- Your data does not leave your environment. What comes out is counters, execution plans and configuration. Not the rows in your tables.
- No irreversible step is taken in production. The way back from every change is written down before that change is applied.
- The maintenance window follows your calendar. Anything that needs downtime is agreed in advance, so there are no surprises during working hours.
Ways of working
-
Assessment
A one off measurement
The environment is measured end to end, then the findings and their priority order are delivered as a report. No obligation to continue, and the report stays with you.
-
Project
A defined piece of work
Always On setup, a version upgrade, a move to the cloud. The scope and what counts as success are written down before the work starts.
-
Ongoing
Remote DBA support
Monitoring, keeping maintenance jobs healthy, a periodic status report and response when something breaks. For teams with no DBA of their own.
What I write and the open source work
I use the method I describe here in my own work too. Everything below is public. You can read the code and repeat the measurements yourself.
- DMC DBA Toolkit Read only diagnostic scripts for four engines. Documented schema, tested in CI, MIT licensed.
- mssql-health-mcp An MCP server exposing SQL Server health and diagnostic data, read only.
- SQL Server 2025 developer book A free bilingual e-book for developers, with examples verified on a live environment.
- Three engine comparison lab Apache Doris, PostgreSQL and SQL Server 2025 measured on the same 20 million rows. Setup and queries are open.
Frequently asked questions
Is it SQL Server only?
No. Most of the weight is on SQL Server, but PostgreSQL, MySQL and MongoDB are in scope too. That is why the open source diagnostic set covers all four engines.
Do you work remotely?
Most of the work runs remotely: measurement, reporting, query fixes, reviews. If a setup or a critical migration needs someone on site, that can be arranged too. Base is Istanbul, Turkey.
We are a small team, is this for us?
Teams without a database administrator of their own are exactly who comes here most. The same four steps run on a single server environment, they just take less time.
How long does an assessment take?
It depends on the number of servers and the size of the data. Write those two down and I can give a time estimate up front, so nothing surprises you halfway through.
Do we keep the report?
You do. It records how each measurement was taken, so even if you choose not to continue, your own team can repeat the same steps.
Do you make changes directly in production?
Only in an agreed maintenance window and only after the way back has been written down. The whole diagnostic phase runs on read only access.
Let us work out where to start Tell me about your environment. The version, the hardware and when the problem started are enough to begin. We will find out together where to look.
Get in touch