Hallo Ralf!
Ich habe nun mal alle DB’s miteinander
verglichen (laufen in verschiedenen Lokationen mit den selben
Aufgaben - also sollte alle DB’s gleich aufgebaut sein) und
festgestellt, dass der Index ‚BXPKSENDTABLEVARCHAR2‘ in dieser
lokation in den Tablespace ABCPARAMETER und nicht in
ABCOFFLINE schreibt.
Die Idee mit dem Vergleich ist ja an und für sich ganz gut, aber ich halte es für einen vorschnellen Schluss zu glauben, dass zwangsläufig die eine DB falsch ist, die einen Unterschied zu allen anderen aufweist - das könnte durchaus auch umgekehrt sein (z.B. Fehler in den Skripten korrigiert, aber die bereits bestehenden Datenbanken „vergessen“ anzupassen). Ich würde also in dem Fall versuchen denjenigen zu kontaktieren, der die DB auch aufgesetzt hat.
Und nun die Quälenden Frage: Dass ich dem Index den richtigen
Tablespace ‚aufdübeln‘ kann, davon gehe ich aus, aber was
passiert in der Zukunf?
Was du beim „umdübeln“ tust ist eigentlich nichts anderes, als den Index in einem anderen Tablespace komplett neu aufzubauen. Das sollte theoretisch keinerlei weiteren Auswirkungen haben, solange nicht „irgendjemand“ sich darauf verlässt, dass ein bestimmter Index auch in einem bestimmten Tablespace liegt. Wir bei uns verwenden z.B. einen eigenen Tablespace für (logisch gesehen) temporäre Daten, die per Datenbank-Job immer wieder mal gelöscht werden - und zwar unabhängig davon wie die Tabellen in dem TS heissen. Wenn du mir da eine Stammdatentabelle reinlegst erlebst du früher oder später ein blaues Wunder…
Nimmt er dann die schon vorhandenen
Eintragungen mit in den neuen Tablespace? Oder ist damit ein
zukünftiger crash vorprogrammiert?
Wie schon gesagt, das Resultat ist das gleiche, als wenn du den Index von vorneherein im anderen Tablespace angelegt hättest (abgesehen von der internen Struktur des Indexes, aber das führt hier jetzt wohl etwas zu weit). Die Frage ist nur, ob auch „jeder“ weiss, dass du den Index verschoben hast, der das auch wissen muss.
Ich bitte Euch um Rat, denn ich habe zwar eine Testumgebung,
aber was im richtigen Betrieb passiert, wenn sehr viele Daten
auf die DB wollen, das kann ich natürlich nicht richtig
austesten!!!
Ich würde dir wirklich wärmstens empfehlen mit demjenigen Kontakt aufzunehmen, der die DB auch angelegt hat. Andernfalls landest du unter Umstaänden in Teufels Küche, obwohl die Probleme, die ein fehlender Index hätte noch zu den geringeren Übeln zählen, wenn da nicht auch gerade ein unique constraint oder primary key dranhängt. Ansonsten wirst du einen fehlenden Index wohl nur bei der Performance bemerken.
Ich möchte auch nochmals daran erinnern, dass es
sich um eine Oracle 7.3 handelt!!
Und da empfehle ich DRINGENDST einen Update. Zur Zeit sind von Oracle nur die Versionen 8.1.x und neuer Supported, du bist also schon zwei Versionen im Rückstand, und angesichts der Tatsache, dass Oracle in der Regel immer nur 2 1/2 Versionen unterstützt (sprich 8i wird wohl in nicht allzu fernen Zukunft desupported) solltest du dir gleich mal Gedanken über 10g machen.
Vielen Dank!!!
Leider wenig praktisch hilfreiches von meiner Seite… Solltest du meine Warnung in den Wind schlagen wollen, so kann man einen Index verschieben:
ALTER INDEX REBUILD TABLESPACE ;
Gruss,
Martin
: unter 7.x gibt’s kein rebuild (bin selber vor _kurzem_ auf einer 7.3.4 reingefallen); es führt kein weg am index droppen und index neu anlegen vorbei (wobei man sich die index-parameter ev. aufschreiben sollte od. mittels toad sich ein script rausgeneriert - ja, ich bin ein fauler hund)