Spaß mit dem Geoinformationssystem
Nur für den eigentlich gar nicht so unwahrscheinlichen Fall, daß ich doch nicht der Einzige bin, der von SDE 9.0 auf 9.3.1 (mit Oracle als Geodatabase natürlich) direkt upgraden will - was ja eigentlich supported ist: Die Sache hat einen Haken. Einen ganz kleinen zwar nur, aber...
sdesetup -o upgrade -d ORACLE11G -u sde -p sdepassword
fällt gleich am Anfang mit einem -51 (underlying DBMS error) auf die Nase. Im sde_setup.log findet sich des Rätsels Lösung: Es wird versucht, den constraint DBTUNE_UK zu enablen. Allerdings existiert dieser in der alten Datenbank nicht für die DBTUNE-Tabelle - stattdessen gibt es den DBTUNE_PK (PK = Primary Key, UK = Unique Key)...
Nun ja, der Teufel hat drei (oder mehr) davon, und natürlich in sämtlichen verfügbaren Versionen - also flugs in einer 9.3er Geodatabase nachgesehen, und tatsächlich, dort findet sich DBTUNE_UK. Nach manuellem drop des DBTUNE_PK und Anlegen des DBTUNE_UK in der 9.0er lief das Upgrade dann ohne weiteres durch.
Weiß der Geier, warum ESRI das geändert hat und warum sich nirgendwo in den Weiten des www und auch nicht in den Support-Foren auch nur der kleinste Hinweis auf dieses "Feature" finden ließ... ich werde allerdings auf der ESRI 2010 mal direkt die Experten befragen, bevor ich meinen Workaround auf die Produktionsdatenbank "loslasse".
Wenn jetzt jemand nach DBTUNE_UK sucht, dann findet er aber wenigstens diesen bescheidenen Blogeintrag ;-)
Update:
Nachdem ich auf die neue DB und ihr read-only-Gegenstück auf der anderen Seite der Welt jetzt die Snapshot-Replikation aufgesetzt habe weiß ich auch, woher die Diskrepanz PK/UK kommt:
Für die Replikation wird seitens Oracle natürlich ein Primary Key benötigt, und so wird der DBTUNE_UK vom Replikationsskript eben kurzerhand zum DBTUNE_PK gemacht - also einfach wieder einmal einer dieser Spezialfälle, an die anscheinend kein Mensch gedacht hat (weswegen ich dazu auch nichts finden konnte, denn bei tausenden anderer Anwender, die nicht replizieren taucht das natürlich gar nicht auf). Alles wird gut ;-)
sdesetup -o upgrade -d ORACLE11G -u sde -p sdepassword
fällt gleich am Anfang mit einem -51 (underlying DBMS error) auf die Nase. Im sde_setup.log findet sich des Rätsels Lösung: Es wird versucht, den constraint DBTUNE_UK zu enablen. Allerdings existiert dieser in der alten Datenbank nicht für die DBTUNE-Tabelle - stattdessen gibt es den DBTUNE_PK (PK = Primary Key, UK = Unique Key)...
Nun ja, der Teufel hat drei (oder mehr) davon, und natürlich in sämtlichen verfügbaren Versionen - also flugs in einer 9.3er Geodatabase nachgesehen, und tatsächlich, dort findet sich DBTUNE_UK. Nach manuellem drop des DBTUNE_PK und Anlegen des DBTUNE_UK in der 9.0er lief das Upgrade dann ohne weiteres durch.
Weiß der Geier, warum ESRI das geändert hat und warum sich nirgendwo in den Weiten des www und auch nicht in den Support-Foren auch nur der kleinste Hinweis auf dieses "Feature" finden ließ... ich werde allerdings auf der ESRI 2010 mal direkt die Experten befragen, bevor ich meinen Workaround auf die Produktionsdatenbank "loslasse".
Wenn jetzt jemand nach DBTUNE_UK sucht, dann findet er aber wenigstens diesen bescheidenen Blogeintrag ;-)
Update:
Nachdem ich auf die neue DB und ihr read-only-Gegenstück auf der anderen Seite der Welt jetzt die Snapshot-Replikation aufgesetzt habe weiß ich auch, woher die Diskrepanz PK/UK kommt:
Für die Replikation wird seitens Oracle natürlich ein Primary Key benötigt, und so wird der DBTUNE_UK vom Replikationsskript eben kurzerhand zum DBTUNE_PK gemacht - also einfach wieder einmal einer dieser Spezialfälle, an die anscheinend kein Mensch gedacht hat (weswegen ich dazu auch nichts finden konnte, denn bei tausenden anderer Anwender, die nicht replizieren taucht das natürlich gar nicht auf). Alles wird gut ;-)
virtualmono - 7. Apr, 23:27
716 mal gelesen
Trackback URL:
https://virtualmono.twoday.net/stories/6279491/modTrackback