本文回答了关于Azure Blob 存储生命周期管理策略的常见问题。
我制定了新政策。 为什么这些操作不会立即执行？
一旦你配置了策略，它可能需要长达24小时才能生效。 一旦策略生效，执行动作所需的时间可能会根据存储账户的大小和执行的操作而有所不同。
如果我更新现有的策略，操作运行需要多长时间？
更新后的政策可能需要最长24小时才能生效。 一旦策略生效，执行操作所需的时间会根据存储账户的大小和执行的操作而有所不同。 如果此次更新是为了禁用或删除某条规则，并且使用了 enableAutoTierToHotFromCool，仍会自动分层到热层。 例如，设定一个包含 enableAutoTierToHotFromCool 基于最后访问权的规则。 如果该规则被禁用或删除，而某个 Blob 当前处于冷存储层或低温存储层，随后又被访问，则它会移回热存储层，因为在生命周期管理之外，一旦发生访问，就会应用热存储层。 如果禁用或删除生命周期管理规则，blob不会从热状态移动到冷冷却状态。 唯一的预防方法是 autoTierToHotFromCool 关闭最后访问时间追踪。
运行已完成，但未移动或删除某些 Blob 对象
根据存储账户的大小和对象数量，你可能需要多次运行才能处理所有对象。 你也可以查看存储资源日志，看看生命周期管理策略是否执行了操作。
即使策略是执行和删除blob，我也没看到容量变化
检查存储账户是否启用了软删除或版本控制等数据保护功能。 即使策略会删除这些 blob，这些 blob 仍可能以软删除状态存在，或者作为较早的版本保留下来，这取决于这些功能的配置方式。
我已将一个已存档的 Blob 重新激活。 我怎样才能防止它暂时被移回档案层级？
如果该存储帐户已启用生命周期管理策略，则通过更改访问层来重新水化 Blob 可能会导致这样一种情况：生命周期策略会将 Blob 移回存档层。 如果最后修改时间、创建时间或最后访问时间超过策略设定的阈值，就会发生这种情况。 预防这种状况有三种方法：
将
daysAfterLastTierChangeGreaterThan条件添加到策略的tierToArchive操作中。 参见使用生命周期管理策略归档blob。暂时禁用影响该斑点的规则，防止它再次归档。 当 Blob 可以安全地移回存档层时，重新启用该规则。
如果 Blob 需要永久保留在热层、凉层或冷层中，请将该 Blob 复制到生命周期管理策略不适用的其他位置。
Blob 前缀匹配字符串未将策略应用于预期的 Blob 对象
策略的 blob 前缀匹配字段是一个完整或部分的 blob 路径，你可以用它匹配你希望策略操作应用到的 blob。 路径必须以容器名称开始。 如果未指定前缀匹配，该策略将应用于存储帐户中的所有 Blob。 前缀匹配字符串的格式为 [container name]/[blob name]。
请记住关于前缀匹配字符串的以下几点：
- 像
container1/这样的前缀匹配字符串适用于名为container1的容器中的所有 blob。 前缀匹配字符串为container1，不带末尾正斜杠字符（/），适用于所有容器名称以字符串container1开头的容器中的所有 Blob。 前缀与名为container11、container1234、container1ab、 的容器相匹配。 - 前缀匹配字符串
container1/sub1/适用于名为container1的容器中所有以字符串sub1/开头的 Blob。 例如，前缀与名为container1/sub1/test.txt或container1/sub1/sub2/test.txt的斑点相匹配。 - 星号字符
*是blob名称中的有效字符。 如果你在前缀中使用星号字符，前缀会匹配名字中带有星号的斑点。 星号不能用作通配符。 - 问号字符
?是blob名称中的有效字符。 如果你在前缀中使用问号字符，前缀会匹配名字中带有问号的斑点。 问号不能用作通配符。 - 前缀匹配只考虑正（
=）逻辑比较。 它会忽略否定（!=）逻辑比较。 - 前缀匹配以区分大小写的方式进行。
有没有办法确定该策略将会在什么时间执行？
遗憾的是，无法追踪政策执行的时间，因为这是一个后台调度过程。 生命周期策略在规则创建或更新后24小时内开始执行。 策略会根据需要在后台持续处理对象。 系统优先处理来自工作负载的请求。 因此，无法跟踪策略可能正在执行的时间点。 处理对象所需的时间可能取决于存储账户的请求速率。 如果存储账户的请求速率接近存储账户的上限，这个时间可能会更长。