Understanding Statistics io and Logical reads - is logical reads information correct

Question

Hi,
This question arises during a performance test - on SQL Server 2012 with SP2.
In the following example, table has only column and that is of data type INT.
When inserted 592 records of data type INT it is doing only 1 logical read but as soon another record is inserted SP is reporting 2 logical reads. Why?
In the code, i have highlighted difference between 
statistics io - logical reads and sys.dm_exec_procedure_stats.total_logical_reads
to understand the difference between these 2 information.
set nocount on
GO
create table dbo.test_storage_and_logical_reads
employee_number int --primary key
GO
go
CREATE procedure dbo.test_sp_logical_reads
as
begin
select
employee_number
from dbo.test_storage_and_logical_reads
order by employee_number desc
end
go
insert into dbo.test_storage_and_logical_reads
(employee_number)
VALUES (1)
GO 592
EXEC sp_spaceused 'dbo.test_storage_and_logical_reads'
--set statistics io on
--GO
exec dbo.test_sp_logical_reads
GO
----Table 'test_storage_and_logical_reads'. Scan count 1, logical reads 1, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
---- But sys.dm_exec_procedure_stats.total_logical_reads is reporting 3 instead.
truncate table dbo.test_storage_and_logical_reads
GO
insert into dbo.test_storage_and_logical_reads
(employee_number)
VALUES (1)
GO 593
EXEC sp_spaceused 'dbo.test_storage_and_logical_reads'
exec dbo.test_sp_logical_reads
GO
----Table 'test_storage_and_logical_reads'. Scan count 1, logical reads 2, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
---- But sys.dm_exec_procedure_stats.total_logical_reads is reporting 4 instead.
--drop procedure dbo.test_sp_logical_reads
--drop table dbo.test_storage_and_logical_reads
GO
NB: I do understand the logical and physical reads. Thanks.
For quick review of new features, try virtual labs: http://msdn.microsoft.com/en-us/aa570323

Answer 1

Hi.
I still need to test the scenario but if you read definition of this DMV it says 'Returns aggregate performance statistics for cached stored procedures' so I guess, I am not sure 3 can be due to this aggregated output given by this DMV. Will test it
on SS 2012 SP2 will get back to you.
Please mark this reply as answer if it solved your issue or vote as helpful if it helped so that other forum members can benefit from it.
My TechNet Wiki Articles
Hi Shanky / Sean Gallardy
i think Sean Gallardy created the "test_sp_logical_reads" table in master DB, i have that same issue when i accidentiatly created the table "test_sp_logical_reads" in master, but when i create the same table in USER DB like "sample1"
it only allocate 1 page for 592,
hi Asam,
Let me narrow down the your question, if my understanding is correct ...
<<When you have the free space in a page of a Heap, why SQL Server is assigning New page for a New Record>>
Answer is in PFS bytes
The answer is that PFS bytes are not fully reset until the page is reallocated. On deallocation, the only bit in the PFS byte that's changed is the allocation status bit - this makes it very easy to rollback a deallocation
--Before inserting the 593 record plese execute the below query
--Note Replace "database1" with your DBName
DBCC TRACEON (3604);
DBCC IND ('database1', 'test_storage_and_logical_reads', 1);
--Result
PageFID PagePID IAMFID IAMPID ObjectID IndexID PartitionNumber PartitionID iam_chain_type PageType IndexLevel NextPageFID NextPagePID PrevPageFID PrevPagePID
1 2770 NULL NULL 517576882 0 1 72057594039828480 In-row data 10 NULL 0 0 0 0
1 2769 1 2770 517576882 0 1 72057594039828480 In-row data 1 0 0 0 0 0
--your intrested in the second record(page)
DBCC PAGE ('database1', 1, 2769,3) WITH TABLERESULTS;
--you can find 38th row as
--PFS (1:1) = 0x64 MIXED_EXT ALLOCATED 100_PCT_FULL
--which means your page is full
--you can try inserting 300 rows it will show you PFS (1:1) = 0x61 MIXED_EXT ALLOCATED 50_PCT_FULL
please refer in the below link
http://blogs.msdn.com/b/sqlserverstorageengine/archive/2006/07/08/under-the-covers-gam-sgam-and-pfs-pages.aspx
http://aboutsqlserver.com/2013/12/17/sql-server-storage-engine-heap-tables/
"This page has a PFS byte value of 0x04 - how can it be full when its not allocated?"
The answer is that PFS bytes are not fully reset until the page is reallocated. On deallocation, the only bit in the PFS byte that's changed is the allocation status bit - this makes it very easy to rollback a deallocation.
Here's an example. Using a database with a simple table with one row.
A DBCC PAGE of the IAM page includes:
PFS (1:1) = 0x70 IAM_PG MIXED_EXT ALLOCATED 0_PCT_FULL
If I run the following:
BEGIN
TRANSACTION
DROP
TABLE T1
GO
And then do the DBCC PAGE again, the output now includes:
PFS (1:1) = 0x30 IAM_PG MIXED_EXT 0_PCT_FULL
And if I rollback then transaction, the DBCC PAGE output reverts to:
PFS (1:1) = 0x70 IAM_PG MIXED_EXT ALLOCATED 0_PCT_FULL
Thanks
Saravana Kumar C