PLATTEN VOLL! Verhalten der AS/400???

[micha1904]

Hallo Zusammen,

danke für eure Hilfe.

Die Systemwerte stehen auf *msg sowie jetzt 5%.

Wir werden wohl doch schon ehr unsere Platten bekommen je nachdem ob der zusätzliche Käfig für unsere Erweiterungeinheit lieferbar ist. Wir haben alle Möglichkeiten ausgeschöpft um Platz zu schaffen uns bleibt jetzt nur noch als kurzfristige Lösung eine Datenbank zu sichern und dann zu löschen. Diese Datenbank ist eine Testumgebung und wird sehr selten benutzt, da es unser EBP-System ist. Was meint ihr aber mit selten oder gar nicht benötigten Umgebungen (S36)?

Na ja, unsere Entscheider denken eh darüber nach auf eine Windows Umgebung zu wechseln mit einer SQL Datenbank. Preislich ist dies wohl nicht zu toppen.....Mal schauen was da noch so kommt.......

Glückauf

Michael

[Pikachu]

Hallo Michael!

Es gibt noch einen weiteren Schwellenwert. Dieser steht im STRSST unter "Work with disk units" > "Work with disk configuration" > "Work with ASP threshold". Wird dieser %-Wert an freiem Plattenplatz unterschritten, dann stellt z.B. das SNADS seine Dienste vorläufig ein.

Viele Grüße
Jürgen

[Fuerchau]

Bei 1947 Gigabytes wäre ich mit einer PC-Lösung und SQL-Datenbank eher vorsichtig. Insbesonders das Thema Performance, Verteilung der DB auf mehrere Platten (da läuft nämlich nichts automatisch), Datensicherung/Wiederherstellung usw. usw.

Und preislich ?
Was kostet ein/mehrere PC-Server mit 1947 GB ?
Was kosten dann ein SQL-Server, Oracle-Server o.ä. ?
Wieviel Leute benötige ich für die Wartung ?
Welche Versionsabhängigkeiten gibts zwischen Windws/Linux/SQL-Datenbank ?
Wie sind die Zugriffsmethoden ?
Gibt es eine PC-Lösung mit mehr als 97% Ausfallsicherheit ?

PS:
Was das Aufräumen auf der AS/400 angeht so wirkt manchmal ein RGZPFM wahre Wunder, auch ein RCLSTG ist da nicht zu verachten (QRPLOBJ, QSPL, ...).
Mach mal die Probe aufs Exempel und schau dir per DSPFD bei einer Lib die prozentuale Auslastung zwischen Anzahl Sätze und gelöschten Sätzen.
Prüfe die Dateien ggf. auf REUSEDLT(*YES).

[holgerscherer]

Wir haben alle Möglichkeiten ausgeschöpft um Platz zu schaffen uns bleibt jetzt nur noch als kurzfristige Lösung eine Datenbank zu sichern und dann zu löschen. Diese Datenbank ist eine Testumgebung und wird sehr selten benutzt, da es unser EBP-System ist. Was meint ihr aber mit selten oder gar nicht benötigten Umgebungen (S36)?

zum Beispiel eine solche Datenbank, sprich Collection oder auch Bibliothek... wenn es dringend ist, diese zur Seite sichern. Im Zweifelsfalle kann kompetentes Personal gewiss helfen

Na ja, unsere Entscheider denken eh darüber nach auf eine Windows Umgebung zu wechseln mit einer SQL Datenbank. Preislich ist dies wohl nicht zu toppen.....Mal schauen was da noch so kommt.......

*röchel* Das mag kurzfristig günstiger sein. Langfristig wohl eher nicht, da der administrative Aufwand hier wohl etwas höher anzusiedeln ist.

-h

[spiceisnice]

S/36,S/38 Umgebung löschen bringt bei dieser Größenordnung rein gar nichts (< 1GB) - das ist xxxSS1 Option 4,5,6,11 (Libs QMGU,QSSP,QSYS38,QMU400)

Eventuell mit PRTDSKINF Plattenbelegung (*OBJ,*LIB,*SYS) analysieren - vorher natürlich erfassen GO DISKTASKS 1,2.

Besonders *SAVF *JRNRCV und gelöschte Sätze in DB's achten. QRPLOBJ (durch IPL), SPLF's im SAP kein Thema, dafür IFS Objekte beachten.

Am besten verzichtbare Daten offline stellen (SAV), dann DLT. Update/Upgrade - dann RST.

[BenderD]

Hallo,

Vorsicht!!! eine wegen Überlauf stehen gebliebene AS400 braucht zum IPL Platz!!! und es ist keineswegs selbstverständlich, dass ein manuelles IPL geht , dann kommt man nicht bis zum löschen. Wenn man jetzt nicht weit genug im IPL kommt, oder in dem Step, bis zu dem man kommt, keinen Platz durch Verkleinerung interner Arbeitsbereiche schaffen kann, dann muss man scratchen - mit Datenverlust.

Zur Perforance: Das angesprochene Volumen kriegt man heutzutage auf fast jede Datenbank (sprich DB2, Oracle, SQL Server) auf fast jeder Plattform (sprich Mainframe, AS400, Linux auf Intel, RS6000, Windows NT/XP Server). Die AS400 ist hierbei nicht das Rennpferd, eher ein gutmütiger Ackergaul (wenn man genügend davon vorspannt, kann man auch größere Lasten mit flottem LKW Tempo bewegen.

Zu den Kosten: EDV ist wie jeder Virus, wenn er seinem Wirt zuwenig davon nimmt, verliert er gegen Konkurrenten, nimmt er ihm zuviel, dann bringt er seinen Wirt um. Auf einen einfachen Nenner gebracht: das EDV Budget hängt nur wenig von der verwendetetn Plattform ab - je nach Plattform variiert das Verhältnis zwischen Hardware, Software, Maintenance.

mfg

Dieter Bender

zum Beispiel eine solche Datenbank, sprich Collection oder auch Bibliothek... wenn es dringend ist, diese zur Seite sichern. Im Zweifelsfalle kann kompetentes Personal gewiss helfen



*röchel* Das mag kurzfristig günstiger sein. Langfristig wohl eher nicht, da der administrative Aufwand hier wohl etwas höher anzusiedeln ist.

-h

[JonnyBrazil]

Hall Micha,

versuche PTF's permanent anzulegen, da kann einiges zusammenkommen.
Vorher noch eventuell nicht benötigte Licenzprogramme zu löschen. Z.B GDDM und ähnliches.

Weiters sollten die Journalempfänger überprüft werden. diese werden teileise automatisch erstellt und nicht gelöscht.

Gruss Hans

[micha1904]

Hallo Zusammen,

erst einmal Danke für eure zahlreichen Antworten.

Heute bekommen wir schon einmal vorab 3x 35GB Platten und weitere dann mit einem neuen Käfig in den nächsten Tagen.

Im Moment sieht wirklich alles danach aus, dass es in Zukunft eine Windows/SQL Lösung geben wird. Meine Zweifel und auch eure Zweifel finden bei unserern Entscheidern kein wirkliches offenes Ohr , obwohl man sich starke Gedanken macht, da unsere Firma seit der EDV Einführung mit einer AS/400 (und älter) arbeitet. Letztendlich sind zu einem die Kosten entscheidend und zum anderen die Vorteile die uns wohl eine SQL Lösung laut SAP liefern wird (30% weniger Datenbankgröße als bisher bessere Performance u.s.w u.s.w......)

Warten wir es ab

Michael

[Fuerchau]

Also das mit der DB-Größe und besseren Performance halte ich da eher für ein Gerücht !
Sicherlich hat SAP seine Anwendungen auf SQL-Server/Oracle optimiert. Aber dass diese DB's schneller sind ?
Bei SAP liegt die Performance weniger in der DB als in der Anwendung !