You developed a new TSQL code and want to check is there a slow SQL statement inside and which is it? Or you debug the code and want to know which statement throws error, maybe inside of a trigger or calculated field which calls a function that fails and is not immediately visible what is happening? Or you test application on QA environment, and want to check for SQL errors or slow statements to return them back to dev for correction before problems hit production? Then read on…
Do you use ROWVERSION/TIMESTAMP to pull changed data?
If you do, you might experience a problem – not all changed rows are pulled, some are skipped. How can that be, if we pulled entire range of rowverion changes with no gaps?
Let me illustrate it in this video with demo inside:
In a few days I am traveling to Iceland for the first time in life. A land of lava, ice caves and Aurora Borealis. There is a SQL Saturday conference organized by local SQL community that I am looking forward to meet. Lot of interesting lectures you can attend there (besides mine of course) – this is the full schedule.
If anyone is interested to meet me, talk about SQL Server, life, or any other topic, it will be an opportunity there in Reykjavik at the conference, or have a drink with me on Sunday after the conference (11th May 2018) – you are welcome to contact me.
Server is sometimes slow and you want to know why? Here is a lightweight diagnostic SQL kit which will give you the answer. You need to put it on your server to start logging of performance info. This solution is already in use by many productions with mission-critical workload.
Demonstration of the smallest possible deadlock: only one statement, one table, one row.
Without transactions (no BEGIN TRANSACTION). Even RCSI (Read Committed Snapshot Isolation) is turned ON to eliminate shared locks. Everything is “by the book” as Books Online suggest to minimize deadlocks. How is that possible to deadlock? There is a complexity in simplicity of this demo. In video it is explained why single-row deadlock occurs. If you understand single-row deadlock, you will be able to understand even most complex production deadlock situations. And understanding the cause is the first step to eliminate them.
Enjoy the video, and tell me your opinion. Thank you!
It is SQL Server user group in Basel, after spending short time in Zürich. I am very happy to meet people there. Presentation will be very useful and interesting, and you are more than welcome to register and get there!
Recently, for the first time in my life I had a customer from India. A far away, beautiful country I had never opportunity to visit, with 1.3 billion of people. I thought it would be interesting experience, and it was indeed.
They have a 1.5TB SQL Server Enterpise Edition database used by Microsoft Dynamics AX. Read more ›
I am honored to be selected to speak in not one but two sessions of SQL Server conference Kulendayz 2017. The topics are “Tuning optional filters” and “Mirror Killer in SQL 2016&2017 Standard Edition”. There are also other great speaks and very interesting topics. Be there and improve your skills! https://lnkd.in/gDhZ7NX#kulendayz17http://www.kulendayz.com
Databases should be fast and simple to use. We make them so. Do not let your customers wait for a slow database response - hire a top professional! We are passionate about creating highly-tuned SQL Server systems. Do you want yours to become one? Simply call us or send email, and we will take care of the rest.
Keep your transaction log backups at least to second full backup. Even if the latest full backup is corrupt, you can recover without any data loss. E.g. if you take full backup weekly, diff backup daily, and transaction log backup hourly, keep your transaction log backup at least for 2 weeks, so it reaches the second full backup.