DB2 LOCKLIST i MAXLOCKS en TSM Server

11 Novembre 2012 § Deixa un comentari

DB2 paràmetres

Per defecte LOCKLIST i MAXLOCKS són automàtics, això permet l’ajust dinàmic dels recursos de memòria requerida de DB2 per les peticions de les diferents aplicacions consumidores; aquest ajust dinàmic és possible si esta habilitat self_tuning_mem = ON en la BD de TSM (TSMDB1).

Quan surten en els logs del sistema avisos “lock escalation” acaba repercutint en el rendiment de la BD i acaba degradant els treballs de backup TSM Server, això també ens esta indicant que hem d’ajustar aquests paràmetres al valor òptim.

La no optimització d’aquests valors pot ser causa de  DB2 “deadlocks” en l’entorn de Tivoli Storage Manager.

Per IBM DB2 tenim en el Centre d’Informació: “locklist – Maximum storage for lock list configuration parameter“.

DB2 LOCKLIST

Indica la quantitat de memòria pàginada reservada del “DataBase heap” per gestionar bloquejos, el paràmetre ajusta el nombre de pàgines de 4KB. Hi ha un LOCKLIST per BD, en aquest cas és dels bloquejos de totes les operacions de TSM Server. Un “lock” de DB2 consumeix 40B en x32 i 64B en plataformes x64.

DB2 MAXLOCKS

Indica % de reserva de recusos de la LOCKLIST per una aplicación quan hi ha un “lock escalation”. En el cas del TSM Server com que es trata d’una única aplicació contra DB2 convé per rendiment que aquest valor sigui 95 – 98%.

Objectiu:

Tenir una LOCKLIST suficient per quan hi hagi el máxim de carrega de feina del TSM server no es produeixin “deadlock i lock scalation” que acaben degradant la BD i el rendiment del TSM Server.

La clau:

Quan hi ha una gran quantiat de dades mogudes, eliminades i/o actualitzades tenint en compte el temps per ser processades disminuirà el rendiment del TSM Server, el pitjor escenari és que l’operació requerida no pugui acabar pe qué no és servida per DB2; per tant he de conèixer la quantitat de dades en concurrència en TSM i la recomanació “Managing the DB2 LOCKLIST Configuration Parameter with Tivoli Storage Manager“:

KEY FORMULA FOR DB2 LOCKLIST ADJUSTMENTS
Concurrent data movement
500GB = 2500000  locks = 122000 LOCKLIST
1TB   = 5000000  locks = 244000 LOCKLIST
5TB   = 25000000 locks = 1220000 LOCKLIST
MEMORY REQUIREMENTS FOR LOCKLIST
122000 LOCKLIST  = 499MB  (122000 x 4096)
244000 LOCKLIST  = 1GB    (244000 x 4096)
1220000 LOCKLIST = 4.9 GB (1220000 x 4096)

Procediment ex.

Si tenim 250 nodes clients en concurrència per fer backup que generen de l’ordre 4TB de dades en una finestra horaria de 6H i genera una migració de 3TB dades total 7TB = 1708000 LOCKLIST requerit per

(1220000 LOCKLIST/5 TB) * 7 TB= 1708000 LOCKLIST
Memòria req.= 1708000 * 4KB =  6832000KB  = 6,5GB

Això respond a uns requeriments de 28466 locks / min. de carrega * 4KB = 112MB /min.

Si el TSM Server només fa backups, no fa arxivats i no té activada la deduplicació 28466 LOCKLIST pot ser suficient per aguantar sense degradacions “lock scalation”.

Si tenim el TSM Server fent arxivats i deduplicacions a més de la resta de treballs aleshores es recomanable dispossar com a mínim 1/3*1708000 = 569333 LOCKLIST.

Aquests valors poden ser suficients, però també poden no ser definitius si hi han pics que superen aquests requeriments de LOCKLIST.

Què fem aleshores?

Quan es produeix “lock scalation” és genera un log d’avís similar a:

ADM5501I  DB2 está realitzant un reajust de bloquejos. La aplicació afectada es denomina “dsmserv.exe” i està associada al nom de carrega de treball “SYSDEFAULTUSERWORKLOAD” i a l’ID d’aplicació “*LOCAL.SERVER1.121013224855” en el miembro “0”. El nombre total de bloquejos retinguts actualmente és “X” i el nombre de bloquejos a retenir de destino és de “Y“.  La sentència que s’esta executant actualment és “DELETE/INSERT … FROM “TSMDB1″.”TTTTTT””.

Això passa per qué s’ha superat el valor del paràmetre de configuració MAXLOCKS (% massa petit, per TSM Server recomanable 95%-98%) o bé la llista de bloquejos està plena (LOCKLIST massà petit). És a dir els valors actuals no són suficients.

Si hi han molts avisos ADM5501I aleshores incrementem LOCKLIST en proporció al diferencial entre X i Y, és a dir:
El nou valor de LOCKLIST cálculat = (1 + (Y/X)) * LOCKLIST, pe. si X=25345, Y=9345 i LOCKLIST=28466; (1 + (9345 /25345)) * 28466 = 38962 LOCKLIST

Si MAXLOCKS té un valor notablement inferior al 98%  (pe. 10, 20, …, 90%) i s’estan produint “lock scalation” aleshores incrementant MAXLOCKS 98 pot ser suficient per corretgir el problema.

Amb això reduirem els Avisos, si surt algún més podem repetir l’operació fins que l’ajust sigui suficient.

Càlcul inicial LOCKLIST

Aleshores, còm determinem el nombre de pàgines inical de LOCKLIST? si ens basem en la documentació de DB2 “locklist – Maximum storage for lock list configuration parameter“, el procediment concreta l’objectiu de cercar uns màxims i mínims requerits per les aplicacions que han de treballar contra la DB, en aquest cas seria TSM Server i la TSMDB1; i el nostre objectiu ens porta a calcular directment el máxim de pàgines requerides per la LOCKLIST en tot el que seria una jornada laboral del TSM de 24H.

Podem emprar la formula:  LOCKLIST = ((M1B + MsB * NBA) * MAXAPPLS) / 4096:

M1B: Mida en “Bytes” del primer Bloqueig 256B
MsB: Mida en “Bytes” dels següents Bloquejos 128B
NBA: Nómbre de Bloquejos per Aplicació 512
MAXAPPLS (Màxim d’Aplicacions Actives contra DB2 TSMDb1 del TSM Server)?
si volem assegurar podem considerar el nombre de sessions + nombre de processos oberts pel TSM Server en 24H. Consideraant 6H de màxima activitat també pot ser suficient. En el nostre cas ex. podem considerar 250 Nodes client que obren unes 2000 sessions diaries + 150 processós aproximadament addicionals que s’executen en TSM; això comporta un MAXAPPLS 2150 (list applications creades contra DB2 en el decurs d’un día).

Fent ((256 + 128*512) * 2150 / 4096 = 34534 LOCKLIST correspond a uns req. de memòria d’uns 141MB.

Un cop establerts aquests valors si hi han Avisos de “lock scalation” podem seguir l’explicat en l’apartat anterior.

Condicions

Tot el referènciat en aquesta nota esta en relació a TSM server amb DB2 amb entorns de sistemes x64, en entorns de sistemes de x32 els valors aquí paràmetritzats poden canviar, si bé el procediment per anar ajustant els valors pot ser aquest sempre quan acomplim els requeriments de memòria suficient.

Com canviar els valors?

Des de l’entorn de CLP de DB2:

Assegurar la variable d’entorn DB2INSTANCE amb el nom de la instància de BD DB2 TSM Server,

set DB2INSTANCE=SERVER1
db2 start dbm
db2 connect to tsmdb1

d2  update db cfg using MAXAPPLS 2150 AUTOMATIC IMMEDIATE
d2  update db cfg using MAXLOCKS 98 AUTOMATIC IMMEDIATE
d2  update db cfg using LOCKLIST 34534 AUTOMATIC IMMEDIATE

db2 disconnect tsmdb1
db2 stop dbm

Anuncis

DB2 RUNSTATS i/o REORG AUTOMATIC?

9 Novembre 2012 Comentaris tancats a DB2 RUNSTATS i/o REORG AUTOMATIC?

Com?

Saber ràpidament si la BD DB2 TSM Server té manteniments d’indexació i taules en mode AUTOMATIC.

Procediment:

Des de l’entorn de CLP de DB2:

En Windows assegurar la variable d’entorn amb el nom de la instància:

set DB2INSTANCE=SERVER1

db2 start dbm
db2 connect to tsmdb1
db2 get db cfg | find “REORG”
(en linux# db2 connect to tsmdb1db2 get db cfg | grep “REORG”)

Reorganización automática              (AUTO_REORG) = ON

db2 get db cfg | find “RUNSTATS”
(en linux# db2 connect to tsmdb1db2 get db cfg | grep “RUNSTATS”)

Runstats automático                 (AUTO_RUNSTATS) = ON

db2 disconnect tsmdb1
db2 stop dbm

Per modificar-ho, ex.

Estàn el TSM server aturat
db2 start dbm
db2 connect to tsmdb1
db2 get db cfg | find "AUTO"
Manteniment automàtic                        (AUTO_MAINT) = ON
  Copia de seguretat de bd automàtica    (AUTO_DB_BACKUP) = OFF
  Manteniment de taules automàtic        (AUTO_TBL_MAINT) = ON
    Runstats automàtic                    (AUTO_RUNSTATS) = ON
      Estadístiques sentències automàt. (AUTO_STMT_STATS) = ON
    Descripció automàt. estadístiques   (AUTO_STATS_PROF) = OFF
      Actualització automàtica perfils    (AUTO_PROF_UPD) = OFF
    Reorganització automàtica                (AUTO_REORG) = ON

db2 update db cfg using AUTO_RUNSTATS OFF
db2 update db cfg using AUTO_REORG OFF

db2 get db cfg | find "AUTO"
Manteniment automàtic                        (AUTO_MAINT) = ON
  Copia de seguretat de bd automàtica    (AUTO_DB_BACKUP) = OFF
  Manteniment de taules automàtic        (AUTO_TBL_MAINT) = ON
    Runstats automàtic                    (AUTO_RUNSTATS) = OFF
      Estadístiques sentències automàt. (AUTO_STMT_STATS) = ON
    Descripció automàt. estadístiques   (AUTO_STATS_PROF) = OFF
      Actualització automàtica perfils    (AUTO_PROF_UPD) = OFF
    Reorganització automàtica                (AUTO_REORG) = OFF
db2 disconnect tsmdb1
db2 stop dbm

Ara ja es pot ficar en marxa el TSM Server que agafarà la nova disposició.

Amb el TSM Server en marcha

Fem directament en l’entorn de CLP de DB2:

db2 connect to tsmdb1
db2 update db cfg using AUTO_RUNSTATS OFF
db2 update db cfg using AUTO_REORG OFF
db2 disconnect tsmdb1

Un cop hem modificat els paràmetres per tal que tingui efecte hem d’aturar el TSM Server desde consola (Halt) i tornar a ficar en marxa, això fara para i iniciar DB2 amb la nova disposició.

BD DB2 de TSM Server, requereix REORG?

29 Octubre 2012 Comentaris tancats a BD DB2 de TSM Server, requereix REORG?

Símptomes

L’espai de la BD del TSM Server i el Backup creixent malgrat que el nombre d’objectes i expiracions requerits per TSM estan estabilitzats.
Això acaba repercutint en el temps de reposta de les operacions requerides de TSM Server.

Millors pràctiques

També en temps de treball (backup, migration, expiration, reclamation) del TSM Server convé que la BD DB2 no active operacions de manteniment automàtic, sempre és més òptim que estiguin planificats.

(troubleshooting DB2 TSM ServerScheduling table and index reorganization).

Procediment

  1. Anar a CLP del DB2
  2. Sortir de la Sessió de dbm del DB2 Command Line Process (quit) i havent aturat els serveis de TSM Server, generem un informe d’estat de taules i indexs de la BD de TSM Server fent la seqüència de commandes per dbm:
    db2 start dbm
    db2 connect to tsmdb1
    db2 reorgchk current statistics on table all >db2reorgchk.out
    db2 disconnect tsmdb1
    db2 stop dbm
  3. De l’arxiu db2reorgck.out generat obtenim la informació necessària per delimitar les taules i indexs que requereixen fer REORG. De l’arxiu convé analitzar les darreres columnes que tenen els “*” que són les alarmes que informen sobre la necessitat d’aplicar REORG (columnes F1, F2, F3, F4 i F5). Taules especialment problemàtiques: BF_AGGREGATED_BITFILES, BF_BITFILE_EXTENTS, BF_DEREFERENCED_CHUNKS, BF_QUEUED_CHUNKS, BACKUP_OBJECTS i ARCHIVE_OBJECTS
  4. Editem un arxiu de text amb extensió .DB2 pe.: TSMREORG.DB2 amb els scripts de dbm per fer els REORG requerits:
    connect to tsmdb1;
    reorg table TSMDB1.AF_BITFILES;
    reorg indexes all for table TSMDB1.AF_BITFILES;
    reorg table TSMDB1.BF_AGGREGATED_BITFILES;
    reorg indexes all for table TSMDB1.BF_AGGREGATED_BITFILES;
    reorg table TSMDB1.BF_BITFILE_EXTENTS;
    reorg indexes all for table TSMDB1.BF_BITFILE_EXTENTS;
    reorg table TSMDB1.BF_DEREFERENCED_CHUNKS;
    reorg indexes all for table TSMDB1.BF_DEREFERENCED_CHUNKS;
    reorg table TSMDB1.BF_QUEUED_CHUNKS;
    reorg indexes all for table TSMDB1.BF_QUEUED_CHUNKS;
    reorg table TSMDB1.BACKUP_OBJECTS;
    reorg indexes all for table TSMDB1.BACKUP_OBJECTS;
    reorg table TSMDB1.ARCHIVE_OBJECTS;
    reorg indexes all for table TSMDB1.ARCHIVE_OBJECTS;
    reorg table TSMDB1.BF_AGGREGATE_ATTRIBUTES;
    reorg indexes all for table TSMDB1.BF_AGGREGATE_ATTRIBUTES;
    reorg table TSMDB1.DF_BITFILES;
    reorg indexes all for table TSMDB1.DF_BITFILES;
    connect reset;
  5. Després aquest arxiu es pot processar en batch per dbm des del CLP de DB2 per la instancia de la BD de TSM Server:
    set DB2INSTANCE=SERVER1
    db2 -z TSMREORG.LOG -tf TSMREORG.DB2
  6. El resultat del procés restará en TSMREORG.LOG.
  7. Quan s’inicia un procediment de REORG si fa molt de temps que no s’ha fet cal fer previament Backup de  TSM Server, aturar el TSM Server i després executar el script que pot durar hores, moltes hores, depend de la degradació de les taules i els indexs.

Where Am I?

You are currently browsing the BBDD category at Felip Sanchez.