SQL Server Storage

DBCC IND 的语法是：

DBCC IND ( {dbname}, {table_name},{index_id} )

Index_id为0的时候，表示取的是堆表的信息，其他数值，等同于sys.indexes.index_id.

返回结果所包含的列有:

PageFID: page file Id. 数据页所在的数据文件的地址。也就是sys.database_files.file_id 的值。

PagePID: page id

IAMFID: index allocation MAP file id. 等同 sys.database_files.file_id.

IAMPID: Index allocation MAP page id

PageType : 注明了这个page的用途 :

1 - Data page 2 - Index page 3 - Large object page 4 - Large object page 8 - Global Allocation Map page 9 - Share Global Allocation Map page 10 - Index Allocation Map page 11 - Page Free Space page 13 - Boot page 15 - File header page 16 - Differential Changed Map page 17 - Bulk Changed Map page

其他字段比较容易理解。

既然知道了这一个页，比如IAMPID， 那我们就可以知道这个页到底存了哪些东西，还可以比较IAM page 与普通page的异同。 甚至还可以比较GAM, IAM, SGAM的不同，这放以后讨论。现在我们的表里暂时只有一条数据，所以总共才2个page. 一个IAM page,一个data page. 真好用来做比较。要想看一个page的存储内容，DBCC PAGE就该上场了。用法如下：

DBCC PAGE( {dbid|dbname}, pagenum [,print option] [,cache] [,logical] )

也有的是这么介绍的，毕竟这是非官方支持的命令，所以都试试

dbcc page ( {‘dbname’ | dbid}, filenum, pagenum [, printopt={0|1|2|3} ])

The filenum and pagenum parameters are taken from the page IDs that come from various system tables and appear in DBCC or other system error messages. A page ID of, say, (1:354) has filenum = 1 and pagenum = 354.

The printopt parameter has the following meanings:

0 – print just the page header 1 – page header plus per-row hex dumps and a dump of the page slot array (unless its a page that doesn’t have one, like allocation bitmaps) 2 – page header plus whole page hex dump 3 – page header plus detailed per-row interpretation Filenum: 对应了DBCC IND结果集里的 pageFID, 数据文件的 ID

PAGENum：对应了 DBDD IND 结果集里的 pagePID, 数据页的 ID

PrintOpt:

0: page头文件信息

1: page头文件信息，加上每一行的16进制信息

2: page头文件信息，加上每一页的16进制信息

3: page头文件信息，加上详细的每一页的每一行的解释信息

似乎这里第二种写法比较靠谱:

DBCC PAGE (lenistest5, 3,9,3)

PAGE: (3:9)

BUFFER:

BUF @0x0000000484E524C0

bpage = 0x00000003F348C000 bhash = 0x0000000000000000 bpageno = (3:9)

bdbid = 35 breferences = 0 bcputicks = 0

bsampleCount = 0 bUse1 = 15680 bstat = 0xb

blog = 0x1212121c bnext = 0x0000000000000000

PAGE HEADER:

Page @0x00000003F348C000

m_pageId = (3:9) m_headerVersion = 1 m_type = 10

m_typeFlagBits = 0x0 m_level = 0 m_flagBits = 0x0

m_objId (AllocUnitId.idObj) = 120 m_indexId (AllocUnitId.idInd) = 256

Metadata: AllocUnitId = 72057594045792256

Metadata: PartitionId = 72057594040549376 Metadata: IndexId = 0

Metadata: ObjectId = 245575913 m_prevPage = (0:0) m_nextPage = (0:0)

pminlen = 90 m_slotCnt = 2 m_freeCnt = 6

m_freeData = 8182 m_reservedCnt = 0 m_lsn = (35:193:15)

m_xactReserved = 0 m_xdesId = (0:0) m_ghostRecCnt = 0

m_tornBits = 0 DB Frag ID = 1

Allocation Status

GAM (3:2) = ALLOCATED SGAM (3:3) = ALLOCATED

PFS (3:1) = 0x70 IAM_PG MIXED_EXT ALLOCATED 0_PCT_FULL DIFF (3:6) = CHANGED

ML (3:7) = NOT MIN_LOGGED

IAM: Header @0x0000000012DFA064 Slot 0, Offset 96

sequenceNumber = 0 status = 0x0 objectId = 0

indexId = 0 page_count = 0 start_pg = (3:0)

IAM: Single Page Allocations @0x0000000012DFA08E

Slot 0 = (3:8) Slot 1 = (0:0) Slot 2 = (0:0)

Slot 3 = (0:0) Slot 4 = (0:0) Slot 5 = (0:0)

Slot 6 = (0:0) Slot 7 = (0:0)

IAM: Extent Alloc Status Slot 1 @0x0000000012DFA0C2

(3:0) - (3:1272) = NOT ALLOCATED

DBCC execution completed. If DBCC printed error messages, contact your system administrator.

有这么一行需要特别注意的:

IAM: Single Page Allocations @0x0000000012DFA08E

Slot 0 = (3:8)

这是说明IAM PAGE 这一页记录了他所能管辖的数据页的分配，slot 0 =(3:8). 8就代表了data page id =8 .

而下面这一行，代表的就是IAM PAGE所在的page id

Page @0x00000003F348C000

m_pageId = (3:9)

比较下data page 与 IAM Page 的不同：

DBCC PAGE (lenistest5, 3,8,3)

PAGE: (3:8)

BUFFER:

BUF @0x0000000484E53D80

bpage = 0x00000003F34AA000 bhash = 0x0000000000000000 bpageno = (3:8)

bdbid = 35 breferences = 0 bcputicks = 0

bsampleCount = 0 bUse1 = 16691 bstat = 0xb

blog = 0x212121cc bnext = 0x0000000000000000

PAGE HEADER:

Page @0x00000003F34AA000

m_pageId = (3:8) m_headerVersion = 1 m_type = 1

m_typeFlagBits = 0x0 m_level = 0 m_flagBits = 0x8000

m_objId (AllocUnitId.idObj) = 120 m_indexId (AllocUnitId.idInd) = 256

Metadata: AllocUnitId = 72057594045792256

Metadata: PartitionId = 72057594040549376 Metadata: IndexId = 0

Metadata: ObjectId = 245575913 m_prevPage = (0:0) m_nextPage = (0:0)

pminlen = 16 m_slotCnt = 1 m_freeCnt = 8075

m_freeData = 115 m_reservedCnt = 0 m_lsn = (35:193:28)

m_xactReserved = 0 m_xdesId = (0:0) m_ghostRecCnt = 0

m_tornBits = 0 DB Frag ID = 1

Allocation Status

GAM (3:2) = ALLOCATED SGAM (3:3) = ALLOCATED

PFS (3:1) = 0x61 MIXED_EXT ALLOCATED 50_PCT_FULL DIFF (3:6) = CHANGED

ML (3:7) = NOT MIN_LOGGED

Slot 0 Offset 0x60 Length 19

Record Type = PRIMARY_RECORD Record Attributes = NULL_BITMAP Record Size = 19

Memory Dump @0x000000001AF5A060

0000000000000000: 10001000 bb7d7701 10a60000 01000000 020000 ….?}w..|………

Slot 0 Column 1 Offset 0x4 Length 8 Length (physical) 8

transactionDate = 2016-05-24 22:47:07.290

Slot 0 Column 2 Offset 0xc Length 4 Length (physical) 4

amont = 1

这页存储的数据一目了然，而且数据类型，字节大小都明白的告诉我们了：

Slot 0 Column 1 Offset 0x4 Length 8 Length (physical) 8

transactionDate = 2016-05-24 22:47:07.290

Slot 0 Column 2 Offset 0xc Length 4 Length (physical) 4

amont = 1

到这里我们已经可以用脚本来归纳所有file group, data file,以及table ,index的对应关系了：利用 DBCC IND来获取整个数据库 表和索引的文件对应关系。还有一种方法，使用新增加的DMC来查询，这个DMV是 sys.dm_db_database_page_allocations.分清楚表和索引的存储关系，不仅仅是方便管理，更有利于性能的提高，表和索引分别存储在不同的硬盘驱动器上，有利于并行处理。

use lenistest4godeclare @tablename varchar(200)declare @index_Id intdeclare @sqlstatement nvarchar(max)declare @databasename varchar(200) =‘lenistest4‘declare cur_tables cursorfor (select schema_name(schema_id) +‘.‘+name as tableNamefrom sys.tables )open cur_tablesfetch next from cur_tables into @tablenameif exists( select 1 from tempdb.sys.tables where upper(name) like upper(‘%tempTabIndall%‘) )drop table #tempTabIndall ;create table #tempTabIndall(PageFID bigint, PagePID bigint, IAMFID bigint, IAMPID bigint, ObjectID bigint, IndexId bigint, PartitionNumber bigint, PartitionID bigint,iam_chain_type varchar(500) , PageType bigint, IndexLevel bigint, NextPageFID bigint, NextPagePID bigint,PrevPageFID bigint, PrevPagePID bigint)create index idx_pagefid on #tempTabIndall(PageFID) ;while @@FETCH_STATUS = 0begindeclare cur_indexes cursor for(select index_id from sys.indexes where object_id = object_id(@tablename))open cur_indexesfetch next from cur_indexes into @index_Idwhile @@FETCH_STATUS = 0beginset @sqlstatement = N‘insert into #tempTabIndallexec sp_executesql N‘‘DBCC IND(‘ + @databasename + ‘,‘‘‘‘‘+@tablename+‘‘‘‘‘,‘ + convert(varchar(max),@index_Id)+‘)‘‘‘ ;print @sqlstatementexec sp_executesql @sqlstatementfetch next from cur_indexes into @index_Idendclose cur_indexesdeallocate cur_indexesfetch next from cur_tables into @tablenameendclose cur_tablesdeallocate cur_tablesselect distinctobject_name(t.ObjectID) as tablename, t.IndexId, ti.name as IndexName, f.FileGroupName, f.Filegroup_type_description, f.DefaultFileGroup, f.datafile_type_description, f.fileName, f.file_physical_namefrom #tempTabIndall tinner join (select distinct object_id,index_id,name from sys.indexes) ti on t.ObjectID = ti.object_id and t.IndexId = ti.index_idleft join (selectisnull(data_file_id,0 ) as data_file_id, isnull(g.FileGroupName,‘LOG File Group‘) as FileGroupName, isnull(g.type_desc,‘LOG FILE GROUP‘) as Filegroup_type_description, isnull(g.is_default,0) as DefaultFileGroup, f.type_desc as datafile_type_description, f.name as fileName, f.physical_name as file_physical_name, f.state_desc as datafilestatus, f.size_mb as datafile_size_mb, f.max_size_mb as datafile_max_size_mbfrom (select name as FileGroupName,data_space_id,type_desc,is_defaultfrom sys.filegroups) gright outer join (selectfile_id as data_file_id,type_desc,data_space_id,name,physical_name,state_desc,size * 8 /1024 as size_mb,max_size * 8 /1024 as max_size_mbfrom sys.database_files) f on g.data_space_id = f.data_space_id)f on f.data_file_id = t.PageFIDorder by f.file_physical_name asc ,object_name(t.ObjectID) asc, t.IndexId asc

SQL Server Storage

标签：

小编还为您整理了以下内容，可能对您也有帮助：

如何解决SQLServer占内存过多的问题

我们需要准备的材料分别是：电脑。

1、在我的电脑中，搜索访问sql占用内存，在右侧的管理服务器中选择重新启动，重启一下IIS。

2、查看一下，sql服务仍然占用大量的内存，内存占用基本没有改变。

3、然后重启sql服务。

4、然后再重启一下sql代理。

5、最后再看一下任务管理器，就会发现内存占用量降低了。

VS2008安装失败！Microsoft Visual Studio Web 创作组件

解决方案一：找到Office 2007的安装文件

第一步：因为除Visual Studio本身以外，VS安装过程中安装的其他附带安装的组件，基本上都是有单独安装包的。先找到Visual Studio Web 创作组件的安装包，试试单独安装能不能成功。果然，在安装DVD的\WCU\WebDesignerCore文件夹中找到了“Visual Studio Web 创作组件”的安装程序。将其复制到硬盘上并解压缩，可以发现该组件使用的是Office 2007的安装方式，运行其中的setup.exe，出现与Office 2007相同的安装程序界面。单击“立即安装”，结果出现找不到office.zh-cn文件夹中文件的对话框，选择了安装程序所在的正确位置并确定，又再一次弹出同样的窗口，安装无法继续。

第二步：仔细核对文件名，确定安装文件夹中的确有需要的文件，但为什么还是提示找不到呢？

既然这个组件使用Office 2007的安装方式，文件夹中也有office.zh-cn这个和Office 2007共有的组件，那会不会是因为Office 2007的问题，导致Visual Studio Web 创作组件无法安装呢？

第三步：打开Vista中的“程序和功能”，选择Office 2007，并单击”更改“按钮，在弹出的安装程序界面中，选择”修复“，并继续，果然不出所料，这时也出现了同样的找不到安装文件的对话框，基本确定是因为Office 2007的问题导致Visual Studio 安装失败。

第四步：这时想起来，在安装Office时，安装程序默认情况下会将安装文件缓存在系统分区的隐藏文件夹MSOCache中，安装完成后并不会将其删除。由于这个文件夹实在是太大了，平常用Office其实并不需要它，因此安装完Office之后就手动将其删除了，而在修复Office组件时，需要访问MSOCache文件夹中的安装文件，所以就出现了以上问题。以往的经验是，已删除MSOCache文件夹时，可以放入Office原来的安装光盘，即可顺利修复。于是直接放入Office 2007的安装光盘，在弹出寻找文件的对话框时，指向安装盘中office.zh-cn文件夹所在的位置（一般是光驱根目录），Office 2007被成功修复，这时再安装Visual Studio Web 创作组件，也顺利的安装上了

第五步：接下来启动Visua Studio 2008安装程序，也顺利的安装，没有再遇到问题。安装完成后可以再次删除安装Visual Studio Web 创作组件时缓存下来的MSOCache文件夹（注意是隐藏文件夹）。

至此终于找到原因，原来是因为Office 2007的安装源缓存MSOCache文件夹被用户删除导致的。只要找到Office 2007的安装文件，即可顺利安装Visual Studio Web 创作组件。

最后还要考虑一个问题，为什么指向Visual Studio Web 创作组件安装程序中的office.zh-cn文件夹无法通过验证，而Office 2007安装盘中的office.zh-cn文件就可以呢？对比两个文件夹发现，其中只有OfficeLR.cab、officemui.msi、officemui.xml三个文件不同，而前两个主要文件，仅仅是数字签名日期不同。可能是由于系统中已经安装了Office 2007，而记录了这些安装程序的哈希值，安装程序只承认Office 2007的安装文件版本，而不接受其他的版本。

解决方案二：清理office2007

第一步：使用Windows Installer 清理实用工具，清理Microsoft Office system即可。

Windows Installer 清理实用工具下载地址：http://download.microsoft.com/download/e/9/d/e9d80355-7ab4-45b8-80e8-983a48d5e1bd/msicuu2.exe

第二步：清理有2007版office的bate版。

解决方案三：终结者（本人使用的方法，推荐哦）

据我个人经历，大概几天前吧，我试过了上述及网上其他一些乱起八糟的所有方法（可能是因为我电脑“中毒太深”，又安装过VC6.0，又安装过VS2005，还安装者office 2007），综合各方面因素考虑，与其网上四处搜罗解决方法，不如重装系统来的痛快，所以，解决方案三就是：终结者–系统重装。

在重新安装系统之后也要注意一点，首先，无可非议，office 2007应该最后安装，另外如果你要使用SQL Server 2005的话（VS2008默认安装是没安装它的），你得先安装SQL Server 2005，你可以理解成VS2008默认安装的只是SQL Server 2005的一个精简版本，所以在此提供两种方案供要使用SQL Server 2005的用户选择：

方案3.1：先单独安装SQL Server 2005,然后安装VS2008，记住，这里要自定义安装，把默认安装选项里的SQL Server 2005去掉，最后安装office 2007.

方案3.2：直接默认安装VS2008，然后到微软官方下载SQL Server Management Studio Express，具体地址可查看：http://www.microsoft.com/downloads/results.aspx?pocId=&freetext=Microsoft%20SQL%20Server%20Management%20Studio%20Express&DisplayLang=zh-cn

为何内存数据库姗姗来迟，SQL Server 2014新特性知多少

内存数据库

在传统的数据库表中，由于磁盘的物理结构，表和索引的结构为B-Tree，这就使得该类索引在大并发的OLTP环境中显得非常乏力，虽然有很多办法来解决这类问题，比如说乐观并发控制，应用程序缓存，分布式等。但成本依然会略高。而随着这些年硬件的发展，现在服务器拥有几百G内存并不罕见，此外由于NUMA架构的成熟，也消除了多CPU访问内存的瓶颈问题，因此内存数据库得以出现。

内存的学名叫做Random Access Memory（RAM），因此如其特性一样，是随机访问的，因此对于内存，对应的数据结构也会是Hash-Index，而并发的隔离方式也对应的变成了MVCC，因此内存数据库可以在同样的硬件资源下，Handle更多的并发和请求，并且不会被锁阻塞，而SQL Server 2014集成了这个强大的功能，并不像Oracle的TimesTen需要额外付费，因此结合SSD AS Buffer Pool特性，所产生的效果将会非常值得期待。

SQL Server内存数据库的表现形式

在SQL Server的Hekaton引擎由两部分组成：内存优化表和本地编译存储过程。虽然Hekaton集成进了关系数据库引擎，但访问他们的方法对于客户端是透明的，这也意味着从客户端应用程序的角度来看，并不会知道Hekaton引擎的存在。如图1所示