DB2 Vsam Jcl Ims Cics
skip to main |
skip to sidebar
Ittuning è il blog creato per scambiarsi informazioni sulle ottimizzazioni e sulle esperienze esercitate dagli esperti del settore nell'ambito dell'Information Tecnology , sia in ambito mainframe che dipartimentale.
ITTUNING
IL BLOG è AL SERVIZIO DI TUTTI GLI ESPERTI DI INFORMATICA CHE DESIDERINO CONDIVIDERE LE LORO ESPERIENZE SUL TUNING E L'OTTIMIZZAZIONE SIA IN AMBITO MAINFRAME CHE DIPARTIMENTALE.
24 commenti:
Nell'ambito di un flusso batch di repro di un file vsam di grosse dimensioni ,sforiamo con la finestra batch richiesta da cliente.
Senza far intervenire l'applicativo mi sapete consigliare una metodologia per abbassare i tempi di elapsed del batch.
Grazie
Puoi impostare i parametri previsti sul jcl per i dataset vsam es
//DBMASX DD DSN=S0812.IMENS.SRD1.SRDMAST,DISP=SHR,
// AMP=('AMORG,BUFND=75,BUFNI=75') , ti consiglio di impostare se hai un dataset sequenziale anche il parametro bufno=200 nella relativa scheda jcl
In una query il predicato 'like' nella condizione permette l'utilizzo dell'indice ?
dipende :
A esiste un campo indicizzato con la colonna specificata ?
B se il % viene messo come primo carattere il db2 non utilizzerà l'indice.
Alcuni giorni fa sono stato contattato da un collega che aveva la necessità di utilizzare sotto il controllo di una transazione Ims un programma in Sql dinamico dove sql veniva generato dinamicamente da un modulo Java, il tutto sotto il controllo di un package db2.
L'applicativo di competenza eseguiva le call in questione su tabelle con owner differenti.Siccome l'owner non era qualificato all'interno della call abbiamo dovuto creare gli alias db2 tentando di validare il tutto tramite l'opzione qualifier nel membro di bind.Faccio presente che gli accessi al db2 sono gestiti tramite racf.
Chiaramente il bind del plan e del package sono stati eseguiti immettendo la clausola dynamicrules bind validati bind per permettere di eseguire il controllo autorizzativo solo all'atto del bind e propagarlo a tutti gli autorizzatori impostando come qualifier del package l'owner principale.
Il db2 in questo caso 'utilizzo degli alias' non si è comportato come ci si aspettava (bypassando il controllo racf-db2 nel momento dell'esecuzione dell'istruzione) ma ha eseguito il controllo fermando l'utente con un bel -551. Per ovviare al tutto abbiamo dovuto rigenerare le tabelle con un owner solo settando il qualifier dell'owner e del qualifier del bind package e plan uguale all'owner di creazione delle tabelle.
Dimanna
Come se fa a nun raddoppia????
Invece di eseguireprima laselect addizionare 1 e dopo fare l'update fai subito update set + 1epoi esegui la select
In una transazione Ims/db2 una call sql su una tabelladi parecchi milioni di record durapiù di 5 ore.
In particolare la tabella ha 4 indici ed il codice sql che esegue è del tipo
where campo1 between :h and :h
and campo2 between :h and :h
e cosi via per circa una decina di campi . Come posso fare a far decidere in sql statico la migliore strategia di accesso e ridurre i tempi di elapsed ?
L'unica cosa che può ottimizzare un linguaggio del genere in presenza di più indici è utilizzare all'atto del bind del package la clausola defer prepare.
In questo modo il db2 valuterà la strategia di accesso ai dati all'atto dell'esecuzione tenendo in considerazione i valori immessi dall'operatore.
Stiamo utilizzando tramite una applicazione web sql dinamico , il tutto è lanciato sempre dalla stessa utenza.
Notiamo una certa perdita di tempo causata da una rivalidazione delle strategie di accesso ai dati .
Ma il db2 nel caso di sql dinamico lanciato dalla stessa utenza non doveva tenere traccia in cache delle strategie di accesso ?
Devi verificare che in dsnzparm sia attivato il parametro cache dyn .
Probabilmente sul tuo sottositema è impostato a no ed il db2 non può mantenere in cache le strategie.
Esiste un metodo per spostare dalla
'fetch' alla 'Open' del cursore l'attività di estrazione dei dati?
Ottenendo quindi maggiori tempi al
momento dell'apertura del cursore, ma ottimizzando i tempi di scansione delle occorrenze rilevate.
Stai parlando di una elaborazione batch o di un TP?
Allora lacosaè un po complessa:
Se ituoi tempi sono sulla fetch , molte volte la causa è di naturaapplicativa , per esempio se tu hai utilizzato l'opzione optimize for 1 rows all'interno di un cursore e il db2 tira fuori + di una riga ti troverai sotto il monitor dei tempi alti nelle fetch successive.
In realta tu dovevi usare la clausola fetch first 1 row per ottenere il migior risultato.
In un attività di tipo batch per velocizzare l'accesso ai dati conviene mettere a livello di bind del package la clausola currentdata no , questo ti permetterà di utilizzare al meglio le funzioni del db2 ed in particolare la sequential detection e la lock avoidance.
Per eliminare o contenere i dubbi su tale argomento ho effettuato MVS JOB JOB
JOB SYSTEM START END
NAME CPU_SEC ID TIME TIME
M910256N 1324 SVA1 2007-10-16-15.45.33.540000 2007-10-16-16.37.38.050000 Compress n
M910256Y 1304 SVA1 2007-10-16-15.45.33.620000 2007-10-16-16.22.44.120000 Compress y
una prova sui consumi di cpu di una tabella con lunghezza record di 1079 byte contenente 20574213 record .
Il job M910256N indica i consumi e gli elapsed dello scarico della tabella senza compressione , mentre il job M910256Y indica quelli della tabella compressa.
Si fa presente che i due job sono partiti in parallelo , con la stessa priorità e sulla stessa classe di esecuzione.
si può notare come nonostante il job M910256Y lavori sullo scarico intero della tabella compressa , il consumo di cpu è inferiore di circa 20 secondi mentre l'elapsed time è inferiore di 15 minuti .
inoltre evidenzio la percentuale di spazio utilizzato per oggetto
DDBAS000 SDBAS00N 1 S 2097360 2097152 100
DDBAS000 SDBAS00N 2 S 2097360 2097152 100
DDBAS000 SDBAS00N 3 S 2097360 2097152 100
DDBAS000 SDBAS00N 4 S 2097360 2097152 100
DDBAS000 SDBAS00N 5 S 2097360 2097152 100
DDBAS000 SDBAS00N 6 S 2097360 2097152 100
DDBAS000 SDBAS00N 7 S 2097360 2097152 100
DDBAS000 SDBAS00N 8 S 2097360 2097152 100
DDBAS000 SDBAS00N 9 S 2097360 2097152 100
DDBAS000 SDBAS00N 10 S 2097360 2097152 100
DDBAS000 SDBAS00N 11 S 2097360 2097152 100
DDBAS000 SDBAS00N 12 S 2097360 2097152 100
DDBAS000 SDBAS00N 13 S 2097360 2097152 100
DDBAS000 SDBAS00N 14 S 730080 174300 24
DDBAS000 SDBAS00Y 1 S 2097360 2097152 100
DDBAS000 SDBAS00Y 2 S 2033280 1969952 97
dai dati si evince che il ts compresso occupa una percentuale minima dello spazio del ts non compresso.
totali
ts n ts y % occupata
27437276 4067104 14,82328
Di conseguenza i risparmi saranno su tutte le attività che riguardano gli oggetti .
Image copy,Reorg , batch, comprese le operazioni di disaster recovery a caldo dove il data-transfer sarà commisurato all'ampiezza dell'oggetto.
Controindicazioni .
Per tabelle con un'alta movimentazione online possibile revisione dei parametri del locksize da pagina a riga.
Come sapere che giorno è con una query
SELECT CASE (DAYS(&A&WEEK&A)-DAYS(&A&WEEK&A)/7 * 7) + 1
WHEN 1 THEN 'DOM'
WHEN 2 THEN 'LUN'
WHEN 3 THEN 'MAR'
WHEN 4 THEN 'MER'
WHEN 5 THEN 'GIO'
WHEN 6 THEN 'VEN'
WHEN 7 THEN 'SAB'
END GIORNO
FROM SYSIBM.SYSDUMMY1
Ma non è meglio questa?
SELECT DAYOFWEEK_ISO('2007-10-23')
FROM SYSIBM.SYSDUMMY1
Ciao
Angelo
Hai ragione Angelo mi piace di più ;
C'è sempre da imparare.
In alternativa se si vuole gia decodificato il giorno si può fare un mix delle due
SELECT CASE (DAYOFWEEK('2007-10-24')
WHEN 1 THEN 'DOM'
WHEN 2 THEN 'LUN'
WHEN 3 THEN 'MAR'
WHEN 4 THEN 'MER'
WHEN 5 THEN 'GIO'
WHEN 6 THEN 'VEN'
WHEN 7 THEN 'SAB'
END GIORNO
FROM SYSIBM.SYSDUMMY1
Ho altissimi consumi dicpua livello transazionale cics che posso controllare ?
Ho altissimi consumi dicpua livello transazionale cics che posso controllare ?
Verifica i display eseguiti dai programmi applicativi
ho due database uno host e uno dipartimentale ed ho la necessita su cics di accedere a tutte e due.
è possibile associare alla stessa transazione due plan uno normale e uno remoto????
grazie
perchè altrimenti facendo le connect e poi la reset avrei una syncpoint automatica
e cioò non mi aggrada molto anche perchè in caso di errore non potrei tornare indietro su quello che ho già confermato
Posta un commento