Difference size DBCC Page and DBCC Fileheader

I'm trying to read the current database size using dbcc command.

In my test I execute following commands:

DBCC Fileheader('tempdb',1) => size = 988152
DBCC Page('tempdb',1,0,3) => size = 5112

When I check tempdb initial size with the user interface I get 7.720MB (= 988152 * 8 / 1024).
How come there is a difference between the size found with dbcc fileheader and dbcc page?

Update:

Output from DBCC FileHeader can be found here, the output from DBCC Page can be found here

Update:

Yesterday I restarted the server but the difference is still present.
The size with dbcc page is now 0.


BindingID = 2c0a5351-ab60-11d2-896a-00c04fd9374a

FileIdProp = 1 FileGroupId = 1 Size = 0

MaxSize = 65535 Growth = 32768 Perf = 0

BackupLsn = (0:0:0) FirstUpdateLsn = (0:0:0)

OldestRestoredLsn = (0:0:0) FirstNonloggedUpdateLsn = [NULL]
MinSize = 0 Status = 0

UserShrinkSize = 65535 SectorSize = 512 MaxLsn =
(0:0:0) FirstLsn = (0:0:0) CreateLsn = (0:0:0)

DifferentialBaseLsn = (0:0:0) DifferentialBaseGuid =
00000000-0000-0000-0000-000000000000 FileOfflineLsn =
(0:0:0) FileIdGuid = b0c06a0f-4ee5-43aa-92be-8f03dee24690

RestoreStatus = 0 RestoreRedoStartLsn = (0:0:0)

RestoreSourceGuid = 00000000-0000-0000-0000-000000000000
HardenedSkipLsn = [NULL] ReplTxfTruncationLsn = [NULL]

TxfBackupLsn = [NULL] FstrContainerSize = [NULL]

MaxLsnBranchId = 00000000-0000-0000-0000-000000000000
SecondaryRedoStartLsn = [NULL] SecondaryDifferentialBaseLsn =
[NULL] ReadOnlyLsn = (0:0:0) ReadWriteLsn = (0:0:0)

RestoreDifferentialBaseLsn = (0:0:0) RestoreDifferentialBaseGuid =
00000000-0000-0000-0000-000000000000 RestorePathOrigin

DBCC Fileheader gives: minsize=131072, size=131072 and maxsize=-1

Restart SQL Server and see if they suddenly match.

There is a documented behaviour where if tempdb grows you can get different results depending on how you query what size it is. For example sys.master_files shows tempdb size on start; sys.database_files shows actual size (as do some of the Fileproperty() function results).

Nacho Alonso Portillo wrote on MSDN:

Well, it happens that when SQL Server autogrows a file which is part 
of TEMPDB, the size change is not reflected in sys.master_files (or
sys.sysaltfiles for that matter). As per the functional specifications of
the storage engine, for TEMPDB the change in the size of one of its files
is only reflected in those system tables for explicit grows and shrinks, 
not for those triggered by the automatic mechanisms.

https://blogs.msdn.microsoft.com/ialonso/2012/10/08/inaccurate-values-for-currently-allocated-space-and-available-free-space-in-the-shrink-file-dialog-for-tempdb-only/

StackExchange Database Administrators Q#135621, answer score: 3