Datenverlust

[stef0]

Seit längerer Zeit habe ich mit meinem Programm ein hartnäckiges Problem:
Es werden auf einer Oracle-Datenbank INSERTs, UPDATEs, DELETEs ausgeführt. Commited wird, die Datensätze werden also erzeugt, geändert, gelöscht. Allerdings passiert es des öfteren, dass z.B. einen Tag später schon gespeicherte Datensätze nicht mehr vorhanden sind, obwohl in dieser Zeit laut Protokoll kein einziges DELETE ausgeführt wurde.
Woran könnte es liegen? Ich bin für jeden kleinen Hinweis dankbar.

 

[abollm]

Seit längerer Zeit habe ich mit meinem Programm ein hartnäckiges Problem:
Es werden auf einer Oracle-Datenbank INSERTs, UPDATEs, DELETEs ausgeführt. Commited wird, die Datensätze werden also erzeugt, geändert, gelöscht. Allerdings passiert es des öfteren, dass z.B. einen Tag später schon gespeicherte Datensätze nicht mehr vorhanden sind, obwohl in dieser Zeit laut Protokoll kein einziges DELETE ausgeführt wurde.
Woran könnte es liegen? Ich bin für jeden kleinen Hinweis dankbar.

Schon einmal einen Oracle-Trace laufen gelassen und das Trace-File analysiert?

 

[DP]

index rebuilden lassen?!

 

[stef0]

Schon einmal einen Oracle-Trace laufen gelassen und das Trace-File analysiert?

Ich habe ein INSERT-, DELETE-Audit laufen lassen, hat mich aber nicht weitergebracht. Meinst du das mit "Oracle-Trace"? Außerdem werden die SQL-Statements vom Programm in einer Datei mitprotokolliert, allerdings sieht man auch hier nichts ungewöhnliches...
Weitere Ideen?

index rebuilden lassen?!

Sorry, wär nicht schlecht, wenn du das etwas erläutern könntest. Da reichen meine DB-Kenntnisse bei weitem nicht aus ...

 

[DP]

index rebuilden lassen?!

 

[abollm]

index rebuilden lassen?!

Wieso soll ein defekter Index zu Datenverlusten führen? In der Regel doch eher zu doppelten Datensätzen.

 

[DP]

ne, eher zu nicht gefundenen datensätzen

 

[stef0]

ne, eher zu nicht gefundenen datensätzen

Die Datensätze sind aber definitiv weg...

 

[abollm]

Schon einmal einen Oracle-Trace laufen gelassen und das Trace-File analysiert?

Ich habe ein INSERT-, DELETE-Audit laufen lassen, hat mich aber nicht weitergebracht. Meinst du das mit "Oracle-Trace"? Außerdem werden die SQL-Statements vom Programm in einer Datei mitprotokolliert, allerdings sieht man auch hier nichts ungewöhnliches...
Weitere Ideen?

index rebuilden lassen?!

Sorry, wär nicht schlecht, wenn du das etwas erläutern könntest. Da reichen meine DB-Kenntnisse bei weitem nicht aus ...

Audit ist nicht Trace:

Aber eigentlich habe ich falsch gedacht, zunächst würde das Alert-File im bdump-Verzeichnis analysieren, um irgendwelche DB-Fehler auszuschließen.

 

[bronks]

... Die Datensätze sind aber definitiv weg...

Welches Produkt und welche Version ist es und auf welchem Betriebssystem läuft das ganze? Dann wäre noch interessant, ob es ein ProductionRelease ist.

Ich habe schon mit diversen Bugs in den Datenbanken, der 3 bedeutenden Hersteller gekämpft, aber das Sätze in einer DB, die für Production freigegeben ist, verschwinden wäre schon ein sehr grober Bug.

 

[abollm]

@stef0:

Wie ist denn dein DB-Schema aufgebaut?

Hast du nur Tabellen, Views, Trigger und Indizes im Schema?

Oder gibt es daneben auch Stored Procedures, Java Stored Procedures?

Vielleicht schlägt ja auch irgendein Datenbak-Job zu, den einer nihct korrekt eingestellt hat.

Bei einer sauberen Struktur und einer korrekt aufgesetzten Datenbank schließe ich ein einfaches Löschen "aus heiterem Himmel" bei Oracle zunächst einmal aus. Da stimme ich auch bronks hinsichtlich eines "groben Bugs" zu.

 

[stef0]

Wie ist denn dein DB-Schema aufgebaut?

Schema: DB
Tabellen: TR, LI
Indizes: nur TR_UK1 und LI_UK1 (unique constraints)
keine Views
keine Procedures

Welches Produkt und welche Version ist es und auf welchem Betriebssystem läuft das ganze? Dann wäre noch interessant, ob es ein ProductionRelease ist.

Wie finde ich das denn raus, habe keinen physischen Zugang zum DB-Server und auch keine Admin-Rechte.

Danke schon mal für die Bemühungen.

 

[abollm]

Welches Produkt und welche Version ist es und auf welchem Betriebssystem läuft das ganze? Dann wäre noch interessant, ob es ein ProductionRelease ist.

Wie finde ich das denn raus, habe keinen physischen Zugang zum DB-Server und auch keine Admin-Rechte.

Danke schon mal für die Bemühungen.

Du musst bzw. solltest einen Oracle-Client auf deiner Maschine installiert haben. Ansonsten wirst du kaum weiter kommen. Wenn du eine Oracle-Client-Installation hast (erkennbar daran, dass du - unter Windows-OS - Einträge in der Start-Leiste unter Programme hast, die mit "Oracle" beginnen, darunter dann u.a. auch SQL*Plus.

Das letztgenannte Programm startest du und loggst dich ein. Nach dem erfolgreichen Einloggen erhältst du folgende Ausgabe (hier ein Beispiel) auf deinem Bildschirm:

SQL*Plus: Release 9.2.0.7.0 - Production on Mon Feb 5 12:00:25 2007

Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.


Connected to:
Oracle9i Release 9.2.0.6.0 - Production
JServer Release 9.2.0.6.0 - Production

SQL>

Der obere Eintrag steht für den Client, der untere Eintrag für den DB-Server.

 

[stef0]

DB-Version:
Enterprise-Edition Release 9.2.0.1.0 - Production with partitioning, spatial, OLAP, Oracle Data Mining options

Ein grober DB-Bug ist es wohl dann nicht?!

 

[abollm]

Hm, sieht nicht danach aus.

Du hast offenbar keinen Zugriff auf den DB-Server, oder? Wenn ja, dann schau dir dort unbedingt die Datei <Instanzname>alert.log an. Wenn nein, dann bitte den DBA darum.

Treten die merkwürdigen Löschaktionen nur sporadisch auf, oder in irgendeiner Form regelmäßig?

 

[stef0]

DBA benachrichtigt...

Meistens treten die Verluste bei den Datensätzen auf "where datum = morgen", aber wirklich nur "meistens".

 

[DP]

bin von oracle schon zu lange weg... aber evtl. wurde ein rollback gemacht und die änderungen sieht man nicht im logfile?!

 

[stef0]

Das ist ein Auszug aus dem alert.log, laut DBA nichts sonderbares dabei:

Mon Feb 05 03:04:08 2007
ARC1: Evaluating archive   log 1 thread 1 sequence 3131
  Current log# 2 seq# 3132 mem# 2: ...\...\...\REDO\REDO32.LOG
ARC1: Beginning to archive log 1 thread 1 sequence 3131
Creating archive destination LOG_ARCHIVE_DEST_1: '...\...\...\...\03131.001'
ARC1: Completed archiving  log 1 thread 1 sequence 3131
Mon Feb 05 09:42:46 2007
Thread 1 advanced to log sequence 3133
  Current log# 1 seq# 3133 mem# 0: ...\...\...\REDO\REDO11.LOG
  Current log# 1 seq# 3133 mem# 1: ...\...\...\REDO\REDO21.LOG
  Current log# 1 seq# 3133 mem# 2: ...\...\...\REDO\REDO31.LOG
Mon Feb 05 09:42:46 2007
ARC0: Evaluating archive   log 2 thread 1 sequence 3132
ARC0: Beginning to archive log 2 thread 1 sequence 3132
Creating archive destination LOG_ARCHIVE_DEST_1: '...\...\...\03132.001'
ARC0: Completed archiving  log 2 thread 1 sequence 3132

 

[DP]

solche effekte hatte ich auch schon mal unter mysql - da sind dann positionen von aufträgen "verschwunden".

lösung des ganzen: durch einen bug wurden per update andere auftragsnummern vergeben.

 

[abollm]

Schalte doch einfach mal den Archive-Modus für einige Tage aus, um zu sehen, ob damit etwas faul ist.