-
...ist eine Weile her, dass wir das mal (unfreiwillig) ausprobiert haben, an die Dump area kam man früh genug dran, und wenn man die vorsorglich groß genug gemacht hatte, konnte man die früh genug im manuellen IPL kleiner machen, dann alle Schritte überspringen, die man abwählen konnte und als erstes haben wir dann eine große vollständig gesicherte Bibliothek gelöscht, um Zeit für sorgfältige Analyse zu gewinnen.
D*B
-
Wir hatten das vor 2 Wochen ca.
Unsere Maschine hängt an einem recht flotten Storage, daher ging das recht flott. Ich war grad nicht im Büro. Als ich wiederkam und in die MSGs vom QSYSOPR guckte, sah ichs dann...
--Kapazitätsgrenze des Speicherverzeichnisses erreicht.--
Die Plattenauslastung lag da schon bei 98,9 %.
Naja, grad nochmal gut gegangen. Verdächtigen Job dann gekillt, und die Plattenauslastung sank dann von selber schon wieder.
Ich überlege nun gerade, den Systemwert so zu ändern, dass die Maschine einfach früh genug direkt ein IPL macht, damit der Job auf jeden Fall abgebrochen wird. Besser als einfach nur *MSG, was nix bringt wenn gerade mal keiner da ist.
-
... dazumal war es ein Reisekostenabrechnungsprogramm einer Kaufhaussoftware auf einem PC, das einen shared Folder vollgemüllt hat, bis die Maschine stand. Wir haben halt versucht den Job zu finden, was uns nicht gelang und haben dann manuell gestartet, wie oben beschrieben. Früher IPL zu machen bringt einem unter Umständen einen Abbruch von Jobs, was auch nicht so toll ist, da die wenigsten wirklich wiederanlauffähig sind.
D*B
-
Ungünstige User-Queryabfragen per BI können ebenso zum Plattenüberlauf führen. Da gabs mal einen SQL-Crossjoin, der dann das System tatsächlich in den Shutdown zwang, da alles in eine temporäre Tabelle geladen wurde.
Nur nach dem IPL war dann alles wieder weg und die Ursache nicht zu erkennen, bis zum nächsten Versuch des Users. Es hat ein wenig gedauert, den lieben Übeltäter zu finden.
-
Bei uns wars kein Query. Query machen bei uns nur ein paar wenige Leute und die wissen was die da tun.
Der Job kam mit großer Wahrscheinlichkeit von unserer neuen webbasierten Warenwirtschaft, die lediglich die Datenbank der AS400 nutzt. Dort wird ebenfalls mit SQL gearbeitet und man kann da in der Warenwirtschaft auch eigene SQLs halt "bauen".
Das der Plattenplatz nach abbruch des Jobs von selber wieder frei wurde, spricht auf jeden Fall FÜR ein wildgewordenes SQL und temporäre Tabellen.
Ist für mich trotzdem sehr unbefriedigend, dass wir den exakten Grund nicht finden konnten :/
-
... können auch temporäre indexe gewesen sein. Ich würde in jedem Fall History, Joblogs, WRKPRB, Plan cache, index advisory u.ä. nochmal durchforsten, ob da was zu finden ist.
-
Unter Query fasse ich alle Abfragen zusammen. Damit ist nicht mehr nur Query/400 gemeint.
Query => engl. für Abfrage ;-)
Similar Threads
-
By dschroeder in forum NEWSboard Programmierung
Antworten: 5
Letzter Beitrag: 29-06-17, 17:35
-
By cicero22 in forum NEWSboard Programmierung
Antworten: 2
Letzter Beitrag: 08-05-17, 09:06
-
By dschroeder in forum NEWSboard Programmierung
Antworten: 4
Letzter Beitrag: 27-08-14, 13:27
-
By post in forum NEWSboard Programmierung
Antworten: 9
Letzter Beitrag: 28-04-14, 10:39
-
By hs in forum IBM i Hauptforum
Antworten: 11
Letzter Beitrag: 03-09-01, 14:42
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks