[NEWSboard IBMi Forum]
  1. #1
    Registriert seit
    May 2004
    Beiträge
    444

    Probleme mit View RECORD_LOCK_INFO

    Hallo zusammen,

    ich bin jetzt etwas am Ende.

    Ich wollte alle Jobs ermitteln die auf Lockwait sind. Das habe ich hinbekommen
    SELECT *
    FROM TABLE (QSYS2.ACTIVE_JOB_INFO()) as t
    where t.Job_status = 'LCKW';

    Jetzt wollte ich wissen welcher Job meinen Lockwait verursacht.

    Da habe ich den View RECORD_LOCK_INFO gefunden.
    Wenn ich jetzt allerdings den nachfolgenden Select
    SELECT * FROM qsys2.record_lock_info WHERE JOB_NAME =
    '249492/SPEPGMRHK/S01IPD0038' ausführe (Den Jobnamen habe ich aus dem oben genannten Select) bekomme ich Schnappatmung wegen der Dauer

    Mit Tablename = und Schemaname = ist er rasend schnell, leider steht mir aber nur der Jobname zur Verfügung.

    Jetzt habe ich mir gedacht schaust Du dir mal mit
    SELECT * FROM sysviews WHERE TABLE_SCHEMA = 'QSYS2' an wie das SQL-Statement für den View aussieht. Vielleicht bekomme ich was ich brauche aus den Tabellen die verwendet werden.

    Und das lautet wie folgt
    SELECT COALESCE(A.TABLE_SCHEMA,''), COALESCE(A.TABLE_NAME,''), COALESCE(B.TABLE_PARTITION,''), COALESCE(A.SYSTEM_TABLE_SCHEMA,''), COALESCE(A.SYSTEM_TABLE_NAME,''), COALESCE(B.SYSTEM_TABLE_MEMBER,''), COALESCE(RELATIVE_RECORD_NUMBER,0), COALESCE(LOCK_STATE,''), COALESCE(LOCK_STATUS,''), COALESCE(LOCK_SCOPE,''), COALESCE(JOB_NAME,''), THREAD_ID, LOCK_SPACE_ID FROM QSYS2.SYSTABLES A INNER JOIN QSYS2.SYSPSTAT B ON A.SYSTEM_TABLE_SCHEMA = B.SYSTEM_TABLE_SCHEMA AND A.SYSTEM_TABLE_NAME = B.SYSTEM_TABLE_NAME, TABLE ( QSYS2.RECORD_LOCK_INFO ( A.SYSTEM_TABLE_SCHEMA , A.SYSTEM_TABLE_NAME , B.SYSTEM_TABLE_MEMBER , A.IASPNUMBER ) ) AS C;

    Jetzt habe ich mir die beiden Tabellen QSYS2.SYSTABLES und QSYS2.SYSPSTAT angeschaut, aber aus dem SQL erschließt sich mir nicht wie er den Status "HELD" und "WAITING" in den View RECORD_LOCK_INFO bekommt und vor allem nicht wie er auf die Satznummer kommt.

    Was ich eigentlich will ist, dass ich die Jobs bekomme die auf LCKW sind und welcher Job die Sperre verursacht und warum (also z.B. Datei A mit RecordID 2 ist der Verursacher)

    Vielleicht hat jemand eine Idee

    Ich habe auch versucht einen Create Index auf RECORD_LOCK_INFO zu machen, aber das geht nicht. Deshalb auch die Idee eventuelle über die Tabellen des Views zu gehen.

  2. #2
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Das ist der Fluch der Table-Functions, die zuerst immer alle Daten ermitteln muss, bevor eine Where-Einschränkung verwendet werden kann.
    Die Dauer erklärt sich von selber, da zuerst über alle Jobs ermittelt werden muss, wer auf Lock wartet.
    Nun basiert das API LockInfo (WRKOBJLCK) aber leider aus dem Zugriff über das Objekt und nicht den Job.
    Somit muss ein Filter über den Job eben sämtliche Lock's ermitteln um dann den Job auszufiltern.

    Das Ganze basiert ja auf den Standard-API's, die USRSPC's erstellen, Listen generieren und dann die Table-Functions bereitstellen.

    Du must mal prüfen, ob es eine View für "Job-Sperren" gibt, die dir die Objekte und den Status auflistet. Diese kannst du dann auf "Wait" (Wartet) prüfen und hast somit das Objekt auf das gewartet wird.
    Mit diesem kannst du dann die Record_Lock_Info nach Objekt durchsuchen, welcher Job den Status HELD auf dem Satz hat.

    Zur Not kannst du ja die fehlende Table-Function selber schreiben:
    https://www.ibm.com/support/knowledg...s/qwcrjblk.htm
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  3. #3
    Registriert seit
    May 2004
    Beiträge
    444
    Du must mal prüfen, ob es eine View für "Job-Sperren" gibt, die dir die Objekte und den Status auflistet.
    Ja RECORD_LOCK_INFO macht das :-(

  4. #4
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Das liefert WRKOBJLCK-Ergebnisse.
    Ich meine aber die Job-Lock's (WRKJOB=>12: Mit Jobsperren arbeiten).
    Damit erhält man erst mal die Objekte des Jobs um dann auf die Objektsperren zu kommen.
    Ich habe leider aktuell keinen Zugriff auf diese System-Views.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  5. #5
    Registriert seit
    May 2004
    Beiträge
    444
    Yupp das ist der OBJECT_LOCK_INFO der genauso lange braucht

    SELECT COALESCE(A.OBJLONGNAME ,'') AS SCHEMA, COALESCE(B.OBJLONGNAME ,'') AS OBJNAMLONG, COALESCE(A.OBJNAME,'') AS OBJLIB, COALESCE(S2.OBJNAME,''), C.MEMBER_NAME, COALESCE(M.OBJECT_TYPE,''), B.SQL_OBJECT_TYPE, COALESCE(B.IASP_NUMBER,0), CASE B.IASP_NUMBER WHEN 0 THEN '*SYSBAS' ELSE COALESCE(C.ASPGRP, '*SYSBAS') END CASE, C.MEMBER_LOCK_TYPE, COALESCE(C.LOCK_STATE,''), COALESCE(C.LOCK_STATUS,''), COALESCE(C.LOCK_SCOPE,''), COALESCE(C.JOB_NAME,''), C.THREAD_ID, C.LOCK_SPACE_ID, COALESCE(C.LOCK_COUNT,0), C.LIBRARY_NAME, C.PROGRAM_NAME, C.MODULE_LIBRARY_NAME, C.MODULE_NAME, C.PROCEDURE_NAME, C.STATEMENT_ID, C.MI_INSTRUCTION FROM (SELECT OBJLONGNAME, OBJNAME FROM TABLE(QSYS2.OBJECT_STATISTICS('*ALLSIMPLE', 'LIB',NULL)) AS L) AS A, LATERAL (SELECT OBJECT_TYPE FROM QSYS2.OBJTYPES) AS M, LATERAL (SELECT OBJNAME FROM TABLE(QSYS2.OBJECT_STATISTICS( A.OBJNAME,M.OBJECT_TYPE,'*ALLSIMPLE') ) AS X WHERE M.OBJECT_TYPE <> '*LIB' OR (M.OBJECT_TYPE = '*LIB' AND A.OBJNAME = 'QSYS')) AS S2 , LATERAL (SELECT OBJNAME, OBJLONGNAME, OBJTYPE, SQL_OBJECT_TYPE, IASP_NUMBER FROM TABLE(QSYS2.OBJECT_STATISTICS(CHAR(A.OBJNAME,10), M.OBJECT_TYPE ,S2.OBJNAME)) AS Q ) AS B, LATERAL (SELECT * FROM TABLE(QSYS2.OBJECT_LOCK_INFO(CASE WHEN B.OBJTYPE = '*LIB' THEN 'QSYS' ELSE QSYS2.FCTO7F(A.OBJNAME) END, QSYS2.FCTO7F(B.OBJNAME), B.OBJTYPE,B.IASP_NUMBER )) AS E) AS C

    Wobei der RECORD_LOCK_INFO noch etwas tiefer geht und die Satznummer mit ausgibt.

  6. #6
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Hier heißt es eben, mal genau zu analysieren, welche Table-Function mit welchen Parametern genau aufgerufen wird.
    An statt dann alles in einen großen Join zu packen, muss man dann wohl aus Performancegründen die SQL's in Einzelschritte zerlegen:
    1. create table as (select job-info where status = wait), geht auch als Insert into select ...
    2. Mit diesem Ergebnis holt man sich nun die Object_Lock_Info nur für diese Jobs und kann ggf. direkt mit Object_Lock_Info über den Objektnamen gejoint, die Jobs mit Satzstatus "Hold"

    Viuelleicht gibts noch eine Sicht "Jobsatzsperren", um nur die Objekte zu ermitteln, wo der Job auf Status "Wait" sitzt. Dann kann man zu diesem Objekt den Job ermitteln, der den Satz sperrt.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  7. #7
    Registriert seit
    Aug 2001
    Beiträge
    2.869
    Wenn Du die Bibliothek und/oder die Tabelle angibst, läuft das Ganze schnell, da die Auswertung nur für die Selektions-Kriterien erfolgen kann.
    Wenn Du nach Job suchst dauert das ewig, da zunächst für ALLE Bibliotheken und ALLE Tabellen die Satz-Sperren ermittelt werden müssen und wenn alle Informationen ermittelt sind, kann die Selektion nach Job-Nr. erfolgen. Das dauert nun mal.
    Die View, bzw. die zugrunde liegende UDTF (User Defined Table Function) basiert auf dem API QDBRRCDL (Retrieve Record Locks), das für jede einzelne Tabelle/physische Datei in allen Bibliotheken aufgerufen werden muss.
    Die Job-Informationen können nur über dieses API ermittelt werden.

    Damit erübrigt sich wohl auch irgendwelche temporären Tabellen zu erstellen.

    M.E. die einzige Möglichkeit das Ganze etwas schneller zu bekommen, wäre, wenn man die in der Bibliotheksliste des Jobs befindlichen Tabellen/physische Dateien vorselektieren könnte.
    Meines Wissens gibt es dafür aber keinen Service.

    Birgitta
    Birgitta Hauser

    Anwendungsmodernisierung, Beratung, Schulungen, Programmierung im Bereich RPG, SQL und Datenbank
    IBM Champion seit 2020 - 4. Jahr in Folge
    Birgitta Hauser - Modernization - Education - Consulting on IBM i

  8. #8
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    "Damit erübrigt sich wohl auch irgendwelche temporären Tabellen zu erstellen."
    Klar, wenn man seine Anforderungen nicht überprüft.

    SQL ist eine Massenverarbeitung die ausschließlich von Indizes lebt.
    Nur dann ist SQL schnell.
    Nun liegt es in der Natur der Sache, dass Table-Function keinen Index bieten und SQL somit gezwungen ist, sämtliche Informationen zu lesen, und das dauert, da auch der Aufruf von API's mit allem Drum und Dran (USRSPC-Verarbeitung) eben aufwändig ist.

    Wenn ich aber eine bestimmte Information suche, ist ist durchaus sinnvoll, in Teilergebnissen zu denken.
    Bei der Verwendung von SQL wird gerne die gute alte Tradition des logischen Denkens vernächlässgt. Denn dazu gehört es eben, sich über Zugriffe vorher gedanken zu machen.

    Wenn ich also die Aufgabe betrachte, so stehen da letztlich 3 API-Views zur Verfügung.
    1. Job's um auf die/den Jobs einzuschränken, der auf LOCKW steht.
    Damit reduziert sich bereits im 2. Schritt, die Anzahl der zu prüfenden Job-Satzsperren.

    2. Mit diesen wenigen Jobs (im Zweifel meist nur 1), ermittle ich nun die Objekte, of die diese Jobs warten. Da kommt je Job immer nur 1 Objekt heraus (ausßer bei Multithreading bei z.B. Java).

    3. mit diesen wenigen Objekten (im Zweifel meist nun auch nur noch 1) schaue ich nun, welche Jobs wiederum genau dieses Objekt im Zugriff haben um letztlich Job, Objekt und Satznummer zu erhalten.

    Baue ich alles in einen großen SQL, zwinge ich ja SQL dazu alle Informationen zu ermitteln, also auch die, die ich gar nicht benötige (z.B. tote Jobs), um mir letztlich das selbe Ergebnis zu liefern, dass ich durch Zerlegung in Einzelschritte erreiche.

    Wenn du auf temporäre Tabellen verzichten möchtest, kann man das natürlich auch ausprogrammieren (Declare/Open/Fetch/Close, Schleifen, Compilieren, Testen, korrigieren).
    Mit temporären Tabellen kann ich die Zwischenergebnisse einfacher verifizieren und ggf. dann per Joins aus den Zwischenergebnissen auf die Tablefunctions weitermachen.
    Wenn dann alles klar ist, kann ich das auch noch in eine SRCPF packen und per RUNSQL einfach ausführen.

    Dieses Verfahren (das hat mit Table-Functions wenig zu tun), wende ich sehr häufig an, da SQL mir zu oft auch trotz Indizes einfach zu lange braucht. Erst wenn ich die Aufgabe, so wie früher;-), in Einzelschritte zerlege, komme ich von Minutenlaufzeiten auf Sekunden.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  9. #9
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Nun habe ich mir die Views mal auf einem V7R3-System angeshen.
    Leider ghen diese Views nicht vom Job, sondern von den Objekten aus.
    Somit ist eine performante Abfrage aus diesen Views leider nicht möglich.

    Aber es hindert euch ja nicht, aus den bekannten API's TABLE-Funtions zu schreiben, die die fehlenden JOB-Informationen (welche Objekte in Benutzung sind) zu schreiben.

    Leider geht auch dei RECORD_LOCK_INFO von den Objekten und nicht von den Job's aus.
    Somit werden alle Objekt ausgewertet, also auch solche, die derzeit in keinem Job verwendet werden.

    Um also obige Aufgabe performant zu lösen, muss man hier leider die klassischen API's verwenden.

    https://www.ibm.com/support/knowledg...s/qdbrjbrl.htm
    https://www.ibm.com/support/knowledg...s/qwcrlcki.htm
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

Similar Threads

  1. SQL index auf view
    By dibe in forum IBM i Hauptforum
    Antworten: 14
    Letzter Beitrag: 01-07-18, 17:27
  2. SQL CREATE or Replace View
    By KingofKning in forum NEWSboard Programmierung
    Antworten: 9
    Letzter Beitrag: 19-06-17, 08:10
  3. SQL View mit Index/Key
    By malzusrex in forum NEWSboard Programmierung
    Antworten: 9
    Letzter Beitrag: 19-10-16, 19:53
  4. SQL Create view V5R4
    By KingofKning in forum NEWSboard Programmierung
    Antworten: 7
    Letzter Beitrag: 07-09-15, 09:29
  5. SQL-View auf /36-Datei
    By GruberWolfgang in forum NEWSboard Programmierung
    Antworten: 17
    Letzter Beitrag: 02-09-15, 22:48

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • You may not post attachments
  • You may not edit your posts
  •