dbcc

There are a number of uses for the DBCC SQLPERF command. I touched upon one of them in my last post on how you can use the command to obtain information about transaction log growth.

This handy little DBCC command has been around for a while now. So lets look at the others ways you use it….

1. Viewing wait statistics data
2. Clearing wait statistics data
3. Clearing latch wait statistics data
4. Obtaining log space size and used data

Syntax and examples for DBCC SQLPERF

--syntax
DBCC SQLPERF(option)
WITH NO_INFOMSGS

--example uses

DBCC SQLPERF(waitstats)

DBCC SQLPERF('sys.dm_os_latch_stats' , CLEAR)

DBCC SQLPERF('sys.dm_os_wait_stats' , CLEAR)

DBCC SQLPERF(logspace)

Looking at each use case for DBCC SQLPERF in turn….

DBCC SQLPERF(waitstats)

There are newer ways to do this by reading from sys.dm_os_wait_stats but it can be used to obtain wait statistics from your SQL Server.

I wrote about waits stats and wait types in an earlier post so have a read of that if you want to know more about them.

DBCC SQLPERF(‘sys.dm_os_wait_stats’ , CLEAR)

This resets the wait statistics data that your SQL Server has collected since it was last restarted – very handy for performance tuning.

DBCC SQLPERF(‘sys.dm_os_latch_stats’ , CLEAR)

Latches are internal resource locks and wait data is recorded in a similar way to wait type data. To clear out the latch waits that your SQL Server has collected since it was last restarted then run this command.

DBCC SQLPERF(logspace)

Finally, in order to get log space data on how large your transaction logs are and what percentage of them is in use then execute this command. My last post was about this dbcc command, you can view that here.

Permissions needed for DBCC SQLPERF

In order to run this command, your user needs VIEW SERVER STATE permission on the server.

DBCC CHECKINDENT can be used to reset a tables identity value on a column.

On the official Microsoft page about it, it reads

“Checks the current identity value for the specified table in SQL Server 2016 and, if it is needed, changes the identity value. You can also use DBCC CHECKIDENT to manually set a new current identity value for the identity column.”

This was an interesting find but when you might you use it?

I will create a small table to demonstrate how to use this.

T-SQL:

CREATE TABLE Table_1
(
ID INT IDENTITY(1,1) NOT NULL,
DateAdded DATETIME NOT NULL
)

Insert some rows….

INSERT INTO Table_1(DateAdded)
VALUES(GETDATE());
INSERT INTO Table_1(DateAdded)
VALUES(GETDATE());
INSERT INTO Table_1(DateAdded)
VALUES(GETDATE());
INSERT INTO Table_1(DateAdded)
VALUES(GETDATE());
INSERT INTO Table_1(DateAdded)
VALUES(GETDATE());

Check the current value which produces the below output….

DBCC CHECKIDENT ('Table_1', NORESEED);

Checking identity information: current identity value ‘5’, current column value ‘5’.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Now we will reset the identity value so that the next time we insert data, the value will be 10….

DBCC CHECKIDENT('Table_1', RESEED, 9);

Checking identity information: current identity value ‘9’, current column value ‘5’.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Add another row and check identity value. The row inserted will have a value of 10….

INSERT INTO Table_1(DateAdded)
VALUES(GETDATE());

Checking identity information: current identity value ’10’, current column value ’10’.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

Scenarios when you might use DBCC CHECKIDENT

It’s already clear what the function of this is but when might you use it?

I’m nervous at the thought of this being called in a production environment but in a dev environment, sure it could come in handy if you need to reset things to a known state.

TRUNCATE TABLE is a command which will enable you to delete all rows from a table and at the same time, reset the identity value. However you need permission to be able to do this and it will only work if the table is not referenced by a foreign key constraint. This is when DBCC CHECKIDENT is useful.

Some notes about DBCC CHECKIDENT

• You need to be a db_owner (dbo) of the database. If you are not a dbo, you would need permission to execute on behalf of dbo using WITH EXECUTE AS
• Reseed as (n – 1). So if you wanted a value of 5 as your next value, reseed using 4
• Setting a value which is less than values which are already in the table will result in unique constraint violations as soon as the value inserted hits a value which already exists in the table.
• Data type limits apply, you cannot exceed the max value of a TINYINT for example when reseeding.
• Running it on an empty table produces a change in behaviour. The following demonstrates this….

DBCC CHECKIDENT('Table_1', RESEED, 0);

Now after running that DBCC statement and then adding a row, you would expect the next value to be a 1 but it’s not….

INSERT INTO Table_1(DateAdded)
VALUES(GETDATE());

DBCC CHECKIDENT ('Table_1', NORESEED)

Checking identity information: current identity value ‘0’, current column value ‘0’.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.

This is normal behaviour however. If the table is empty, then the next value is the reseed value as opposed to the reseed value plus the increment value.