If you issue a DBCC CHECKDB on a big database to verify for consistency errors, it will take a long time to complete, but the Management Studio windows usually does not give you any hint about how long does it take, or a percentage progress. Luckily enough sql server has a Dynamic Management View that can solve your problem.

This is the SQL code to visualize progress of the operation

   1: SELECT  session_id ,

   2:         request_id ,

   3:         percent_complete ,

   4:         estimated_completion_time ,

   5:         DATEADD(ms,estimated_completion_time,GETDATE()) AS EstimatedEndTime, 

   6:         start_time ,

   7:         status ,

   8:         command 

   9: FROM sys.dm_exec_requests

  10: WHERE database_id = 16

In my example I filtered the results only for the database and used the Id of the database that you can obtain with the DB_ID function.

An example of what you got with this query is represented in the following picture.

As you can see you can easily visualize percentage of completion, estimated end time and the command that is running.

Gian Maria.

I’ve a stored procedure with a query that runs on a quite big database, it was slow (more than one minute to run) and was optimized using a temp table. The result is that execution time dropped to ~2 secs, and since this was acceptable the optimization stopped.

After a couple of months, the query become really slow again, it got executed in ~30 secs and I started to investigate why.

A quick tour with SSMS and STATISTICS I/O did not reveal some news, but the execution plan have a strange sort operation that takes 90% of the time of the overall query and this is really strange, but I did not find any reason why it should slow the query so much. To have a better picture of what is happening I decided to fire the Activity Monitor to check if the query stops for any lock in table, but I found that the task that is executing the query goes into heavy parallelism (you see a lot of row in the activity monitor with the same id), but each subtask is waiting a lot with a  CXPACKET wait type and everything seems stuck. CXPACKET wait time happens when the execution of the query is parallelized so I decided to disable parallelism of the query with OPTION (MAXDOP 1) to verify if the situation change. The result is that the query now executed in ~2 secs, like it did two months before, so I decided to leave it with parallelism disabled and it start to run just fine.

The conclusion is,: when database is big, and query are complex, it is not so simple to understand why a query is slow, sometimes you need to tweak how SQL Server issue the query with Query Hint and you should use all the tools you have to understand what is really happening .

Gian Maria.

In a production Sql Server database we had some issue with the hardware, the result is that one very big database started to gave us errors on DBCC CHECKDB, the error is the following one.

Msg 8929, Level 16, State 1, Line 1
Object ID xxxxxx, index ID 1, partition ID xxxxxx, alloc unit ID xxxxx (type In-row data): Errors found in off-row data with ID xxxxxxx owned by data record identified by RID = (3:34252:4)

This happens in one of the most central and important table of the database, that contains millions of record, and only 20 rows gave us error, so I’d like to verify witch rows had the error, because in that table there are lots of records in logical status “deleted” and the corresponding physical row can be removed from the database without much pain and reinserted with the very same data to avoid dataloss.

So my question is… how can I identify the row given the RID (Row Identifier?) First of all from Object ID you can easily find the name of the table with select Object_Name(<Object_ID>) but what about the RID. After a little search I find the sys.fn_physLocFormatter function and I created this query

   1: SELECT sys.fn_PhysLocFormatter (%%physloc%%) AS RID,  

   2:         *

   3: into debug.RIDTABLE 

   4: FROM TableName

I selected into a table in Debug schema the RID of the Row as well as all the other columns of the table with error, now I take the output of the DBCC CHECKDB, selected all the RID of rows with errors and I could execute the query

   1: select * from debug.RIDTABLE

   2: where RID IN ('(3:34252:4)', '(x:xxxxx:x)'..... 

To extract from the RIDTAble all the row with errors, then I can simply delete them from the original table, and insert them again from the RIDTABLE. Checking the data inside RIDTABLE it seems that the data is correct, except for a NVARCHAR(MAX) field that contains long string of text.

After the process DBCC CHECKDB did not give any other error, so I was quite happy to solve this problem without the need to put the database in single-user-mode, but the most important aspect is that I was able to identify the rows with error, to understand the impact of errors in the software. It turned out that only a couple of lines contained really important data, the others are in Deleted status, so we did not lost anything so important.

Gian Maria.

Suppose you have a big table with about 3 GB of data in and you need to add a nullable new column on it, you can open SSMS, open the table in designer and create a new column of type Int called sclo_durationInMinutes, press save and the table gets update quite immediately.

Then you realize that the user want the duration in Minutes as a floating point number, so you open the designer, change the type of the sclo_durationInMinutes from Int to Float and press save…. after 30 seconds SSMS tells you that you got a timeout. If you look at the change script you can verify, with HORROR, that changing the type of a column is done with the creation of a temporary table, copy all the data (3 GB) in the temp table and finally deleting the old table and renaming the temp table with the name of the original table… REALLY?

Then I simply opened a new query and issue an ALTER TABLE manually

alter table dbo.scanlog

alter column sclo_durationInMinutes Float null 

I know that SSMS should work for a wide range of change, but requiring a full copy of a table just to change the type of a column it is quite overkill.

In the end, if you use SSMS it is better for you to have a deep knowledge of SQL, because the designer too much often opts for Copy-drop-rename strategy to alter structure of a table.

Gian Maria.

I love Database Project, introduced with Visual Studio 2008, and with SQL server 2012 they will be replaced by the Data Tools (codename Juneau), so I have a couple of links to share about this argument.

In this link you can find a table that compares all the features. As you can see, actually, one of the most missed feature in my opinion is the Data Generation and Database Unit Testing support. The important stuff is that, as stated in the blog, SSDT can be used side-by-side with VSDB if your application relies on features not included in SSDT CTP4, so at least if you have Database Projects where you use Unit Test you can still use them with no problem.

If you are going to convert existing Database Project into SSDT you should read this post that list the most common issues you can face during the conversion.

If you are moving from CTP3 to CTP4, you should read this post, that basically explain how to uninstall CTP3. Clearly I strongly suggest people to install CTP in Virtual Machine so you should not need this, but just in case you installed CTP3 in production machine , it will be handy.

Finally here is a list of the new features of the CTP4.

Enjoy Denali.

Gian Maria.

I’have a table with some dirty data, if you select it seems that everything is ok, but since it was imported from an external source, it happens that some string field actually ends with strange non alpha char.

The symptom is that I have some strange behavior on some data, then I verify what is the content of that row, so I issue a Select * from xxx where Name = ‘Azioni’ and got no result, so I select everything that contains Azioni and I found the record. This is the clear symptom that the field contains some strange stuff in it, so I simply to a Copy and paste in the editor to see exactly what is stored in the field, and I found

Do you see the strange char at the end? So I need a trim function that removes every non alphabetic character from the beginning and the end of the string. Looking in the internet I found this interesting article that lists a function that remove all non alpha char from the string, so I modified to make it remove non-alpha char only from the beginning and the end.

Here it is if you need it:

create Function [dbo].[TrimNonAlphaCharacters](@Temp nVarChar(max))

Returns nVarChar(max)

AS

Begin

    While PatIndex('[^a-z]%', @Temp) > 0

        Set @Temp = Stuff(@Temp, PatIndex('[^a-z]%', @Temp), 1, '')

    While PatIndex('%[^a-z]', @Temp) > 0

        Set @Temp = Stuff(@Temp, PatIndex('%[^a-z]', @Temp), 1, '')

    Return @TEmp

End

I’ve not tested it extensively, just ran it against my data and verified that it solves my problem, so I’m pretty confident that it works, but feel free to post any correction or any better implementation if you have one

Gian Maria.

I have a database with several Gigabyte of data and query performance is usually a issue, so we need to take great care of indexes and DB optimization. Since the vast majority of data access is done with NHibernate, we have also some read-only view that we use to easy the access from the views.

One of this view, have four left outer join from a main table to other four tables and we have a SELECT COUNT query that is quite slow, so we decide to understand how to optimize it. I started looking at the execution plan and I found this.

Figure 1: Original execution plan.

The execution plan clearly shows that we have a join between two tables, but I’m issuing a SELECT COUNT with condition on fields of the first table only, the question is: why sql server issue a join with another table, if the other table does not contains fields that are involved on the query?

The answer is really simple, a JOIN between two tables influences the number of rows returned, suppose that for each record of the main table we have 2 records on the table in join, this situation affects the SELECT COUNT operation, so SQL SERVER has no choice, he need to do the JOIN. Our Data Model enforces in Business Logic that for each record in the main table, at most we can have a single related record on the other table, so I decided to make the index that supports the foreign key unique (it was not unique because we usually enforce this type of constraint in business logic).

Once the index is Unique, Sql Server knows that the join could not affect the result of SELECT COUNT and from execution plan I verified that the join is gone and performances are greatly improved.

The motto is: if you have Business Logic that enforce uniqueness, creating a unique index at the Database Level if you are using that field in join can lead to better execution plans.

Gian Maria.