To look at what’s going on lets create a sample new table in a table and take a peak at the data.  To setup this test we create a new database and setup that database for use with AlwaysOn Availability Groups.  The availability group is setup with no readable secondary replicas.

create table MyTest (c1 int identity(1,1),
c2 int,
c3 varchar(100))
GO
insert into MyTest
(c2, c3)
values
(1, ‘test’)
GO 400

This creates a new table in the database with 400 rows in it.  Looking at the output from DBCC IND we can see that this table takes up 2 data pages with a root page (this will become important later on).

Looking at the data for the first data page we can see the following information.

Slot 0 Offset 0×60 Length 23

Record Type = PRIMARY_RECORD        Record Attributes =  NULL_BITMAP VARIABLE_COLUMNS
Record Size = 23
Memory Dump @0x000000003CACA060

0000000000000000:   30000c00 01000000 01000000 03000001 00170074  0………………t
0000000000000014:   657374                                        est

Slot 0 Column 1 Offset 0×4 Length 4 Length (physical) 4

c1 = 1

Slot 0 Column 2 Offset 0×8 Length 4 Length (physical) 4

c2 = 1

Slot 0 Column 3 Offset 0×13 Length 4 Length (physical) 4

c3 = test

Slot 0 Offset 0×0 Length 0 Length (physical) 0

KeyHashValue = (8194443284a0)

When we update this row changing the value of c2 to equal 2 nothing really changes which we can see from DBCC PAGE again.

Slot 0 Offset 0×60 Length 23

Record Type = PRIMARY_RECORD        Record Attributes =  NULL_BITMAP VARIABLE_COLUMNS
Record Size = 23
Memory Dump @0x000000003EECA060

0000000000000000:   30000c00 01000000 02000000 03000001 00170074  0………………t
0000000000000014:   657374                                        est

Slot 0 Column 1 Offset 0×4 Length 4 Length (physical) 4

c1 = 1

Slot 0 Column 2 Offset 0×8 Length 4 Length (physical) 4

c2 = 2

Slot 0 Column 3 Offset 0×13 Length 4 Length (physical) 4

c3 = test

Slot 0 Offset 0×0 Length 0 Length (physical) 0

KeyHashValue = (8194443284a0)

Next I’ve changed the settings for the availability group to support readable secondary replicas.  Once that change has been made we change the value of c2 for the same row to equal the value of 3.  Again we can look at this with DBCC PAGE.

Slot 0 Offset 0x1d4e Length 37

Record Type = PRIMARY_RECORD        Record Attributes =  NULL_BITMAP VARIABLE_COLUMNS VERSIONING_INFO
Record Size = 37
Memory Dump @0x000000003AEEBD4E

0000000000000000:   70000c00 01000000 03000000 03000001 00170074  p………………t
0000000000000014:   65737400 00000000 0000000f 06000000 00        est…………..

Version Information =
Transaction Timestamp: 1551
Version Pointer: Null

Slot 0 Column 1 Offset 0×4 Length 4 Length (physical) 4

c1 = 1

Slot 0 Column 2 Offset 0×8 Length 4 Length (physical) 4

c2 = 3

Slot 0 Column 3 Offset 0×13 Length 4 Length (physical) 4

c3 = test

Slot 0 Offset 0×0 Length 0 Length (physical) 0

KeyHashValue = (8194443284a0)

Looking at these two outputs from DBCC PAGE we can see a couple of differences.  First we see an additional value in the “Record Attributes” field which adds in VERSIONING_INFO to the value.  We also see that the record size has changed from 32 to 37.  Additionally we see that the Version Information has been added.

Looking at the DBCC PAGE output on one of the replicas for the same page as before we see some different information.

Slot 0 Offset 0x1d4e Length 37

Record Type = PRIMARY_RECORD        Record Attributes =  NULL_BITMAP VARIABLE_COLUMNS VERSIONING_INFO
Record Size = 37
Memory Dump @0x000000003893BD4E

0000000000000000:   70000c00 01000000 03000000 03000001 00170074  p………………t
0000000000000014:   65737440 01000001 0000000f 06000000 00        est@………….

Version Information =
Transaction Timestamp: 1551
Version Pointer: (file 1 page 320 currentSlotId 0)

Slot 0 Column 1 Offset 0×4 Length 4 Length (physical) 4

c1 = 1

Slot 0 Column 2 Offset 0×8 Length 4 Length (physical) 4

c2 = 3

Slot 0 Column 3 Offset 0×13 Length 4 Length (physical) 4

c3 = test

Slot 0 Offset 0×0 Length 0 Length (physical) 0

KeyHashValue = (8194443284a0)

Specifically at this point we see that the Version Pointer now has a value in it. This tells us that the SQL Server has put a copy of the original page into the tempdb database so that we can read it.

A question comes up as to what happens to the page when this row information is added.  Specifically does the page split because of this additional 14 bytes of new data per row.  The answer to this question is “it depends”.  In my testing that I did when I updated a single row the page didn’t split, mostly this would be because there was some free space in the database page.  When I updated rows 2-40 and looked at DBCC IND I saw that in fact the page had split.

Looking at the values within the page there are now 159 rows in the page which was the original database page when there were 322 rows within the database page.  The remainder of the rows were copied into a new database page.

Now that we’ve identified that SQL Server is going to be page splitting older database pages, potentially like crazy what can we do about it?  The answer to that question is to just deal with it and to decrease the fill factor as needed so that page splits happen as little as possible.

To make matters worse when we rebuild the index on the table and look at the output from DBCC PAGE again we can see that the additional flag has been removed from row 1 (seen below).  This tells us that no only will this problem come up the first time that data is modified, it’ll come up every time that index rebuilds are done when the data is changed for the first time after the rebuild.

Slot 0 Offset 0×60 Length 23

Record Type = PRIMARY_RECORD        Record Attributes =  NULL_BITMAP VARIABLE_COLUMNS
Record Size = 23
Memory Dump @0x000000003E0CA060

0000000000000000:   30000c00 01000000 03000000 03000001 00170074  0………………t
0000000000000014:   657374                                        est

Slot 0 Column 1 Offset 0×4 Length 4 Length (physical) 4

c1 = 1

Slot 0 Column 2 Offset 0×8 Length 4 Length (physical) 4

c2 = 3

Slot 0 Column 3 Offset 0×13 Length 4 Length (physical) 4

c3 = test

Slot 0 Offset 0×0 Length 0 Length (physical) 0

KeyHashValue = (8194443284a0)

Changing the data again, this time changing the first 40 rows (id values 1-40) the new flag comes into place as expected.  If we reorganize the index instead of doing a rebuild this time the flags are left in place.

This tells us that the better option for doing index maintenance on databases which are being protected by AlwaysOn Availability Groups is going to be to use reorganize commands instead of rebuild commands.  This way the 14 byte pointer isn’t removed from the rows so that when they are modified the additional 14 bytes of data doesn’t need to be added.

If you’ve got rows which are changed all the time then this will be a way to handle it.  If the rows never change after the data is reorged then it may or may not be something worth worrying about.

Hopefully this helps answer the questions of what these extra bytes are for and how we can deal with them.

Denny

The WITH (NOLOCK) table hint isn’t a go faster button for SQL Server.  It has actual implications to the data which is being returned by the query.  The biggest of these implications is that the data might not be correct.  You see the WITH (NOLOCK) table hint uses dirty reads to return the data, so it basically ignores the locks which other queries have taken.  This is why the query appears to run faster, because the query isn’t being blocked any more.  The proper approach would be to find the query which is causing the extended blocking and figure out why it is taking so long to run, and fix the performance problems of that query.

The only go faster button that is available in SQL Server is the CREATE INDEX statement.  Anything else isn’t truly a go faster button, and has other side effects which must be understood before being implemented.

Denny

The second thing to check is that you don’t need to add any additional indexes.  If your queries are doing scan’s which they shouldn’t be then this will put extra load on the disks.

If everything else looks good it’s time to get the boss to open their checkbook and buy more disks, or faster disks.

Denny

The meeting starts at 6:30pm, and I believe that there will be pizza provided and who doesn’t like pizza and a DACPAC discussion.

The user group meets at the New Horizons Computer Learning Center in Anaheim.

1900 S. State College Blvd.
Suite 100
Anaheim, CA 92806

It’s right behind Angel’s stadium (or what ever its called this month), you can’t miss it.

I’ll have some SWAG with me, but not a whole lot (my supplies are starting to run low).

See you there.

Denny

You can see this yourself by creating a table, with a date field, then stuff some records into that table.

CREATE TABLE sample_table
(id INT IDENTITY(1,1) PRIMARY KEY,
dt DATETIME)
go
CREATE INDEX ix_sample_table ON dbo.sample_table
(dt)
go
INSERT INTO sample_table
(dt)
SELECT '1/1/2000 15:00:00'
UNION
SELECT '1/2/2000 12:00:00'
UNION
SELECT '1/3/2000 08:00:00'
go

You can now query the dt column and use the convert function. When you view the execution plan you’ll see that an index scan is being used.

SELECT id, dt
FROM sample_table
WHERE CONVERT(varchar(10), dt, 101) = '01/01/2000'

But it you use the BETWEEN operator instead of the = operator you’ll see the engine using an index seek instead of the index scan.

SELECT id, dt
FROM sample_table
WHERE dt BETWEEN '01/01/2000' AND '01/02/2000'

Now the same thing applies when using other functions to the datetime column in the table. For example if you were to have a system where people need to search based on the timezone where the data is stored in UTC time, but searching needs to happen based on the users time zone.

The easiest way to do this would be to put a dateadd function around the dt field. However even when using the BETWEEN operator you still use an index scan, instead of the seek. In this case I’m searching against the pacific timezone.

SELECT id, dt
FROM sample_table
WHERE dateadd(mi, -420, dt) BETWEEN '01/01/2000' AND '01/02/2000'

Now, if you switch the -420 to 420, and put the DATEADD function around the dates in the BETWEEN operator the index seek will be preserved. The query looks a little strange, but that’s ok. It’s the end result that we are looking for here.

SELECT id, dt
FROM sample_table
WHERE dt BETWEEN dateadd(mi, 420, '01/01/2000') AND dateadd(mi, 420, '01/02/2000')

Now if you have the UtcOffset that you want to use stored in another table such as an Account table. We’ll recreate the sample_table to go with this.

CREATE TABLE sample_table
(id INT IDENTITY(1,1) PRIMARY KEY,
dt DATETIME,
AccountId int)

CREATE TABLE Account
(AccountId INT PRIMARY KEY,
UtcOffset INT)
go
CREATE INDEX ix_sample_table ON dbo.sample_table
(dt)
INCLUDE (AccountId)
go
INSERT INTO sample_table
(dt, AccountId)
SELECT '1/1/2000 15:00:00', 1
UNION
SELECT '1/2/2000 12:00:00', 2
UNION
SELECT '1/3/2000 08:00:00', 1

INSERT INTO Account
SELECT 1, -420
UNION
SELECT 2, -300

In order to make this work, you have to take the UtcOffset value *-1 so that the date is adjusted in the correct direction to make the query work.

SELECT id, dt
FROM sample_table
JOIN Account on sample_table.AccountId = Account.AccountId
WHERE dt BETWEEN dateadd(mi, Account.UtcOffset*-1, '01/01/2000') AND dateadd(mi, Account.UtcOffset*-1, '01/02/2000')

(Ignore the Clustered Index Scan on the Account table, correcting that isn’t the goal of this post.

Hopefully you find this technique useful.

Denny

This time the LA Code Camp will be the weekend after PDC this time as the weekend before is a home football game.  Apparently the home games are pretty popular so they need all the available parking for the game, especially since we were right next to the stadium last time.

There will be all sorts of great presenters giving presentations at this event.  Hopefully a bunch of the PDC speakers will be coming and giving presentations.

I’ve got three presentations lined up so far (more may come, I’ve got time to decide).

• Reading the SQL Server Execution Plan
• SQL Server Indexing for the Client Developer
• Storage for the DBA

In the Reading the SQL Server Execution Plan session I’ll be going over how to read the execution plan, as well as how to get the SQL Server to change it’s mind.

In the SQL Server Indexing for the Client Developer I’ll be showing proper techniques for SQL Server indexing.

In the Storage for the DBA session I’ll be going over some best practices for how to setup your storage, as well as how to talk to your storage admin so that you can get the best storage possible for the server, while still keeping the finances of buying storage in mind.  During the session (network access permitting) we’ll be looking at a production EMC storage array to see what the Storage Admin sees and how what he sees translates to what we DBAs see on the server.

Full session descriptions are available on to SoCal Code Camp site or via the links above.

Denny

This little query should help you with that.  You may need adjust it slightly to account for extra spaces in your plan guide, I tried to account for double spaces, but if you have more than two spaces anywhere in the top part you’ll need to tweak it.

select cast(replace(replace(replace(hints, '  ', ' '), 'OPTION (USE PLAN N''', ''), ''')', '') as xml), *
from sys.plan_guides

This will give you XM that you can click on, which should open right up in SSMS as a query plan (if using SQL Server 2008, if you are using the SQL 2005 SSMS you’ll need to save the XML file and rename it to *.sqlplan and open it in SSMS).

Denny

• Table Scan
• Clustered Index Scan
• Index Scan
• Clustered Index Seek
• Index Seek

The basic rule to follow is Scans are bad, Seeks are good.

When SQL Server does a scan it loads the object which it wants to read from disk into memory, then reads through that object from top to bottom looking for the records that it needs.

When SQL Server does a seek it knows where in the index that the data is going to be, so it loads up the index from disk, goes directly to the part of the index that it needs and reads to where the data that it needs ends.  This is obviously a must more efficient operation than a scan, as SQL already knows where the data is that it is looking for.

When SQL Server is looking for your data probably one of the largest things which will make SQL Server switch from a seek to a scan is when some of the columns are you looking for are not included in the index you want it to use.  Most often this will have SQL Server fall back to doing a clustered index scan, since the Clustered index contains all the columns in the table.  This is one of the biggest reasons (in my opinion at least) that we now have the ability to INCUDE columns in an index, without adding those columns to the indexed columns of the index.   By including the additional columns in the index we increase the size of the index, but we allow SQL Server to read the index, without having to go back to the clustered index, or to the table it self to get these values.

We’ll look at this more shortly when we look at execution plans.

Denny