Perché DB2 suggerisce una tabella per tablespace?

Question

I documenti DB2 per DB2/Z V10 hanno il seguente frammento nel sezione tablespaces:

Come regola generale, dovresti avere solo una tabella in ogni spazio della tabella.

Ma in realtà non fornisce alcuna logica per questo.

Abbiamo alcune tabelle che memorizzano informazioni storiche basate sul tempo lungo le seguenti righe (notevolmente ridotte in complessità ma dovrebbero essere sufficienti per illustrare):

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 tabella giornaliera ha tutti i record orari arrotolati in un solo giorno e la tabella mensile fa lo stesso con i dati giornalieri, rimpicchiandolo nella riga con data YYYY-MM-01).

Ora mi sembra che questi tavoli siano tutti molto simili di scopo e non sono certo perché Vorremmo tenerli in tablespace separati.

Sconto Per ora la possibilità di combinarli in un singolo tavolo, questo è un suggerimento che ho fatto, ma ci sono complicazioni che lo impediscono.

Che cosa è La logica dietro la linea guida "una tabella per tablespace"? Quali sono le eccezioni, se presenti? Suppongo che lo siano Maggio essere eccezioni poiché sembra una linea guida piuttosto che una regola dura e veloce.

Answer 1

Solo un'ipotesi selvaggia ... ma forse IBM raccomanda non più di un tavolo per spazio da tavolo perché molte utility dB/2 operano a livello dello spazio del tavolo. Se si inseriscono più tabelle in uno spazio della tabella, le utility operano su tutte le tabelle come unità.

Ad esempio, il backup e il ripristino del lavoro a livello di spazio del tavolo. Non è possibile eseguire il backup/ripristinare singole tabelle all'interno dello stesso spazio della tabella. Sono tutti backup o restaurati come unità. Credo che lo stesso tipo di cose si applichi ad altre utility e probabilmente anche per molti parametri di sintonia.

Answer 2

In questi giorni il motivo principale per il mantenimento di una tabella per spazio della tabella è amministrativo. La maggior parte delle utility DB2 funzionano a livello di spazio del tavolo. Ad esempio, se si esegue un carico Sostituisci su uno spazio della tabella per una tabella specifica, tutte le altre tabelle finiranno vuote poiché la prima cosa che il carico di sostituzione fa è eliminare tutte le righe.

Quindi "Perché non dovresti tenere una tabella per spazio da tavolo?". Penso che sia ragionevole e persino desiderabile includere più tabelle in un singolo spazio da tavolo quando la tabella è correlata alla misura in cui l'uno è inutile senza l'altro. Per esempio. Personalizzato + nextcustomeridtable.

Un'altra considerazione è il tipo di spazio sul tavolo. A seconda del tipo di spazio della tabella che hai creato potrebbero esserci implicazioni per la creazione di più tabelle in un singolo spazio da tavolo. Se non si utilizza gli spazi della tabella segmentati, una scansione dello spazio della tabella leggerà tutte le pagine nello spazio della tabella, comprese le pagine di altre tabelle. Vedi Argomento "Scansione spaziale Table" qui: http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=%2fcom.ibm.db2.doc.ve%2fdvnhlpcn_tablescan.htm

Answer 3

Legola che hanno cambiato il testo sulla loro documentazione.

Il collegamento fornito alla domanda ora contiene le seguenti informazioni:

Il numero di tabelle che dovresti definire in uno spazio della tabella dipende dalle caratteristiche delle tabelle:

Se un tavolo potrebbe diventare grande di dimensioni, è meglio mettere il tavolo nel proprio spazio del tavolo. Questo design semplifica la messa a punto delle prestazioni e, in particolare, la messa a punto del pool di buffer. Per le tabelle più piccole, gli spazi di tabelle segmentati a tabella multipla sono migliori. Questo progetto aiuta a ridurre il numero di set di dati che devono essere gestiti per il backup e il recupero e il numero di set di dati che il sistema di database deve aprire e chiudere durante le operazioni DB2.

È meglio ridurre al minimo il numero di spazi della tabella in ciascun database per i seguenti motivi:

Durante l'esecuzione delle dichiarazioni di definizione dei dati, il sistema di database detiene un blocco esclusivo sull'intero database fino a quando non viene eseguita un'operazione di impegno. Il blocco esclusivo esegue le seguenti funzioni: Il blocco esclusivo impedisce le esecuzioni simultanee delle dichiarazioni di definizione dei dati per tabelle e indici nello stesso database. Se la cache dell'istruzione dinamica è disabilitata (parametro del sottosistema Cachedyn = NO), il sistema di database utilizza il blocco del database per serializzare l'esecuzione delle istruzioni di definizione dei dati e le istruzioni dinamiche SQL che accedono a tabelle e indici nel database.

Se nel database sono bloccati contemporaneamente meno spazi della tabella, meno spazi della tabella sono bloccati. Durante l'esecuzione della fase switch delle operazioni di utilità REorg online, il sistema di database ottiene un blocco esclusivo sull'intero database per serializzare l'esecuzione delle operazioni di reorg online e le istruzioni di definizione dei dati su tabelle e indici nel database.

Se nel database sono bloccati contemporaneamente meno tabelle, meno tabelle sono bloccate. Il volume di registrazione per le istruzioni di definizione dei dati è più piccolo quando meno spazi della tabella si trovano nel database.

Answer 4

Generalmente è perché le opzioni delle prestazioni tendono ad essere migliori per le configurazioni "una tabella per tablespace". Ad esempio la capacità di eseguire la scansione di partizione limitata per alcune query se la tabella è partizionata (che richiede 1 TB per TS).

(Ma come persona di performance mainframe lo direi, no?) :-)