Examines the scale-out capabilities of SQL Server Agent, using the MSX/TSX subsystem. This capability allows you to run jobs on multiple systems and consolidate the job results/history onto a single server.
SQL Server Agent jobs are made up of a series of one or more Job Steps. A job step is assigned to a specific job subsystem, which identifies the kind of work the job step is going to perform. Each job step runs in a separate security context, although each job also has an owner that determines who can modify the job.
How to be notified when a job succeeds or fails, or be notified when a SQL Server performance condition is met.
Examines the database mail system configuration in depth. You will learn how to configure database mail to work with SMTP mail systems, and get some troubleshooting tips.
How to interpret and configure the SQL Server Agent error logs. Critical information about SQL Server Agent is sent to this error log, so knowing how to find it and how to interpret information in the log will save you valuable troubleshooting time.
How to configure and optimize job steps. Topics such as process flow between steps, security, and more details of the job subsystems are examined.
The Job Activity Monitor is the system administration tool to run jobs, view job history, and enable/disable jobs. This article will also review some of the stored procedures run by the Job Activity Monitor that you can also use directly to do your own custom job monitoring.
One common usage of SQL Server Agent historically has been the ability to shell out to the operating system and run command line programs, using SQL Server Agent primarily as a job scheduler. This article will examine the pros and cons of using the SQL Server 2008 & 2008 R2 Powershell subsystem versus the CmdExec subsystem to perform tasks in the Operating System.
Security is a confusing topic to many, especially when it comes to understanding what rights are needed to monitor and use SQL Server Agent. This article will examine the rights and roles used for SQL Server Agent, as well as the security context requirements for jobs.
In this level, we're going to dig a little deeper into the Extended Events engine, its architecture, and fundamental components. It will give you a deeper understanding of why, in general, an Extended Events session is inherently lower in overhead than an equivalent SQL Trace. We'll also investigate how to design our event sessions to minimize any unnecessary overhead during event data collection, even when we need to create relatively complex event sessions to investigate difficult performance problems.
Setting page visibility and the active page are often overlooked last steps when publishing...
By Steve Jones
It’s time for T-SQL Tuesday again and this time Todd Kleinhans has a great...
By Steve Jones
Recently I was working in VS Code and I saw a walkthrough for the...
Comments posted to this topic are about the item Password Guidance
Comments posted to this topic are about the item Using table variables in T-SQL
I am trying to check out elastic query between two test instances we have...
What happens if you run the following code in SQL Server 2022+?
declare @t1 table (id int); insert into @t1 (id) values (NULL), (1), (2), (3); select count(*) from @t1 where @t1.id is distinct from NULL;See possible answers