Queries with parameter sensitive plans can perform poorly when an inappropriate query plan is used.
Even if your statistics are up to date, parameter sensitive plans can be caused by skewed data, so performing a data skew analysis can identify which filter columns might be involved in poor query plans.
I’ve adapted the code found here into a SQL Server stored procedure that can be run across an entire database, a schema, a single table or just a single column.
It should be relatively easy to convert this to other RDBMS.
Here’s an example of the output when run on the Stackoverflow 2013 downloadable database (approximately 50GB):
The ‘Monty Hall’ problem is best described by the wikipedia entry:
The Monty Hall problem is a probability puzzle, loosely based on the American television game show Let’s Make a Deal and named after its original host, Monty Hall. The problem was originally posed (and solved) in a letter by Steve Selvin to the American Statistician in 1975.It became famous as a question from reader Craig F. Whitaker’s letter quoted in Marilyn vos Savant‘s “Ask Marilyn” column in Parade magazine in 1990.
Suppose you’re on a game show, and you’re given the choice of three doors A, B and C.
Behind one door is a car; behind the other two are goats. You pick a door, say door A, and the host, who knows what’s behind the doors, opens another door, say door B, which has a goat. He then says to you, “Do you want to change your choice to door C?”
Is it to your advantage to switch? (It is!)
Many readers of vos Savant’s column refused to believe switching is beneficial and rejected her explanation. After the problem appeared in Parade, approximately 10,000 readers, including nearly 1,000 with PhDs, wrote to the magazine, most of them calling vos Savant wrong.[4] Even when given explanations, simulations, and formal mathematical proofs, many people still did not accept that switching is the best strategy.[5]Paul Erdős, one of the most prolific mathematicians in history, remained unconvinced until he was shown a computer simulation demonstrating vos Savant’s predicted result.[6]
First we need to define some notation:
A, B – events P(A) – the probability of event A occurring P(B) – the probability of event B occurring P(A | B) – the probability of event A occurring, given that event B has already occurred P(B | A) – the probability of event B occurring, given that event A has already occurred
Bayes Theorem is defined as:
The following reasoning is from Julian Havil’s book “Impossible?”
Assign symbols to the events:
A – the event “car is behind door A” B – the event “car is behind door B” C – the event “car is behind door C” MA – the event “Monty opens door A” … similarly for MB , MC
Assume door A is chosen initially by the player, so Monty can open door B or C:
P(MB | A) = ½ , P(MB | B) = 0, P(MB | C) = 1
So, since A, B and C are mutually exclusive events:
P(MB) = P(MB | A)P(A) + P(MB | B)P(B) + P(MB | C)P(C) = ½ x ⅓ + 0 x ⅓ + 1 x ⅓ = ½
Now, the player can stick or change. If they stick with door A, their probability of winning the car is:
P(A | MB) = P(MB | A)P(A) / P(MB) = (½ x ⅓) / ½ = ⅓
If they switch to door C, their probability of winning the car is:
P(C | MB) = P(MB | C)P(C) / P(MB) = (1 x ⅓) / ½ = ⅔
TLS1.1 and TLS1.0 (and lower) protocols are insecure and should no longer be used.
For .NET 4.7 or later, you do not need to set System.Net.ServicePointManager.SecurityProtocol. The default value (SecurityProtocolType.SystemDefault) allows the operating system to use whatever versions it has been configured for, including any new versions that may not have existed at the time your application was created.
If you want to explicitly code this in .NET, rather than specify the allowed protocols, disable the disallowed protocols before making any connections:
// TLS must be 1.2 or greater. Disable SSL3, TLS1.0 and TLS1.1 [Note: this is the default behaviour for .NET 4.7 or later]
ServicePointManager.SecurityProtocol &= (~SecurityProtocolType.Ssl3 & ~SecurityProtocolType.Tls & ~SecurityProtocolType.Tls11);
If you have a high end NVidia graphics card and you’re investigating data science with Keras+Tensorflow, then you obviously want Tensorflow to take advantage of your GPU (training times for deep neural networks can be 10 – 15 times faster even when compared to the latest CPUs).
As well as being able to target multiple servers and multiple databases, it now also has the option to exclude specified queries from being executed (such as those that might take some time to execute on large very databases or busy server instances).
The source code is available on GitHub and you can download the executable directly from these links:
I was searching through email today looking for a LINQPad snippet that a colleague, James Miles, wrote some time ago, one which we used to generate the scripts for a production SQL Server database + transaction log point in time restore after IT had a little SAN mishap!
In doing so, I came across this gem from James: Solving Puzzles in C#: Poker Hands, which is not just a great example of writing a recursive function but of problem solving in general. [Where I used to work, we often used to have a Friday puzzle where I tried to come up with or find puzzles that wouldn’t be easy to solve by brute force. This was one of the many times I was thwarted by James and others!]
Starting with the upcoming SQL Server 2017 CU3 and SQL Server 2016 SP2 releases, CXPACKET waits are split into an actionable wait (CXPACKET) and a negligible wait (CXCONSUMER). (these wait types are already present in Azure SQL Database).
