Timeline for SQL DBA data type is changed after upgrade
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 14, 2018 at 6:22 | answer | added | Pankaj Kumar | timeline score: 0 | |
| Mar 13, 2018 at 17:34 | history | edited | Hannah Vernon♦ | CC BY-SA 3.0 |
edited tags and improved formatting
|
| Mar 13, 2018 at 15:23 | comment | added | Avarkx | @AaronBertrand Excellent point, they could try using flag 2312 as well to force the new estimator - I immediately go to a 9481 check on account of the persisting shell-shock from the month after we did our 2000->2008->2014 upgrades without thorough testing :$ | |
| Mar 13, 2018 at 15:17 | comment | added | Aaron Bertrand | @Avarkx My guess is that this is because of stats and/or still using the old CE (and that's the CE he's using now, unless he did update the compatibility level manually after the upgrade, which most people don't). Regressions under the new CE are bad, but they're uncommon. | |
| Mar 13, 2018 at 15:11 | comment | added | Avarkx |
Have fun with the differences between the 2014 Cardinality Estimator ( CE ) and previous versions. Find a query that's under-performing and set the trace flag with OPTION( QUERYTRACEON 9481 ) to it to use the old estimator, for the time being.
|
|
| Mar 13, 2018 at 14:50 | comment | added | Aaron Bertrand | I doubt this is the reason. Stop looking at profiler, did you check the execution plans? After the upgrade, did you (a) update statistics and (b) update the compatibility level? | |
| Mar 13, 2018 at 14:45 | review | First posts | |||
| Mar 13, 2018 at 15:35 | |||||
| Mar 13, 2018 at 14:44 | history | asked | MAK | CC BY-SA 3.0 |