Formel zur Berechnung von I-O Operationen

[cbe]

Hallo,

das teure dabei sind die Indexe. Bei solchen Massen lohnt es sich ggf. die Indexe zu löschen und wenn man fertig ist wieder aufzubauen - das Daten füllen geht dann vieel schneller, nur ist beim Index-Aufbau die Maschine eine Weile beschäftigt und in dieser Zeit ist der Index (und damit die Anwendung) nicht verfügbar.

Trotzdem haben wir es idR. so gemacht für Reorg von Buchhaltungsdaten (ging so ca. 20 std, mit angehängten Indexen hätte es mind. mehrere Tage benötigt).

Eine Faustformel, wie lange was dauert, kann ich Dir aber auch nicht geben, hängt wohl auch stark vom Hauptspeicher ab.

Gruß
Christian

[Fuerchau]

Vor allen Dingen sollte FRCWRITE solange abgeschaltet werden.

[Burkhard]

Hallo,

das teure dabei sind die Indexe. Bei solchen Massen lohnt es sich ggf. die Indexe zu löschen und wenn man fertig ist wieder aufzubauen - das Daten füllen geht dann vieel schneller, nur ist beim Index-Aufbau die Maschine eine Weile beschäftigt und in dieser Zeit ist der Index (und damit die Anwendung) nicht verfügbar.

Trotzdem haben wir es idR. so gemacht für Reorg von Buchhaltungsdaten (ging so ca. 20 std, mit angehängten Indexen hätte es mind. mehrere Tage benötigt).

Eine Faustformel, wie lange was dauert, kann ich Dir aber auch nicht geben, hängt wohl auch stark vom Hauptspeicher ab.

Gruß
Christian

Genau das ist das Problem, wenn ich berechnen kann, dass ich an einem langen Wochenende (z.B. Pfingsten) die Daten mit nur einer log. Sicht übernommen bekomme und danach die Zeit ausreicht alle anderen benötigten 14 [SIC!] logischen Sichten aufzubauen würde ich es gerne so machen. Wenn nicht muss ich das Produktivsystem für etwig und drei Tage mit der Übernahme belasten...

Und dann noch die unausweichliche Frage des Dummies, was bitte ist FRCWRITE, und wie stelle ich es aus?

Verwirrt und Ahnungslos, aber voller Hochachtung vor allen klugen Tipps.

Burkhard

[kuempi von stein]

...Und dann noch die unausweichliche Frage des Dummies, was bitte ist FCWRITE, und wie stelle ich es aus?...

ich glaube, damit ist FRCRATIO gemeint. Siehe CRTPF bzw. CRTLF

k.

[Burkhard]

Genau das ist das Problem, wenn ich berechnen kann, dass ich an einem langen Wochenende (z.B. Pfingsten) die Daten mit nur einer log. Sicht übernommen bekomme und danach die Zeit ausreicht alle anderen benötigten 14 [SIC!] logischen Sichten aufzubauen würde ich es gerne so machen. Wenn nicht muss ich das Produktivsystem für etwig und drei Tage mit der Übernahme belasten...

Und dann noch die unausweichliche Frage des Dummies, was bitte ist FRCWRITE, und wie stelle ich es aus?

Verwirrt und Ahnungslos, aber voller Hochachtung vor allen klugen Tipps.

Burkhard

Aha, habe gerade herausbekommen, das damit die Blockung im Systemcache beeinflusst wird.

Danke.

[cbe]

... Wenn nicht muss ich das Produktivsystem für etwig und drei Tage mit der Übernahme belasten...
...

und mit einer evtl. laufenden Sicherung hast Du während dieser ewig+3Tage kein Problem?

Überrede doch mal die entsprechenden Leute, dass Du im Produktiv-System 1 Idx übers Wochenende testweise neu aufbauen darfs, das gibt meiner Meinung nach die beste Zeitschätzung.

Nicht alle Indexe dauern gleichlang, manchmal scheint das System auf bereits bestehende zurückgreifen zu können. Ich würde einen mit großer Objektgröße nehmen.

Eine PF kann übrigens bereits einen Index enthalten, den kannst Du (soweit ich weiß) leider nicht temporär löschen, der würde in jedem Fall bremsen.

Gruß,
Christian

[Burkhard]

und mit einer evtl. laufenden Sicherung hast Du während dieser ewig+3Tage kein Problem?
...
Eine PF kann übrigens bereits einen Index enthalten, den kannst Du (soweit ich weiß) leider nicht temporär löschen, der würde in jedem Fall bremsen.

Gruß,
Christian

Die PF sind "sauber" und die Datensicherung ist ein ernstes Problem.
Voraussichtlich muss die Datei in einem anderen Verzeichnis bearbeitet werden das nicht gesichert wird. Und, ja, mir ist auch schon schlecht bei dem Gedanken, dass etwas passieren könnte!

Ein leines bisschen verzweifelt
Burkhard

[Fuerchau]

Selbst auf einem schnellen System (bis 1000 Sätze/Sek. gepuffert), wirst du wohl ca. 48 Stunden benötigen.
Da lohnt es sich ggf. das Ganze in Häppchen durchzuführen.

[cbe]

Häppchenweise macht natürlich nur mit angehängten Indexen Sinn.

Bevor Du aber die Sicherung umgehst, schreib lieber ein Kopierprogramm, dass Satz für Satz nimmt, kopiert und aus der Quelldatei herauslöscht, und das z.B. alle 1000 Sätze prüft, ob ein Datenbereich auf "X" steht.
Hiermit kannst Du kurz vor der Sicherung die Datei entsperren, und den Kopierjob gleich nach der Sicherung wieder anlaufen lassen.
So kannst Du auch steuern, dass tagsüber das Ding nicht läuft, weil die Anwender sich wahrscheinlich reihenweise über die Performance beschweren würden.

Ich würde auf jeden Fall prüfen, ob die Indexe neu aufzubauen nicht doch möglich ist.

Gruß
Christian

[BenderD]

Hallo,

auf einem schnellen System mit parallel Database Feature ist das mit SQL wesentlich schneller durch (Faktor 10 mindestens, eher 20). Bei den Häppchen und ausreichender I/O Leistung (balanciertes System) ist Parallelisierung das Zauberwort).

mfg

Dieter Bender

Selbst auf einem schnellen System (bis 1000 Sätze/Sek. gepuffert), wirst du wohl ca. 48 Stunden benötigen.
Da lohnt es sich ggf. das Ganze in Häppchen durchzuführen.

[Fuerchau]

@Dieter
Allerdings verhindert FRCWRITE das wieder.

[BenderD]

Hallo,

das muss keineswegs so sein, erstens topt Journalisierung den FRCRATIO, zweitens kann bei REUSE durchaus an mehreren Stellen geschrieben werden und bei write cache der Platten ist das forcierte Schreiben auch nur ein logisches

mfg

Dieter

@Dieter
Allerdings verhindert FRCWRITE das wieder.