SQL SCRIPTS:Where are sp_configure settings stored? Another reason to backup master…
One of the 'corruptions' is because of a special page that only exists in the master database – the CONFIG block of the SQL Server instance. It's page number 10 in data file ID 1 of master. DBCC CHECKDB flags this as a corruption if it's present in any other database apart from master, as the page in master is marked as allocated, but no object owns it. This is only allowed in master. Similar allowances are made by DBCC CHECKDB in every database for the boot page (page 9 in file 1) and for each data and log file's file header page (page 0 in each file). See here for a blog post about the boot page and here for a blog post about file header pages.
What does this special page store? It stores all the sp_configure options for the SQL Server instance. This is yet one more reason to make sure you regularly back up the master database because if you lose master then you lose all your configuration settings for that SQL Server instance.
You can examine this page using DBCC PAGE or the equally undocumented, but nowhere nearly as well known, DBCC CONFIG command (they use the same code under the covers and both require trace flag 3604).
Here's an example from one of my laptop instances:
DBCC TRACEON (3604);
DBCC PAGE ('master', 1, 10, 3);
GOPAGE: (1:10)BUFFER:BUF @0x0000000080FC0AC0bpage = 0×0000000080572000 bhash = 0×0000000000000000 bpageno = (1:10)
bdbid = 1 breferences = 0 bcputicks = 264
bsampleCount = 1 bUse1 = 23062 bstat = 0xc00009
blog = 0×32159 bnext = 0×0000000000000000PAGE HEADER:Page @0×0000000080572000m_pageId = (1:10) m_headerVersion = 1 m_type = 14
m_typeFlagBits = 0×0 m_level = 0 m_flagBits = 0×200
m_objId (AllocUnitId.idObj) = 99 m_indexId (AllocUnitId.idInd) = 0 Metadata: AllocUnitId = 6488064
Metadata: PartitionId = 0 Metadata: IndexId = 0 Metadata: ObjectId = 99
m_prevPage = (0:0) m_nextPage = (0:0) pminlen = 0
m_slotCnt = 1 m_freeCnt = 0 m_freeData = 8190
m_reservedCnt = 0 m_lsn = (0:0:1) m_xactReserved = 0
m_xdesId = (0:0) m_ghostRecCnt = 0 m_tornBits = -1051583237Allocation StatusGAM (1:2) = ALLOCATED SGAM (1:3) = NOT ALLOCATED
PFS (1:1) = 0×64 MIXED_EXT ALLOCATED 100_PCT_FULL DIFF (1:6) = CHANGED
ML (1:7) = NOT MIN_LOGGEDSlot 0, Offset 0×60, Length 9, DumpStyle BYTERecord Type = PRIMARY_RECORD Record Attributes = Record Size = 9Memory Dump @0x000000001580C0600000000000000000: 00000800 e2040000 09†††††††††††††††††….รข…DS_CONFIG @0x000000001580C060cconfsz = 8 cmajor = 9 cminor = 0
crevision = 75 cbootsource = 2 crecinterval = 0
ccatalogupdates = 0 cmbSrvMemMin = 0 cmbSrvMemMax = 2147483647
cusrconnections = 0 cnetworkpcksize = 4096 ckbIndexMem = 0
cfillfactor = 0 ctapreten = 0 cwritestatus = 0
cfgpriorityboost = 0×0 cfgexposeadvparm = 0×0 cfglogintime = 20
cfgpss = 0 cfgpad = 4096 cfgxdes = 16
cfgaffinitymask = 0 cfgaffinitymask64 = 0 cfgIOAffinityMask = 0
cfgIOAffinity64Mask = 0 cfgbuf = 4362 cfgdes = 0
cfglocks = 0 cfgquerytime = 600 cfgcursorthrsh = -1
cfgrmttimeout = 10 cfg_dtc_rpcs = 0 cclkrate = 31250
cfg_max_text_repl_size = 65536 cfgupddate = 41023 cfgupdtime = 14252889
fRemoteAccess = 1 cfgbufminfree = 331 cnestedtriggers = 0×1
cdeflang = 0 cfgTransformNoiseWords = 0×0 cfgPrecomputeRank = 0×0
crossdbownchain = 0 cidCfg = 0x3400d008 cidCfgOld = 0x3400d008
cfgCutoffYear = 2049 cfgLangNeutralFT = 1033 maxworkthreads = 0
minworkthreads = 32 minnetworkthreads = 32 threadtimeout = 15
connectsperthread = 0 cusroptions = 0 exchcostthreshold = 5
maxdop = 0 cpwdpolicyupgrade = 0×1 cfServerTriggerRecursion = 1
cfDisableResultsetsFromTriggers = 0 cfgPHConnectTimeout = 60 CLREnabled = 0
cfgmaxcrawlrange = 4 ftSmallBufMin = 0 ftSmallBufMax = 100
ftLargeBufMin = 0 ftLargeBufMax = 100 RemoteDacEnabled = 0
CommCritComplianceEnabled = 0 EkmEnabled = 0 cUserInstanceTimeout = 0x3c
cfgEnableUserInstances = 0×1 m_BackupCompressionDefault = 0×0 FilestreamAccessLevel = 2
OptimizeForAdhocWorkloads = 0 cchecksum = 1250DBCC execution completed. If DBCC printed error messages, contact your system administrator.
You can see that the CONFIG block is stored in a special way as the record length DBCC PAGE reports is only 9 bytes, whereas the CONFIG block is several hundred bytes. When SQL Server starts, it opens a channel directly to master's MDF and reads the entire 8Kb of page 10 into memory and typecasts it into the in-memory CONFIG data structure. If the CONFIG block is damaged, the server won't start.
As you can see from the output, not everything in the CONFIG block is exposed or settable via sp_configure.