The Heap™ – Consultancy ©®

12:01 AM

@JoeObbish what happened?

12:29 AM

@sp_BlitzErik you asked about the SUM() OVER () query yesterday

I tried to be helpful but didn't hear back, so I'm wondering if you got the explanation that you were looking for

12:46 AM

@JoeObbish I don't think I saw your response. I know why the row store query didn't go parallel. I was surprised that the column store one did.

you can go to the top and hit "load older messages" to see it

@JoeObbish watching last episode of Fargo. Will check tomorrow.

enjoy

got some baking to do this evening

What's on the menu?

strawberry shortcake for a friend's birthday tomorrow

Q: Login failed ,login is from untrusted domain

1:05 AM

Sounds delightful

4 hours later…

hot2use

5:30 AM

min-ga-la-ba (Burmese)

-1

Login failed. The login is from an untrusted domain and cannot be used with Windows authentication. Error: 18452, Severity: 14, State: 1. SSPI handshake failed with error code 0x8009030c, state 14 while establishing a connection with integrated security; the connection has been close...

RTFM IMHO FWI

2 hours later…

Philᵀᴹ

7:34 AM

Added brief summary . — Prasad 2 mins ago

Clear as mud

Andriy M

I think I can see what they want. I'll see if I can rewrite it after the OP replies to me.

Andriy M

8:04 AM

Gave it a shot. Is it better?

1 hour later…

Andy K

9:14 AM

morning

Andriy M

9:33 AM

Morning

2 hours later…

Tom V

11:04 AM

Weird issue of the day

as I understand it, the audit logout in profiler shows the total of IO/duration whatever of all queries executed during the connection

On this server the audit logout duration is consistently around 10 seconds higher than the sum of everything it did

Connection pooling issues maybe

11:53 AM

@giò very good. Now you can follow my other suggestion about trying it for yourself ;) — dezso 19 secs ago

hot2use

12:38 PM

@TomV

Amount of time taken by the event. Although the server measures duration in microseconds, SQL Server Profiler can display the value in milliseconds, depending on the setting in the Tools>Options dialog.

Tom V

Yeah, the actual issue was elsewhere

I was probably confused

hot2use

:-)

2 hours later…

2:34 PM

good morning

Andy K

3:14 PM

@dezso you around?

3:26 PM

@ypercubeᵀᴹ yes

@dezso I have a weird case, I get a "could not serialize due to concurrent update"

while my query has SELECT * FROM s WHERE EXISTS (...correlated) LIMIT 1 FOR UPDATE;

Do yo have any idea how this might happen/

isolation level = REPEATABLE READ

3:50 PM

@ypercubeᵀᴹ is it conflicting with itself?

@dezso I have to dig more

There might be other open transactions

But even if that's the case, it shouldn't raise this error, should it?

@ypercubeᵀᴹ TBH I could never fully understand when an UPDATE causes serialization errors and when not, even after some experimenting

what is pretty sure that no SELECT FOR UPDATE will run into it when running alone :D

but I can reproduce this easily

I'd guess the FOR UPDATE is a hint that the row will change, and then the violation is clear

4:07 PM

@dezso yes, when I try to reproduce with 2 transactions, I don't get it.

One transaction locks the rows, the 2nd just waits

for the first to commit and then gets unblocked

My app must be doing something else.

4:21 PM

when you first update (but don't commit yet), and then try to lock the row in another transaction, this latter will fail but only upon ending the other transaction

that is consistent with your error message

1 hour later…

5:26 PM

Oh thnx, let me check that scenario

5:38 PM

@dezso No, I can't get this.

When a transaction issues FOR UPDATE or just UPDATE, then the 2nd transaction trying to do FOR UPDATE just blocks

3 hours later…