Resumen

  • Las tablas permanentes de Snowflake tienen siete días de Fail-safe después de Time Travel. El almacenamiento histórico sigue siendo facturable durante esa etapa fija.
  • Reducir la retención, elegir tablas transient y retirar clones modifica distintas causas de conservación. El ahorro llega cuando salen los bytes que siguen sujetos a cobro.

Una limpieza puede llegar tarde incluso cuando la orden de borrado se ejecutó a tiempo. Snowflake documenta el caso de una tabla que heredó 90 días de retención de su esquema y después fue eliminada. Reducir más tarde la retención del esquema a un día deja intactos los 90 días de esa tabla.

El objeto salió del trabajo cotidiano con sus condiciones anteriores. La política nueva alcanza a los objetos activos; el almacenamiento de lo ya borrado sigue otro calendario. Para un comprador que ha prometido un recorte de costes, la diferencia merece más atención que el número de tablas retiradas.

La guía de Time Travel explica que, para cambiar el período de aquel objeto eliminado, primero debe restaurarse y después modificarse su retención. La elección inicial de conservación puede acompañar a los datos durante el cierre de un proyecto, aunque el equipo ya haya pasado a otra cosa.

El borrado deja una etapa de siete días

La descripción de Fail-safe establece un período de siete días, no configurable, que comienza cuando termina Time Travel. Durante Time Travel el cliente puede consultar o restaurar el historial dentro de las condiciones del servicio. Después, la recuperación corresponde a Snowflake mediante su soporte.

Fail-safe ofrece un último intento de recuperación frente a fallos operativos graves, una vez agotadas las otras opciones. Se presta según el mejor esfuerzo y puede llevar de horas a días. La recuperación utiliza además cómputo sin servidor sujeto a facturación. Guardar los datos y pedir que sean recuperados son dos actividades con coste.

La función tiene una utilidad clara: un error puede resultar más caro que unos días adicionales de almacenamiento. Esa utilidad explica que los bytes continúen guardados cuando el analista ya no puede acceder a ellos por la vía ordinaria. La protección sigue vigente y el espacio sigue en la cuenta.

El cuadro oficial de retención histórica muestra las opciones básicas.

Tipo de tabla Time Travel Fail-safe posterior
Permanente en Standard Edition Cero o un día Siete días
Permanente en Enterprise Edition y superiores De cero a 90 días Siete días
transient Cero o un día Ninguno
temporary Cero o un día, hasta el borrado o el fin de sesión Ninguno

Poner a cero Time Travel en una tabla permanente deja los siete días posteriores. Una consulta histórica de larga duración puede retrasar la entrada en Fail-safe hasta terminar. Los cambios de estado también requieren procesos en segundo plano. El calendario describe etapas de conservación; las referencias pendientes pueden añadir su propia duración.

De diez días a uno: cambia la recuperación disponible

La documentación propone otra operación concreta: reducir de diez a uno los días de una tabla. El historial de los días dos a diez pasa a Fail-safe y el último día continúa en Time Travel. El cliente acorta su acceso directo al pasado; los datos más antiguos avanzan hacia la siguiente etapa de protección.

También importa el mínimo que establezca el administrador de la cuenta. Puede elevar el período efectivo por encima del valor escogido para un objeto. Revisar una cifra de cero exige conocer la política heredada y ese mínimo, además del parámetro local.

Estas reglas convierten el diseño de una tabla en una decisión económica anticipada. Las condiciones que una persona fijó al crearla influyen en el gasto que otra tendrá que explicar cuando la retire.

Los clones dejan sus propias referencias

Según las consideraciones de almacenamiento, un clon de copia cero comparte al principio las microparticiones existentes. Las modificaciones posteriores generan particiones propias. Cada objeto tiene su ciclo de vida, por lo que un entorno de desarrollo puede seguir utilizando datos que la tabla original ya dejó atrás.

El contador de TABLE_STORAGE_METRICS distingue bytes activos, bytes de Time Travel, bytes de Fail-safe y bytes retenidos para clones. Esta última categoría incluye también datos conservados por copias de seguridad WORM. Borrar solo el objeto original puede dejar vivas esas referencias.

La vista conserva tablas eliminadas mientras generan costes. Volver a crear el mismo nombre puede dejar varias versiones con historiales propios. El nombre que recuerda un equipo sirve para encontrar el trabajo; los identificadores y los bytes explican qué almacenamiento queda asociado a cada versión.

La información de Account Usage puede tardar hasta 90 minutos en actualizarse. Una fila antigua con los cuatro contadores principales a cero no genera almacenamiento facturable. Para poner precio a la conservación de una cuenta concreta hacen falta sus bytes comprimidos retenidos, su política efectiva y su tarifa aplicable.

La tarifa más corta incluye una renuncia

La guía general de costes incluye en el cobro los datos activos y sus versiones históricas, calculados sobre almacenamiento comprimido. Una tabla transient permite como máximo un día de Time Travel y elimina Fail-safe. Su contenido activo sigue facturándose mientras exista la tabla: el límite de un día corresponde a la protección histórica adicional.

Las tablas de trabajo que pueden reproducirse encajan en esa elección. Si el historial de una transient expira, Snowflake ya no puede recuperarla mediante Fail-safe. Reconstruirla exige tiempo y recursos; si tarda en volver un proceso de negocio, ese retraso también forma parte del coste.

Las temporary añaden el límite de la sesión. Su historial termina al borrarlas o finalizar la sesión. Desconectarse no cierra por sí mismo esa sesión, de modo que apagar el cliente puede dejar pendiente la limpieza que se daba por terminada.

La compra real consiste en decidir qué posibilidad de recuperación merece cuánto almacenamiento. Una orden de borrado completa su función antes de resolver todas esas decisiones. El contador se apaga cuando dejan de conservarse los bytes que lo alimentan.