Oracle数据库FabricPool分层策略
ONTAP提供了四个策略、用于控制性能层上的Oracle数据如何成为重新定位到容量层的候选对象。
仅快照
。 snapshot-only
tiering-policy
仅适用于未与活动文件系统共享的块。实际上、它需要对数据库备份进行层化。创建快照后、块将成为分层的候选块、然后将其覆盖、从而导致块仅存在于快照中。之前的延迟 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卷 all
通过策略、您可以将文件存储在一个可见且易于管理的位置、但几乎不会占用本地存储层上的空间。