Random insane bad execution plans in Microsoft SQL Server












1















Hi together I know that issue has been discussed for several times, but we face an insane weird issue on our new SQL Server 2014 SP3 right now, and we just can't get behind.



We switched over from Oracle to MS SQL Server last year. Our mayor DB is quite big, abt. 800GB, big tables, PDM system. +1000 active users.
16 cores, 192 GB Memory, SSD SAN Storage. ESX 6.5



Settings in SQL Server:
-> Create Auto Statistics Enabled
-> optimize for Ad Hoc Queries = true
-> Snapshot Isolation enabled
-> Max Parallel = 4
-> Threshold 50
-> Statistics Updates async in TempDB, normally enabled on our main DBs.



Any how, we have some queries which are handled extremly bad. All leads to the fact that the SQl Server Optimizer creates an execution plan, thinks its okay but on execution it does an inner join (or multiples) with Millions instead of expected 1-2 rows. And of cours millions of logical reads. And I can't get behind whats ongoing in this. These statements ran minutes then.



So basically, we have already 3 databases. All same version and hardware, Prod Test and Dev Environment. My tests can be done pretty easily. All dbs are configured the same and show the same behaviour, but on different queries. Lets say somethimes the test environment does the same statement multipletimes in 47s, the prod db in just a second. Others take seconds in Prod, are instand in Test. What the heck is going on? I always retry the statements muliple times to ensure its cached.



Good Case



Bad Case



1s vs 47s. Both of these DBs share the same SQL Instance.



Any ideas what could have been wrong here? How to correct single execution plans? How can it be that the sql server doenst learn from that extremly bad statement and to correct it the next time it runs?



Thanks for your help and ideas.










share|improve this question


















  • 1





    Did you try to use a modern join syntax instead of the old school Oracle one?

    – Seth
    Jan 24 at 6:48






  • 1





    Consider asking on Database Administrators instead. Super User isn't really the best place for this question. You can flag your own question to request migration.

    – Bob
    Jan 24 at 7:38


















1















Hi together I know that issue has been discussed for several times, but we face an insane weird issue on our new SQL Server 2014 SP3 right now, and we just can't get behind.



We switched over from Oracle to MS SQL Server last year. Our mayor DB is quite big, abt. 800GB, big tables, PDM system. +1000 active users.
16 cores, 192 GB Memory, SSD SAN Storage. ESX 6.5



Settings in SQL Server:
-> Create Auto Statistics Enabled
-> optimize for Ad Hoc Queries = true
-> Snapshot Isolation enabled
-> Max Parallel = 4
-> Threshold 50
-> Statistics Updates async in TempDB, normally enabled on our main DBs.



Any how, we have some queries which are handled extremly bad. All leads to the fact that the SQl Server Optimizer creates an execution plan, thinks its okay but on execution it does an inner join (or multiples) with Millions instead of expected 1-2 rows. And of cours millions of logical reads. And I can't get behind whats ongoing in this. These statements ran minutes then.



So basically, we have already 3 databases. All same version and hardware, Prod Test and Dev Environment. My tests can be done pretty easily. All dbs are configured the same and show the same behaviour, but on different queries. Lets say somethimes the test environment does the same statement multipletimes in 47s, the prod db in just a second. Others take seconds in Prod, are instand in Test. What the heck is going on? I always retry the statements muliple times to ensure its cached.



Good Case



Bad Case



1s vs 47s. Both of these DBs share the same SQL Instance.



Any ideas what could have been wrong here? How to correct single execution plans? How can it be that the sql server doenst learn from that extremly bad statement and to correct it the next time it runs?



Thanks for your help and ideas.










share|improve this question


















  • 1





    Did you try to use a modern join syntax instead of the old school Oracle one?

    – Seth
    Jan 24 at 6:48






  • 1





    Consider asking on Database Administrators instead. Super User isn't really the best place for this question. You can flag your own question to request migration.

    – Bob
    Jan 24 at 7:38
















1












1








1








Hi together I know that issue has been discussed for several times, but we face an insane weird issue on our new SQL Server 2014 SP3 right now, and we just can't get behind.



We switched over from Oracle to MS SQL Server last year. Our mayor DB is quite big, abt. 800GB, big tables, PDM system. +1000 active users.
16 cores, 192 GB Memory, SSD SAN Storage. ESX 6.5



Settings in SQL Server:
-> Create Auto Statistics Enabled
-> optimize for Ad Hoc Queries = true
-> Snapshot Isolation enabled
-> Max Parallel = 4
-> Threshold 50
-> Statistics Updates async in TempDB, normally enabled on our main DBs.



Any how, we have some queries which are handled extremly bad. All leads to the fact that the SQl Server Optimizer creates an execution plan, thinks its okay but on execution it does an inner join (or multiples) with Millions instead of expected 1-2 rows. And of cours millions of logical reads. And I can't get behind whats ongoing in this. These statements ran minutes then.



So basically, we have already 3 databases. All same version and hardware, Prod Test and Dev Environment. My tests can be done pretty easily. All dbs are configured the same and show the same behaviour, but on different queries. Lets say somethimes the test environment does the same statement multipletimes in 47s, the prod db in just a second. Others take seconds in Prod, are instand in Test. What the heck is going on? I always retry the statements muliple times to ensure its cached.



Good Case



Bad Case



1s vs 47s. Both of these DBs share the same SQL Instance.



Any ideas what could have been wrong here? How to correct single execution plans? How can it be that the sql server doenst learn from that extremly bad statement and to correct it the next time it runs?



Thanks for your help and ideas.










share|improve this question














Hi together I know that issue has been discussed for several times, but we face an insane weird issue on our new SQL Server 2014 SP3 right now, and we just can't get behind.



We switched over from Oracle to MS SQL Server last year. Our mayor DB is quite big, abt. 800GB, big tables, PDM system. +1000 active users.
16 cores, 192 GB Memory, SSD SAN Storage. ESX 6.5



Settings in SQL Server:
-> Create Auto Statistics Enabled
-> optimize for Ad Hoc Queries = true
-> Snapshot Isolation enabled
-> Max Parallel = 4
-> Threshold 50
-> Statistics Updates async in TempDB, normally enabled on our main DBs.



Any how, we have some queries which are handled extremly bad. All leads to the fact that the SQl Server Optimizer creates an execution plan, thinks its okay but on execution it does an inner join (or multiples) with Millions instead of expected 1-2 rows. And of cours millions of logical reads. And I can't get behind whats ongoing in this. These statements ran minutes then.



So basically, we have already 3 databases. All same version and hardware, Prod Test and Dev Environment. My tests can be done pretty easily. All dbs are configured the same and show the same behaviour, but on different queries. Lets say somethimes the test environment does the same statement multipletimes in 47s, the prod db in just a second. Others take seconds in Prod, are instand in Test. What the heck is going on? I always retry the statements muliple times to ensure its cached.



Good Case



Bad Case



1s vs 47s. Both of these DBs share the same SQL Instance.



Any ideas what could have been wrong here? How to correct single execution plans? How can it be that the sql server doenst learn from that extremly bad statement and to correct it the next time it runs?



Thanks for your help and ideas.







sql-server sql






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Jan 24 at 6:37









KrautmasterKrautmaster

61




61








  • 1





    Did you try to use a modern join syntax instead of the old school Oracle one?

    – Seth
    Jan 24 at 6:48






  • 1





    Consider asking on Database Administrators instead. Super User isn't really the best place for this question. You can flag your own question to request migration.

    – Bob
    Jan 24 at 7:38
















  • 1





    Did you try to use a modern join syntax instead of the old school Oracle one?

    – Seth
    Jan 24 at 6:48






  • 1





    Consider asking on Database Administrators instead. Super User isn't really the best place for this question. You can flag your own question to request migration.

    – Bob
    Jan 24 at 7:38










1




1





Did you try to use a modern join syntax instead of the old school Oracle one?

– Seth
Jan 24 at 6:48





Did you try to use a modern join syntax instead of the old school Oracle one?

– Seth
Jan 24 at 6:48




1




1





Consider asking on Database Administrators instead. Super User isn't really the best place for this question. You can flag your own question to request migration.

– Bob
Jan 24 at 7:38







Consider asking on Database Administrators instead. Super User isn't really the best place for this question. You can flag your own question to request migration.

– Bob
Jan 24 at 7:38












0






active

oldest

votes











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1397783%2frandom-insane-bad-execution-plans-in-microsoft-sql-server%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























0






active

oldest

votes








0






active

oldest

votes









active

oldest

votes






active

oldest

votes
















draft saved

draft discarded




















































Thanks for contributing an answer to Super User!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1397783%2frandom-insane-bad-execution-plans-in-microsoft-sql-server%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

flock() on closed filehandle LOCK_FILE at /usr/bin/apt-mirror

Mangá

 ⁒  ․,‪⁊‑⁙ ⁖, ⁇‒※‌, †,⁖‗‌⁝    ‾‸⁘,‖⁔⁣,⁂‾
”‑,‥–,‬ ,⁀‹⁋‴⁑ ‒ ,‴⁋”‼ ⁨,‷⁔„ ‰′,‐‚ ‥‡‎“‷⁃⁨⁅⁣,⁔
⁇‘⁔⁡⁏⁌⁡‿‶‏⁨ ⁣⁕⁖⁨⁩⁥‽⁀  ‴‬⁜‟ ⁃‣‧⁕‮ …‍⁨‴ ⁩,⁚⁖‫ ,‵ ⁀,‮⁝‣‣ ⁑  ⁂– ․, ‾‽ ‏⁁“⁗‸ ‾… ‹‡⁌⁎‸‘ ‡⁏⁌‪ ‵⁛ ‎⁨ ―⁦⁤⁄⁕