¿Por qué DB2 sugiere una tabla por espacio de tabla?

Question

Los documentos DB2 para DB2/Z V10 tienen el siguiente fragmento en el sección de espacios de tabla:

Como regla general, debe tener solo una tabla en cada espacio de mesa.

Pero en realidad no proporciona ninguna justificación para esto.

Tenemos algunas tablas que almacenan información histórica basada en el tiempo a lo largo de las siguientes líneas (muy reducidas en complejidad pero deberían ser suficientes para ilustrar):

Table HOURLY_CPU_USAGE:
    RecDate        date
    RecTime        time
    Node           char(32)
    MaxCpuUsage    float
    primary key    (RecDate, RecTime, Node)
Table DAILY_CPU_USAGE:
    RecDate        date
    Node           char(32)
    MaxCpuUsage    float
    primary key    (RecDate, Node)
Table MONTHLY_CPU_USAGE:
    RecDate        date
    Node           char(32)
    MaxCpuUsage    float
    primary key    (RecDate, Node)

(La tabla diaria tiene todos los registros por hora enrollados en un solo día, y la tabla mensual hace lo mismo con los datos diarios, enrollándolo en la fila con la fecha YYYY-MM-01).

Ahora me parece que estas tablas son muy similares en propósito y no estoy seguro por qué Queremos mantenerlos en espacios de tabla separados.

Descuento por ahora la posibilidad de combinarlos en una sola mesa, esa es una sugerencia que he hecho, pero hay complicaciones que lo evitan.

Qué es ¿La justificación detrás de la guía "Una tabla por espacio de tabla"? ¿Cuáles son las excepciones, si las hay? Supongo que son mayo Sea excepciones, ya que parece una guía en lugar de una regla dura y rápida.

Answer 1

Solo una suposición salvaje ... pero tal vez IBM recomienda no más de una mesa por espacio de mesa porque muchos utilidades de DB/2 operan al nivel del espacio de la mesa. Si coloca varias tablas en un espacio de mesa, entonces los servicios públicos funcionan en todas las tablas como una unidad.

Por ejemplo, copia de seguridad y restauración del trabajo en el nivel de espacio de mesa. No puede hacer una copia de seguridad/restaurar tablas individuales dentro del mismo espacio de mesa. Todos están respaldados o restaurados como una unidad. Creo que el mismo tipo de cosas se aplica a otras utilidades y probablemente para muchos parámetros de ajuste también.

Answer 2

En estos días, la razón principal para mantener una tabla por espacio de tabla es administrativa. La mayoría de los servicios públicos de DB2 funcionan en el nivel de espacio de mesa. Por ejemplo, si realiza un reemplazo de carga en un espacio de tabla para una tabla específica, todas las otras tablas terminarán vacías como lo primero que hace la carga reemplazar es eliminar todas las filas.

Entonces, "¿Por qué no conservarías una mesa por espacio de mesa?". Creo que es razonable e incluso deseable incluir múltiples tablas en un solo espacio de tabla cuando la tabla está relacionada con la medida en que uno es inútil sin el otro. P.ej. CustomerTable + NextCustomerIdTable.

Otra consideración es el tipo de espacio de mesa. Dependiendo del tipo de espacio de tabla que haya creado, podría haber implicaciones de rendimiento con la creación de múltiples tablas en un solo espacio de tabla. Si no está utilizando espacios de mesa segmentados, un escaneo de espacio de mesa leerá todas las páginas en el espacio de la tabla, incluidas las páginas de otras tablas. Consulte el tema "Table Space Scan" aquí: http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=%2FCOM.IBM.DB2.doc.ve%2FDVNHLPCN_TABLESCAN.HTM

Answer 3

Se ve que han cambiado el texto en su documentación.

los Enlace proporcionado en la pregunta ahora contiene la siguiente información:

El número de tablas que debe definir en un espacio de tabla depende de las características de las tablas:

Si una mesa puede ser grande en tamaño, es mejor poner la mesa en su propio espacio de mesa. Este diseño simplifica el ajuste de rendimiento y, en particular, el ajuste de la piscina de búfer. Para tablas más pequeñas, los espacios de mesa segmentados de múltiples tablas son mejores. Este diseño ayuda a reducir la cantidad de conjuntos de datos que deben administrarse para la copia de seguridad y la recuperación, y la cantidad de conjuntos de datos que el sistema de base de datos necesita abrir y cerrar durante las operaciones de DB2.

Es mejor minimizar el número de espacios de tabla en cada base de datos por las siguientes razones:

Durante la ejecución de las declaraciones de definición de datos, el sistema de base de datos contiene un bloqueo exclusivo en toda la base de datos hasta que se ejecuta una operación de confirmación. El bloqueo exclusivo realiza las siguientes funciones: el bloqueo exclusivo previene las ejecuciones concurrentes de las declaraciones de definición de datos para tablas e índices en la misma base de datos. Si el caché de la declaración dinámica está deshabilitado (parámetro del subsistema Cachedyn = no), el sistema de la base de datos utiliza el bloqueo de la base de datos para serializar la ejecución de las declaraciones de definición de datos y las declaraciones dinámicas de SQL que acceden a las tablas e índices en la base de datos.

Si hay menos espacios de tabla en la base de datos, menos espacios de tabla se bloquean simultáneamente. Durante la ejecución de la fase de conmutación de operaciones de utilidad Reorg en línea, el sistema de base de datos obtiene un bloqueo exclusivo en toda la base de datos para serializar la ejecución de las operaciones REORG en línea y las declaraciones de definición de datos en tablas e índices en la base de datos.

Si hay menos tablas en la base de datos, se bloquean simultáneamente menos tablas. El volumen de registro para las declaraciones de definición de datos es menor cuando se encuentran menos espacios de tabla en la base de datos.

Answer 4

En general, es porque las opciones de rendimiento tienden a ser mejores para las configuraciones de "una tabla por espacio de tabla". Por ejemplo, la capacidad de realizar una parada limitada para ciertas consultas si la tabla está dividida (que requiere 1 TB por TS).

(Pero como persona de rendimiento de mainframe, diría eso, ¿no?) :-)