BUG #: 20010946 (SQLBUDT)
網(wǎng)站建設(shè)哪家好，找成都創(chuàng)新互聯(lián)！專注于網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開(kāi)發(fā)、小程序開(kāi)發(fā)、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項(xiàng)目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了五指山免費(fèi)建站歡迎大家使用！
癥狀
在 Microsoft SQL Server 2005 中運(yùn)行 DBCC 檢查命令時(shí), 您可能會(huì)收到類似于以下的錯(cuò)誤信息：
8909 16 1
表錯(cuò)誤: 對(duì)象 ID 0，索引 ID-1，0，分區(qū) ID 分配單元 ID 0
(類型未知)，頁(yè)標(biāo)識(shí) (6:8040) 包含它的頁(yè)面頁(yè)眉中不正確的頁(yè) ID。 中的 PageId
頁(yè)標(biāo)題 = （0： 0）。
對(duì)于存儲(chǔ)在一個(gè) NTFS 文件系統(tǒng)分區(qū)的數(shù)據(jù)庫(kù)運(yùn)行 DBCC 檢查命令 NTFS 分區(qū)處于 MULTI-USER 模式時(shí)，SQL Server 數(shù)據(jù)庫(kù)引擎創(chuàng)建的內(nèi)部、 只讀數(shù)據(jù)庫(kù)快照。 此行為會(huì)阻止運(yùn)行 DBCC 檢查命令時(shí)，正在阻塞的問(wèn)題和并發(fā)問(wèn)題。對(duì)數(shù)據(jù)庫(kù)快照使用一個(gè)或多個(gè)稀疏文件來(lái)存儲(chǔ)數(shù)據(jù)。
滿足以下條件時(shí)發(fā)生此問(wèn)題：
? SQL Server 頁(yè)已寫入稀疏文件。
? 這些稀疏文件用于為 DBCC 副本和數(shù)據(jù)庫(kù)快照。
? 這些稀疏文件是丟失。
因?yàn)橄∈栉募G失，SQL Server 在運(yùn)行 DBCC 檢查命令時(shí)讀取這些網(wǎng)頁(yè)上的零的數(shù)據(jù)。
注意 此行為可能導(dǎo)致一個(gè) false 未能在運(yùn)行 DBCC 時(shí)出現(xiàn)檢查命令。 由于 DBCC 檢查命令操作的內(nèi)部、 只讀數(shù)據(jù)庫(kù)快照，命令不表示指示已損壞數(shù)據(jù)庫(kù)本身。 命令僅指示有是內(nèi)部、 只讀數(shù)據(jù)庫(kù)快照有問(wèn)題。
回到頂端
原因
由于爭(zhēng)用條件的可能會(huì)發(fā)生此問(wèn)題。 在 NTFS 稀疏文件的異步非緩存的寫入操作發(fā)生爭(zhēng)用條件。
回到頂端
更多信息
當(dāng)頁(yè) ID 為 0： 0，可能還會(huì)出現(xiàn)錯(cuò)誤消息類似于以下：
錯(cuò)誤: 824，Severity： 24，狀態(tài)： 2 SQL Server 檢測(cè)到一個(gè)邏輯基于一致性的 I / O 錯(cuò)誤： 不正確的 pageid (預(yù)期的 30:62 ； 實(shí)際 0： 0）。
1.稀疏列是用在可空列上的，用于減少null值的空間占用，使用關(guān)鍵字sparse
2.創(chuàng)建稀疏列
使用sql創(chuàng)建表的時(shí)候，就指定稀疏列，使用下面的SQL語(yǔ)句：
create table SparseTable(
Id varchar(36) not null, -- 主鍵 GUID
Addr1 varchar(200) null, -- 地址1
Addr2 varchar(200) null, -- 地址2
Addr3 varchar(200) sparse null, -- 地址3，當(dāng)這個(gè)列很少會(huì)有數(shù)據(jù)時(shí)，可以設(shè)為稀疏列
);
3.查看稀疏列
在創(chuàng)建好的表上面點(diǎn)擊鼠標(biāo)右鍵，選擇【設(shè)計(jì)】，在新出現(xiàn)的界面中選中Addr3列，在下面就可以看到稀疏列標(biāo)記了
4.插入測(cè)試數(shù)據(jù)
往表中插入幾行測(cè)試數(shù)據(jù)，其中，在一些行的稀疏列不插入值
5.查詢數(shù)據(jù)
使用select查詢表中所有數(shù)據(jù)，可以看到稀疏列與普通列沒(méi)什么區(qū)別的樣子
6.修改數(shù)據(jù)
使用update語(yǔ)句，將稀疏列的值全部設(shè)置為null，然后使用select查詢所有數(shù)據(jù)，在sqlserver2016版本中，稀疏列也是返回過(guò)來(lái)的。在sqlserver2008版本中，稀疏列使用select *的時(shí)候是不返回的
7.刪除數(shù)據(jù)
使用delete語(yǔ)句刪除一行記錄，從過(guò)程可以看出，是否含有稀疏列的delete語(yǔ)句都是一樣的
隨著機(jī)器學(xué)習(xí)的發(fā)展，過(guò)去傳統(tǒng)的結(jié)構(gòu)化數(shù)據(jù)分析方法已經(jīng)不能滿足我們的需求了。如何在神經(jīng)網(wǎng)絡(luò)中利用非結(jié)構(gòu)化數(shù)據(jù)是很重要的一點(diǎn)。所以很多研究者致力于將非結(jié)構(gòu)化數(shù)據(jù)處理成結(jié)構(gòu)化數(shù)據(jù)的工具開(kāi)發(fā)。將非結(jié)構(gòu)化數(shù)據(jù)轉(zhuǎn)化為結(jié)構(gòu)化數(shù)據(jù)有以下幾個(gè)方法：
1. 傳統(tǒng)方法——樹(shù)
雖然絕大多數(shù)數(shù)據(jù)是非結(jié)構(gòu)化格式的，但是結(jié)構(gòu)化數(shù)據(jù)普遍存在于各類商業(yè)應(yīng)用軟件和系統(tǒng)中，例如產(chǎn)品數(shù)據(jù)存儲(chǔ)，交易日志，ERP和CRM 系統(tǒng)中都存在大量結(jié)構(gòu)化數(shù)據(jù)，這些結(jié)構(gòu)化數(shù)據(jù)仍應(yīng)用著陳舊的數(shù)據(jù)技術(shù)處理，如基于規(guī)則的系統(tǒng)，決策樹(shù)等。這樣的方法需要人工進(jìn)行特征提取，操作繁瑣且需要耗費(fèi)大量人力進(jìn)行數(shù)據(jù)標(biāo)簽。
非結(jié)構(gòu)化數(shù)據(jù)，也就是通常使用的雜亂無(wú)章的文本數(shù)據(jù)。非結(jié)構(gòu)化數(shù)據(jù)通常是不能用結(jié)構(gòu)化數(shù)據(jù)的常規(guī)方法以傳統(tǒng)方式進(jìn)行分析或處理的，所以這也成為AI領(lǐng)域一個(gè)常見(jiàn)的難題，要理解非結(jié)構(gòu)化數(shù)據(jù)通常需要輸入整段文字，以識(shí)別其潛在的特征，然后查看這些特征是否出現(xiàn)在池中的其他文本中。因此，在處理此類任務(wù)時(shí)，深度學(xué)習(xí)以其出色的特征提取能力一騎絕塵，于是所有人都開(kāi)始想著把神經(jīng)網(wǎng)絡(luò)用在結(jié)構(gòu)化數(shù)據(jù)上——建個(gè)全連接層，把每一列的內(nèi)容作為輸入，再有一個(gè)確定好的標(biāo)簽，就可以進(jìn)行訓(xùn)練和推理了。
2. 新型利器——深度學(xué)習(xí)
需要尋找結(jié)構(gòu)化數(shù)據(jù)的語(yǔ)義，目前要解決的問(wèn)題主要有：
①數(shù)據(jù)清洗。要在結(jié)構(gòu)化數(shù)據(jù) AI 應(yīng)用上有所成果，首先需要解決人工數(shù)據(jù)清洗和準(zhǔn)備的問(wèn)題，找到極少或者沒(méi)有人為干預(yù)的自動(dòng)化方法，才能使得這一應(yīng)用可落地可拓展。
②異構(gòu)數(shù)據(jù)。處理結(jié)構(gòu)化數(shù)據(jù)的其中一大挑戰(zhàn)在于，結(jié)構(gòu)化數(shù)據(jù)可能是異構(gòu)的，同時(shí)組合了不同類型的數(shù)據(jù)結(jié)構(gòu)，例如文本數(shù)據(jù)、定類數(shù)據(jù)、數(shù)字甚至圖像數(shù)據(jù)。其次，數(shù)據(jù)表有可能非常稀疏。想象一個(gè) 100 列的表格，每列都有 10 到 1000 個(gè)可能值（例如制造商的類型，大小，價(jià)格等），行則有幾百萬(wàn)行。由于只有一小部分列值的組合有意義，可以想象，這個(gè)表格可能的組合空間有多么「空」。
③語(yǔ)義理解。找到這些結(jié)構(gòu)化數(shù)據(jù)的語(yǔ)義特征。處理結(jié)構(gòu)化數(shù)據(jù)并不僅僅依賴于數(shù)據(jù)本身的特征 (稀疏，異構(gòu)，豐富的語(yǔ)義和領(lǐng)域知識(shí)），數(shù)據(jù)表集合 (列名，字段類型，域和各種完整性約束等）可以解碼各數(shù)據(jù)塊之間的語(yǔ)義和可能存在的交互的重要信息。也就是說(shuō)，存儲(chǔ)在數(shù)據(jù)庫(kù)表中的信息具有強(qiáng)大的底層結(jié)構(gòu)，而現(xiàn)有的語(yǔ)言模型（例如 BERT）僅受過(guò)訓(xùn)練以編碼自由格式的文本。
3. 結(jié)構(gòu)化數(shù)據(jù)清洗
除了某些特定的需求外，經(jīng)過(guò)預(yù)處理之后的結(jié)構(gòu)化數(shù)據(jù)，應(yīng)該滿足以下特點(diǎn)：
①所有值都是數(shù)字–機(jī)器學(xué)習(xí)算法取決于所有數(shù)據(jù)都是數(shù)字；
②非數(shù)字值（在類別或文本列中的內(nèi)容）需要替換為數(shù)字標(biāo)識(shí)符；
③標(biāo)識(shí)并清除具有無(wú)效值的記錄；
④識(shí)別并消除了無(wú)關(guān)的類別；
⑤所有記錄都需要使用相同的一致類別。
在SQL Server 2005中，它的另外一個(gè)強(qiáng)大的新特點(diǎn)是數(shù)據(jù)庫(kù)快照。數(shù)據(jù)庫(kù)快照是一個(gè)數(shù)據(jù)庫(kù)的只讀副本，它是數(shù)據(jù)庫(kù)所有數(shù)據(jù)的映射，由快照被執(zhí)行的時(shí)間點(diǎn)來(lái)決定它的內(nèi)容。
這些數(shù)據(jù)庫(kù)快照在報(bào)表方面是非常有價(jià)值，因?yàn)樵诳煺諗?shù)據(jù)庫(kù)中或者在原數(shù)據(jù)庫(kù)中，對(duì)于任何查詢而言沒(méi)有鎖就將被執(zhí)行?？煺找部梢允褂迷跒?zāi)難恢復(fù)中，因?yàn)槟憧梢詫F(xiàn)有的數(shù)據(jù)恢復(fù)到現(xiàn)有的快照中，或者還可以在有害數(shù)據(jù)操作聲明的事件中存儲(chǔ)個(gè)別必要的表和數(shù)據(jù)。
數(shù)據(jù)庫(kù)快照是如何工作的?
可以使用典型的數(shù)據(jù)庫(kù)命令CREATE DATABASE語(yǔ)句來(lái)生成一個(gè)數(shù)據(jù)庫(kù)快照，在聲明中有一個(gè)源數(shù)據(jù)庫(kù)快照的附加說(shuō)明。當(dāng)快照被建立時(shí)，同時(shí)生成一個(gè)稀疏文件。這個(gè)文件（只能使用在NTFS卷中）在初始化的時(shí)候并沒(méi)有磁盤空間分配給它——盡管你可能在WINDOWS資源管理器中看到了文件的大小，它會(huì)看上去與原始的源數(shù)據(jù)庫(kù)文件的大小相同。對(duì)磁盤來(lái)說(shuō)其實(shí)這個(gè)文件的大小接近于零。
數(shù)據(jù)庫(kù)快照在初始化時(shí)讀的數(shù)據(jù)文件是來(lái)自于源數(shù)據(jù)庫(kù)的。當(dāng)源數(shù)據(jù)庫(kù)的數(shù)據(jù)發(fā)生變化時(shí)，數(shù)據(jù)引擎就會(huì)將原始數(shù)據(jù)從源數(shù)據(jù)庫(kù)拷貝到快照數(shù)據(jù)庫(kù)中。這個(gè)技術(shù)確?？煺諗?shù)據(jù)庫(kù)只反映快照被執(zhí)行時(shí)數(shù)據(jù)的狀態(tài)。當(dāng)SELECT命令被用來(lái)發(fā)布反對(duì)數(shù)據(jù)庫(kù)快照時(shí)，不管數(shù)據(jù)頁(yè)的讀取是否被定位在源數(shù)據(jù)庫(kù)數(shù)據(jù)文件中還是在快照數(shù)據(jù)庫(kù)數(shù)據(jù)文件中都是沒(méi)有鎖被發(fā)布的。因?yàn)樵谥蛔x數(shù)據(jù)庫(kù)快照中是沒(méi)有鎖被發(fā)布，數(shù)據(jù)庫(kù)快照對(duì)于報(bào)表解決方案是一個(gè)重要的解決方案。
一個(gè)快照的實(shí)例
現(xiàn)在，讓我們來(lái)看看數(shù)據(jù)庫(kù)快照在SQL Server 2005中是如何工作的。為此，首先我需要一個(gè)源數(shù)據(jù)庫(kù)作為快照的來(lái)源。下面的腳本將創(chuàng)建一個(gè)源數(shù)據(jù)庫(kù)：
以下為引用的內(nèi)容：
USE master
GO
IF EXISTS(SELECT name from sysdatabases where [name] = 'SourceDatabase')
DROP DATABASE SourceDatabase
GO
CREATE DATABASE SourceDatabaseON PRIMARY
(
NAME = SourceDatabase_Data,
FILENAME = 'C:SQLServerSourceDatabase_Data.mdf'
) LOG ON
(
NAME = SourceDatabase_Log,
FILENAME = 'C:SQLServerSourceDatabase_Log.ldf'
)
GO
注意這里產(chǎn)品區(qū)域的大小。我定義它的大小為CHAR（150）來(lái)強(qiáng)調(diào)數(shù)據(jù)文件的增長(zhǎng)級(jí)數(shù)，這樣在我接下來(lái)的實(shí)例中將更容易解釋清楚快照是如何工作的。
現(xiàn)在既然我已經(jīng)有了一個(gè)源數(shù)據(jù)庫(kù)，現(xiàn)在我裝載一些數(shù)據(jù)來(lái)擴(kuò)展數(shù)據(jù)文件的大小位。如此，使用列表1中的腳本來(lái)創(chuàng)建銷售歷史表。
以下為引用的內(nèi)容：
USE SourceDatabase
GO
IF OBJECT_ID('SalesHistory')0 DROP TABLE SalesHistory
GO
CREATE TABLE SalesHistory
( SaleID INT IDENTITY(1,1),
Product CHAR(150), SaleDate DATETIME,
SalePrice MONEY
)
DECLARE @i INT
SET @i = 1
WHILE (@i =10000)
BEGIN INSERT INTO SalesHistory (Product, SaleDate, SalePrice)
VALUES ('Computer', DATEADD(mm, @i, '3/11/1919'),
DATEPART(ms, GETDATE()) + (@i + 57) )
INSERT INTO SalesHistory (Product, SaleDate, SalePrice)
VALUES ('BigScreen', DATEADD(mm, @i, '3/11/1927'),
DATEPART(ms, GETDATE()) + (@i + 13) )
INSERT INTO SalesHistory (Product, SaleDate, SalePrice)
VALUES ('PoolTable', DATEADD(mm, @i, '3/11/1908'),
DATEPART(ms, GETDATE()) + (@i + 29) )
SET @i = @i + 1
END
GO
數(shù)據(jù)庫(kù)快照為你現(xiàn)有的數(shù)據(jù)庫(kù)創(chuàng)建了一個(gè)數(shù)據(jù)庫(kù)的殼，然后無(wú)論何時(shí)當(dāng)數(shù)據(jù)頁(yè)被修改的時(shí)候，改變也同時(shí)被寫入稀疏文件(sparse file)當(dāng)中。當(dāng)人們獲取數(shù)據(jù)的時(shí)候，數(shù)據(jù)中沒(méi)有變化的部分是從原始數(shù)據(jù)庫(kù)中得到的，而改變的部分則是從稀疏文件中獲得。
稀疏文件和數(shù)據(jù)庫(kù)快照
當(dāng)數(shù)據(jù)庫(kù)快照被創(chuàng)建的時(shí)候，第一次的創(chuàng)建是十分迅速的。因?yàn)閷?shí)際上只是創(chuàng)建了一個(gè)用來(lái)記錄被修改文件的殼。隨著時(shí)間的推移，文件不斷的被修改，這些修改頁(yè)都將被寫進(jìn)稀疏文件。你的主數(shù)據(jù)庫(kù)中修改的文件越多，就有越多的文件被寫入稀疏文件。因此，有越來(lái)越多的磁盤空間被用來(lái)保存你的主數(shù)據(jù)庫(kù)和快照的數(shù)據(jù)庫(kù)，也增加了你服務(wù)器的磁盤輸入輸出的次數(shù)。
稀疏文件被寫入大小為64KB的分組塊當(dāng)中。每一個(gè)分組塊增量能包含8個(gè)大小為8KB的數(shù)據(jù)頁(yè)。所以，每次在你的主數(shù)據(jù)庫(kù)中有任何的數(shù)據(jù)改變，都會(huì)先把數(shù)據(jù)頁(yè)拷貝到稀疏文件當(dāng)中，然后再將主數(shù)據(jù)庫(kù)中文件的變化寫入稀疏文件。一旦數(shù)據(jù)頁(yè)被寫入稀疏文件，他們就不再需要被寫出來(lái)。因?yàn)轫?yè)面的全部?jī)?nèi)容被保護(hù)起來(lái)，讓其處于當(dāng)快照建立時(shí)的狀態(tài)。
為了實(shí)現(xiàn)優(yōu)化磁盤并消除磁盤沖突，在主數(shù)據(jù)庫(kù)以外的獨(dú)立的驅(qū)動(dòng)器和陣列中創(chuàng)建稀疏文件是一個(gè)明知之舉。原因有二：
其一，當(dāng)快照被建立的時(shí)候，沒(méi)有數(shù)據(jù)被寫入稀疏文件。從快照進(jìn)行的所有的數(shù)據(jù)訪問(wèn)實(shí)際上都是在主數(shù)據(jù)庫(kù)文件當(dāng)中的。隨著時(shí)間的推移，你會(huì)通過(guò)在不同的陣列和磁盤上從主文件數(shù)據(jù)庫(kù)讀取未被修改過(guò)的文件和從稀疏文件讀取修改過(guò)的數(shù)據(jù)的方法來(lái)減少輸入輸出的負(fù)擔(dān)。
其二，根據(jù)你數(shù)據(jù)庫(kù)數(shù)據(jù)的易變動(dòng)性和數(shù)據(jù)變化的數(shù)量，你可以通過(guò)將在主數(shù)據(jù)庫(kù)的讀取工作和稀疏文件的寫入工作分離來(lái)減少輸入輸出的瓶頸大小。
使用數(shù)據(jù)庫(kù)快照
在這里你一定要記住的事情就是，你的查詢請(qǐng)求訪問(wèn)的依然是你的主數(shù)據(jù)庫(kù)。當(dāng)初始的快照被建立的時(shí)候，其實(shí)僅建立了一個(gè)空的殼子。所有的數(shù)據(jù)請(qǐng)求都是在主數(shù)據(jù)庫(kù)文件中被完成的。隨著時(shí)間的流逝和文件不斷地被修改，就有一些數(shù)據(jù)請(qǐng)求從初始的數(shù)據(jù)庫(kù)文件中分離出來(lái)指向了稀疏文件。所以，盡管看上去它是一個(gè)獨(dú)立的數(shù)據(jù)庫(kù)，那些根本的數(shù)據(jù)仍然是源于主數(shù)據(jù)庫(kù)。
鑒于此，你需要確定不要試圖去進(jìn)行你日?；顒?dòng)范圍以外的查詢。這樣說(shuō)吧，你創(chuàng)建了一個(gè)快照，接著你進(jìn)行了讀寫的操作，并對(duì)每個(gè)人做了記錄。當(dāng)那些記錄被執(zhí)行查詢操作時(shí)，他們?nèi)匀焕^續(xù)影響著主數(shù)據(jù)庫(kù)。所以你要保證任何新的活動(dòng)都不會(huì)影響主數(shù)據(jù)的活動(dòng)。
另外，你需要記住到底有哪些數(shù)據(jù)是被寫入稀疏文件里的，而不是認(rèn)為所有可能的數(shù)據(jù)都被寫進(jìn)了稀疏文件?；旧希?dāng)快照被創(chuàng)立時(shí)，主數(shù)據(jù)庫(kù)的大小就是快照稀疏文件的潛在大小。如果稀疏文件中的數(shù)據(jù)量已經(jīng)達(dá)到甚至超過(guò)數(shù)據(jù)庫(kù)的一半時(shí)，也許再創(chuàng)造一個(gè)數(shù)據(jù)庫(kù)的完整拷貝來(lái)取代現(xiàn)有的快照是一個(gè)更好的主意。
綜上所述，我認(rèn)為，數(shù)據(jù)庫(kù)快照是一個(gè)非常新的功能。我也希望在SQL Server2005的所有版本，而不僅僅在企業(yè)版和開(kāi)發(fā)版中可以應(yīng)用這個(gè)功能。有一個(gè)沒(méi)有討論的地方就是我們沒(méi)有討論有關(guān)對(duì)數(shù)據(jù)庫(kù)鏡像使用快照。其實(shí)，無(wú)論是鏡像還是原數(shù)據(jù)庫(kù)，快照都給了你最好的方法。因?yàn)殓R像是離線的，你并不能訪問(wèn)那些數(shù)據(jù)，所以說(shuō)無(wú)論是鏡像還是原數(shù)據(jù)庫(kù)，它都給了你最好的方法。花一些時(shí)間去理解快照是如何應(yīng)用于你的環(huán)境中的，并且確認(rèn)你監(jiān)視著維護(hù)快照的影響以及通過(guò)快照進(jìn)行的數(shù)據(jù)存儲(chǔ)。
重慶分公司
重慶分公司
