I am executing a simple query/stored procedure from my application against a large table and it's taking a long time to execute. The column I'm using in my WHERE clause is indexed and it's very selective. The search column is not wrapped in a function so that's not the issue. What could be going wrong?
In most organizations, the DBA team is seriously outnumbered by headstrong developers and clock driven managers, and "great" DBAs will often be outnumbered by...well...the not so great. In order to be heard in this environment, a DBA will not only need to be very skilled, but will also need a healthy dose of ego.
Although, generally speaking, source control is the truth, a database doesn't quite conform to the ideal because the target schema can, for valid reasons, contain other conflicting truths that can't easily be captured in source control. Dave Ballantyne explains the problems and suggests a solution.
Sept 15th, 2012 at the CAIT Campus of Washington University in St.Louis - 5 Jackson Avenue, Clayton, MO 63105
SQL Saturday #154 is the very first SQL Saturday event in the St.Louis area. It is a free one day event for SQL Server professionals and those wanting to learn about SQL Server. We are planning on a 4 track event with 200 attendees. We currently have several sessions aligned towards Database Administration, Application Development, Business Intelligence and professional Development Tracks. We also have several sessions focused on SQL Server 2012! Please visit our event website for more details and free registration.
Come visit Rhode Island and meet fellow SQL Server professionals from all over New England as SQL Saturday comes on Sept 15, 2012.
This editorial was originally published on Nov 19, 2007. It is being republished as Steve is on vacation. With the tremendous amount of digital storage that people can carry around these days, how do you balance the security risks.
Why does the transaction log fill up? There are a variety of reasons, and MVP Gail Shaw walks you through the various things to check.
SQL Server 2012 AlwaysOn Availability Groups provides a unified high availability and disaster recovery (HADR) solution that improves upon legacy functionality previously found across disparate features. Prior to SQL Server 2012, several customers used database mirroring to provide local high availability within a data center, and log shipping for disaster recovery across a remote data center. With SQL Server 2012, this common design pattern can be replaced with an architecture that uses availability groups for both high availability and disaster recovery. This paper details the key topology requirements of this specific design pattern, including quorum configuration considerations, steps required to build the environment, and a workflow that shows how to handle a disaster recovery event in the new topology.
An interesting method of preventing restaurant fraud and a poll for other ways to determine the accuracy of data. This editorial was originally published on Nov 2, 2007. It is being republished as Steve is on vacation.
It is Friday, the queries are running, and nobody is watching the bill. That...
By Steve Jones
Annabel retired from Redgate Software this week. Across most of my career at Redgate,...
By Tim Radney
As a SQL Server DBA with years of experience tuning production environments, I’ve seen...
Comments posted to this topic are about the item What is the Cloud?
Comments posted to this topic are about the item Changing the Schema
Comments posted to this topic are about the item Index Fragmentation Explained: Page Splits,...
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