A quick elementary post which is my entry to this months’ T-SQL Tuesday entry hosted by a good friend SQLDoubleG http://www.sqldoubleg.com/2017/07/03/tsql2sday-92-lessons-learned-the-hard-way/.
We are here to talk about mistakes we used to make. There is one mistake that I am going to discuss and is something that I used to do 10 years ago, obviously I do not do this anymore.
I was VERY excited when I read the following tweet (below) from Bob Ward regarding SQL Server Diagnostics capability. What is it you are asking? It is an extension to SQL Server Management Studio (SSMS) where it gives you the ability to Upload / Analyse dump files created by SQL Server.
A really quick one today, something that made me think for a minute and I thought it might make others think too. So you have enabled TDE – Transparent Data Encryption (you can see these previous posts here: https://blobeater.blog/?s=tde&submit=Search) on your SQL Server database and in the back of your mind you know TempDB gets encrypted too.
I have a SQL Server that is constantly producing “dump” files (with a MDMP File type), these are named SQLDumpxxxx (xxx = numerical value). They are located in the following directory: C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\Log\ – sound familiar?
Have a look at this screen shot – it’s messy!
Following on from my previous blog post I mentioned that I had to find a solution to the “unable to call into C compiler” message. This meant that the specific SQL Server database in question (that contained in-memory tables) went into recovery pending mode, meaning that recovery needed to run but something was preventing it from even starting.
I had a messy (another one) day, last thing I wanted was a “broken” SQL Server instance where I was faced with multiple “service terminated unexpectedly” messages. I thought it would make a decent blog post to share with you all.
A very quick post for today, recently I have been working on some code to gather metrics around SQL Server memory, more specifically, how much memory is on your server, your total / target memory and PLE. (If you want to know more about total vs target see this link: https://blobeater.blog/2017/03/01/sql-server-target-vs-total-memory/)
A quick post that is hopefully useful, I wanted a quick way to find the time, size of the database file size change and who caused it.
Hopefully you know the relevance and importance of setting a correct value for max memory on your SQL Server. By default it will be the value 2147483647 which is not a random number but the 8th Mersenne prime! In a computing sense it is the maximum positive value for a 32-bit signed binary integer and that is big.
Have you heard of SQLskills? Have you heard of the waits library? If not then where have you been hiding?
