Ver Mensaje Individual
  #2 (permalink)  
Antiguo 02/12/2011, 18:05
Avatar de matanga
matanga
 
Fecha de Ingreso: octubre-2007
Ubicación: España
Mensajes: 1.091
Antigüedad: 17 años
Puntos: 85
Respuesta: Tablespaces con Block Size diferentes

Cita:
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.

Cita:
¿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