Firebird Backup zerstört Datenbank

[hanspeter]

Hallo,
ich habe wieder einmal ein unerklärliches Problem.
Ich sichere eine Datenbank über IBExpert Backup.
Lese ich das Backup zurück (existierende Datenbank ersetzen), dann ist
die Datenbank nicht mehr verwendbar.
Beim Öffnen in IBExpert kommt die Fehlermeldung
"Cannot transliterate character between character sets.
Cannot transliterate character between character sets."
und die Datenbank ist in IBExpert nach dem Öffnen leer.
Die vorhandene Datenbank funktioniert im System problemlos.
Lasse ich über IBExpert eine Validierung laufen, dann kommt die Meldung
"Connection error.
bad parameters on attach or create database.
secondary server attachments cannot validate databases.
IBE: Validation completed."

Hat wer eine Idee, woran das liegen könnte
und wie ich wieder zu einer korrekten Datenbank komme?

(Und nein es ist nichts passiert, ich habe noch X Sicherheitskopien der aktuellen Datenbank.)

Für einen Tip dankbar.
Gruß
Peter

[haentschman]

und wenn du eine komplett neue (statt überschreiben) anlegst ?

[hanspeter]

Zitat:

Zitat von haentschman (Beitrag 1030150)

und wenn du eine komplett neue (statt überschreiben) anlegst ?

Gerade ausprobiert - die gleiche Wirkung.

Was ich gerade überlege, die Datenbank gibt es schon seit mehr als 10 Jahren von Interbase über FB 1.0 bis jetzt FB 2.1.
Ich habe sie zwar immer mit jedem Wechsel auf die nächste Version updatet, aber sie wird zwischen mehreren Stellen permanent ausgetauscht.
Wäre es ein Versionsproblem, dann wäre das ja beinahe tödlich. Backup funktioniert, Restore ist kaputt.
Den Fehler merkt man erst im Ernstfall und dann ist es zu spät.

Gruß
Peter

[mkinzler]

Versuche die DB mal über ein Script auszulagern und lege die datenbank damit neu an

[haentschman]

Zitat:

Wäre es ein Versionsproblem, dann wäre das ja beinahe tödlich. Backup funktioniert, Restore ist kaputt.

aber sie wird zwischen mehreren Stellen permanent ausgetauscht.

...auch wenn das Backup und Restore auf dem gleichen Rechner gemacht wird ?

[webcss]

Zitat:

Zitat von hanspeter (Beitrag 1030151)

Was ich gerade überlege, die Datenbank gibt es schon seit mehr als 10 Jahren von Interbase über FB 1.0 bis jetzt FB 2.1.

wobei Du jedes update hoffentlich mit einem backup auf dem alten und einem restore auf dem neuen interbase/firebird machst?!

Zitat:

Zitat von hanspeter (Beitrag 1030151)

Ich habe sie zwar immer mit jedem Wechsel auf die nächste Version updatet, aber sie wird zwischen mehreren Stellen permanent ausgetauscht.
Wäre es ein Versionsproblem, dann wäre das ja beinahe tödlich. Backup funktioniert, Restore ist kaputt.
Den Fehler merkt man erst im Ernstfall und dann ist es zu spät.

Das ist tödlich, da jede version eine neue ODS (OnDiskStructure) hat...

Grundsätzlich sollte man vor jedem restore eines arbeitssystems einen testrestore machen, um den zugriff zu testen.

Zu Deinem Problem: Wenn die DV mit unterschiedlichen CharacterSets arbeitet, aka User 1 arbeitet mit WIN1252, ein anderer mit ISO8859_1, dann gehts schon schief, weil unterschiedliche CharacterSets in ein und derselben DB vorliegen, Firebird (od IB) Restore aber nur mit einem vorhandenen klar kommt.

Das solltest Du dringend prüfen.

Hoffe das hilft Dir weiter.

[hanspeter]

Zitat:

Zitat von haentschman (Beitrag 1030153)

Zitat:

Wäre es ein Versionsproblem, dann wäre das ja beinahe tödlich. Backup funktioniert, Restore ist kaputt.

aber sie wird zwischen mehreren Stellen permanent ausgetauscht.

...auch wenn das Backup und Restore auf dem gleichen Rechner gemacht wird ?

Das mache ich auf dem gleichen Rechner, unmittelbar im Ibexpert.
1. IbExpert - Backup
2. Explorer lösche Datenbank
3. Ibexpert Restore
4. Ibexpert Öffen -> DB zerschossen.

Auch wenn es ein Charset oder sonst ein Problem ist, dann darf das Backup nicht fehlerfrei ablaufen
und ein nicht verwendbares Backup erzeugen!
Ich probiere das jetzt noch mal ohne IbExpert mit gback.

Gruß Peter

[haentschman]

ich hab das mal mit meinem IBExpert ablaufen lassen. Keine Probleme.

Was mir aufgefallen ist:
- beim Backup steht die Seitengröße, beim Restore Default. Wenn die beiden nicht identisch sind was passiert dann ?

...eben probiert, nix. Alles in Ordnung. Nur das das Restore länger dauert wegen der Anpassung.

[hanspeter]

Zitat:

Zitat von haentschman (Beitrag 1030162)

Was mir aufgefallen ist:
- beim Backup steht die Seitengröße, beim Restore Default. Wenn die beiden nicht identisch sind was passiert dann ?

...eben probiert, nix. Alles in Ordnung. Nur das das Restore länger dauert wegen der Anpassung.

Die Seitengröße ist seit 10 Jahren gleich. (4096)

In dem System wird eine Datei temporär angelegt und hat eine Gültigkeit von etwa einem Jahr. Mit dieser Datenbank besteht
das Problem nicht, sondern nur mit der Archivdatenbank.
Als Notlösung habe ich erst mal alle Anwender informiert, die Archivdatenbank nicht mehr üpber Backup zu sichern, sondern
wenn alle Clients ausgeloggt sind, manuell zu sichern.

Gruß
Peter

[haentschman]

Machen die Anwender das Backup auch über IBExpert ? Da kann man ne Menge Haken setzen :zwinker:

Vieleicht ein kleines Tool geschrieben, was das Backup übernimmt, damit identische Einstellungen herrschen.

[hanspeter]

So jetzt habe ich es.
Die angelieferte Datenbank war ODS 11.0 als FB 2.0.
Das installierte FB 2.1 hat ODS 11.1.

Normalerweise sollte man jetzt mit GBack aus FB 2.0 ein Backup und dann in FB2.1 ein Restore
machen können.
Beim Translate von Blobdaten gibt es wohl einen Bug, der seit 09/2009 im Bugtracker eingetragen ist.
Dieser hat bei mir zugeschlagen.
Ich habe jetzt die Datenbank neu angelegt und dann die Daten importiert.
Ist natürlich tödlich, wenn der Anwender brav sein Backup anlegt und das nicht funktionsfähig ist.

Ich habe noch einen weiteres Problem mit FB, das im Moment nicht lösbar ist.
Ich habe eine SP, die Abrechnungen vornimmt. Wird diese SP aktiviert, dann läuft sie länger.
Nimmt jetzt irgend ein Client Änderungen vor,dann kommt häufig ein deadlook.
Dieser hat zur Folge, das ich das Programm herunterfahren und den FB Dienst beenden und neu
starten muss. Erst ein Entfernen der SP und ausführen der Abrechnung im Programm hat den deadlook dauerhaft beseitigt.
Aufgrund weiterer Vorteile, die ein Wechsel bringen würde, denke ich im Moment darüber nach auf den MS SQL Server (kostenfreie Variante) zu wechseln.
Hat wer das schon mal gemacht und kann den Aufwand abschätzen?

Gruß
Peter


Gruß Peter

[mkinzler]

Neue Frage neuer Thread

[MPö]

Cannot transliterate character between character sets

Bei mir kam dieser Fehler nach dem Umstieg von der Version 1.5 auf 2.1
Grund waren Umlaute in der Beschreibung der Datenbankfelder.
Die DB benutzt den Charset WIN1252

[dataspider]

Zitat:

Zitat von hanspeter (Beitrag 1030227)

Ich habe noch einen weiteres Problem mit FB, das im Moment nicht lösbar ist.
Ich habe eine SP, die Abrechnungen vornimmt. Wird diese SP aktiviert, dann läuft sie länger.
Nimmt jetzt irgend ein Client Änderungen vor,dann kommt häufig ein deadlook.
Dieser hat zur Folge, das ich das Programm herunterfahren und den FB Dienst beenden und neu
starten muss. Erst ein Entfernen der SP und ausführen der Abrechnung im Programm hat den deadlook dauerhaft beseitigt.
Aufgrund weiterer Vorteile, die ein Wechsel bringen würde, denke ich im Moment darüber nach auf den MS SQL Server (kostenfreie Variante) zu wechseln.
Hat wer das schon mal gemacht und kann den Aufwand abschätzen?

Gruß
Peter


Gruß Peter

Ich halte es nicht für den richtigen Weg - immer dann - wenn man ein scheinbar unlösbares Problem hat, die DB oder die Zugriffskomponenten zu wechseln.

Lies mal den Beitrag, vielleicht kannst du das Problem ja lösen:
http://www.ibphoenix.com/main.nfs?a=..._exp_deadlocks

Wichtig ist, das der Prozess, der einen Fehler bekommt, ein Rollback macht und die Transaktion neu startet.

Frank

[mkinzler]

das mit dem neuen Thread war aber ernst gemeint