Stairway to SQL Server Agent - Level 3: Agent Alerts and Operators
How to be notified when a job succeeds or fails, or be notified when a SQL Server performance condition is met.
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.
In this level of the Stairway to Server Virtualization, learn how to build a Hyper-V virtual machine for SQL Server.
With Fabric Mirroring, Microsoft is promoting a nice and appealing story for operational reporting...
If you’ve been watching AI roll through the data community and thinking, “this seems...
By Arun Sirpal
Not every production incident is a database in RECOVERY_PENDING or a corrupted event (like...
Comments posted to this topic are about the item SQL Art, Part 4: Happy...
Hi All I am trying to find 'bad' characters that users might type in....
Comments posted to this topic are about the item Extreme DAX: Take your Power...
I set up a few users on my SQL Server 2022 instance.
CREATE LOGIN User1 WITH PASSWORD = 'Demo12#1' CREATE USER User1 FOR LOGIN User1 GO CREATE LOGIN User2 WITH PASSWORD = 'Demo12#2' CREATE USER User2 FOR LOGIN User2 GO CREATE LOGIN User3 WITH PASSWORD = 'Demo12#3' CREATE USER User3 FOR LOGIN User3 GOI then created a schema that one of them owned. Under this schema, I added a table with some data.
CREATE SCHEMA MySchema AUTHORIZATION User1
GO
CREATE TABLE Myschema.MyTable(myid INT)
GO
INSERT MySchema.MyTable
(
myid
)
VALUES
(1), (2), (3)
GO
SELECT * FROM MySchema.MyTable
GO
I granted rights and verified that User2 could access this table.
GRANT SELECT ON Myschema.MyTable TO User2 GO SETUSER 'USER2' GO SELECT * FROM MySchema.MyTable GOThis worked. Now, I move this schema to a new user.
ALTER AUTHORIZATION ON SCHEMA::Myschema TO User3; GOWhat happens with this code?
SETUSER 'USER2' GO SELECT * FROM MySchema.MyTable GOSee possible answers