As we've seen with scheduled jobs on SQL Server, it's very flexible and allows a DBA or developer a lot of freedom. Sure. There is your automation, but it's not the same, and for many coming from an SQL environment perhaps not intuitive enough and outside their comfort zone. This perceived lack of equivalent functionality on Azure, has been a pain point for those moving from an on-premise experience. With that in mind, Microsoft has released elastic jobs to enable similar generic job scheduling, but within the context of databases.

At this time holistic job agent service is in preview. And while it can tag at any SQL database except managed instances, it can only be hosted on databases that our service level S0 or above. The elastic job agent service is database driven with tables and stored procedures that are hosted within a database.

From that host database, the service can target multiple Azure SQL servers and databases that are part of a target group. This means a job is defined within the context of a target group and can be applied to all database targets within the group. An elastic job needs credentials to operate. One credential called the refresh or master credential is used for logging on to the target server and querying the master database.

A job credential is needed to execute the steps or actions within a job. You could think of it as analogous to selecting run as within an SQL server job agent. These credentials must exist both on the target and the host server. The job and refreshed credentials can be the same or they can be different. And you could have a separate credential for every step of a job, or they could all be the same credential.

Next, let's look at creating an elastic job. By default, all databases on a server become target databases, and those you don't want to tag it, need to be explicitly excluded.