Transaktionsprotokoll voll
- Dieses Thema hat 5 Antworten und 1 Teilnehmer, und wurde zuletzt aktualisiert vor 18 Jahre, 2 Monaten vonGast.
- AuthorPosts
- 18. Januar 2005 um 12:11 Uhr #2500
Hallo,
Ich benutze eine DB2 V7.2.
Beim Refresh einer MQT mit einer hohen Anzahl von Datensätzen bekomme ich ebenjenen Errorcode 964.ich weiss, dass diese Frage wohl schon im alten Board beanwortet wurde, allerdings ist die URL leider nicht mehr gültig:
https://www.ruban.de/wwwboard/messages/622.htmlIch habe auch bereits beim Create Table – Statement der MQT ein NOT LOGGED INITIALLY angehängt, was ebenfalls erfolglos blieb (sprich gleicher Fehler beim Refresh).
Die Logfilesize zu erhöhen ist mir aufgrund mangelnder Berechtigung nicht möglich.Da ich recht neu in dem Thema bin, bitte ich um Nachsicht, falls die Beschreibung nicht detailliert genug ist. :-/
vielen Dank
Henrik18. Januar 2005 um 12:28 Uhr #2961Die URL des ursprünglichen threads ist:
https://ruban.de/wwwboard/messages2002/622.html
vielleicht findest Du dort Deine Antwort
19. Januar 2005 um 16:34 Uhr #3286Hallo,
danke für den aktualisierten Link. Anhand dessen habe ich die LOGFILSIZ auf den Maximalwert von 262144 gestellt. Das reicht wenn ich aus meinen Gruppierungen das rollup() entferne. Danke erstmal dafür.
Gibt es denn keine andere Möglichkeit, für eine MQT das Loggen generell auszuschalten ? Beim Refresh Table derselben MQT trat das Problem auch wieder auf. Ein Drop und neuerliches Anlegen nebst REFRESH TABLE ging dann wieder …. ???
Danke Henrik7. April 2005 um 10:48 Uhr #3498Hallo,
habe mithilfe der Steuerzentrale die Transaktionsdateien von Umlauf auf Archiv umgestellt und die Größe im Filesystem erhöht. Seither trat der Fehler nicht mehr auf.
Grüße8. April 2005 um 9:54 Uhr #3638Hi Henrik,
Dein Problem ist nur verschoben: Alle Transaction Logs werden nun aufbewahrt, bis Deine Platte/Device voll ist. 😮
Die Frage ist nun: Wozu sollen die Logs dienen? ???
Wenn Du nur die Absicherung der schwebenden Units of Works benötigst, dann reicht das rollierende Wiederverwenden der Logs. Wichtig: Eine Unit of Work muß auf/in die Logs passen. Deswegen Logs schön groß machen und die Anzahl der Logs erhöhen. Früher gab es eine Grenze für den Umfang bei 2 GB, die ist aber gefallen. Secondary Logs werden nur bei Bedarf angelegt und später wieder beseitigt – hilft, wenn der Platz knapp ist.
Alternativ könnte MQ vielleicht öfter mal einen COMMIT Points setzen. Damit würden die auf dem rollierenden Log zu protokollierenden Units kleiner und früher wieder frei werden.
Arbeiten mehrer UoW’s mit rollierenden Logs, kann ein obsoletes Log nur freigegeben werden, wenn alle Units erledigt sind.Muß der gesamte Zeitraum von Backup zu Backup mit den Logs abgesichert werden, solltest Du (wie geschehen), auf Log Archivierung umstellen. Was passiert aber im Falle eines Platten Crashs? Ok, ein RAID 5 Controller hilft dabei. Was passiert im Falle des kompletten Rechnersausfalls bzw einem Bombenanschlags auf Euer Gebäude? :-/
Ich will darauf hinaus, dass Archive Logs nur an einem vom primären DB Server entfernten Ort wirklich nützlich sind. Beispiel: Ein SAP R/3 DB-Server und Dual Logging auf einem Ausfall-Server. Oder Archiverung auf einem Band-System (TMS, Veritas). :'(Viel Erfolg!
Gruß
Gernot8. April 2005 um 13:09 Uhr #3743 - AuthorPosts
You must be logged in to reply to this topic.
