Tablespaces con Block Size diferentes

[MarioHeredia]

Hola a todos,

Necesito ayuda con este problema que tengo.
A medida que uno va aprendiendo va corrigiendo errores y es exactamente lo que quiero hacer ahora.

Cuando la base fue creciendo fui separando las tablas en tablespaces, que me servian para separar la frecuencia de los datos entre otras cosas, pero utilice diferentes tipos de block_size y esto ahora me esta afectando.

Tengo un ratio de eficiencia del 64% en los tbs con un block_size de 2k. Y un 99% de efectividad en los tbs que tiene un block_size de 8k.

Se que la solucion es migrar las tablas a tbs nuevos con un block_size de 8k.
Entonces, la pregunta es.

¿Cual es la mejor manera de migrar las tablas?
¿Que pasos a seguir se recomienda para obtener el menor impacto en la BD?

Se entiende el problema?
Les agradezco la colaboracion.

Les mando un saludo grande,
Mario.

[matanga]

Tengo un ratio de eficiencia del 64% en los tbs con un block_size de 2k. Y un 99% de efectividad en los tbs que tiene un block_size de 8k

Este comportamiento es comprensible, el bloque es la unidad mínima que gestiona el motor para subir y bajar los datos entre el tablespace y cache, un bloque de 2k es pequeño y almacena pocas filas, esto decrece la probabilidad de encontrar una fila en cache lo que puede ser uno de los motivos de un ratio tan bajo. También existe otra consideración, siempre es buena idea que el tamaño del bloque sea múltiplo al tamaño del bloque del sistema operativo (por ejemplo: para un os block size de 8k definir un db block size de 8k, 16k, etc), esto incrementa la eficiencia de la cache a nivel del sistema operativo, piensa que si tienes un db block size de 2k y un os block size de 8k, cuando se sube un db block a memoria en la base de datos, se está subiendo un os block de 8k donde 6k son innecesarios.

¿Cual es la mejor manera de migrar las tablas?
¿Que pasos a seguir se recomienda para obtener el menor impacto en la BD?

1. Utilizar la sentencia alter table table_name move nuevo_tablespace, y además, tras la ejecución es necesario hacer un rebuild de los índices ya que al mover la tabla se crear nuevos rowid dejando los índices en estado unusable, y actualizar las estadísticas ya que las condiciones de almacenamiento como por ejemplo cantidad de extents, cantidad de filas por bloque, filas anidadas, filas migradas, etc. en el nuevo tablespace serán diferentes por lo que las estadísticas existentes serán incorrectas. En cuanto a impacto, lo bueno es que es un método simple, los posibles errores son predecibles, es seguro y en caso de fallo se puede relanzar el proceso sin problemas, y lo malo es que se bloquea la tabla en la ejecución y las consultas que utilicen los indices darán error hasta que se haga el rebuild.

2. Utilizar el paquete DBMS_REDEFINITION, codificar el proceso es más complejo pero permite mover la tabla online, solo merece la pena si el bloqueo del move es un problema.

3. Crear una tabla en el nuevo tablespace y pasar los datos con un select, esto sería algo como:

Código:

create table tabla_nueva tablespace tablespace_nuevo
as select * from tabla_vieja;

create index index_name on tabla_nueva;

create trigger trigger_name on tabla_nueva;

drop table tabla_vieja;

alter table tabla_nueva rename to tabla_vieja;

En este caso, la tabla es accesible durante el proceso pero solo como readonly, cualquier cambio que se haga se perderá con el drop y codificar el proceso es más complejo porque tiene que contemplar la definición de índices, triggers y constraints. Igual que el punto 2, solo merece la pena si necesitas evitar el bloqueo.

Saludos

[MarioHeredia]

Ok Matanga, entonces serian estos los (mejores) pasos para solucionar el problema de un tbs con un tamaño de blck_size inadecuado.

Pasos:

1. Crear un nuevo tbs con un blck_size de 8k.
2. Recrear las tablas, restricciones e indices del viejo tbs al nuevo tbs.
3. Eliminar la vieja tabla (dejar el sinonimo publico si existe, porque seguira siendo util).
4. Cambiar el nombre de la nueva tabla por el nombre de la vieja tabla.

Matanga Querido, lo tengo !!!
Voy a comenzar con los tbs que considero mas significativos.

Te mando un saludo grande y muchas gracias.
Mario.

[matanga]

Hola Mario, me parece que hay un error en mi respuesta, repasando la documentación veo que un alter table table_name move solo requiere de un lock tipo exclusive, es decir, mientras se está moviendo la tabla, las operaciones DML de otras sesiones estarán en espera, pero los SELECT tendrán respuesta inmediata con consistencia read-committed. Teniendo esto en cuenta, puede que sea mejor la opción 1, ya que de manera más simple, ofrece el mismo resultado y accesibilidad sobre los datos que la opción 3.

En resumen, los pasos y un ejemplo pueden ser:

1. Crear el nuevo tablespace.
2. Mover las tablas al nuevo tablespace
3. Rebuild de índices con la opción de moverlos a un nuevo tablespace.
4. Actualizar las estadísticas.

Código:

begin
 for t in ( select owner, table_name 
                 from dba_tables 
                 where tablespace_name = 'tablespace_viejo' ) loop

  --move de cada tabla.
  --el comando varía para columnas tipo LOB y tablas particionadas.
  --también soporta parallel. 
  execute immediate 
       'alter table '|| t.owner ||'.'|| t.table_name ||
           ' move tablespace tablespace_nuevo';
  
  --para tener los datos disponibles en forma inmediata
  --un rebuild de índices con estado unusable después de cada move 
  for i in ( select owner, index_name 
                 from dba_indexes
                 where table_name = t.table_name
                 and table_owner = t.owner ) loop

    --rebuild sobre el mismo tablespace
    execute immediate 
         'alter index '|| i.owner ||'.'|| i.index_name ||' rebuild';

    --o bien, rebuild y mover a un tablespace diferente
    --execute immediate 
          --'alter index '|| i.owner ||'.'|| i.index_name ||
                --' rebuild tablespace_nuevo';

  end loop;

  --y por cada move y rebuild, 
  --actualizar las estadísticas para el optimizador.
  dbms_stats.gather_table_stats(t.owner, t.table_name);

 end loop;

end;
/

Saludos

[MarioHeredia]

Matanga querido, como te va?

Che, el move funciona al pelo con tablas sin particionar.
Pero tengo muchas tablas con particiones, vos que me recomendas?

Y muchas gracias desde ya por cualquier comentario.

Te mando un saludo grande.
Mario.

[matanga]

En partitioning, las tablas solo permiten operaciones lógicas sobre los datos, son las particiones las que se encargan de los temas físicos como pueden ser la definición del tablespace o la forma de alocar extents. En este caso particular, una tabla se mueve ejecutando el comando move sobre cada una de sus particiones.

Código:

--tabla t1 con dos particiones p1 y p2
ALTER TABLE t1
 MOVE PARTITION p1 TABLESPACE tablespace_nuevo;
ALTER TABLE t1
 MOVE PARTITION p2 TABLESPACE tablespace_nuevo;

También habría que considerar los segmentos de tipo LOB ya que tienen una definición de almacenamiento independiente y por defecto el move no los mueve junto con la tabla. En este caso, hay que definir en el comando un tablespace para la tabla y uno para el LOB.

Código:

--mover la tabla t1 y la columna lob c1
ALTER TABLE t1 MOVE
 LOB(c1) STORE AS (TABLESPACE tablespace_nuevo) --ts para el lob 
 TABLESPACE tablespace_nuevo; --ts para la tabla

--mover solo la tabla t1 
ALTER TABLE t1
 MOVE TABLESPACE tablespace_nuevo;

Saludos