【IT168專稿】 談到GAM和SGAM,我們不得不從數(shù)據(jù)庫(kù)的頁(yè)和區(qū)說(shuō)起。一個(gè)數(shù)據(jù)庫(kù)由用戶定義的空間構(gòu)成,這些空間用來(lái)永久存儲(chǔ)用戶對(duì)象,例如數(shù)據(jù)庫(kù)管理信息、表和索引。這些空間被分配在一個(gè)或多個(gè) 操作系統(tǒng) 文件中。
當(dāng)我們創(chuàng)建一個(gè)數(shù)據(jù)庫(kù)的時(shí)候,例如以缺省的方式CREATE DATABASE TESTDB,SQLServer自動(dòng)幫我們創(chuàng)建好如下兩個(gè)數(shù)據(jù)庫(kù)文件。
?
這兩個(gè)數(shù)據(jù)文件是實(shí)實(shí)在在的 操作系統(tǒng) 文件,其中一個(gè)是叫行數(shù)據(jù)文件,用來(lái)存儲(chǔ)數(shù)據(jù)庫(kù)的各種對(duì)象,另外一個(gè)是日志文件,從來(lái)記錄數(shù)據(jù)變化的過(guò)程。
從邏輯角度而言,數(shù)據(jù)庫(kù)的最小存儲(chǔ)單位為頁(yè)即8kb。
數(shù)據(jù)庫(kù)被分成若干邏輯頁(yè)面(每個(gè)頁(yè)面8KB),并且在每個(gè)文件中,所有頁(yè)面都被連續(xù)地從0到x編號(hào),其中x是由文件的大小決定的。我們可以通過(guò)指定一個(gè)數(shù)據(jù)庫(kù)ID、一個(gè)文件ID、一個(gè)頁(yè)碼來(lái)引用任何一個(gè)數(shù)據(jù)頁(yè)。每個(gè)數(shù)據(jù)頁(yè)則用來(lái)存儲(chǔ)表和索引,以及相關(guān)的數(shù)據(jù)庫(kù)管理信息。
我們順著上面數(shù)據(jù)文件的路徑可以找到該文件,觀察一下新建的數(shù)據(jù)文件的大小為:
2.18 MB (2,293,760 字節(jié))=2,293,760b/8kb=280個(gè)頁(yè)面=35個(gè)區(qū)
數(shù)據(jù)庫(kù)進(jìn)行空間管理的最小單位為區(qū)(extents)。
一個(gè)區(qū)由8個(gè)邏輯上連續(xù)的頁(yè)面組成(64KB的空間)。為了能夠更有效地分配空間,SQL Server 2008不會(huì)為少量的數(shù)據(jù)向數(shù)據(jù)表分配整區(qū)的空間。SQL Server 2008有兩種類型的區(qū)。
統(tǒng)一類型的區(qū) 這些區(qū)為單個(gè)對(duì)象所有,區(qū)中所有的8個(gè)數(shù)據(jù)頁(yè)只能被所屬對(duì)象使用。
混合類型的區(qū) 這些區(qū)能為最多8個(gè)對(duì)象共享。
SQL Server為新的表或索引從混合類型的區(qū)中分配頁(yè)面。當(dāng)該表或索引增長(zhǎng)到8個(gè)頁(yè)面時(shí),以后所有的分配都使用統(tǒng)一類型的區(qū)。
當(dāng)一張表或一個(gè)索引需要更多的空間時(shí),SQL Server需要找到能夠用來(lái)分配的空間。如果該表或索引整體仍然少于8個(gè)頁(yè)面,SQL Server必須找到能夠用來(lái)分配的混合類型區(qū)構(gòu)成的空間。如果表或索引有8個(gè)頁(yè)面或更大,SQL Server必須找到一個(gè)自由的統(tǒng)一類型的區(qū)。
SQL Server使用兩種特殊類型的頁(yè)面來(lái)記錄哪些區(qū)已經(jīng)被分配出去了,哪些類型(混合類型或統(tǒng)一類型)的區(qū)可供使用:
全局分配映射(Global Allocation Map,GAM)頁(yè)面 這些頁(yè)面記錄了哪些區(qū)已經(jīng)被分配并用作何種用途。一個(gè)GAM頁(yè)面在它所覆蓋空間里針對(duì)每一個(gè)區(qū)都有一個(gè)數(shù)據(jù)位。如果數(shù)據(jù)位為0,那么對(duì)應(yīng)的區(qū)正在使用;如果該數(shù)據(jù)位為1,那么該區(qū)為自由區(qū)。一個(gè)GAM頁(yè)面除了頁(yè)面頭部和其他一些需要記入的開(kāi)銷大概有8 000字節(jié)或者說(shuō)64 000位空間可用,所以每個(gè)GAM頁(yè)面可以覆蓋64 000個(gè)區(qū),也就是大約4GB的數(shù)據(jù)。這意味著一個(gè)文件的每4GB空間對(duì)應(yīng)一個(gè)GAM頁(yè)面。
共享全局分配映射(Shared Global Allocation Map,SGAM)頁(yè)面 這些頁(yè)面記錄了哪些區(qū)當(dāng)前被用作混合類型的區(qū),并且這些區(qū)需含有至少一個(gè)未使用的頁(yè)面。就像一個(gè)GAM頁(yè)面,每一個(gè)SGAM頁(yè)面覆蓋了大約64 000個(gè)區(qū),也就是大約4GB的數(shù)據(jù)。一個(gè)SGAM頁(yè)面在它所覆蓋空間里針對(duì)每一個(gè)區(qū)都有一個(gè)數(shù)據(jù)位。如果數(shù)據(jù)位為1,那么對(duì)應(yīng)的被使用的區(qū)為混合類型,并且該區(qū)有一些自由頁(yè)面;如果數(shù)據(jù)位為0,那么對(duì)應(yīng)的區(qū)不是一個(gè)混合類型的區(qū),或者雖然是一個(gè)混合類型的區(qū),但是所有的頁(yè)面都已被使用了。
表4-2顯示了基于每一個(gè)區(qū)當(dāng)前的使用情況,在GAM和SGAM中該區(qū)所對(duì)應(yīng)的比特位模式。
區(qū)的當(dāng)前使用情況 | GAM比特位設(shè)置 | SGAM比特位設(shè)置 |
自由,未使用 | 1 | 0 |
統(tǒng)一類型或已全部使用的混合區(qū) | 0 | 0 |
含有自由頁(yè)面的混合區(qū) | 0 | 1 |
如果SQL Server需要找到一個(gè)新的完全沒(méi)有使用的區(qū),那么它可以使用任何一個(gè)在GAM頁(yè)面中對(duì)應(yīng)的比特位值為1的區(qū)。如果SQL Server需要找到一個(gè)有著可用空間(有一個(gè)或多個(gè)自由頁(yè)面)的混合類型的區(qū),那么它可以尋找一個(gè)對(duì)應(yīng)的GAM中的值為0、SGAM中的值為1的區(qū)。如果不存在有可用空間的混合類型的區(qū),SQL Server會(huì)使用GAM頁(yè)面來(lái)尋找一個(gè)全新的區(qū)并將其分配為混合類型的區(qū),然后使用該區(qū)中的一頁(yè)。如果根本沒(méi)有自由區(qū),那么這個(gè)文件已經(jīng)滿了。
第0頁(yè) | 第1頁(yè) | 第2頁(yè) | 第3頁(yè) | 第4頁(yè) | 第5頁(yè) | 第6頁(yè) | 第7頁(yè) |
m_type=15 | m_type=11 | m_type=8 | m_type=9 | m_type=0 | m_type=0 | m_type=16 | m_type=17 |
頭文件頁(yè) | PFS頁(yè) | GAM頁(yè) | SGAM頁(yè) | 保留頁(yè) | 保留頁(yè) | DCM頁(yè) | BCM頁(yè) |
SQL Server能夠迅速地鎖定一個(gè)文件中的GAM頁(yè)面,因?yàn)樗偸俏挥谌魏螖?shù)據(jù)庫(kù)文件的第三頁(yè)上(頁(yè)碼為2)。SGAM頁(yè)面是在第四頁(yè)上(頁(yè)碼為3)。下一個(gè)GAM頁(yè)面出現(xiàn)在第一個(gè)GAM頁(yè)面(頁(yè)碼為2)以后的每511 230個(gè)頁(yè)面中,并且下一個(gè)SGAM頁(yè)面出現(xiàn)在第一個(gè)SGAM頁(yè)面(頁(yè)碼為3)以后的每511 230個(gè)頁(yè)面中。每一個(gè)數(shù)據(jù)庫(kù)文件的頁(yè)碼為0的頁(yè)面是文件頭頁(yè)面,并且每個(gè)文件僅有一頁(yè)。頁(yè)碼0是頭文件頁(yè),頁(yè)碼1是頁(yè)面自由空間頁(yè)(Page Free Space,PFS)。
在SQLServer2008的每一個(gè)數(shù)據(jù)庫(kù)中的前八頁(yè)順序都是固定的。
除了第9頁(yè)為數(shù)據(jù)庫(kù)的BOOT頁(yè)以外,從第8頁(yè)到第173頁(yè)為SQLServer2008內(nèi)部系統(tǒng)表的相關(guān)存儲(chǔ)信息,然后從第174頁(yè)到第279頁(yè)為未分配頁(yè)面。因?yàn)榈谝豁?yè)從0開(kāi)始,所以剛好280頁(yè),即和我們看到的數(shù)據(jù)庫(kù)數(shù)據(jù)文件的大小完全相等。
第8頁(yè) | 第8頁(yè) | 第8頁(yè) | 第N頁(yè) | 第173頁(yè) | 第279頁(yè) |
m_type=1 | m_type=13 | m_type in (1,2,10) | N/A | ||
Data頁(yè) | Boot頁(yè) | 主要為內(nèi)部系統(tǒng)表相關(guān)信息 | 未分配 |
以下截圖是通過(guò)SQLServer2008的Internals Viewer插件看到的整體頁(yè)面結(jié)構(gòu),該插件是從http://www.SQLInernalsViewer.com網(wǎng)站下載的,分為不同的.net版本。
備注:TESTDB為新創(chuàng)建的空數(shù)據(jù)庫(kù),沒(méi)有任何用戶自定義對(duì)象,直到有建表腳本為止;
?
?
???????關(guān)于數(shù)據(jù)庫(kù)頁(yè)類型如下所示:
類型 | 頁(yè)面類型名稱 | 頁(yè)面類型描述 |
1 | Data page | 堆表和聚集索引的葉子節(jié)點(diǎn)數(shù)據(jù) |
2 | Index page | 聚集索引的非葉子節(jié)點(diǎn)和非聚集索引的所有索引記錄 |
3 | Text mixed page | A text page that holds small chunks of LOB values plus internal parts of text tree. These can be shared between LOB values in the same partition of an index or heap. |
4 | Text tree page | A text page that holds large chunks of LOB values from a single column value. |
7 | Sort page | 排序時(shí)所用到的臨時(shí)頁(yè),排序中間操作存儲(chǔ)數(shù)據(jù)用的。 |
8 | GAM page | 全局分配映射(Global Allocation Map,GAM)頁(yè)面 這些頁(yè)面記錄了哪些區(qū)已經(jīng)被分配并用作何種用途。 |
9 | SGAM page | 共享全局分配映射(Shared Global Allocation Map,GAM)頁(yè)面 這些頁(yè)面記錄了哪些區(qū)當(dāng)前被用作混合類型的區(qū),并且這些區(qū)需含有至少一個(gè)未使用的頁(yè)面。 |
10 | IAM page. | 有關(guān)每個(gè)分配單元中表或索引所使用的區(qū)的信息 |
11 | PFS page. | 有關(guān)頁(yè)分配和頁(yè)的可用空間的信息 |
13 | boot page. | 記錄了關(guān)于數(shù)據(jù)庫(kù)的信息,僅存于每個(gè)數(shù)據(jù)庫(kù)的第9頁(yè) |
15 | file header page | 記錄了關(guān)于數(shù)據(jù)庫(kù)文件的信息,存于每個(gè)數(shù)據(jù)庫(kù)文件的第0頁(yè) |
16 | DCM page | 記錄自從上次全備以來(lái)的數(shù)據(jù)改變的頁(yè)面,以備差異備份 |
17 | BCM page | 有關(guān)每個(gè)分配單元中自最后一條 BACKUP LOG 語(yǔ)句之后的大容量操作所修改的區(qū)的信息 |
實(shí)際上SQLServer還包括一些未公開(kāi)的頁(yè)面類型,例如type 19,type 14等等。
本章我們主要介紹GAM頁(yè)和SGAM頁(yè),其他頁(yè)面類型會(huì)稍后介紹。
那么如何查看頁(yè)面信息呢,從SQLServer2000起便開(kāi)始提供了一個(gè)讀取數(shù)據(jù)頁(yè)結(jié)構(gòu)的命令DBCC Page。該命令為非文檔化的命令,具體如下:
DBCC Page ({dbid|dbname},filenum,pagenum[,printopt])
具體參數(shù)描述如下:
dbid?????????????? 包含頁(yè)面的數(shù)據(jù)庫(kù)ID
dbname?????? 包含頁(yè)面的數(shù)據(jù)庫(kù)的名稱
filenum???????? 包含頁(yè)面的文件編號(hào)
pagenum????? 文件內(nèi)的頁(yè)面
printopt??????????? 可選的輸出選項(xiàng);選用其中一個(gè)值:
????????????????????????? 0:默認(rèn)值,輸出緩沖區(qū)的標(biāo)題和頁(yè)面標(biāo)題
???????????????????????? 1:輸出緩沖區(qū)的標(biāo)題、頁(yè)面標(biāo)題(分別輸出每一行),以及行偏移量表
???????????????????????? 2:輸出緩沖區(qū)的標(biāo)題、頁(yè)面標(biāo)題(整體輸出頁(yè)面),以及行偏移量表
?????????????????????????3:輸出緩沖區(qū)的標(biāo)題、頁(yè)面標(biāo)題(分別輸出每一行),以及行偏移量表;每一行后跟分別列出的它的列值
如果要想看到這些輸出的結(jié)果,還需要設(shè)置DBCC TRACEON(3604)。
如前文所述,GAM頁(yè)一定存在于該數(shù)據(jù)庫(kù)的第二個(gè)頁(yè)面,SGAM頁(yè)則一定存在于該數(shù)據(jù)庫(kù)的第三個(gè)頁(yè)面;而每一個(gè)數(shù)據(jù)庫(kù)都會(huì)存在文件編號(hào)為1的數(shù)據(jù)庫(kù)文件,所以我們執(zhí)行以下命令即可。
- DBCC?TRACEON(3604)??
- DBCC?PAGE(TESTDB,1,2,1)??—查看GAM頁(yè)信息??
- DBCC?PAGE(TESTDB,1,3,1)??—查看SGAM頁(yè)信息??
- DBCC?PAGE(TESTDB,1,2,2)??—查看GAM頁(yè)信息和整體輸出頁(yè)面??
- DBCC?PAGE(TESTDB,1,3,2)??—查看SGAM頁(yè)信息和整體輸出頁(yè)面??
- DBCC?PAGE(TESTDB,1,2,3)??—查看GAM頁(yè)信息及相應(yīng)列值??
- DBCC?PAGE(TESTDB,1,3,3)??—查看SGAM頁(yè)信息及相應(yīng)列值??
- DBCC?PAGE(TESTDB,1,2,1)?WITH?TABLERESULTS??—以表格形式查看SGAM頁(yè)信息及相應(yīng)列值??
- DBCC?PAGE(TESTDB,1,3,1)?WITH?TABLERESULTS??—以表格形式查看SGAM頁(yè)信息及相應(yīng)列值??
?
我們可以看到一個(gè)完整的頁(yè)面分為四個(gè)部分;BUFFER、PAGE HEADER、DATA和OFFSET TABLE。
讓我們首先從GAM頁(yè)開(kāi)始看起:
BUFFER部分:
顯示給定頁(yè)面的緩沖信息,是
內(nèi)存
中的結(jié)構(gòu),用于管理頁(yè)面,該信息僅當(dāng)該頁(yè)面處于
內(nèi)存
時(shí)才有意義。關(guān)于這個(gè)部分我們知之甚少,基本上無(wú)法找到相關(guān)材料。
BUF @0x03585CD8 | 每一次清空緩存再次查詢,地址都會(huì)改變 |
bpage = 0x060B4000 | 每一次清空緩存再次查詢,地址都會(huì)改變 |
bhash = 0x00000000 | 相對(duì)不變 |
bpageno = (1:2) | 當(dāng)前頁(yè)面地址 |
bdbid = 8 | sys.databases.database_id |
breferences = 1 | 每一次清空緩存再次查詢,地址都會(huì)改變 |
bUse1 = 41490 | 每一次清空緩存再次查詢,地址都會(huì)改變 |
bstat = 0xc00009 | 相對(duì)不變 |
blog = 0x59ca2159 | 相對(duì)不變 |
bnext = 0x00000000 | 相對(duì)不變 |
PAGE HEADER部分:
PAGE HEADER部分顯示的是該頁(yè)面上的所有報(bào)頭字段的數(shù)據(jù)
?
PAGE HEADER這部分內(nèi)容只有通過(guò)DBCC PAGE(TESTDB,1,2,2)即整體輸出頁(yè)面才能夠展現(xiàn);通過(guò)與上面表格的對(duì)照,我們勉強(qiáng)能識(shí)別一些相關(guān)存儲(chǔ)信息;當(dāng)這部分缺乏官方文檔的支持,為了避免無(wú)謂的猜測(cè),所以暫時(shí)就不做深入探討了。
?
DATA 部分
?
? DATA部分一般分為若干插槽號(hào)(Slot),如果是數(shù)據(jù)頁(yè)或索引頁(yè)的話,可以理解為一行記錄,SQLServer通過(guò)文件號(hào)+頁(yè)面號(hào)+插槽號(hào)用來(lái)唯一標(biāo)識(shí)表中的每一條記錄。但在GAM頁(yè)中我們可以把Slot 0理解為GAM頁(yè)的保留頁(yè),共計(jì)94個(gè)字節(jié)。
從第194個(gè)字節(jié)開(kāi)始(頁(yè)面總是從第0個(gè)字節(jié)開(kāi)始的),到第196個(gè)字節(jié),這三個(gè)字節(jié)代表已分配的分區(qū)的情況。即0000C0。
我們?cè)賮?lái)看一下DBCC PAGE(TESTDB,1,2,3)的執(zhí)行結(jié)果。
?
上面顯示從第1頁(yè)到第168頁(yè)已分配,而第176頁(yè)到272頁(yè)未分配,和DBCC PAGE(TESTDB,1,2,2)顯示的194個(gè)頁(yè)面似乎有些矛盾,實(shí)際上是不矛盾的。如前文所述,GAM對(duì)未使用的分區(qū)標(biāo)識(shí)為0,而對(duì)已分配的分區(qū)標(biāo)識(shí)為1
1個(gè)分區(qū)=64頁(yè),因?yàn)榍?28個(gè)頁(yè)面均已分配,所以前兩個(gè)字節(jié)為00 00
從第128個(gè)頁(yè)面起到第175個(gè)頁(yè)面也均已分配,實(shí)際上為6個(gè)區(qū)為0也就是說(shuō)連續(xù)6個(gè)bit為0,一個(gè)字節(jié)為8個(gè)bit,最后兩個(gè)bit為11,所以該字節(jié)為0000 0011,在此需要反轉(zhuǎn)一下相關(guān)二進(jìn)制位;反轉(zhuǎn)之后為1100 0000即為C0。
最后讓我們用Internals Viewer插件看一下GAM頁(yè)的全貌吧。
?
SGAM頁(yè)面
BUFFER:
BUF @0x0358A7F4
bpage = 0x062AE000???????????? bhash = 0x00000000??????????????bpageno = (1:3)
bdbid = 8??????????????????????breferences = 3?????????????????????? bUse1 = 14428
bstat = 0xc00009?????????????? blog = 0x21212159??????????????bnext = 0x00000000
???????????????????????????????????????????????????????????????
PAGE HEADER:???????????????????????????????????????????????????
Page @0x062AE000???????????????????????????????????????????????
m_pageId = (1:3)?????????????? m_headerVersion = 1???????????? m_type = 9
m_typeFlagBits = 0x0?????????? m_level = 0???????????????????? m_flagBits = 0x200
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 = 90
m_slotCnt = 2??????????????????m_freeCnt = 6?????????????????? m_freeData = 8182
m_reservedCnt = 0??????????????m_lsn = (18:435:5)??????????????m_xactReserved = 0
m_xdesId = (0:0)?????????????? m_ghostRecCnt = 0?????????????? m_tornBits = 177043542
Allocation Status??????????????
GAM (1:2)=ALLOCATED????????????SGAM (1:3)=NOT ALLOCATED??????????PFS(1:1)=0x44 ALLOCATED 100_PCT_FULL
DIFF (1:6) = CHANGED?????????? ML (1:7) = NOT MIN_LOGGED?????????
DATA:
Slot 0, Offset 0x60, Length 94, DumpStyle BYTE
Record Type = PRIMARY_RECORD???????? Record Attributes =??????????????????
Memory Dump @0x4F32C060
00000000:?? 00005e00 00000000 00000000 00000000 ?..^.............?????????
00000010:?? 00000000 00000000 00000000 00000000 ?................?????????
00000020:?? 00000000 00000000 00000000 00000000 ?................?????????
00000030:?? 00000000 00000000 00000000 00000000 ?................?????????
00000040:?? 00000000 00000000 00000000 00000000 ?................?????????
00000050:?? 00000000 00000000 00000000 0000??????..............???????????
Slot 1, Offset 0xbe, Length 7992, DumpStyle BYTE
Record Type = PRIMARY_RECORD???????? Record Attributes =??????????????????
Memory Dump @0x4F32C0BE
00000000:?? 0000381f 20ee2000 00000000 00000000 ?..8. . .........?????????
00000010:?? 00000000 00000000 00000000 00000000 ?................?
00001F30:?? 00000000 00000000 ???????????????????........???????????
?
? 以下為DBCC PAGE(TESTDB,1,3,3)得到的相關(guān)信息,有興趣的可以和20ee20做一下對(duì)比。
(1:40)?????? -??????????????=???? ALLOCATED???????????????????????????????
(1:48)?????? - (1:64)?????? = NOT ALLOCATED???????????????????????????????
(1:72)?????? - (1:88)?????? =???? ALLOCATED???????????????????????????????
(1:96)?????? -??????????????= NOT ALLOCATED???????????????????????????????
(1:104)??????- (1:120)??????=???? ALLOCATED???????????????????????????????
(1:128)??????- (1:160)??????= NOT ALLOCATED???????????????????????????????
(1:168)??????-??????????????=???? ALLOCATED???????????????????????????????
(1:176)??????- (1:272)??????= NOT ALLOCATED
?
最后讓我們用Internals Viewer插件看一下SGAM頁(yè)的全貌吧。
?
總結(jié)一下,關(guān)于GAM和SGAM頁(yè)比較困難的地方:
1、 關(guān)于GAM和SGAM頁(yè)中的BUFFER信息基本無(wú)法理解,也找不到相關(guān)材料。
2、 PAGE HEADER的部分信息和Slot 0中的一部分信息,也無(wú)法找到相關(guān)材料。
3、 SGAM頁(yè)中的NOT ALLOCATED實(shí)際上是統(tǒng)一類型區(qū)或者已使用完的混合類型的區(qū),而ALLOCATED實(shí)際上為含有自由頁(yè)面的混合區(qū)。
4、 GAM頁(yè)中0代表已分配,1代表自由區(qū);和一般的標(biāo)志位的含義剛好相反。
5、 GAM和SGAM實(shí)際上只分配了280個(gè)頁(yè)面,即35個(gè)區(qū);顯示出來(lái)的數(shù)據(jù)內(nèi)容雖然很多,但后面的分區(qū)信息實(shí)際上是不存在的。
6、 GAM和SGAM通過(guò)DBCC的printopt為3的屬性顯示出來(lái)的頁(yè)面分配信息看似是斷號(hào)的。
7、 GAM和SGAM的區(qū)信息的字節(jié)是通過(guò)二級(jí)制反轉(zhuǎn)得到的。
GAM和SGAM頁(yè)的總的大小為8192個(gè)字節(jié);文件頭為96個(gè)字節(jié),slot 0為94個(gè)字節(jié),slot 1的頭部的系統(tǒng)信息為4個(gè)字節(jié),尾部的系統(tǒng)信息為10個(gè)字節(jié),所以有效存儲(chǔ)應(yīng)為7988個(gè)字節(jié),63904個(gè)區(qū),511230個(gè)頁(yè);事實(shí)上當(dāng)數(shù)據(jù)文件超過(guò)約4G的時(shí)候,我們將能在第511232頁(yè)、 第511233頁(yè)分別找到其對(duì)應(yīng)的GAM、SGAM頁(yè)面。
更多文章、技術(shù)交流、商務(wù)合作、聯(lián)系博主
微信掃碼或搜索:z360901061

微信掃一掃加我為好友
QQ號(hào)聯(lián)系: 360901061
您的支持是博主寫(xiě)作最大的動(dòng)力,如果您喜歡我的文章,感覺(jué)我的文章對(duì)您有幫助,請(qǐng)用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧,狠狠點(diǎn)擊下面給點(diǎn)支持吧,站長(zhǎng)非常感激您!手機(jī)微信長(zhǎng)按不能支付解決辦法:請(qǐng)將微信支付二維碼保存到相冊(cè),切換到微信,然后點(diǎn)擊微信右上角掃一掃功能,選擇支付二維碼完成支付。
【本文對(duì)您有幫助就好】元
