Quanto dovrei fare il mio log attivo?

Stima della dimensione del log attivo necessaria per un gestore code.

La dimensione del log attivo è limitata da:
logsize = (primaryfiles + secondaryfiles) * logfilepages * 4096

Il log dovrebbe essere abbastanza grande da gestire la transazione in esecuzione da più tempo quando il gestore code scrive la quantità massima di dati al secondo sul disco.

Se la transazione in esecuzione da più tempo per N secondi e la quantità massima di dati al secondo scritti sul disco dal gestore code è B byte al secondo nel log, il log deve essere almeno:
logsize >= 2 * (N+1) * B

È probabile che il gestore code stia scrivendo la quantità massima di dati al secondo sul disco quando si sta eseguendo il carico di lavoro di picco o quando si stanno registrando le immagini dei supporti.

Se una transazione viene eseguita per un periodo di tempo tale che l'estensione del log contenente il primo record di log non è contenuta nel log attivo, il gestore code esegue il rollback delle transazioni attive una alla volta, a partire dalla transazione con il record di log più vecchio.

Il gestore code deve rendere inattive le vecchie estensioni di log prima di utilizzare il numero massimo di file primari e secondari e il gestore code deve assegnare un'altra estensione di log.

Decidere per quanto tempo si desidera eseguire la transazione più lunga, prima che al gestore code sia consentito eseguire il rollback. La transazione con esecuzione più lunga potrebbe essere in attesa di un traffico di rete lento o, nel caso di una transazione mal progettata, in attesa di input dell'utente.

È possibile esaminare il tempo di esecuzione della transazione più lungo, immettendo il seguente comando runmqsc :
DISPLAY CONN(*) UOWLOGDA UOWLOGTI

L'immissione del comando dspmqtrn -a mostra tutti i comandi XA e non XA in tutti gli stati.

L'immissione di questo comando elenca la data e l'ora in cui è stato scritto il primo record di log per tutte le transazioni correnti.
Attenzione: per calcolare la dimensione del log, è l'ora in cui è stato scritto il primo record di log che conta, non l'ora in cui è stata avviata l'applicazione o la transazione. Arrotondare la lunghezza della transazione più lunga al secondo più vicino. Ciò è dovuto alle ottimizzazioni nel gestore code.

Il primo record di log può essere scritto molto tempo dopo l'avvio dell'applicazione, se l'applicazione inizia, ad esempio, con l'emissione di una chiamata MQGET che attende per un periodo di tempo prima di ricevere effettivamente un messaggio.

Esaminando la data e l'ora massima osservata dall'output
DISPLAY CONN(*) UOWLOGDA UOWLOGTI
il comando immesso in origine, dalla data e ora correnti, è possibile stimare per quanto tempo viene eseguita la transazione in esecuzione più a lungo.

Accertarsi di eseguire questo comando runmqsc ripetutamente mentre le transazioni con esecuzione più lunga sono in esecuzione nel carico di lavoro di picco in modo da non sottovalutare la lunghezza della transazione con esecuzione più lunga.

In IBM® MQ 8.0 utilizzare gli strumenti del sistema operativo, ad esempio iostat su piattaforme UNIX .

È possibile rilevare i byte al secondo che il gestore code sta scrivendo nel log immettendo il seguente comando:
amqsrua -m qmgr -c DISK -t Log
I byte logici scritti, mostrano i byte al secondo che il gestore code sta scrivendo nel log. Ad esempio:

$ amqsrua -m mark -c DISK -t Log
Publication received PutDate:20160920 PutTime:15383157 Interval:4 minutes,39.579 seconds
Log - bytes in use 37748736
Log - bytes max 50331648
Log file system - bytes in use 316243968
Log file system - bytes max 5368709120
Log - physical bytes written 4334030848 15501948/sec
Log - logical bytes written 3567624710 12760669/sec
Log - write latency 411 uSec

In questo esempio, i byte logici al secondo scritti nel log sono 12760669/sec o circa 12 MiB al secondo.

Utilizzo di
DISPLAY CONN(*) UOWLOGDA UOWLOGTI
ha mostrato che la transazione con esecuzione più lunga era:

CONN(57E14F6820700069)
EXTCONN(414D51436D61726B2020202020202020)
TYPE(CONN)
APPLTAG(msginteg_r)                     UOWLOGDA(2016-09-20)
UOWLOGTI(16.44.14)
Poiché la data e l'ora correnti erano 2016-09-20 16.44.19, questa transazione era in esecuzione da 5 secondi. Tuttavia, è necessario tollerare le transazioni in esecuzione per 10 secondi prima che il gestore code esegua il rollback. Quindi la dimensione del log dovrebbe essere:
2 * (10 + 1) * 12 = 264 MiB
.

Il numero di file di log deve essere in grado di contenere la dimensione di log massima prevista (calcolata nel testo precedente). Questo sarà:

Numero minimo di file di log = (Dimensione log richiesta) / (LogFilePages * dimensione pagina file di log (4096))

Utilizzando il valore predefinito LogFilePages, che è 4096, e la stima della dimensione del log di 264MiB, calcolata nel testo precedente, il numero minimo di file di log dovrebbe essere:
264MiB / (4096 x 4096) = 16.5
cioè 17 file di log.
Se si dimensiona il log in modo che il carico di lavoro previsto venga eseguito all'interno dei file primari:
  • I file secondari forniscono una certa contingenza nel caso in cui sia necessario ulteriore spazio di log.
  • La registrazione circolare utilizza sempre i file primari preassegnati, che è marginalmente più veloce dell'allocazione e della deallocazione dei file secondari.
  • Il gestore code utilizza solo lo spazio rimanente nei file primari per calcolare quando eseguire il successivo checkpoint.
Pertanto, nell'esempio precedente, impostare i seguenti valori in modo che il workload venga eseguito all'interno dei file di log primari:
  • LogFilePages = 4096
  • LogPrimaryFiles = 17
  • LogSecondaryFiles = 5
Tieni presente quanto segue:
  • In questo esempio, 5 secondario è più del 20% dello spazio di log attivo.

    Il programma di registrazione tenta di mantenere il carico di lavoro nei soli file primari. Di conseguenza, il programma di registrazione pianifica i punti di controllo quando una frazione dei soli file primari è piena.

    Avere i file secondari è una contingenza, nel caso in cui ci siano transazioni di esecuzione inaspettatamente lunga.

    Tenere presente che il gestore code esegue un'azione per ridurre l'utilizzo dello spazio di log quando più dell ' 80% dello spazio di log totale è in uso.

  • Eseguire lo stesso calcolo se si utilizza la registrazione lineare o circolare.

    Non fa alcuna differenza se si sta calcolando la dimensione di un log attivo lineare o circolare, poiché il concetto di log attivo significa lo stesso sia nella registrazione lineare che nella registrazione circolare.

  • Le estensioni di log necessarie solo per il ripristino del supporto non si trovano all'interno del log attivo e pertanto non vengono conteggiate nel numero di file primari e secondari.
  • Il campo LOGUTIL di DISPLAY QMSTATUS LOG è disponibile per aiutarti a calcolare, approssimativamente, la dimensione del log attivo richiesto.

    Questo campo è progettato per consentire di effettuare una stima ragionevole della dimensione del log richiesto senza eseguire costantemente il campionamento per determinare la durata delle transazioni più lunghe in esecuzione o la velocità di trasmissione massima del gestore code.

Quanto devono essere grandi le mie LogFilePages?

In genere, le LogFilePages devono essere sufficientemente grandi da poter aumentare facilmente le dimensioni del log attivo senza raggiungere il numero massimo di file primari. Alcuni file di log di grandi dimensioni sono preferibili a molti file di log di piccole dimensioni poiché alcuni file di log di grandi dimensioni consentono una maggiore flessibilità per aumentare la dimensione del log, se necessario.

Per la registrazione lineare, file di log molto grandi potrebbero rendere la variabile delle prestazioni. Con file di log molto grandi c'è un passo più grande per creare e formattare un nuovo file di log, o per archiviarne uno vecchio. Questo è più di un problema con la gestione dei log di archivio e manuale perché con la gestione dei log automatica i nuovi file di log vengono creati raramente.