Didn't slow things down locally - going to push it and see what the CI build does...

Morning

Morning

Good Morning

@PaulWhite Thanks for that little piece of information

No worries. There has been an update today but you've probably already seen it. Same link.

Got some Query Store going for that broken Database. Does solve some issues, but I guess SQL 2019 with the AI feature is an even better solution for non-SARG-able queries that tend to fall over. (aka crappy database design)

SELECT * FROM TABLE1, TABLE2
WHERE TABLE1.ID = TABLE2.ID
AND TABLE2.COLUMN22 LIKE '%STRING%'

I don't mind pinning a couple of Execution Plans. But it shouldn't be a full-time job.

Note: TABLE1 50 MIO rows and TABLE2 62 MIO rows

The history table contains a whopping 612 Mio rows.

non-partitioned ---^

Morning

@PaulWhite So works fine locally on 2012 and 2016. Works fine on shared 2012dev instance. One of the CREATE PROCs times out on 2016dev instance (5000 rows of pain mappings - lots of pain in locations all over the body with and without various angina and pain characteristics...)

@CadeRoux does it have any '%%' in it? we found (last week, actually) what 2016 execution plans go up by billions of rows when you toss those in.

although if it works locally on 2016, idk... maybe there's a setting.

@CadeRoux That's weird

I did split it out and get it to complete - took 9 minutes to make and execute the proc.

Still pretty terrible

mangodb wouldn't have that problem

mmm... mangoes

@PaulWhite Well, that's just the one set of 5000 inserts. I assume the whole thing would still be 50 minutes or whatever.

@billinkc My great grandfather said there was only one way to eat a mango. In the bathtub.

@James No, it's straight literal single row INSERTS.

Still digging. FWIW, on SQL 2016, named pipes are disabled, they are enabled on SQL 2012.

Lol, my local workstation instances all have named pipes and TCP/IP disabled. I might want to change that...

These are the waits from one proc: creating the proc that inserts 5208 rows individually into the same table (triggers are back in place since the DB was recreated from scratch), and executing the proc.

To me that tells me out of 9:56 of execution, it wasn't waiting for much at all, right? So not IO issues, not other contention.

It's like the CPUs assigned to this VM are just slow.

They're doing their best. They're under a lot of pressure