Optimierung einer Tabelle

[pronny31]

Hallo,

habe folgendes Problem :

Ich habe im laufe der Zeit innerhalb einer Datenbank Feldeigenschaften geändert ...z.b. Varchar(20) auf Varchar(25) usw., um das im laufenden Betrieb zu machen habe ich einfach ein neues Feld mit den neuen Eingeschaften angelegt anschließend alles aus dem Feld, was da geändert werden soll reinkopiert und dann das alte Feld gelöscht und anschießend neu angelegt und wieder reinkopiert werden . Am Ende am habe ich das Feld das ich zum Kopieren genutzt habe wieder gelöscht !.
Meine Frage ist : Gibt es eine Möglichkeit die Tabelle praktisch wie in Mysql mit Optimize den Überhang zu beseitigen und somit auch keine Lücken zurückzulassen ?


Ich habe schon alles versucht aber es gibt keinen Befehl der den Optimze- Befehl von Mysql ersetzt !

Kann mir einer helfen !

[mkinzler]

Sollte nicht botig sein. Sonst solltest du es mit einem Sweep oder Backup/Restore versuchen.

[Hansa]

Mache einen Backup/Restore Zyklus und alle Leichen werden beseitigt. 8)

[pronny31]

Backup Restore macht das ganze nicht die lücken bleiben habe ich alles im IBExpert nachgeprüft !
Was macht Sweep ?

[mkinzler]

Sweep bereinigt die datenbank von alten Zuständen, die durch das Multigeneratorenprinzip entstehen.
Aber Backup/Restore müsste dein Problem definitiv Lösen (wenn das überhaupt ein Problem ist). Der Server gibt nie Festplattenplatz frei, d.h. auch wenn du alles löschst, wird die Datenbank nicht kleiner, sie wächst nur eine Weile nicht meht. Ein Backup/Restore führt deshalb meistens zu einer kleineren Datei.

Zitat:

die lücken bleiben habe ich alles im IBExpert nachgeprüft !

Wo siehst du dort Lücken?

[pronny31]

Problem ist eigentlich nur das ich ein Insert Statement nicht absetzen kann und ich die Vermutung haben das es daran liegt !

Dieses Statement :

SQL-Code:

Insert Into TableA Select * from TableB  where zaehler =  984

Danach kommt folgende Meldung :

Overflow occurred during data type conversion.
conversion error from string "Diverse Adresse".

Die beiden Tabellen sind von der struktur her absolut identisch !

[mkinzler]

Die interne Reihenfolge der Felder aber nicht

[pronny31]

Ich weiss das beide Tabellen identisch ist und habe im vergleich in IBExpert

[edit=Matze]Bild angehängt. MfG, Matze[/edit]

[generic]

gibt beim insert und beim select die feldnamen mit an.

[pronny31]

:wall: Bei 168 Feldnamen ????????????????
Sicher abbbbbbbbbbbbbbbbbbbäääääääääääääääääääääääääääärr rrrrrrrrrrrrrrrrrrrrrrrrrr. :warn:

[RavenIV]

Zitat:

Zitat von pronny31

Bei 168 Feldnamen ?

Eins Tabelle mit 168 Spalten bedarf eh einer überarbeitung.
Das kann bestimmt in eine der Normalformen übergeleitet werden.
Falls Dir das jetzt nichts sagt, solltest Du Dich mal ein Wenig über DB-Design informieren.

[alex517]

Hallo pronny31,

Zitat:

Ich weiss das beide Tabellen identisch ist und habe im vergleich in IBExpert

- in der linken Tabelle ist kein BEZ1 zu sehen.
- in der linken Tabelle BEZ2, BEZ3 VARCHAR(60) und in der rechten VARCHAR(160).

Das ist nicht wirklich identisch.


Fehler

Zitat:

Overflow occurred during data type conversion.
conversion error from string "Diverse Adresse".

Hier versucht Firebird eine Konvertierung, das sollte bei identischen Tabellen eigentlich nicht notwendig sein.
Ich gehe mal davon aus das "Diverse Adresse" kein Feldname ist sondern der Inhalt eines Feldes.
Du solltes mal untersuchen welches Feld das ist und die Typen dieses Feldes in beiden Tabellen vergleichen.

alex

[IBExpert]

Zitat:

Zitat von pronny31

:wall: Bei 168 Feldnamen ????????????????
Sicher abbbbbbbbbbbbbbbbbbbäääääääääääääääääääääääääääärr rrrrrrrrrrrrrrrrrrrrrrrrrr. :warn:

aber was? einfach die tabelle in ibexpert aus dem datenbankexplorer mit drag and drop in den sql editor ziehen
und schon kannst du auswählen,was für ein sql du dazu haben möchtest :-)

[pronny31]

Nein die Tabelle ist genau durchdacht !
Ich will jetzt nur durch Benutzersteuerung die Datensätze von a nach b kopieren (archivieren)

Die Struktur ist identisch 100 %

[RavenIV]

Du könntest Dir von der DB die Feldnamen geben lassen und dann durchiterieren.

[pronny31]

Ich denke das es Lücken gibt und in Mysql nutze ich den Befehl Optimize was es hier icht gibt und Backup Restore oder Sweep macht nix !
Das Problem ist das ich im IBExpert jetzt noch nachollziehen kann das es Felder gibt welche nachträglich hinzugefügt wurden oder angepasst worden sind ! Ich denke das an den stellen wo was gelöscht worden ist der "Raum" nie mehr nutzbar ist und somit Löcher entstehen was sich mit der Übersicht in IBEXPERT deckt ! Ich bräuchte einen Befehl welcher die Tabellen bei bestehenden Datenmenge so organisiert das es kein "Lücken" mehr gibt.

[mkinzler]

Zitat:

Nein die Tabelle ist genau durchdacht !

Die Bezeichnung Bez1, Bez2 usw. lässt aber auf mangelnde Normalisierung Tippen.

[hoika]

Hallo,

ein

SQL-Code:

select * from TableA

liefert bestimmt nicht die gleiche Feld-Reihenfolge zurück wie

SQL-Code:

select * from TableB

Abhilfe1:
siehe oben

Abhilfe2:
ibexpert Tabelle bearbeiten , Popup "reorder fields"


Das Ändern der Länge eines Felds kann auch einfach in IBExpert gemacht werden,
ohne ein neues Feld ("edit domain").

Ein Optimize macht nicht so viel Sinn,
woher soll denn Firebird wissen, das Name in TableA das gleiche wie Name in TableB ist ?


Heiko

[mkinzler]

Zitat:

Zitat von pronny31

Ich denke das es Lücken gibt und in Mysql nutze ich den Befehl Optimize was es hier icht gibt und Backup Restore oder Sweep macht nix !
Das Problem ist das ich im IBExpert jetzt noch nachollziehen kann das es Felder gibt welche nachträglich hinzugefügt wurden oder angepasst worden sind ! Ich denke das an den stellen wo was gelöscht worden ist der "Raum" nie mehr nutzbar ist und somit Löcher entstehen was sich mit der Übersicht in IBEXPERT deckt ! Ich bräuchte einen Befehl welcher die Tabellen bei bestehenden Datenmenge so organisiert das es kein "Lücken" mehr gibt.

Nein, aber das Problem liegt an der Reihenfolge der Felder nicht an Lücken. Die einzige Möglichkeit wäre wohl die Systemtabellen zu manipulieren, wovon aber abgeraten werden muss.

[RavenIV]

Falsche Aussage 1: Die Tabelle ist durchdacht
Das mag ja schon sein, dass Du Dir etwas überlegt hast.
Du hast aber nicht genug überlegt und die Idee des DB-Designs missachtet.

Falsche Aussage 2: Backup/Restore macht nix
Das macht sehr wohl etwas.
a) wie es der Name schon sagt, legt es ein Backup an und stellt dieses wieder her.
b) es "löscht" nicht mehr benutzten Platz in der DB (z.B. von Delete)

[pronny31]

Ja es geht mir jetzt aber auch um den Aufbau dieser Tabelle und warum er dieses Lücken hat und die Tabelle hat sie 100 %!
Weil wenn ich explizit die Spaltennamen angebe geht es mache ich aber * kommt diese Fehlermeldung !
Ich habe den eindruck das Firebird bei der angabe * einfach annimmt das alles in der selben reihenfolge ist und dadurch der Fehler zustande kommt !

[RavenIV]

Zitat:

Zitat von pronny31

Ja es geht mir jetzt aber auch um den Aufbau dieser Tabelle und warum er dieses Lücken hat und die Tabelle hat sie 100 %!
Weil wenn ich explizit die Spaltennamen angebe geht es mache ich aber * kommt diese Fehlermeldung !
Ich habe den eindruck das Firebird bei der angabe * einfach annimmt das alles in der selben reihenfolge ist und dadurch der Fehler zustande kommt !

Mann, Mann, Mann. :-(

Das, was Du im IBExpert siehst, ist der logische Aufbau der Tabelle.
Die Lücken stellt der IBExpert eben so dar.
Wie willst Du sehen, wie die Tabelle intern von der DB verwaltet wird?

Warum der Fehler bei der Sache mit dem * kommt kann ich Dir auch sagen.
Die Felder der Tabelle sind unterschiedlich beim Datentyp, ausserdem ist die Anzahl Felder unterschiedlich, weiterhin gibt es in der einen Tabell manche Felder der anderen Tabelle nicht.

Les Dir nochmal die Beiträge meiner Vorredner durch und überleg vorher, was Du von Dir gibst.

[mkinzler]

Zitat:

Ich habe den eindruck das Firebird bei der angabe * einfach annimmt das alles in der selben reihenfolge ist und dadurch der Fehler zustande kommt !

Nein Firebird liest diee felder aus der Systemtabelle aus. Später erzeugte felder sind dort natürlich weiter hinten, deshalb ist die logische Reihenfolge der beiden Tabellen verschieden.

[pronny31]

Bevor ich hier was reinstelle überlege ich mir schon was ich sage !
Ich habe Prozeduren geschrieben die die Gleichheit bezogen auf die Struktur und Feldnamen prüft , welche ergeben hat das alles Korrekt ist ! Ihr solltet schon mal lesen was ich schreibe und erst dann Urteilen !!

[RavenIV]

Zitat:

Zitat von pronny31

Bevor ich hier was reinstelle überlege ich mir schon was ich sage !
Ich habe Prozeduren geschrieben die die Gleichheit bezogen auf die Struktur und Feldnamen prüft , welche ergeben hat das alles Korrekt ist ! Ihr solltet schon mal lesen was ich schreibe und erst dann Urteilen !!

Dann extrahier mal die Metadaten der beiden Tabellen und vergleiche diese miteinander.
Wenn Du alles richtig machst, dann kannst Du z.B. mit ExamDiff die Unterschiede feststellen.

[hoika]

Hallo,

> Ich habe Prozeduren geschrieben die die Gleichheit bezogen <
> auf die Struktur und Feldnamen prüft , welche ergeben hat das alles Korrekt ist >

Struktur <> Reihenfolge der Felder

mache einfach mal was ich gesagt habe (select * und Reihenfolge ändern).


Heiko

[pronny31]

Zitat:

mache einfach mal was ich gesagt habe (select * und Reihenfolge ändern)

ja wie ohne die Datenbank bzw. tabellen neu anzulegen ?
es kann ja durchaus sein das bei einem Volumen von ca. 40 - 50 Mio Datensätzen es etwas länger dauert :coder2:
mach mal bitte einen Vorschlag

[mkinzler]

Du brauchst doch die Abfrage mit Feldliste nur einmal erstellen und kannst das Skript dann abspeichern

[Jelly]

Also ich behaupte jetzt mal ganz einfach.... NUTZE NIEMALS EIN SELECT * FROM ...
sondern gebe immer alle Feldnamen an, auch wenn es 168 sind.

Die Zeit, die durch diesen Thread schon verplempert wurde, um dein Problem zu schildern, währenddessen hättest du die 168 Feldnamen schon 10 mal sogar händisch eingetippt.

[pronny31]

Das stimmt schon mir ging es eben auch um den Hintergrund (Datenbanksystemtechnisch) und ich wollte eben eine logische Erklärung haben. Ich dachte es kennt jemand die genauen Gründe dafür und kann mir dabei helfen !
Viele Beiträge hätten nicht verfasst werden müssen , wenn man versucht hätte meine Beiträge aufmerksam zu lesen ! Ich habe z.B. gesagt, dass meine Tabellen von der Struktur her absolut 100 % identisch sind -> anschließend folgt ein Hinweis das die Fehlermeldung auf die Tatsache zurük zu führen wäre, dass die Struktur der beiden Tabellen nicht identisch wäre !

Zitat:

Dann extrahier mal die Metadaten der beiden Tabellen und vergleiche diese miteinander.
Wenn Du alles richtig machst, dann kannst Du z.B. mit ExamDiff die Unterschiede feststellen.

Mmh was soll man darauf antworten !

Dann kamen Hinweise bezüglich des Aufbaus der Datenbank . Ich Rede hier von einer Datenbank die ca 40-50 Millionen Datensätze hat und ansonsten auch hervoragend funktioniert und man sagt mir ich sollte den Aufbau der Datenbank überdenken .

Zitat:

Die Bezeichnung Bez1, Bez2 usw. lässt aber auf mangelnde Normalisierung Tippen.

Diese Hinweise und Antworten haben mit meiner Fragestellung nichts zu tun !

Naja ich habe jetzt beschlossen die Feldnamen manuell zu übergeben und das Statement anschließend auszuführen !


Ich danke all denen die sich ernsthaft damit beschäftigt haben und sinnvolle Beiträge verfasst haben !!!!!!!!

[Jelly]

Zitat:

Zitat von pronny31

Viele Beiträge hätten nicht verfasst werden müssen , wenn man versucht hätte meine Beiträge aufmerksam zu lesen ! Ich habe z.B. gesagt, dass meine Tabellen von der Struktur her absolut 100 % identisch sind -> anschließend folgt ein Hinweis das die Fehlermeldung auf die Tatsache zurük zu führen wäre, dass die Struktur der beiden Tabellen nicht identisch wäre !

Also jetzt machst du dich lächerlich, sorry.

In diesem Beitrag von dir hattest du vorhin wunderschön in einem Bild offen gelegt, dass die beiden Tabellen eben in der Reihenfolge der Felder NICHT identisch sind. Jetzt behauptest du weiter stur und fest, sie seien es trotzdem, und um alle Beweise zu vernichten, enfernst du den Screenshot.

Du meinst also nicht im ernst, dass ich darauf noch weiter eingehen möchte.

Und noch was: Ob nun 1000 oder 50 Millionen Datensätze in einer Tabelle stehen, das sagt noch längst nichts über ein gescheites DB Design aus.

Und glaube mir, du hast hier von einigen alten Hasen Antworten auch zu der theoretischen Frage erhalten, sogar von IBExpert selbst, dem Autor von IBExpert. Der kennt Firebird wie seine Westentasche, und wagst es trotzdem sein Wissen anzuzweifeln, und auf deine leichtsinnige, unbegründete Aussage zu basieren, die Tabellen wären identisch... Alswo wirklich, ja :gruebel:

[mkinzler]

Schau dir doch die Einträge der beiden Tabellen in der Systemtabelle an und du wirst sehen das selbe Struktur nicht gleiche Reihenfolge bei select * bedeutet.
Ich habe mal eine Testtabelle erzeugt und die Änderungen an den Systemtabellen mit Screenshoots dokumentiert.
1: Tabelle vor dem Update
2: Nach Anlage des temporären Feldes.
3: Nach Löschen des alten Feldes
4: Umbenennen des neuen Feldes

Vergleiche mal 1 und 4 und du siehst das Problem

[pronny31]

Mkinzler vielen dank !

Das heißt also , wenn an einer Tabelle A Änderungen vorgenommen worden sind und an der Tabelle B keine Änderungen vorgenommen worden sind anschließend sichergestellt wird das die Tabelle A wieder identisch ist mit der Tabelle B das

SQL-Code:

Insert Into Tabelle A select * from Tabelle B nicht geht !

Stimmst du mir da zu ?

[hoika]

Hallo,

ibexpert, tabelle bearbeiten - rechte maustaste reihenfolge ändern)


Heiko

[Jelly]

Zitat:

Zitat von pronny31

Stimmst du mir da zu ?

Ich zumindest nicht.

Wenn du an Tabelle A die Metadaten änderst (alter table), warum sollte sich die Tabellenstruktur wieder zurückspielen duch ein Insert into?

[pronny31]

Nein ich will jetzt in die Tabelle A meine Daten zurückspielen daher das Insert Statement !
Meine beiden Tabellen sind mitlerweile wieder identisch .... und jetzt habe ich vor alles von a nach zu kopieren b
das Bild, welches ich vorhin reingestellt habe zeigt das die Reihenfolge nicht identisch ist und ich habe gelesen das eine Änderung der Reihenfolge nur an der Systemtabelle vorgenommen werden kann und das ist ziemlich gefährlich da dies zur vollständigen Zerstörung der Datenbank führen kann ! Also denke ich das es in diesen Zustand ohne Änderung der Reihenfolge nicht möglich ist dieses Statement abzusetzen und außerdem kann man eine Änderung dieser Reihenfolge nicht via Sql - Statement korregieren !

[mkinzler]

Zitat:

as Bild, welches ich vorhin reingestellt habe zeigt das die Reihenfolge nicht identisch ist und ich habe gelesen das eine Änderung der Reihenfolge nur an der Systemtabelle vorgenommen werden kann und das ist ziemlich gefährlich da dies zur vollständigen Zerstörung der Datenbank führen kann !

wenn du einen exklusiven Zugriff auf die DB hast, sollte es keine größeren Probleme geben.

Zitat:

Also denke ich das es in diesen Zustand ohne Änderung der Reihenfolge nicht möglich ist dieses Statement abzusetzen

Wenn du die Reihenfolge im select angibst sollte die Reihenfolge der Felder doch egal sein.

Zitat:

und außerdem kann man eine Änderung dieser Reihenfolge nicht via Sql - Statement korregieren !

Und Warum nicht? Wie glaubst du werden sie dann vom Admin-Tool geändert?

[hoika]

Hallo,

zur Positionsänderung

http://www.ibphoenix.com/main.nfs?a=...60_altercol_fs

SQL-Code:

alter table table1 alter field1 position 3 modify field1 position 2;

Das sollte ab FB1.5 gehen.

Heiko

[pronny31]

Bist du dir sicher das das keinen einfluß auf bestehende Datenbestände hat bzw. nichts zerstört ?
Habe gehört das sowas nicht empfohlen wird !

[mkinzler]

Wie gesagt sollte gleichzeitig kein Zugriff auf die Datenbank erfolgen. Außerdem sollte man vor jeder Strukturänderung einer Datenbank vorher ein Backup durchführen.