In partnership with
Prefer another language? Prefere receber em português? ¿Prefieres recibirlo en español? Choose here / Escolha aqui / Elige aquí
Last Monday's post used an exam-style case. It had a company with 300 databases in Azure, and the team ran maintenance by hand. One requirement said they must keep their SQL Server Agent jobs. Add a few other requirements, and the case points to SQL Managed Instance.
This tip shows how an exam answer and a real project can differ, with three questions I would ask before I accept that answer.
For the exam, that is a good answer. You read the case, you pick one of the options, and you move on. An exam does not let you talk to the customer.
A real project does. Here are my three questions.
Question 1: What does "maintenance" mean?
When a DBA hears "maintenance", we think of index rebuilds and statistics updates. The customer may mean something else. It can be a task in the application, or a job that never touches the database structure.
It sounds like a simple question. Many people don't ask it because "it is obvious". It is not. If I assume, my architecture can be built on the wrong thing. So I ask: what is the maintenance, exactly?
Question 2: What does "manually" mean?
With 300 databases, "manual" is a warning sign. Something has to change. But I have heard "I do it manually" many times, and it often means something else. The person has a script, or a prepared process. It is only not a service, or it runs outside Azure.
So I ask the customer to show me what they do today. The answer tells me how much is really manual.
Question 3: Can an elastic job do this work?
Say the maintenance is T-SQL that must run in many databases. Then I look at elastic jobs before I look at Managed Instance. Here is what Microsoft documents:
An elastic job agent is an Azure resource that creates, runs and manages jobs. It is compute only.
A job has steps with a T-SQL script, and a target group says where it runs: servers, elastic pools or databases.
The target group is read when the job runs, so a job reaches every database that exists at that moment.
Microsoft contrasts this with SQL Agent, which can't enumerate the target databases dynamically. That matters when databases are added or removed often.
This could remove one reason for Managed Instance. But elastic jobs are not SQL Agent. They run T-SQL scripts against Azure SQL Database. SQL Agent can run more kinds of steps. So I check the details with the customer before I decide.
Note on platforms. Elastic jobs work with any tier of Azure SQL Database. A Hyperscale database, or a serverless database with auto-pause, can't be the job database. Serverless databases can be targets. For Managed Instance, SQL Server Agent supports T-SQL and SSIS job steps, but not command shell steps. Always check the pages in the References, because they change.
Find what’s slowing your GTM.
Most GTM problems aren’t one big failure. They’re one or two weak spots quietly dragging down the rest.
The free GTM Audit scores your go-to-market across four dimensions, then sequences a 90-day roadmap for your stage.
Drop your URL. Get your score in about 10 minutes.
"Close" is not "the same"
Here is a second warning. Choosing a product only because the application wants to keep its features is risky.
A diagram on Microsoft's T-SQL differences page says Managed Instance is "nearly 100% like SQL Server". The key word is nearly. The text of the same page says high compatibility, and then it lists the differences. Some features exist in both, but they behave a little differently. Two examples from that page:
Backups. Native backups on Managed Instance are limited to full
COPY_ONLYbackups to a URL.Resource Governor. If a request goes over
REQUEST_MAX_CPU_TIME_SEC, Managed Instance always ends it. SQL Server ends it only if a trace flag is on.
A small difference may change nothing. Or it can be the trap: the application works well in one place and fails, or works badly, in the other. Small details make a big difference.
The exam and the real world
There is nothing wrong with the answer in Monday's post. The exam asks for a direct answer, and it gives you a few options on a screen. In real life, I can add questions, find other options, and go deeper. That is the reason for these Thursday tips: to bring a bit of the real world to the exam topics.
Your next step (about five minutes)
Write your own query. Pick a SQL Server instance that you may move to Managed Instance, and list what its Agent jobs really run. SQL Server Agent keeps everything in the msdb system database. These are the tables to start with:
msdb.dbo.sysjobs: one row for each job.msdb.dbo.sysjobsteps: one row for each step of a job. Thesubsystemcolumn tells you the step type, such as T-SQL or command shell.msdb.dbo.sysjobschedulesandmsdb.dbo.sysschedules: when each job runs.msdb.dbo.sysjobhistory: how each run ended.
Your goal: one result that shows every job and the type of each of its steps. Then compare it with the two pages in the References. A T-SQL step is a candidate for elastic jobs or for Managed Instance. A command shell step is a question for Managed Instance, because the page lists it as not supported.
Writing the query yourself is the point. You learn what these tables hold, and you can use them again for the next migration.
Cost. These are small system tables, so the cost is low. Still, run your query outside your busiest hour.
References
Elastic jobs in Azure SQL Database (Microsoft Learn, page last updated October 2026)
T-SQL differences between SQL Server and Azure SQL Managed Instance (Microsoft Learn, page last updated July 2026)
That is the tip of the week. See you in the next one.
Glossary
Term | What it means |
|---|---|
COPY_ONLY backup | A full backup that does not change the backup chain. On Managed Instance, it is the only kind of native backup you can run yourself. |
DP-300 | The exam for the Azure Database Administrator Associate certification. |
Elastic jobs | An Azure service that runs T-SQL scripts on many Azure SQL databases, on a schedule, with logs and retries. |
Job database | A new, empty Azure SQL database where the elastic job agent keeps job definitions and history. |
Job step | One piece of a job. In SQL Server Agent it can be T-SQL, SSIS, a command shell, and more. |
msdb | The system database where SQL Server Agent keeps its jobs, steps and history. |
Resource Governor | A feature that limits the CPU, memory and I/O a workload can use. |
SQL Managed Instance | An Azure service with high compatibility with SQL Server, including SQL Server Agent. |
SQL Server Agent | SQL Server's job scheduler. It runs jobs such as backups and maintenance. |
Target group | In elastic jobs, the list of servers, pools and databases where a job runs. |
How I write: every post starts from my own notes and experience. I use AI tools to help draft and edit, and I review every word before it goes out.
The technical details in this post are based on publicly available Microsoft documentation as of November 2026.
Disclaimer: The views expressed in this article are those of the author and do not necessarily reflect the official policy or position of Microsoft. The author is a Microsoft employee.
