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.
The first level in the Stairway to Virtualization introduces the concept of virtualized servers as well as the terminology and benefits of implementing the technology.
By Brian Kelley
If you are considering any of the ISACA AI certs like the Advanced Artificial...
By ChrisJenkins
Are you currently using Microsoft Fabric or considering migrating to it? If so, there...
By SQLPals
Track SQL Server Configuration Changes Using the Error Log If you...
Artificial intelligence tools are quickly becoming part of daily business operations, from document analysis...
Comments posted to this topic are about the item Designing SQL Server ETL Pipelines...
Comments posted to this topic are about the item Detecting Deadlocks Quickly
In the Database Engine, when a deadlock is detected, what does the detection interval shrink to (in time)?
See possible answers