Recursive CTE to Calculate Dates for the Last 30 Days
Have you ever needed to generate a list of dates for the last 30 days. There are lots of different ways to do this with… Read More »Recursive CTE to Calculate Dates for the Last 30 Days
Have you ever needed to generate a list of dates for the last 30 days. There are lots of different ways to do this with… Read More »Recursive CTE to Calculate Dates for the Last 30 Days
After the last post on Cumulative Distribution Function (CDF) or as it is known in TSQL CUME_DIST(), I realized that although I showed how to… Read More »Cumulative Distribution Function (CDF) – Analyzing the Roll of Dice with TSQL
It is handy to have a SQL Restore script ready to go for every backup that you run. Here is a script that will help… Read More »Building a SQL Restore Script When Your Backup Runs
SQL Server 2017 introduces a new column in the sys.dm_db_file_space_usage system table. The column is modified_extent_page_count, which tells how many pages have been modified in your data file since the last full backup.
SELECT * FROM sys.dm_db_file_space_usage;
What is really interesting about this is that with a little math you can calculate the percentage of your data file that has been modified. This would be useful when running differential backups to be able to determine if it would make more sense to run a full backup or a differential backup. Basically when your differential backup gets large enough, based on the number of modified_extent_page_count pages, then it may make sense to do a full backup and reset this counter, and get back to smaller differential backups.
Here is an example
SELECT df.name, df.physical_name, total_page_count, allocated_extent_page_count, modified_extent_page_count, 100.0 * modified_extent_page_count / allocated_extent_page_count as PercentChanged FROM sys.dm_db_file_space_usage fsu INNER JOIN sys.database_files df on df.file_id = fsu.file_id;
Now based on the Percent Changed column we can make some assumptions on the size of the differential backup, and decide if we want to do a differential backup or a full backup.
Read More »Determining how much of your data file has been modified
From time to time I get asked about checkDB, and there are many solutions out there, but I have one that I generally use that is very simple and does the job.
The script below created a stored procedure in the DBHealthHistory database that can be used to check as many databases as you can get through in a specific time interval. Here it is set to 5 minutes, but that usually gets extended for large databases. If you set the job to daily, and the job doesn’t get through checking all the databases today, it will pick up where it left off and check the rest tomorrow.
Depending on the number and size of your databases you may want to run this more than once a day, or for a longer period than the 5 minutes.
Note: the 5 minute limitation is checked before starting the next check, so if you have a database that takes hours to check, that will kick off in the 5 minute interval and run until completion.
Today I had the opportunity to present on TempDB to the Spokane SQL Server users group (PASS Chapter). The session was titled TempDB – Do This… Read More »TempDB – Do This and Don’t Do That
A while back a wrote a blog post with a query to Visualize the VLF’s in your database. Today I have an update to that script.
Here is an updated script that has adds another column called “TextStatus” to the output to give you a better idea of what the different statuses mean. You now get 3 statuses shown, “In Use”, “Available”, and “Available Never Used”. The If you have lots of VLFs that are “Available Never Used” that may be an indication that your log file may be larger than you need. If you don’t have any that are “Available Never Used” the log may be smaller than you need.
Updating SQL Server statistics may not be as obvious as it may sound.
Imagine this scenario. I invite you over for dinner and a game of Scrabble. After dinner, I start to do the dishes, while you set up the game. Rather than just doing the dishes that are dirty from our dinner, I decide to take all the dishes from the shelves, and drawers in my kitchen. I create a gigantic pile of all of the dishes, both clean and dirty on the kitchen counter. You get the game setup, and we start playing the game. Between turns, I jump back into the kitchen, and wash a few dishes, then on my turn, I jump back into the game and play my turn, then back to the kitchen again. During the game you are constantly waiting for me to jump back into the game to make my move. You could see how long this would draw out the game with me washing all the dishes, even the ones that were already clean. 4 hours later, I finally finish the dishes, and shortly thereafter we finish the game. It is unlikely, even if you love to play Scrabble that you would ever return to my house for dinner and a game again. Tomorrow night, when I have dinner with my family, I do the same thing, and every night after dinner I wash all the dishes in the kitchen, even the clean ones. You can see how wasteful this sounds, and perhaps some people would even label me as OCD or something worse in this scenario.
Although this is obviously the wrong way to do things, often times we end up doing the equivalent of this in our SQL Server maintenance tasks.
Today I am presenting my “TempDB – Do This and Don’t Do That” session at SQL Saturday Redmond. Here is the download of the presentation… Read More »TempDB – Do This and Don’t Do That
So you are checking your database with DBCC CheckDB and of course if you are like me you use the WITH NO_INFOMSGS parameter. But it turns out that CheckDB is taking longer to run that you expected, and you want to check and see what table is currently being checked.
Here is a quick SQL Script that I use to find the current table that is being checked by DBCC CheckDB
use [your database]; go -- use this to find the session id of DBCC CheckDB SELECT session_id, start_time, command, percent_complete, total_elapsed_time, estimated_completion_time, database_id, user_id, last_wait_type FROM sys.dm_exec_requests CROSS APPLY sys.dm_exec_sql_text(sql_handle) WHERE command like '%DBCC%'; DECLARE @sessionID as integer = 53; -- enter the session ID of DBCC CheckDB Here SELECT name, schema_id, type_desc FROM sys.objects WHERE object_id = (SELECT TOP 1 resource_associated_entity_id FROM sys.dm_tran_locks WHERE request_session_id = @sessionID AND resource_type = 'OBJECT' AND resource_associated_entity_id <> 50);