Formel zur Berechnung von I-O Operationen

[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.