Una de las partes más importantes en el diseño de una Base de Datos es el diseño de los Tablespaces.

Con la evolución de la Base de Datos Oracle y la evolución de las tecnologías de Storage (discos), se hace necesario una evolución del diseño de los tablespaces.

Para el diseño de los tablespaces tendremos en cuenta lo siguiente:

• Que se pueda adaptar al 99% de las Bases de Datos.
• Que no sea complejo el crear y administrar los tablespaces.
• Que sea escalable en cuanto al tamaño de la Base d Datos.
• Que sea escalable con el hardware.
• Que se adapte fácilmente a la evolución del hardware.
• Que evite los posibles cuellos de botella en el sistema.

Podemos adelantar que el diseño es una aplicación práctica del método SAME: Stripe And Mirror Everywhere. O bien: Reparte los datos y duplícalos por todas partes. Este método se basa en repartir los datos entre todos los discos y que, además, los discos entén en mirror.

En nuestro caso, la adaptación intenta evitar los abusos que se han dado en su implementación y evitar los cuellos de botella.

Diseño en un entorno NO RAC

Donde deben estar los datos

En un entorno No RAC, los datos pueden residir en:

• Filesystem
• ASM
• Raw Devices
• (Clustered FileSystems)

Se ha escrito mucha literatura acerca de que los datos en FileSystem son más lentos de acceso que en el resto de los casos. Como consecuencia, a priori, podríamos desechar el crear los Tablespaces sobre FileSystems.

Lo que no se conoce tan extrensamente es que, para los datos en FileSystem, el Sistema Operativo mantiene una Caché de los mismos (independiente de otras cachés) y que para el resto de los sistemas, no hay caché de datos a nivel de Sistema Operativo.

Actualmente, la diferencia de tiempo de acceso según que los datos estén en FileSystem o Raw Devices o ASM se ha igualado considerablemente.

Por tanto:

• Primera decisión: Los Tablespaces/Datafiles residirán en FileSystem
  

Tipos de Tablespaces que hay en una Base de Datos

 Podemos clasificar los Tablespaces de una Base de Datos según:

• Tablespaces de Sistema
  • SYSTEM
  • SYSAUX
  • TEMP
  • UNDO/Rollback Segments
• Tablespaces de Usuario
  • Los que contienen datos de las aplicaciones

Los tablespaces tipo TOOLS, USERS y similares tendrán consideración de Sistema o Usuario según contengan o no datos de las aplicaciones

Diseño de Tablespaces de Usuario

Proponemos un diseño de Tablespaces de Usuario tal que:

• Se deben crear 4 u 8 FileSystems distintos.
  • Se debe procurar que estos FileSystems residan en distintos discos/RAIDs
  • No obstante, aunque no se pueda asegurar, se deben crear sobre 4 u 8 FileSystems aunque estos FileSystems residan sobre los mismos discos  o RAIDs
    • Con esto se evitan las posible contenciones debidas al header de FileSystem.
• Todos tienen el mismo tamaño.
  • Se estima que el tamaño de Tablespace debe estar comprendido entre 50 Gb y 100 Gb
    • Este valor es un número de compromiso entre la manejabilidad del Tablespace (suficientemente pequeño) y el número de Tablespaces (Fácil de administrar)
  • El número de Tablespaces será el cociente de dividir el tamaño de la Base de Datos por el tamaño de cada Tablespace.
• Todos los Tablespaces tienen el mismo número de Datafiles y, en cada Tablespace, los Datafiles son del mismo tamaño.
  • El número de Datafiles se estima en 4 u 8.
    • Cada Datafile debe estar en un FileSystem distinto.
    • Este valor es un compromiso entre la manejabilidad del Datafile (suficientemente pequeño), el número de Datafiles (Fácil de administrar) y el evitar cuellos de botella en los headers de Datafile.
  • El tamaño de cada Datafile será de 12 .. 24 Gb
    • Debe tenerse en cuenta que el máximo tamaño de un Datafile con un tamaño de bloque de 8 Kb es de 32 Gb.
• Al crear el Tablespace, se creará con todos los Datafiles y del mismo tamaño. Si se desea, se pueden crear con un tamaño pequeño y AutoExtent
  • De esta forma, los datos se repartirán de forma uniforme en todos los Datafiles (Método SAME).
• Si un Tablespace debe crecer más allá de estos límites:
  • O bien se añaden 4 Datafiles del mismo tamaño
  • O bien se migran datos a otros tablespaces. Esta opción es la preferida.
• Todos los Tablespaces se definirán como:
  • Locally Managed: Para evitar contención en el Tablespace SYSTEM y la posibilidad de fragmentación del espacio libre.
  • Segment Space Auto: Para evitar contenciones en las Free Queues y los bloques de datos

EXTEND MANAGEMENT LOCAL AUTOALLOCATE

SEGMENT SPACE MANAGEMENT AUTO

Obsérvese que, con este diseño de Tablespaces:

• Todos los Tablespaces son equivalentes.
• No se distingue entre Tablespaces para Datos y Tablespaces para Índices: un mismo Tablespace puede contebner Datos e índices
• Aunque el sistema solo aceda a los datos de un único Tablespace, dado el método SAME utilizado, la Base de Datos será capaz de utilizar, como mínimo, el 80% de la potencia total del acceso a disco.
  • Estos datos se han obtenido de forma empírica
• Finalmente, con este diseño de Tablespaces, no nos debemos preocupar de en Tablespace poner los datos/indices. Basta con ponerlos en algún Tablespace que tenga suficiente espacio libre.
  • Esto facilita enormemente el diseño de la Base de Datos.

Diseño de Tablespaces de Sistema

Para los Tablespaces de Sistema se indica:

• Tablespace SYSTEM y SYSAUX: un único Datafile. Si es posible, en FileSystems distintos.
  • Después del arranque de la Base de Datos, la actividad del Tablespace SYSTEM debe ser mínima: si tiene mucha actividad, se requiere un tuning debido a que la Base de Datos irá lenta.
  • Para el Tablespace SYSAUX, básicamente contiene los datos del AWK (Statspack) y la mayor actividad es de Insert con un único proceso: no hay contención debido a que no hay concurrencia.
• Tablespace TEMP
  • Deben crearse como TEMPORARY y con un tamaño de extent fijo
    • El tamaño de extent debe, aproximadamente, el tamaño del Tablespace dividido por el número máximo de sesiones dividido por 3.
    • Es decir: que cada sesión tenga derecho a unas 3 extensiones de TEMP.
  • Pueden crearse con 2 datafiles en FileSystems distintos
• Tablespace UNDO
  • Debe crearse como UNDO
  • Puede craerse con 2 datafiles en Filesystems distintos entre sí y distintos de los del tablespace TEMP.

Diseño en un entorno RAC

En un entrono RAC no se puede crear la Base de Datos sobre FileSystem.

Vamos a ver las diferencias a considerar al crear na Base d Datos para un entorno RAC.

Donde deben estar los datos

Proponemos que los datos estén en ASM:

• Es estable
• Es gratuito
• Para las versiones RAC con Licencia Standar Edition es obligatorio (Versiones 10.2 y 11 como mínimo).

Diseño de Tablespaces de Usuario

Adaptando lo anteriomente dicho a ASM, poponemos:

• Crear un único ASM GROUP para la Base de Datos
  • Este ASM Group debe estar formado por 4 u 8 LUNs del mismo tamaño
  • Si la Base de Datos fuera muy grande, se pueden crear dos o más ASM GROUPs
• Cada Tablespace estará formado por 4 u 8 Datafiles del mismo tamaño
  • Por supuesto, si solo hay un único ASM GROUP, todos los Datafiles estarán sobre el mismo ASM GROUP.

Para el ersto, se seguirán las mismas indicaciones que para el diseño NO RAC.

Diseño de Tablespaces de Systema

Se seguirán las indicaciones del diseño para NO RAC, pero todos los Datafiles estarán en el mismo ASM GROUP.