Tablas con + de 1.000.000 de registros

Hola gente,

hemos visto que en nuestra base tenemos tablas que ya superan ampliamente el 1.000.000 de registros (casi todas son del tipo log_*).

Si bien no es un problema en si mismo, mi consulta es si en aquellas universidades donde se excede varias veces este número en alguna de sus tablas, han tomado alguna medida al respecto (alguna política de backup).

Saludos!

Juan

Hola Juan, lo que podes hacer es bajar los datos de esas talbas a archivos, luego borrar los datos de esas tablas y a continuacion hacer un export-import de la base asi los tablespaces se achican sino quedaran con el mismo tamaño pero vacios y la base seguiría ocupando el mismo espacio que antes.

Hola Alejandro, ok.

Armaremos alguna política como para que sea algo periódico (1 vez cda 6 meses x ej.). Lo que si vemos que es complicado (y peligroso) de automatizar.

Saludos y gracias!

Juan

Fijate si te sirve esto:


-- Armar los unload de las tablas
SELECT 'UNLOAD TO "c:\backup_logs\' ||  trim(tabname) || '.unl"  SELECT * FROM ' || trim(tabname) || ';'
FROM systables
WHERE tabname[1,4] = 'log_'
ORDER BY 1;

-- Armar los deletes de las tablas
SELECT 'DELETE FROM  '  ||  trim(tabname) || ';' 
  FROM systables 
WHERE tabname[1,4] = 'log_'  ORDER BY 1;

-- Armar los deletes de las tablas con el comando TRUNCATE (mas rapido que DELETE), pero no se si esta disponible en la version 9.21
SELECT 'TRUNCATE TABLE  '  ||  trim(tabname) || ';' 
  FROM systables 
WHERE tabname[1,4] = 'log_'  ORDER BY 1;


Por las dudas revisá que no tengas ninguna tabla de alguna personalización que comience con el prefijo log_

Buenisimo Alejandro!,

lo pruebo en una instancia de test y te cuento. Igualmente la idea no era deshacernos de todos los logs, solo con aquellas que no sean tan relevantes. Por eso preguntaba si había alguna política, para no dejar afuera a alguna importante.

Abrazo!

Podrias ver cuales son las tablas con mayor tamaño y talvez con que hagas una bajada de un 10% de tablas cubras un alto porcentaje del espacio fisico que esta consumiendo los registros de las tablas de log.

Seguramente las mas relevantes (actas) sean los que mas espacio tengan…

Otra forma en vez de bajar los registros a archivos, es tener en otro motor (que este en otro espacio fisico) una base a donde vayas actualizando los datos de estas tablas, con lo cual si tuvieras que buscar algo en las tablas de log lo harias en la otra base y no en la de producción.
Es decir, en el mismo proceso donde bajas los datos a archivo, tener alli mismo un proceso para levantar esos datos a la 2da base (base de logs).