[Oracle] SQL-skripte bleiben hängen, versionsabhängig?

[m3000]

Hallo,

Kann es sein, dass lauffähige SQL-Skripte unter einer neueren Oracle/SQL+-Version nicht laufen? Gibt es Syntax-Änderungen oder so was? Wenn ja, wie erfahre ich, was ich ändern muss?

Hintergrund: Wir werden unsere Anwendung auf eine neue Version updaten. Sie ist bereits für Tests mit migrierten Daten installiert unter Oracle 9.2.0 mit SQL*Plus-Release 9.2.0.6.0. Die bisherige Anwendung läuft unter Oracle 8.1.7 mit SQL*Plus Release 8.1.7.0.0. Betriebssystem ist jeweils SUN_OS_2.

Vielen Dank und Gruss
Marcus

 

[DerKleineBruder]

Hi Marcus,

sollte eigentlich tun. Umgekehrt wäre es eher ein Problem, dass syntaktisch etwas in der 8'er noch nicht geht (natural inner/outer join), aber ansich sollte es da keinerlei Probleme geben.

Es kommt nun natürlich auf die Daten an.
Kann es sein, dass die Tabellen in 9 mit Constraints versehen sind, die ihr in der 8'er nicht angelegt habt, sodass es jetzt zu einem Lock kommt?

Hast du dir dazu die Locks mal angesehen, die die Session erzeugt?

Gruß
das Brüderchen

 

[Exceptionfault]

Da stime ich Brüderchen zu, die SQL*Plus Syntax hat sich eigentlich nur verbessert und
der Client ist wesentlich tolleranter geworden.

Generll für die Migration noch ein paar Punkte:

Gerade beim Umstieg von 8 auf 9 würde ich meine Applikation und das Index Design sehr
genau prüfen. Es ist häufig der Fall, dass nach der Migration von 8 auf 9 die Performance
entgegen den Erwartungen extrem schlecht ist.

Das ist immer dann der Fall, wenn die Applikation auf den RULE BASED Optimizer der 8er
DB optimiert war und nun unter 9 auf dem COST BASED Optimizer läuft. Dann muss man in
jedem Statement evtl. Hints rausnehmen, Statistiken sammeln und die Indizes nochmal
kontrollieren.

Auch die INIT.ORA Parameter muss man betrachten. Es gibt z.B. den
O7_DICTIONARY_ACCESSIBILITY. Der schränkt ab 9 den Zugriff auf das DD für normale
User sehr ein. Damit hat Oracle eine Sicherheitslücke geschlossen, die jedoch häufig für
Administrative Zwecke von Applikationen genutzt wurde.

Und zum Abschluss die Umstellung von RBS zu UNDO TBS und Dictionary Managed TS zu
Locally managed TS. Diese Features sollten eigentlich transparent für die Applikation
sein, dennoch würde ich gut testen wie sich z.B. extrem große Transaktionen (Batch Jobs) verhalten.

 

[m3000]

Hallo Bruder,

"constraints" und "Lock" sagen mir leider nichts

Aber ich war wohl zu voreilig. Ich habe jetzt aus dem Gesamtskript gezielt nur das eine "create table" gestartet, bei dem es zu hängen schien. Es lief durch. Aber es dauerte lt. timing gut 32 Minuten gegenüber 00.42 Sekunden in der alten Umgebung. Der Server ist zwar auch weniger leistungsfähig (Details kenne ich nicht), aber so ein Riesen-Unterschied ... ?
Jedenfalls bleibt es nicht komplett hängen, das ist doch schon mal was.

edit-Ergänzung:
@Exceptionfault: (Hatte meine Antwort verfasst, bevor ich Deine Antwort sah.) Deine Angaben "Performance entgegen den Erwartungen extrem schlecht" decken sich ja mit meinen Zahlen. Tatsächlich habe ich die allermeisten Skripte von meiner Stellenvorgängerin übernommen. "create index" wird nirgends verwendet. Das einzubauen hatte ich mir eh mal vorgenommen, jetzt scheint es an der Zeit dafür zu sein.

Danke, Gruss
Marcus