Shrink

6 views
Skip to first unread message

Franky

unread,
Nov 8, 2016, 11:07:25 AM11/8/16
to foro...@googlegroups.com
¡Buenas muchachos!

Sirva este correo para actualizarnos, a ver cómo estamos todos (que espero que al menos tan bien como tras la última comunicación :-) ) y ya de paso para que me echéis una mano con un temilla de borrado en oracle

Por mi parte aquí seguimos, de coordinador de facturación y mediación para Jazztel (ahora Orange), con un par de proyectillos con Huawei y el propio Orange...en fin, de curro no me puedo quejar.

La pregunta es, para tablas realmente grandes, ¿cuál es la mejor manera de liberar espacio? El shrink me tarda la vida misma y en un entorno de producción no es asumible un tiempo tan grande. No sé si habéis tenido algún problema parecido, y cómo lo habéis tratado.

Pues nada...espero noticias buenas de vosotros y alguna que otra respuesta ;-)

¡Un abrazo!

Cristina Garcia

unread,
Nov 8, 2016, 11:24:23 AM11/8/16
to foro...@googlegroups.com

Hola a todos!!!

Yo ahora mismo estoy en casa porque estoy sin proyecto, a ver que hacen conmigo.

Franky,  no puedes historificar la tabla??
Yo cuando lo he hecho ha sido con inserts select a una tabla nueva, el tema es si te entra en una ventana, a mi no me entraba, así que tenía que hacerlo en distintos días, y para que no tuvieran que tocar código metía un trigger para que me consultara en la otra, al igual que para las fks que no podía duplicar.

Espero haberte ayudado.

Saludos


--
Has recibido este mensaje porque estás suscrito al grupo "FORO_DBA" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a foro_dba+unsubscribe@googlegroups.com.
Para acceder a más opciones, visita https://groups.google.com/d/optout.

Franky

unread,
Nov 8, 2016, 11:34:39 AM11/8/16
to foro...@googlegroups.com
Vaya...si te interesa muevo tu CV por mi empresa, aunque son piratillas....vamos, como todas las cárnicas :-)

Historificamos....el problema es liberar el espacio cuando borramos. Para que te hagas una idea, es la tabla donde se guardan los cdrs (que serían todas las llamadas, todas las conexiones de datos y todos los sms) de todos los clientes. Guardamos el mínimo de 4 meses que se nos exige por ley, pero el tema es ese, que no se libera el espacio que borramos y el shrink es realmente bestia....

Mario Martinez

unread,
Nov 8, 2016, 11:47:44 AM11/8/16
to foro...@googlegroups.com

Hola Frank!!

Por las tierras catalanas sigue todo bien. Aquí continuó en IBM para un proyecto de gas natural y otro de la Generalitat.

La otra opción que veo pero que requiere de un corte de servicio es la exportación de la tabla grande (solo de la tabla que requieras en caso de que no tenga relaciones con otras), la borras de la bbdd y la vuelves a importar. Puedes hacer pruebas para ver cuánto tiempo te lleva todo el proceso y ver si merece la pena esta opción.

Si la tabla tuviera relación con otras tablas pues sería mejor realizar la exportación, borrado de objetos e importación de todo el esquema.

Saludos a todos!!


--

Cristina Garcia

unread,
Nov 8, 2016, 11:47:58 AM11/8/16
to foro...@googlegroups.com

Muchas gracias, te digo algo.

Yo lo haría con el volcado a la otra tabla, haces en un mismo movimiento el quitarte los registros que ya tienen 4 meses,  la fragmentación de la tabla y como creas nuevos los índices, los mantienes.

JAP

unread,
Nov 8, 2016, 1:21:57 PM11/8/16
to foro...@googlegroups.com
Buenas.

Me alegra ver que todo os va (u os sigue yendo) bien o lo mejor posible.

Veamos, la SOLUCIÓN la ha aportado Macarro… pero claro, están las molestias del corte de servicio.

La historificación es un “paliativo” que como bien decís, vacía la tabla (parte objeto) pero no recupera las extensiones vacías (parte segmento)… Así que cuando borras filas hay dos cosas que NO se controlan (al menos fácilmente): que borres todas las filas de un bloque, lo que lo vaciaría realmente y 2 que cuando SI vacías un bloque, al mismo tiempo vacíes los bloques contiguos que conforman la extensión.

Otro “paliativo” es el particionamiento, ya que cuando “historificas” una partición (se supone que a otra tabla particionada o no pero que estará en otro tablespace que estará construido sobre almacenamiento más barato), claro que podrías no “historificar” o hacerlo con INSERT as SELECT, entonces le haces un TRUNCATE a la partición y recuperas (si quieres) todo el espacio. Claro que para esto necesitas licencia Enterprise y Extra Cost Option.

Dentro de Enterprise también puede hacerse (no recuerdo con cual de las multiples Extra Cost Options) un SHRINK de la tabla “on-line” es decir, que la operacion que tanto te tarda, tardará MÁS, pero los datos estarán disponibles y al terminar, te libera el espacio completamente… ¿Magia?… pues no, una combinación de todo lo que hemos descrito anteriormente; es decir, Oracle crea un segmento nuevo (tabla) con nombre interno que NADIE salvo el proceso mismo puede ver, entonces hace un INSERT AS SELECT (como dijo Cristina) usando extensiones nuevas y cuando termina, reconstruye los índices (asociándolos a la nueva tabla), hace un RENAME de la nueva y DROP de la vieja.

¿Solo se puede hacer con un Extra Cost Option y pagando un pastizal a Larry?… pues NO, es cuestión de ponerse a trabajar y currarse unos 10 PL/SQL (no desde cero pq son llamadas a diferentes DBMS y JOBs) que hagan esos pasos (os recomiendo que en una BBDD montanda en una VM que después podáis destruir hagáis una emulación del proceso, por ejemplo desde el EM o llamando al paquete DBMS_REDEFINITION o algo así), veréis como Oracle crea un buen número de JOBs que harán, en mayor o menor medida, lo que acabo de describir.

Ah, un pequeño detalle más… lo que no viene en los White Paper de Oracle cuando quieren vender una Extra Cost Option… para ese trabajo, necesitáis tener el mismo espacio que tenga la tabla más sus indices actualmente y un espacio proporcional en TEMP y UNDO… vamos que tampoco por ahí es gratis. Eso si, considerad las horas de curro que os supondría hacer todo lo que os digo (más el conocimiento) y pensad que realmente Oracle cobra una pasta pq ha invertido tiempo y dinero en que alguien haga esas cosas para nosotros… :-D

Por último, en 12c existe algo que requiere partitioning pero que va historificando automáticamente de almacenamiento caro a barato (aunque esto es opcional) por una política de uso (hot blocks —> cold blocks) que define cada uno en su bbdd.

Como veis, sigo siendo la “alegría” de la huerta… a vuestros gerentes (no técnicos) les encantan los unicornios de colores que hacen que las cosas costosas sean gratis y sin esfuerzo.. a mi, no… bueno, a mi si me gustan, pero no existen… 

Un abrazo a todos!!!


—*
José Antonio de Pablo Jiménez
Principal IT Consultant & CTO
SYSCONFIG Gestión de Sistemas, SLU
Skype: japidba

Para cancelar la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a foro_dba+unsubscribe@googlegroups.com.

JAP

unread,
Nov 8, 2016, 1:34:27 PM11/8/16
to foro...@googlegroups.com
Buenas… again…

Aquí https://oracle-base.com/articles/10g/online-table-redefinition-enhancements-10gr1 mi “amigo” Tim Hall os da un ejemplo de “online” table_redefinition… y esta es la docu (donde siempre debéis ir.. jajajajajajajaja)… http://docs.oracle.com/database/121/ADMIN/tables.htm#ADMIN-GUID-92361F74-4796-407D-A3B9-569C6E544E34

Un abrazo (si, otro)… :P

—*
José Antonio de Pablo Jiménez
Principal IT Consultant & CTO
SYSCONFIG Gestión de Sistemas, SLU
Skype: japidba

Reply all
Reply to author
Forward
0 new messages