Preferred Node Policy-Setting on Traditional SQL Cluster
Preferred node setting facilitates instances on traditional cluster to be on the correct nodes which will lead to load-balancing of the resources.
2017-02-02
4,092 reads
Articles
Seven Monitoring Scripts
Joe has a bunch of small, easy to use scripts that can definitely be the beginning of a great set of monitoring tool. Amazing how much info you can gather with a little bit of code!
2017-02-02 (first published: 2003-06-13)
53,801 reads
SQL Server Execution Plans, Second Edition by Grant Fritchey
Every Database Administrator, developer, report writer, and anyone else who writes T-SQL to access SQL Server data, must understand how to read and interpret execution plans. This book leads you right from the basics of capturing plans, through how to interrupt them in their various forms, graphical or XML, and then how to use the information you find there to diagnose the most common causes of poor query performance, and so optimize your SQL queries, and improve your indexing strategy.
2017-02-02
19,165 reads
SQL Server Performance Dashboard Reports
Setting up SQL Server Management Studio (SSMS) based performance dashboard driven off servers that are registered through a Central Management Server (CMS).
2017-02-02 (first published: 2015-08-20)
16,004 reads
The Effect of NOLOCK on Performance
Using hints in a query is something that most DBAs don't ever seem to bother with, but when they do, NOLOCK seems to be their hint of choice. Wayne Fillis brings us a detailed examination of how this particular hint actually affects the performance of your system.
2017-02-02 (first published: 2007-01-24)
72,493 reads
Understanding Graphical Execution Plans - Part 3: Analyzing the Plan
Learn how to examine and read a SQL Server execution plan in this article. This is the third part of a short series from Darren White that examines execution plans and imparts the basics on an important skill for DBA's and SQL developers alike.
2017-02-02 (first published: 2014-02-25)
20,332 reads
Using A Block Predicate to Restrict Row Updates and Inserts
If you are using row level security in SQL Server 2016 you might find users are updating or inserting rows of data that keep them from seeing the row after they have performed the update or insert statement. If you want to prevent this from occurring, you can use a blocking predicate.
2017-02-02
6,585 reads
2017-02-01
191 reads
Introducing Minion CheckDB by MinionWare
Minion CheckDB completes the MinionWare maintenance and backups suite in style. Each solution is plug-and-play for the busy DBA, and deeply configurable for those shops with in-depth needs.
2017-02-01
735 reads
The Future is Now - An Internet of Things Infographic
A look at the positive and negative aspects of IoT in this infographic.
2017-02-01
250 reads
Blogs
How AgentDBA Diagnoses SQL Server Issues Fast
By Arun Sirpal
Not every production incident is a database in RECOVERY_PENDING or a corrupted event (like...
Five Ways Redshift Serverless Quietly Eats Your Budget
It is Friday, the queries are running, and nobody is watching the bill. That...
A Career of Memories
By Steve Jones
Annabel retired from Redgate Software this week. Across most of my career at Redgate,...
Forums
Extreme DAX: Take your Power BI and Fabric analytics skills to the next level
Comments posted to this topic are about the item Extreme DAX: Take your Power...
What is the Cloud?
Comments posted to this topic are about the item What is the Cloud?
Changing the Schema
Comments posted to this topic are about the item Changing the Schema
Question of the Day
Changing the Schema
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