0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復(fù)
登錄后你可以
  • 下載海量資料
  • 學(xué)習(xí)在線課程
  • 觀看技術(shù)視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認識你,還能領(lǐng)取20積分哦,立即完善>

3天內(nèi)不再提示

進程寫文件會丟失數(shù)據(jù)嗎

科技綠洲 ? 來源:Linux開發(fā)架構(gòu)之路 ? 作者:Linux開發(fā)架構(gòu)之路 ? 2023-11-13 10:57 ? 次閱讀

進程寫文件(使用緩沖 IO)過程中,寫一半的時候,進程發(fā)生了崩潰,會丟失數(shù)據(jù)嗎?

答案,是不會的。

圖片

因為進程在執(zhí)行 write (使用緩沖 IO)系統(tǒng)調(diào)用的時候,實際上是將文件數(shù)據(jù)寫到了內(nèi)核的 page cache,它是文件系統(tǒng)中用于緩存文件數(shù)據(jù)的緩沖,所以即使進程崩潰了,文件數(shù)據(jù)還是保留在內(nèi)核的 page cache,我們讀數(shù)據(jù)的時候,也是從內(nèi)核的 page cache 讀取,因此還是依然讀的進程崩潰前寫入的數(shù)據(jù)。

內(nèi)核會找個合適的時機,將 page cache 中的數(shù)據(jù)持久化到磁盤。但是如果 page cache 里的文件數(shù)據(jù),在持久化到磁盤化到磁盤之前,系統(tǒng)發(fā)生了崩潰,那這部分數(shù)據(jù)就會丟失了。

當(dāng)然, 我們也可以在程序里調(diào)用 fsync 函數(shù),在寫文文件的時候,立刻將文件數(shù)據(jù)持久化到磁盤,這樣就可以解決系統(tǒng)崩潰導(dǎo)致的文件數(shù)據(jù)丟失的問題。

  1. Page Cache

1.1 Page Cache 是什么?

為了理解 Page Cache,我們不妨先看一下 Linux 的文件 I/O 系統(tǒng),如下圖所示:

圖片

Figure1. Linux 文件 I/O 系統(tǒng)

上圖中,紅色部分為 Page Cache。可見 Page Cache 的本質(zhì)是由 Linux 內(nèi)核管理的內(nèi)存區(qū)域。我們通過 mmap 以及 buffered I/O 將文件讀取到內(nèi)存空間實際上都是讀取到 Page Cache 中。

1.2 如何查看系統(tǒng)的 Page Cache?

通過讀取 /proc/meminfo 文件,能夠?qū)崟r獲取系統(tǒng)內(nèi)存情況:

$ cat /proc/meminfo
...
Buffers:            1224 kB
Cached:           111472 kB
SwapCached:        36364 kB
Active:          6224232 kB
Inactive:         979432 kB
Active(anon):    6173036 kB
Inactive(anon):   927932 kB
Active(file):      51196 kB
Inactive(file):    51500 kB
...
Shmem:             10000 kB
...
SReclaimable:      43532 kB
...

根據(jù)上面的數(shù)據(jù),你可以簡單得出這樣的公式(等式兩邊之和都是 112696 KB):

Buffers + Cached + SwapCached = Active(file) + Inactive(file) + Shmem + SwapCached

兩邊等式都是 Page Cache,即:

Page Cache = Buffers + Cached + SwapCached

通過閱讀 1.4 以及 1.5 小節(jié),就能夠理解為什么 SwapCached 與 Buffers 也是 Page Cache 的一部分。

1.3 page 與 Page Cache

page 是內(nèi)存管理分配的基本單位, Page Cache 由多個 page 構(gòu)成。page 在操作系統(tǒng)中通常為 4KB 大?。?2bits/64bits),而 Page Cache 的大小則為 4KB 的整數(shù)倍。

另一方面,并不是所有 page 都被組織為 Page Cache。

Linux 系統(tǒng)上供用戶可訪問的內(nèi)存分為兩個類型[2],即:

  • File-backed pages:文件備份頁也就是 Page Cache 中的 page,對應(yīng)于磁盤上的若干數(shù)據(jù)塊;對于這些頁最大的問題是臟頁回盤;
  • Anonymous pages:匿名頁不對應(yīng)磁盤上的任何磁盤數(shù)據(jù)塊,它們是進程的運行是內(nèi)存空間(例如方法棧、局部變量表等屬性);

為什么 Linux 不把 Page Cache 稱為 block cache,這不是更好嗎?

這是因為從磁盤中加載到內(nèi)存的數(shù)據(jù)不僅僅放在 Page Cache 中,還放在 buffer cache 中。例如通過 Direct I/O 技術(shù)的磁盤文件就不會進入 Page Cache 中。當(dāng)然,這個問題也有 Linux 歷史設(shè)計的原因,畢竟這只是一個稱呼,含義隨著 Linux 系統(tǒng)的演進也逐漸不同。

下面比較一下 File-backed pages 與 Anonymous pages 在 Swap 機制下的性能。

內(nèi)存是一種珍惜資源,當(dāng)內(nèi)存不夠用時,內(nèi)存管理單元(Memory Mangament Unit)需要提供調(diào)度算法來回收相關(guān)內(nèi)存空間。內(nèi)存空間回收的方式通常就是 swap,即交換到持久化存儲設(shè)備上。

File-backed pages(Page Cache)的內(nèi)存回收代價較低。Page Cache 通常對應(yīng)于一個文件上的若干順序塊,因此可以通過順序 I/O 的方式落盤。另一方面,如果 Page Cache 上沒有進行寫操作(所謂的沒有臟頁),甚至不會將 Page Cache 回盤,因為數(shù)據(jù)的內(nèi)容完全可以通過再次讀取磁盤文件得到。

Page Cache 的主要難點在于臟頁回盤,這個內(nèi)容會在第二節(jié)進行詳細說明。

Anonymous pages 的內(nèi)存回收代價較高。這是因為 Anonymous pages 通常隨機地寫入持久化交換設(shè)備。另一方面,無論是否有寫操作,為了確保數(shù)據(jù)不丟失,Anonymous pages 在 swap 時必須持久化到磁盤。

1.4 Swap 與缺頁中斷

Swap 機制指的是當(dāng)物理內(nèi)存不夠用,內(nèi)存管理單元(Memory Mangament Unit,MMU)需要提供調(diào)度算法來回收相關(guān)內(nèi)存空間,然后將清理出來的內(nèi)存空間給當(dāng)前內(nèi)存申請方。

Swap 機制存在的本質(zhì)原因是 Linux 系統(tǒng)提供了虛擬內(nèi)存管理機制,每一個進程認為其獨占內(nèi)存空間,因此所有進程的內(nèi)存空間之和遠遠大于物理內(nèi)存。所有進程的內(nèi)存空間之和超過物理內(nèi)存的部分就需要交換到磁盤上。

操作系統(tǒng)以 page 為單位管理內(nèi)存,當(dāng)進程發(fā)現(xiàn)需要訪問的數(shù)據(jù)不在內(nèi)存時,操作系統(tǒng)可能會將數(shù)據(jù)以頁的方式加載到內(nèi)存中。上述過程被稱為缺頁中斷,當(dāng)操作系統(tǒng)發(fā)生缺頁中斷時,就會通過系統(tǒng)調(diào)用將 page 再次讀到內(nèi)存中。

但主內(nèi)存的空間是有限的,當(dāng)主內(nèi)存中不包含可以使用的空間時,操作系統(tǒng)會從選擇合適的物理內(nèi)存頁驅(qū)逐回磁盤,為新的內(nèi)存頁讓出位置,選擇待驅(qū)逐頁的過程在操作系統(tǒng)中叫做頁面替換(Page Replacement),替換操作又會觸發(fā) swap 機制。

如果物理內(nèi)存足夠大,那么可能不需要 Swap 機制,但是 Swap 在這種情況下還是有一定優(yōu)勢:對于有發(fā)生內(nèi)存泄漏幾率的應(yīng)用程序(進程),Swap 交換分區(qū)更是重要,這可以確保內(nèi)存泄露不至于導(dǎo)致物理內(nèi)存不夠用,最終導(dǎo)致系統(tǒng)崩潰。但內(nèi)存泄露會引起頻繁的 swap,此時非常影響操作系統(tǒng)的性能。

Linux 通過一個 swappiness 參數(shù)來控制 Swap 機制[2]:這個參數(shù)值可為 0-100,控制系統(tǒng) swap 的優(yōu)先級:

  • 高數(shù)值:較高頻率的 swap,進程不活躍時主動將其轉(zhuǎn)換出物理內(nèi)存。
  • 低數(shù)值:較低頻率的 swap,這可以確保交互式不因為內(nèi)存空間頻繁地交換到磁盤而提高響應(yīng)延遲。

最后,為什么 Buffers 也是 Page Cache 的一部分?

這是因為當(dāng)匿名頁(Inactive(anon) 以及 Active(anon))先被交換(swap out)到磁盤上后,然后再加載回(swap in)內(nèi)存中,由于讀入到內(nèi)存后原來的 Swap File 還在,所以 SwapCached 也可以認為是 File-backed page,即屬于 Page Cache。這個過程如 Figure 2 所示。

圖片

Figure2. 匿名頁的被交換后也是 Page Cache

1.5 Page Cache 與 buffer cache

執(zhí)行 free 命令,注意到會有兩列名為 buffers 和 cached,也有一行名為 “-/+ buffers/cache”。

~ free -m
             total       used       free     shared    buffers     cached
Mem:        128956      96440      32515          0       5368      39900
-/+ buffers/cache:      51172      77784
Swap:        16002          0      16001

其中,cached 列表示當(dāng)前的頁緩存(Page Cache)占用量,buffers 列表示當(dāng)前的塊緩存(buffer cache)占用量。用一句話來解釋:Page Cache 用于緩存文件的頁數(shù)據(jù),buffer cache 用于緩存塊設(shè)備(如磁盤)的塊數(shù)據(jù)。頁是邏輯上的概念,因此 Page Cache 是與文件系統(tǒng)同級的;塊是物理上的概念,因此 buffer cache 是與塊設(shè)備驅(qū)動程序同級的。

其中,cached 列表示當(dāng)前的頁緩存(Page Cache)占用量,buffers 列表示當(dāng)前的塊緩存(buffer cache)占用量。用一句話來解釋:Page Cache 用于緩存文件的頁數(shù)據(jù),buffer cache 用于緩存塊設(shè)備(如磁盤)的塊數(shù)據(jù)。頁是邏輯上的概念,因此 Page Cache 是與文件系統(tǒng)同級的;塊是物理上的概念,因此 buffer cache 是與塊設(shè)備驅(qū)動程序同級的。

Page Cache 與 buffer cache 的共同目的都是加速數(shù)據(jù) I/O:寫數(shù)據(jù)時首先寫到緩存,將寫入的頁標記為 dirty,然后向外部存儲 flush,也就是緩存寫機制中的 write-back(另一種是 write-through,Linux 默認情況下不采用);讀數(shù)據(jù)時首先讀取緩存,如果未命中,再去外部存儲讀取,并且將讀取來的數(shù)據(jù)也加入緩存。操作系統(tǒng)總是積極地將所有空閑內(nèi)存都用作 Page Cache 和 buffer cache,當(dāng)內(nèi)存不夠用時也會用 LRU 等算法淘汰緩存頁。

在 Linux 2.4 版本的內(nèi)核之前,Page Cache 與 buffer cache 是完全分離的。但是,塊設(shè)備大多是磁盤,磁盤上的數(shù)據(jù)又大多通過文件系統(tǒng)來組織,這種設(shè)計導(dǎo)致很多數(shù)據(jù)被緩存了兩次,浪費內(nèi)存。所以在 2.4 版本內(nèi)核之后,兩塊緩存近似融合在了一起:如果一個文件的頁加載到了 Page Cache,那么同時 buffer cache 只需要維護塊指向頁的指針就可以了。只有那些沒有文件表示的塊,或者繞過了文件系統(tǒng)直接操作(如dd命令)的塊,才會真正放到 buffer cache 里。因此,我們現(xiàn)在提起 Page Cache,基本上都同時指 Page Cache 和 buffer cache 兩者,本文之后也不再區(qū)分,直接統(tǒng)稱為 Page Cache。

下圖近似地示出 32-bit Linux 系統(tǒng)中可能的一種 Page Cache 結(jié)構(gòu),其中 block size 大小為 1KB,page size 大小為 4KB。

圖片

Page Cache 中的每個文件都是一棵基數(shù)樹(radix tree,本質(zhì)上是多叉搜索樹),樹的每個節(jié)點都是一個頁。根據(jù)文件內(nèi)的偏移量就可以快速定位到所在的頁,如下圖所示。關(guān)于基數(shù)樹的原理可以參見英文維基,這里就不細說了。

圖片

1.6 Page Cache 與預(yù)讀

操作系統(tǒng)為基于 Page Cache 的讀緩存機制提供預(yù)讀機制(PAGE_READAHEAD),一個例子是:

  • 用戶線程僅僅請求讀取磁盤上文件 A 的 offset 為 0-3KB 范圍內(nèi)的數(shù)據(jù),由于磁盤的基本讀寫單位為 block(4KB),于是操作系統(tǒng)至少會讀 0-4KB 的內(nèi)容,這恰好可以在一個 page 中裝下。
  • 但是操作系統(tǒng)出于局部性原理[3]會選擇將磁盤塊 offset [4KB,8KB)、[8KB,12KB) 以及 [12KB,16KB) 都加載到內(nèi)存,于是額外在內(nèi)存中申請了 3 個 page;

下圖代表了操作系統(tǒng)的預(yù)讀機制:

圖片

Figure.操作系統(tǒng)的預(yù)讀機制;

上圖中,應(yīng)用程序利用 read 系統(tǒng)調(diào)動讀取 4KB 數(shù)據(jù),實際上內(nèi)核使用 readahead 機制完成了 16KB 數(shù)據(jù)的讀取。

  1. Page Cache 與文件持久化的一致性&可靠性

現(xiàn)代 Linux 的 Page Cache 正如其名,是對磁盤上 page(頁)的內(nèi)存緩存,同時可以用于讀/寫操作。任何系統(tǒng)引入緩存,就會引發(fā)一致性問題:內(nèi)存中的數(shù)據(jù)與磁盤中的數(shù)據(jù)不一致,例如常見后端架構(gòu)中的 Redis 緩存與 MySQL 數(shù)據(jù)庫就存在一致性問題。

Linux 提供多種機制來保證數(shù)據(jù)一致性,但無論是單機上的內(nèi)存與磁盤一致性,還是分布式組件中節(jié)點 1 與節(jié)點 2 、節(jié)點 3 的數(shù)據(jù)一致性問題,理解的關(guān)鍵是 trade-off:吞吐量與數(shù)據(jù)一致性保證是一對矛盾。

首先,需要我們理解一下文件的數(shù)據(jù)。文件 = 數(shù)據(jù) + 元數(shù)據(jù)。元數(shù)據(jù)用來描述文件的各種屬性,也必須存儲在磁盤上。因此,我們說保證文件一致性其實包含了兩個方面:數(shù)據(jù)一致+元數(shù)據(jù)一致。

文件的元數(shù)據(jù)包括:文件大小、創(chuàng)建時間、訪問時間、屬主屬組等信息。

我們考慮如下一致性問題:如果發(fā)生寫操作并且對應(yīng)的數(shù)據(jù)在 Page Cache 中,那么寫操作就會直接作用于 Page Cache 中,此時如果數(shù)據(jù)還沒刷新到磁盤,那么內(nèi)存中的數(shù)據(jù)就領(lǐng)先于磁盤,此時對應(yīng) page 就被稱為 Dirty page。

當(dāng)前 Linux 下以兩種方式實現(xiàn)文件一致性:

  • Write Through(寫穿):向用戶層提供特定接口,應(yīng)用程序可主動調(diào)用接口來保證文件一致性;
  • Write back(寫回):系統(tǒng)中存在定期任務(wù)(表現(xiàn)形式為內(nèi)核線程),周期性地同步文件系統(tǒng)中文件臟數(shù)據(jù)塊,這是默認的 Linux 一致性方案;

上述兩種方式最終都依賴于系統(tǒng)調(diào)用,主要分為如下三種系統(tǒng)調(diào)用:

圖片

上述三種系統(tǒng)調(diào)用可以分別由用戶進程與內(nèi)核進程發(fā)起。下面我們研究一下內(nèi)核線程的相關(guān)特性。

  • 創(chuàng)建的針對回寫任務(wù)的內(nèi)核線程數(shù)由系統(tǒng)中持久存儲設(shè)備決定,為每個存儲設(shè)備創(chuàng)建單獨的刷新線程;
  • 關(guān)于多線程的架構(gòu)問題,Linux 內(nèi)核采取了 Lighthttp 的做法,即系統(tǒng)中存在一個管理線程和多個刷新線程(每個持久存儲設(shè)備對應(yīng)一個刷新線程)。管理線程監(jiān)控設(shè)備上的臟頁面情況,若設(shè)備一段時間內(nèi)沒有產(chǎn)生臟頁面,就銷毀設(shè)備上的刷新線程;若監(jiān)測到設(shè)備上有臟頁面需要回寫且尚未為該設(shè)備創(chuàng)建刷新線程,那么創(chuàng)建刷新線程處理臟頁面回寫。而刷新線程的任務(wù)較為單調(diào),只負責(zé)將設(shè)備中的臟頁面回寫至持久存儲設(shè)備中。
  • 刷新線程刷新設(shè)備上臟頁面大致設(shè)計如下:
  • 每個設(shè)備保存臟文件鏈表,保存的是該設(shè)備上存儲的臟文件的 inode 節(jié)點。所謂的回寫文件臟頁面即回寫該 inode 鏈表上的某些文件的臟頁面;
  • 系統(tǒng)中存在多個回寫時機,第一是應(yīng)用程序主動調(diào)用回寫接口(fsync,fdatasync 以及 sync 等),第二管理線程周期性地喚醒設(shè)備上的回寫線程進行回寫,第三是某些應(yīng)用程序/內(nèi)核任務(wù)發(fā)現(xiàn)內(nèi)存不足時要回收部分緩存頁面而事先進行臟頁面回寫,設(shè)計一個統(tǒng)一的框架來管理這些回寫任務(wù)非常有必要。

Write Through 與 Write back 在持久化的可靠性上有所不同:

  • Write Through 以犧牲系統(tǒng) I/O 吞吐量作為代價,向上層應(yīng)用確保一旦寫入,數(shù)據(jù)就已經(jīng)落盤,不會丟失;
  • Write back 在系統(tǒng)發(fā)生宕機的情況下無法確保數(shù)據(jù)已經(jīng)落盤,因此存在數(shù)據(jù)丟失的問題。不過,在程序掛了,例如被 kill -9,Page Cache 中的數(shù)據(jù)操作系統(tǒng)還是會確保落盤;
  1. Page Cache 的優(yōu)劣勢

3.1 Page Cache 的優(yōu)勢

1.加快數(shù)據(jù)訪問

如果數(shù)據(jù)能夠在內(nèi)存中進行緩存,那么下一次訪問就不需要通過磁盤 I/O 了,直接命中內(nèi)存緩存即可。

由于內(nèi)存訪問比磁盤訪問快很多,因此加快數(shù)據(jù)訪問是 Page Cache 的一大優(yōu)勢。

2.減少 I/O 次數(shù),提高系統(tǒng)磁盤 I/O 吞吐量

得益于 Page Cache 的緩存以及預(yù)讀能力,而程序又往往符合局部性原理,因此通過一次 I/O 將多個 page 裝入 Page Cache 能夠減少磁盤 I/O 次數(shù), 進而提高系統(tǒng)磁盤 I/O 吞吐量。

3.2 Page Cache 的劣勢

page cache 也有其劣勢,最直接的缺點是需要占用額外物理內(nèi)存空間,物理內(nèi)存在比較緊俏的時候可能會導(dǎo)致頻繁的 swap 操作,最終導(dǎo)致系統(tǒng)的磁盤 I/O 負載的上升。

Page Cache 的另一個缺陷是對應(yīng)用層并沒有提供很好的管理 API,幾乎是透明管理。應(yīng)用層即使想優(yōu)化 Page Cache 的使用策略也很難進行。因此一些應(yīng)用選擇在用戶空間實現(xiàn)自己的 page 管理,而不使用 page cache,例如 MySQL InnoDB 存儲引擎以 16KB 的頁進行管理。

Page Cache 最后一個缺陷是在某些應(yīng)用場景下比 Direct I/O 多一次磁盤讀 I/O 以及磁盤寫 I/O。

聲明:本文內(nèi)容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權(quán)轉(zhuǎn)載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學(xué)習(xí)之用,如有內(nèi)容侵權(quán)或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • 數(shù)據(jù)
    +關(guān)注

    關(guān)注

    8

    文章

    6715

    瀏覽量

    88316
  • 緩沖
    +關(guān)注

    關(guān)注

    0

    文章

    51

    瀏覽量

    17753
  • 磁盤
    +關(guān)注

    關(guān)注

    1

    文章

    355

    瀏覽量

    25096
  • 系統(tǒng)調(diào)用

    關(guān)注

    0

    文章

    27

    瀏覽量

    8309
收藏 人收藏

    評論

    相關(guān)推薦

    Linux如何查看文件是被那個進程占用數(shù)據(jù)?

    文件被那個進程使用,數(shù)據(jù)不是用lsof可以找出來嗎,但現(xiàn)實情況是lsof沒找出來T_T
    發(fā)表于 10-27 09:17 ?470次閱讀

    【Linux學(xué)習(xí)雜談】之父子進程文件的操作

    父子進程文件的操作: 1.子進程繼承父進程中打開的文件。 前提是父進程中將
    發(fā)表于 09-01 20:37

    labview串口讀取高頻率數(shù)據(jù)再保存丟失數(shù)據(jù)

    串口讀取數(shù)據(jù)數(shù)據(jù)一秒40多次寫入,在讀取的同時還保存到txt文件,但是丟失一部分數(shù)據(jù),有高手
    發(fā)表于 11-04 09:32

    Linux進程退出之方法論

    對應(yīng)每一個打開的文件,在內(nèi)存中都有一片緩沖區(qū)。每次讀文件時,連續(xù)的讀出若干條記錄,這樣在下次讀文件時就可以直接從內(nèi)存的緩沖區(qū)讀??;同樣,每次
    發(fā)表于 10-26 21:45

    LabView隊列操作程序數(shù)據(jù)丟失,請問有什么好的改進方法減少數(shù)據(jù)丟失呢?

    本帖最后由 一只耳朵怪 于 2018-6-21 16:01 編輯 各位大神,我寫了一個隊列操作,以便讀取的光譜數(shù)據(jù)能夠慢一點的寫入TDMS文件中,但是程序在運行過程中部分數(shù)據(jù)
    發(fā)表于 06-21 08:14

    請問文件怎么丟失呢?

    ,那么文件怎么丟失呢? 以上來自于百度翻譯 以下為原文 I copied the subject line from mjarabek's posting about v1.40, from
    發(fā)表于 06-17 07:54

    CAN轉(zhuǎn)LWIP丟失數(shù)據(jù)

    各位大神,我用407的開發(fā)板做了一個CAN轉(zhuǎn)以太網(wǎng)的程序。程序不帶操作系統(tǒng),CAN是用中斷做的,LWIP就是用例程的發(fā)送。實際測試發(fā)現(xiàn)當(dāng)LWIP發(fā)送的時候。CAN中斷接收丟失數(shù)據(jù),我個人認為是有
    發(fā)表于 04-03 04:35

    LabVIEW中For循環(huán)丟失數(shù)據(jù)

    LabVIEW中For循環(huán)丟失數(shù)據(jù)LabVIEW程序中包含一個For循環(huán),有時循環(huán)丟失數(shù)據(jù),
    發(fā)表于 02-01 13:00

    微軟Windows 10修復(fù)補丁KB4532693導(dǎo)致文件丟失

    2月11日,微軟為Windows 10發(fā)布了具有重要安全修復(fù)程序的累積更新補丁KB4532693,但該補丁導(dǎo)致用戶升級后桌面、帳號配置文件丟失。
    的頭像 發(fā)表于 02-26 08:12 ?2435次閱讀

    查看Linux文件占用進程數(shù)據(jù)

      centos7 在某一段時間監(jiān)控報警磁盤使用率達99%,由于監(jiān)控屬于概要形式信息,沒有快照信息的監(jiān)控(能發(fā)現(xiàn)某進程的I/O,CPU消耗情況),所以需要在服務(wù)器上去定時執(zhí)行統(tǒng)計命令獲取快照信息
    的頭像 發(fā)表于 11-04 16:46 ?751次閱讀

    虛擬機文件丟失導(dǎo)致Hyper-V服務(wù)癱瘓的數(shù)據(jù)恢復(fù)案例

    虛擬機文件丟失導(dǎo)致Hyper-V服務(wù)癱瘓的數(shù)據(jù)恢復(fù)案例
    的頭像 發(fā)表于 02-14 15:11 ?561次閱讀
    虛擬機<b class='flag-5'>文件</b><b class='flag-5'>丟失</b>導(dǎo)致Hyper-V服務(wù)癱瘓的<b class='flag-5'>數(shù)據(jù)</b>恢復(fù)案例

    SQL Server數(shù)據(jù)庫文件丟失數(shù)據(jù)恢復(fù)案例

    未知原因?qū)е耂ql Server數(shù)據(jù)庫文件丟失,涉及到數(shù)個數(shù)據(jù)庫和數(shù)千張表,不能確定數(shù)據(jù)存儲位置。數(shù)據(jù)庫文件
    的頭像 發(fā)表于 04-28 14:53 ?885次閱讀
    SQL Server<b class='flag-5'>數(shù)據(jù)庫文件</b><b class='flag-5'>丟失</b>的<b class='flag-5'>數(shù)據(jù)</b>恢復(fù)案例

    如何利用Mutex解決并發(fā)文件亂序的問題?

    在實際開發(fā)過程中,我們可能遇到并發(fā)文件的場景,如果處理不當(dāng)很可能出現(xiàn)文件內(nèi)容亂序問題。
    的頭像 發(fā)表于 08-12 09:54 ?563次閱讀

    PLC數(shù)據(jù)丟失如何找回?

    還原到PLC中,以恢復(fù)丟失數(shù)據(jù)。 (2)PLC日志文件:某些PLC系統(tǒng)記錄運行時的日志文件,其中包含了關(guān)鍵的操作和
    的頭像 發(fā)表于 09-05 10:30 ?3301次閱讀

    數(shù)據(jù)數(shù)據(jù)恢復(fù)—Sql Server數(shù)據(jù)庫文件丟失數(shù)據(jù)恢復(fù)案例

    庫。存儲空間LUN劃分了兩個邏輯分區(qū)。 服務(wù)器故障&初檢: 由于未知原因,Sql Server數(shù)據(jù)庫文件丟失丟失數(shù)據(jù)涉及到3個庫,表的數(shù)量有3000左右。
    的頭像 發(fā)表于 04-11 15:38 ?646次閱讀
    <b class='flag-5'>數(shù)據(jù)</b>庫<b class='flag-5'>數(shù)據(jù)</b>恢復(fù)—Sql Server<b class='flag-5'>數(shù)據(jù)庫文件</b><b class='flag-5'>丟失</b>的<b class='flag-5'>數(shù)據(jù)</b>恢復(fù)案例