Stairway to Server-side Tracing - Level 8: How to Automate Traces with SSIS
Level 8 of this stairway series looks at the automation of your tracing using Integration Services.
Level 8 of this stairway series looks at the automation of your tracing using Integration Services.
In this level you will see how to employ the Data Collector feature of SQL Server to automate management of SQL Traces among multiple servers.
What are PowerShell and SQL PowerShell and how do you use them? Level 1 of this Stairway will help you answer these questions, and start to show you why you might want to use this great tool.
Now that you know how to get started with PowerShell, it is time to configure PowerShell for SQL Server use. This level covers the components you'll need and how to configure them.
This level will cover some of the Input/Output operations you can use with PowerShell.
This far, we have learned about installation and setup of the PowerShell environment. You should now have a foundation of SQL Server PowerShell. We now are ready to learn about Objects in SQL PowerShell.
Examines the proxy subsystem, which allows job steps to impersonate another user account in order to perform tasks as a user other than the SQL Server Agent service account. This is especially useful when you want jobs to run as lower privileged users of your SQL Server.
How maintenance plans are used as SQL Server Agent jobs to automate standard system tasks. This article will also lay out some suggested jobs that should be on virtually all SQL Server systems.
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.
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