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 am an IT Professional from the UK with a huge interest in MS technology especially SQL Server and Azure. During 2015 I was mentored by Paul Randal – Data Platform (SQL Server) MVP from SQLskills.
I have written articles for SQL Server Central, TechNet, gathered data for SQLskills Waits and Latches Library. I have also helped the SQL Server product team with testing SQL Server vNext adaptive query processing feature.
My aim is to help you in your day to day work or to reinforce specific areas that I am interested in, so I try to keep things short and simple.
Sometimes I will reinforce basic concepts via a quick SQL Server video clip – https://blobeater.blog/sqlserver-video-library/
Arun Sirpal – BlobEater
p.s. I am no longer afraid to mention that I like Sheep.
I have actually lost Paulie in the garden.
Copyright © All rights reserved. You are free to use any of the content here for personal use but need permission to use it anywhere else on the internet.
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!
Thanks to Grant for hosting this month’s T-SQL Tuesday found (http://www.scarydba.com/2017/06/06/t-sql-tuesday-091-databases-devops/) where it is a chance to share our DevOps stories. I am not going into specifics of databases but I am going to write about it more generally.
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.