本文總結ORACLE ASM的不再使用的空間的回收策略以及對效能的負面影響以及其應對策略。這些問題隱藏的非常深，通常很難被DBA察覺。

本文ASM下磁碟主要是指SSD，也可以包含傳統的儲存廠商。為了分析清楚問題本質，先從SSD的空間使用特點開始。

SSD 快閃記憶體空間使用特點

稍微熟悉SSD的人都瞭解，SSD讀寫的是快閃記憶體，實際全部快閃記憶體容量會比真正可用的快閃記憶體容量要大，這多出來的空間叫OP空間（Over Provision）。機械盤沒有這個特點，這是由快閃記憶體（NAND）讀寫特點決定。

SSD快閃記憶體的寫跟LSM TREE資料庫類似，只支援新增（append），不支援原地修改（in-place update）。要修改資料時，就異地新增新的資料來模擬更新（out-of-place upate）。這樣同一筆資料多次修改時，就有多個版本。除了最新的版本外，其他版本資料都是垃圾資料，佔用的空間需要釋放出來。

快閃記憶體讀寫是以頁為單位（4KiB），快閃記憶體釋放指塊擦除，是以塊為單位（幾百個頁）。塊擦除通常靠SSD的垃圾回收（GC）主動進行。當剩餘的快閃記憶體容量比例很低時，GC會很頻繁。GC期間的資料搬遷會跟業務讀寫爭搶快閃記憶體頻寬資源，所以對業務讀寫效能有影響。

所以，如果SSD的剩餘空間很高時，GC活動會很少，那麼業務讀寫效能受影響的機率也就很小。所以物理容量相同時，OP比例大的盤效能會更好。比如說4TB盤中的 3.2T容量就比3.84T容量時效能好很多。當然代價就是可儲存容量變少。所有SSD的特點都如此，包括可計算儲存CSD。CSD不一樣的地方是內部有透明壓縮，快閃記憶體剩餘空間相對更大更足，GC少很多，後端快閃記憶體頻寬使用率更節省，所以總體效能更好。

SSD快閃記憶體轉換層（FTL）

上面資料更新後換了物理位置，所以SSD還提供一個模組快閃記憶體轉換層（FTL）用於將資料邏輯地址（LBA）對映到快閃記憶體實體地址（PBA）。不管資料如何更新，邏輯地址都保持不變，這樣實現了對核心、檔案系統、應用等的相容。

在SSD內部，當一個實體地址沒有對應的邏輯地址對映且該地址上有資料時，表示是垃圾資料，其空間後面會被回收。反之，一個實體地址如果有邏輯地址對映，則其對應的就是有效資料。即使空間被回收，也要提前將資料搬遷到新的塊上。

SSD的設計者期望上層應用如果確定資料沒有用就通知SSD該邏輯地址作廢（對應實體地址自然也作廢），嚴格來說就是通知SSD將邏輯地址和實體地址解除對映（unmap）。

這個通知機制有多個名稱，本質都是一樣的。在檔案系統的選項裡，叫discard。

如：

mount -o discard /data/nvme0n1 /dev/nvme0n1

有時候也叫 TRIM,  命令 ftrim 就是用於讓檔案系統向底層的SSD發TRIM 命令。

不過檔案系統和資料庫對空間管理有自己的想法。它們都維護有空間的後設資料，自己管理這片邏輯地址。內部空間釋放後自己會複用也不會通知到下層（檔案系統的下層是SSD，資料庫的下層可能是檔案系統或SSD）。這其中最關鍵的一點就是這段無效資料空間什麼時候會被複用。

ORACLE 空間管理介紹

ORACLE裡有2個空間管理方案，一是表空間(tablespace)，二是ASM。

表空間是邏輯概念，實際包含一個或多個物理檔案。表空間上主要放表和索引資料。表空間檔案空間支援預分配，也支援動態分配（自動擴充套件大小autoextend）。表空間檔案不會主動收縮。所以如果表空間內部大表刪除後，表空間剩餘空間會留待後期其他表用，但空間不會告知檔案系統或者磁碟進行回收。

ASM是檔案系統，實際以例項形式執行，支援叢集部署，提供叢集檔案系統服務。ASM主要是替代LVM和檔案系統的，可以直接管理多個磁碟裸裝置，並提供映象和條帶化的IO負載均衡和效能最佳化技術。一個ASM例項管理的儲存容量可以非常大，到EB級別。一個ASM例項也可以提供給多個ORACLE例項使用。ASM可以對底層磁碟進行分組使用，支援4Kn SSD訪問。基於4Kn SSD部署ASM後再部署ORACLE例項，REDO的塊大小自動為4KB。

表空間和ASM可以同時用，ASM主要為ORACLE提供儲存空間地址管理服務，並不會接受ORACLE的I/O請求以及ASM向SSD發讀寫I/O等。真正的I/O 請求還是由ORACLE例項自己完成。ASM跟檔案系統一樣，有自己的後設資料，空間釋放了後會留在內部等複用，也不會主動告知底層SSD釋放對應空間。

ORACLE ASRU 方案

ORACLE ASM 不主動通知磁碟釋放空間，最早觀察到這個應該是儲存產品。儲存產品也有自己的後設資料，對比儲存的已使用空間跟ASM的已使用空間，很容易就發現資料相差很多。於是儲存廠商跟ORACLE聯合搞了一個解決方案叫 ASRU 工具。

在2010年3PAR儲存和ORACLE出了一個解決方案文件

（）。

測試了一下，其原理是將指定的ASM磁碟組裡所有未使用的空間全部寫入0x0資料，然後3PAR儲存廠商會針對全0x0的資料進行最佳化（釋放其空間），從而達到節省儲存內部實際磁碟消耗的目的。後來好像有其他儲存廠商也支援針對0x0資料進行最佳化，於是都推薦這個方案。

這個方案當時看可能還會覺得很有技巧。但是當SSD成為主流替代高階儲存之後，ASM下磁碟是本機的SSD。就不能再使用這個方案了。或者說更嚴重點，這個方案用在SSD上壞透了。

SSD針對0x0資料並不會有最佳化，會當做有效資料用。這個方案用在SSD上等於是將SSD盤全盤未使用空間（標稱容量內）都初始化寫一遍。一般的SSD標盤沒有提供好的方式檢視SSD內部邏輯地址和實體地址容量資訊，所以即使用了，使用者也看不到這個壞的效果。

但是，在可計算儲存上，實際特點會有一點不一樣。可計算儲存（CSD）會對資料進行壓縮，如果資料都是0x0，則實際快閃記憶體物理消耗非常小（實際觀察用ASRU大量寫入0x0資料時寫CSD放大在0.01）。儘管透明壓縮讓ASRU看起來有點價值，實際上這個方案還是很糟糕，因為它用盡了CSD提供的LBA地址。這個導致後面的寫都是異地更新（FTL要不斷的為LBA換PBA）。

現在還有些軟體定義儲存的產品，也提供資料壓縮功能。ASRU在上面問題特徵跟 CSD 類似。

好在ORACLE後來推出了另外一個解決方案。

精簡配置（THIN PROVISION）介紹

不過ORACLE從12c版本後ASM支援一種精簡配置功能。

這是ASM磁碟組的一個屬性後，開啟這個屬性後，在磁碟組做REBALANCE的時候，ASM 會將不使用的空間地址通知到底層磁碟SSD 。這個需要跟ORACLE ASM Filter Driver（ASMFD）結合使用。在早期使用者使用ASM還多用的是 ASMLIB 或者 udev 服務去對映磁碟裸裝置地址。使用 ASMFD之前需要解除安裝 ASMLIB 。

ASMFD的安裝參考ORACLE官方文件即可，下面是精簡的步驟

/u01/app/grid/19.3/bin/crsctl stop has -f/u01/app/grid/19.3/bin/asmcmd afd_configure/u01/app/grid/19.3/bin/crsctl start has/u01/app/grid/19.3/bin/asmcmd afd_dsset '/dev/nvme*'/u01/app/grid/19.3/bin/asmcmd afd_label DATA1 /dev/nvme0n1/u01/app/grid/19.3/bin/asmcmd afd_label DATA2 /dev/nvme1n1/u01/app/grid/19.3/bin/asmcmd afd_scan/u01/app/grid/19.3/bin/asmcmd afd_lsdsk

然後安裝 ASM 例項，建立磁碟組，設定磁碟組的 THIN_PROVISIONED 屬性。

alter diskgroup datadg1 set attribute 'thin_provisioned'='TRUE';

此後，如果有在ASM裡大量刪除檔案。比如說刪除了一個大的表空間、或者刪除大量的歸檔檔案。可以手動觸發REBALANCE 操作釋放空間。

alter diskgroup datadg1 rebalance with balance compact wait;

得益於CSD可以檢視實際的物理容量，透過對比可以看到ASM磁碟組開啟精簡模式後，再刪除大量歸檔後做REBALANCE操作後釋放了SSD物理容量（由於壓縮比在2.73，CSD實際釋放的邏輯空間約在400G以上）。

其他空間技術簡介

還有一個空間回收技術就是檔案打洞，使用Linux的呼叫 fallocate，引數 FALLOC_FL_PUNCH_HOLE和FALLOC_FL_KEEP_SIZE。

示例：

//在4k偏移的位置上打一個12k大小的洞if(fallocate(fd,FALLOC_FL_PUNCH_HOLE|FALLOC_FL_KEEP_SIZE,4096, 4096*3)<0)

fallocate 也是一個linux命令。

檔案打洞後，檔案大小不變，實際佔用的物理容量卻變少了。打洞會通知底層SSD釋放對應的邏輯地址。

有關打洞的詳細的研究可以參考這篇文章：深度剖析Linux CP 原理（附原始碼） (qq.com)

對於打洞的地址的讀取預設都會返回0x0。儘管如此，全部寫入0x0跟打洞還是有本質的區別。ASRU 那個方案不是打洞。

在MySQL 的透明頁壓縮方案裡也用到打洞的方案。觀察一個檔案是不是用了打洞最佳化空間方案就比較它的檔案大小和實際儲存空間大小。

打洞的風險也是有的，那就是一旦後期真的需要這麼多空間，有可能會分配不出來（因為物理空間讓給其他應用了）。所以資料庫的空間管理方案裡通常預設不會使用打洞這個方案。一些虛擬機器或者雲資料庫可能會用這個解決方案。

OceanBase的BLOCKFILE也是一種空間預分配機制，預設不使用稀疏檔案格式， OceanBase 是LSM Tree，會經常性的做版本合併，內部會有大量新版本資料生成和老版本資料刪除，釋放的空間預設也不會通知儲存釋放，除非開啟打洞引數_enable_block_file_punch_hole 。

最後總結一下。

ORACLE 表空間可以預分配，也可以動態分配空間，空間只增不減，除非主動發起檔案收縮命令。ASM 也會自己管理空間，ASM內部不用的空間預設不會通知SSD，除非開啟ASM磁碟組的精簡配置屬性（thin_provisioned）並結合 ASM AFD一起使用。