The Good, the Bad, and the Bug-ly.

This month’s T-SQL Tuesday is brought to us by Brent Ozar ( work | personal | tweets ) and has to do with SQL Server Bugs and Enhancement requests on Microsoft Connect.

Now the reason that this is the topic of this month’s T-SQL Tuesday is nicely spelled out by the host himself:

Now, more than ever, Microsoft has started to respond to Connect requests and get ’em fixed not just in upcoming versions of SQL Server, but even in cumulative updates for existing versions.

If you’ve kept an ear to the ground and an eye out on the social media, (seriously get on Twitter if you haven’t already; with #sqlhelp and #sqlfamily, you’ll never be alone, stuck, and/or bored again), you’d realise that this is true. Microsoft has engaged more than ever with it’s audiences, from hiring a PowerShell developer to actively engaging in various Trello Channels. So much so that a twitterbot was created to keep track of Connect items closed as fixed (Closed As Fixed) by MVP Chrissy LeMaire ( blog | tweets ).

Shameless Plug:

Now, I happen to have a Connect item and I’m going to link to it here. I can do this as this blog shares a commonality with Lesley Gore’s birthday party song. (It’s mine and I can cry if I want to)

Include Clustered Index when altering Indexed Views

However, this T-SQL Tuesday topic has a secondary agenda of getting these Connect items up-voted if we agreed with them. So with that in mind, and seeing how I already had a Connect item open dealing with Views, I took a look at other Connect items around Views to see what else there was and up-voted what I could.

That’s not contributing enough, I hear you say? (Yes, I’ve already heard the “you’re hearing voices” joke, and yes it is slightly funny).
Well that’s fine, because I’m going to highlight and link the Connects I found below for you guys to decide.
So go on! Pretend you’re the Emporer of Rome, a Julius/Julia CTE-aeser, determing the fate of these gladitorial Connect items. Do they get the thumbs up? Or the thumbs down?

Battle of the Bugs:

The Good…

First of all, lets see what we’re running on here…

SELECT @@VERSION

First contender: Inserting to an indexed view can fail

What would happen if I told you that, with regards to a view, sometimes inserting into the table could fail? Well that’s what this Connect item from Dave_Ballantyne found, along with the reason.

CREATE TABLE myTable
(
    Id integer not null,
    InView char(1) not null,
    SomeData varchar(255) not null
)
GO

CREATE VIEW vwIxView
WITH SCHEMABINDING
AS
SELECT 
    ID, 
    Somedata, 
    LEFT(SomeData, CHARINDEX('x', SomeData) - 1) AS leftfromx
FROM 
    dbo.myTable
WHERE 
    InView ='Y'
GO

CREATE UNIQUE CLUSTERED INDEX pkvwIxView ON vwIxView(Id)
GO

Now that we have the groundwork laid out, it’s time for our insert attempt:

DECLARE @id integer,
@inview char(1),
@Somedata char(50)

SELECT @id = 1,
@inview = 'N',
@Somedata = 'a'

INSERT INTO myTable(Id, InView, SomeData)
SELECT @id, @inview, @Somedata

He’s even gone so far as to give an explanation as to why this happens!

This is due to the compute scalar being executed prior to the filter.

Taking a look at the estimated execution plan, we can see that he’s right!

Imagine trying to troubleshoot what was causing the inserts to fail? Horrible! I can imagine tearing my hair out at that one!

I have this done as “The Good” just for the fact that, not content to just report the bug, Dave_Ballantyne even went so far as to find the possible cause. Now it’s just up to Microsoft to get to the fixing…

…The Bad…

Next up, we have moody31415 with “Can’t create Materialized View that references same table twice”

Groundwork:

CREATE TABLE test (A int)
GO
CREATE VIEW vtest WITH SCHEMABINDING
AS
SELECT t1.A, t2.A as A2
FROM dbo.test T1
JOIN dbo.test T2 ON T1.A=T2.A
GO

The problem occurs when we try to add a unique clustered index on this bad boy:

CREATE UNIQUE CLUSTERED INDEX UCL_Test
on dbo.vTest (A, A2)

Now, I originally put this down as “The Bad” because I thought that the issue could be down to trying essentially index the same column twice but that’s not the case…

CREATE TABLE dbo.B (col1 tinyint, col2 tinyint)
GO
CREATE VIEW dbo.SecondOne
WITH SCHEMABINDING
AS
SELECT t1.col1, t2.col2
FROM dbo.B AS t1
JOIN dbo.B AS t2 ON t1.col1 = t2.col1
GO
CREATE UNIQUE CLUSTERED INDEX UCL_test
ON dbo.SecondOne (col1, col2)

In the end, the reason that I have this in “The Bad” section is that I went to the documentation and read this part…

The SELECT statement in the view definition must not contain the following Transact-SQL elements: […] self-joins […]

Now it’s unknown whether this was there when this Connect item was created, but it’s there now (and I didn’t have enough time to re-plan this blog post)

…and The Bug-ly.

In my quest through the magical lands of Connect I stumbled across this little beauty of a bug by Anatoly V. Popov that I had to mention as “The Bug-ly”.

Altering indexed view silently removes all indexes

Yes, I know it’s the same as my one but dammit if I don’t think it’s a bug! That’s why it’s getting my “The Bug-ly” title.
This leaves me with a bit of a conundrum though…Do I close mine and comment on this one to get re-opened? Or do I try and continue to push on my one?

To be honest I don’t know which option to choose but, for anyone new to SQL Server, filing a Connect Item is an exciting but nerve-wracking time.
Exciting because you’ve worked with SQL Server enough to think you know how something should be done.
However, it’s nerve-wracking because you haven’t worked with SQL Server for long enough to know if you are just whining or have an actual item to be taken seriously.

Finding this Connect item was a small little shot of validation for me. Just a little something to say “Hey, I thought this too and I’m with you”.

Summary

It’s a great thing that Microsoft have started to respond to the Connect Items again and going through them you realise how different people are using SQL Server in ways that you didn’t even think to imagine.

So check out a few, leave your comment and up-vote/down-vote as you see fit.

Just…just don’t be this guy please

words: 691

Reading Time: ~3 minutes

Intro:

I’m becoming more and more of a fan of Powershell the more that I interact with it. And I’m a big fan of the work that those over at dbatools are doing (seriously, check it out and also check out their Slack channel).

So when reading an article by Steve Jones (b|t) that mentions using Powershell, especially dbatools, I took immediate attention!

However, while reading the blog, what jumped out at me was the fact that dbatools copies the logins and the passwords. I think that’s epic and saves so much hassle, especially with migrations and environment creation.

But when you script out a login in SSMS, you get the following “warning comment” (and this comes straight from Microsoft) :

/* For security reasons the login is created disabled and with a random password. */

I understand why you don’t want to script out a login’s password for security reasons but disabling it…does that even do anything?

Something that I only recently learned is that, for logins with high privileges, disabling them is not enough; they must be removed.

Overkill, I hear you say?

Example, I retort!

Example:

I will admit that for my example to work, there needs to be help from a member of the securityadmin server role login. So for this example we’re going to have…

1. A disabled sysadmin login,
2. A “compromised” securityadmin login,
3. An “attacking” low-privilege login.

Window 1 (High Permission Account):

-- Create a high privilege login (HPL)
CREATE LOGIN [AllThePower]
    WITH PASSWORD = '1m5trong15wear!';

ALTER SERVER ROLE sysadmin
    ADD MEMBER AllThePower;

-- Disable it.
ALTER LOGIN AllThePower DISABLE;

-- Create a "compromised" login
CREATE LOGIN Enabler
    WITH PASSWORD = 'AlreadyHereButCompromised';

-- Make them part of security so can grant permissions
ALTER SERVER ROLE securityadmin
    ADD MEMBER Enabler;

-- Create a low privilege login (LPL)
CREATE LOGIN Copycat
    WITH PASSWORD = 'NotAsStrongButDoesntMatter';

So now we have all our actors created, we need to connect to the database with all 3 accounts.

Simple as “Connect” -> “Database Engine” -> Change to SQL Auth. and put in the details above for who you want.

Window 2 (CopyCat):

First things first, check who we are and who can we see?

-- Who are we?
SELECT
    SUSER_NAME() AS LoginName,
    USER_NAME() AS UserName;

-- Who can we see?
SELECT
    *
FROM sys.server_principals;

Okay, so we can’t see it but we know that it’s there.

Let’s just cut to the chase and start “God-mode”

-- Can we get all the power
ALTER SERVER ROLE sysadmin
ADD MEMBER CopyCat;

Can we impersonate it?

-- Can we impersonate AllThePower
EXECUTE AS LOGIN = 'AllThePower'
SELECT
    SUSER_NAME() AS LoginName,
    USER_NAME() AS UserName;

Time to go to our compromised account:

Window 3 (Enabler):

Now, who are we and what can we see?

Notice that “Enabler” as part of securityadmin can see the disabled “AllThePower” login?

Great, we can see it, so let’s promote our CopyCat login!

So even though we’re now a member of the securityadmin role, we still can’t promote our login!

I think you’d be safe in thinking that people would give up here, but we know from server_principals that “AllThePower” is there, even though it’s disabled!

So even though we don’t have the ability to promote our login, we do have something that we can do in our power.

GRANT IMPERSONATE.

-- Give CopyCat Grant permission
GRANT IMPERSONATE ON LOGIN::AllThePower TO CopyCat;

Window 2 (CopyCat):

Now can we impersonate our Disabled login?

And can we get all the power?

Finally, we’ll revert our impersonation and see if we actually are sysadmin?

-- Go back
REVERT;
SELECT
SUSER_NAME() AS LoginName,
USER_NAME() AS UserName;

-- Are we superuser?
SELECT IS_SRVROLEMEMBER('sysadmin') AS AreWeSysAdmin;

And now I can do whatever I feel like, anything at all!

Summary:

I’m a fan of removing high-permission accounts that are not needed but I’ve never put into words why. Now I know why disabling is just not enough and, for me, removing them is the option.