« first day (4516 days earlier)      last day (649 days later) » 

00:01
@ErikDarling That explanation doesn't sound convincing. They're still trying to blame the upgrade. I don't know exactly what's going on without trying to reproduce it but it sounds fishy
00:14
I agree. It’s all rather nonsensical sounding, but perhaps my reading comprehension is clouded by their original assertion.
Clouds ruin everything
 
1 hour later…
01:38
They do
02:13
I've been trying to work up some interest in EF's latest self-inflicted problem but no luck so far
i don't think it would matter either way
03:03
Everything's Fucked...
 
3 hours later…
06:12
Morning
Wordle 697 2/6*

⬛🟩🟩⬛⬛
🟩🟩🟩🟩🟩
it's a snake eating a large apple
06:37
Wordle 697 4/6*

⬛⬛⬛⬛⬛
⬛⬛⬛🟨🟨
⬛🟩🟩⬛🟨
🟩🟩🟩🟩🟩
 
1 hour later…
07:50
@JoshDarnell That's our go-to pattern for Synapse.
Wordle 697 4/6*

⬛⬛⬛⬛⬛
🟨🟩⬛⬛⬛
⬛🟩🟩⬛🟨
🟩🟩🟩🟩🟩
@Zikato You're on a roll!
 
1 hour later…
08:57
For those fighting with Teams...
> Advanced Support for Microsoft Teams 1 Day (Jean Opperman) [Microsoft Premier Unified Workshops]
 
2 hours later…
10:55
@ErikDarling so their CASE isn't valid?
11:14
One might say
A chairde - Morning all!
12:02
Wordle 697 6/6*

⬛⬛⬛⬛🟨
🟨🟩⬛⬛⬛
⬛🟩🟩🟩🟩
⬛🟩🟩🟩🟩
⬛🟩🟩🟩🟩
🟩🟩🟩🟩🟩
Again dammit
it's like a boat slowly filling up with water
> but I get bunch of errors : Msg 214, Level 16, State 201, Procedure xp_cmdshell, Line 1 Procedure expects parameter 'command_string' of type 'varchar' [...] I couldn't solve this problem.
i wonder if the poppins could loan them a varchar variable
12:38
Just one more reason to avoid (max) types
user image
3
I've managed to screengrab @HannahVernon Wordle statistics
🤣🤣🤣
13:06
LOL
Nice job!
Wordle 697 4/6

⬜⬜🟩🟩⬜
⬜🟩🟩🟩⬜
⬜🟩🟩🟩⬜
🟩🟩🟩🟩🟩
13:41
malformed 1
13:54
you mean a wizard hat
lamak can't triforce, etc.
 
2 hours later…
15:33
If a WorkTable falls in a query plan, and there's no I/O statistics around it, does it make a sound?
Nice post, Erik
4
@SeanGallardy, do you know what might cause only one replica in DAG to have a large redo queue while others don't?

There's almost the same hardware and disk latency; there is no redo thread blocking. The same number of parallel redo threads, activity is comparable.
16:09
Are you saying you have a problem with identical environments
Because we've heard that one
16:25
I'm specifically avoiding saying "identical environments". But pretty damn close
16:38
@Zikato any long running transaction on the primary?
@Zikato a billion and 3 things
Last one I troubleshot was due to XE's being on one node, and only one node
but you'll need to gather some data
16:52
@SeanGallardy That narrows it down
Which XE? Anything HADR related?
17:22
@Zikato no, this person had an XE to capture statement completed on that node which was adding a ton of overhead. Disabling the XE stopped all their issues.
You have a redo queue, so you'll want to find the redo threads and then capture waits and external waits for those threads
Start there
18:04
Unlike Erik, I have reasonable rates :P
i think our rates are the same in chat
setting the meta for sure
18:55
@SeanGallardy LATCH_EX on RECOVERY_MANAGER
The docs page for that latch says, "Ask Sean"
6
19:50
@Forrest That's where all the time is spent?
Majority, yeah
20:06
what's the callstack?
and how much time, out of total, is spent there?
20:29
Time spent estimate would be 70% or more (based on memory from XE when it was really bad). Top stacks:
sqlmin!ParallelRedoManager::ReleaseDelayedTran
sqlmin!HelperWorker::WorkerLoop

sqlmin!RecXdesTable::FindXdes
sqlmin!RecoveryMgr::AnalyzeLogRecord
sqlmin!RecoveryMgr::MoveUpRedo
20:51
Looks like it's just busy, both of those are typical stacks
is this secondary readable?
yeah, running 60% CPU with activity, though the redo waits have almost no signal time
another readable secondary at similar CPU doesn't have the slow redo
both are primaries for other databases
21:14
What's the actual redo amount/sec?
What's the wait for the latch?
Seems like it's just running through redo
look at forry with the call stacks PRONTO
what a great supportee
Guessing actual redo is 3-10MB/s. Median latch was 4ms in the sample I saw.
How is waiting on a latch actually doing redo?
is there a reliable counter for actual redo rate?
it's just running through redo, there's nothing out of the ordinary with the stacks
so if it's waiting on an ex latch, most likely other parts are going slow
I would suggest setting it to single threaded redo
check the throughput
That'll remove the dependency on other parts of the system getting enough time
no difference, maybe a little slower single-threaded
does the wait type change?
21:21
oooh, good point, not sure we've checked that
> The customer wants to use a third party tool which doesn’t handle BigInt values [...] customer would like Microsoft to provide support for not using BigInt to get around 3rd part tool issue.
What does that even mean
21:38
who knows, man
small numbers lead to big request, Sean's rage overflows
@SeanGallardy sounds like customer should use INT then and Microsoft already supports this?
I was really hoping that was quoted from a Post, but then realized this is your life, lol.
@J.D. Apparently there's a system table used where it has a bigint in it, but the 3rd party tool doesn't support bigint, so they want the table changed to use int so that the 3rd party tool works.
@J.D. Yes, my sad, sad, sad life.
When you haven't written any code, but your build output says: 275 Warning(s)
21:53
@SeanGallardy ah gotcha. Customer doesn't realize CONVERT(INT, SystemTableColumn) is a thing too I guess, assuming the system table doesn't actually exceed 2,147,483,647 lol.
I don't really care enough to investigate, they need to contact 3rd party to update their code or not use it.
Indeed.
Wait
Which system table
lol why....
Erik, did you write bad code
Never
Just ask Paul
Or more importantly ask @Zikato or @JoshDarnell
22:12
classic Windows XP screenshots still in use in 2022 lol.
FIRST PUBLISHED DATE
11/29/2018 10:24 PM
LAST PUBLISHED DATE
4/8/2022 4:35 PM
yah. DPA is so.much.fun.
we enabled Forced Encryption on our instances and DPA won't connect at all now.
I love how they call it the "Success Center"
Probably for the best
undoubtedly
It’s as useless as monitoring tools get
22:18
seems like it. I have some SQL Agent jobs that are designed to have the first step report failure if the job is running on a non-primary AG instance - so step 2 etc doesn't try to run against a read-only database. The job itself reports success, after step 1 completes, however DPA reports the job has failed.
and that's just one tiny issue.
I've witnessed that on a few of the monitoring items
puke on ags
Now there are contained AGs... oh boy
everything is going to break
I’m sure the Azure portal will be just fine
on another matter entirely, our Data Analytics team has a product that uses CDC and fn_dump_dblog to read the log files in order to gather recent data changes for propagation into the data warehouse. They swear up and down that enabling CDC for all the tables won't be a problem because it doesn't actually copy all the changes, just keeps track of LSNs.
sounds like attunity
I can't wait to see how that affects log usage in our Distributed AG
@SeanGallardy its not. I asked the vendor for a copy of their software so I could see how it works, and they initially set up a conference call with me but they've since completely ghosted me.
22:24
👻
Well that’s not true about CDC but it’s still better than CT
22:44
Wonder how their product handles schema changes...

« first day (4516 days earlier)      last day (649 days later) »