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

    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
    18.393
    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: http://www.fuerchau.de/software/upload400.htm
    BI? Da war doch noch was: http://www.ftsolutions.de

  3. #3
    Registriert seit
    May 2004
    Beiträge
    330
    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
    18.393
    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: http://www.fuerchau.de/software/upload400.htm
    BI? Da war doch noch was: http://www.ftsolutions.de

  5. #5
    Registriert seit
    May 2004
    Beiträge
    330
    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
    18.393
    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: http://www.fuerchau.de/software/upload400.htm
    BI? Da war doch noch was: http://www.ftsolutions.de

  7. #7
    Registriert seit
    Aug 2001
    Beiträge
    2.588
    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

    Contractor for Fresche Solutions Inc.
    Anwendungsmodernisierung, Beratung, Schulungen im Bereich RPG, SQL und Datenbank
    IBM Champion 2020
    RPG und SQL-Schulungen
    Fully Free RPG! - 09.-11.03.2020

  8. #8
    Registriert seit
    Feb 2001
    Beiträge
    18.393
    "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: http://www.fuerchau.de/software/upload400.htm
    BI? Da war doch noch was: http://www.ftsolutions.de

  9. #9
    Registriert seit
    Feb 2001
    Beiträge
    18.393
    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: http://www.fuerchau.de/software/upload400.htm
    BI? Da war doch noch was: http://www.ftsolutions.de

Ähnliche Themen

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

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •