Oracle 資料庫 FabricPool 分層原則
ONTAP 提供四項原則、可控制效能層上的 Oracle 資料如何成為移轉至容量層的候選對象。
僅限 Snapshot
。 snapshot-only
tiering-policy
僅適用於未與作用中檔案系統共用的區塊。它基本上會導致資料庫備份分層。在建立快照之後、區塊會成為分層的候選項目、然後區塊會被覆寫、導致區塊只存在於快照中。A 之前的延遲 snapshot-only
區塊視為冷區、由控制 tiering-minimum-cooling-days
音量設定。ONTAP 9.8 的範圍為 2 至 183 天。
許多資料集的變更率都很低、因此這項原則可節省的成本極低。例如、在 ONTAP 上觀察到的典型資料庫每週變更率低於 5% 。資料庫歸檔記錄檔可能佔用大量空間、但通常會繼續存在於作用中的檔案系統中、因此不會成為根據此原則分層的候選項目。
自動
。 auto
分層原則可將分層延伸至快照專用區塊、以及作用中檔案系統內的區塊。區塊冷卻前的延遲由控制 tiering-minimum-cooling-days
音量設定。ONTAP 9.8 的範圍為 2 至 183 天。
此方法可啟用無法與搭配使用的分層選項 snapshot-only
原則。例如、資料保護原則可能需要保留 90 天的特定記錄檔。如果將冷卻期設定為 3 天、則任何超過 3 天的記錄檔都會從效能層中分層移出。此動作可釋放效能層級上的大量空間、同時仍可讓您檢視及管理完整的 90 天資料。
無
。 none
分層原則可防止任何額外的區塊從儲存層分層、但容量層中的任何資料仍會保留在容量層中、直到讀取為止。如果接著讀取區塊、則會將其拉回並放置在效能層上。
使用的主要原因 none
分層原則旨在防止區塊分層、但隨著時間推移而變更原則可能會很有用。例如、假設某個特定資料集已廣泛分層至容量層、但卻產生對完整效能功能的非預期需求。可變更原則以防止任何額外的分層、並確認隨 IO 增加而讀取的任何區塊仍保留在效能層中。
全部
。 all
分層原則取代了 backup
原則自 ONTAP 9.6 起。。 backup
原則僅套用至資料保護磁碟區、意指 SnapMirror 或 NetApp SnapVault 目的地。。 all
原則的功能相同、但不限於資料保護磁碟區。
有了這項原則、就能立即將區塊視為酷炫、並立即分層至容量層。
此原則特別適用於長期備份。它也可以用作階層式儲存管理( HSM )的形式。過去、 HSM 通常用於將檔案的資料區塊分層至磁帶、同時讓檔案本身在檔案系統上保持可見。具有的 FabricPool Volume all
原則可讓您將檔案儲存在可見且可管理的環境中、但幾乎無需佔用本機儲存層的空間。