[Oracle] Migratie oracle 7 naar 9 *

[Verwijderd]

Hallo,

Het bedrijf waar ik werk wil graag onze database (oracle 7) migrerenm naar oracle 9.
Nu heb ik ( en mijn collega's) uren lopen zwoegen om alle triggers, functies, procedures etc.. te optimaliseren onder oracle 7.

Ik vroeg me af of we bij de migratie gewoon de complete database kunnen overzetten?
Kunnen we nog problemen verwachten met onze querys/plsql-code/triggers/etc...?

Wat de inrichting van de database betrefd, daar heb ik helemaal geen kaas van gegeten. Dat mag ook onze dba uitzoeken..:) (al zijn tips natuurlijk altijd welkom)
Het gaat mij vooral om, of dat wat er op een oracle 7 omgeving is geprogrameerd, ook zonder problemen werkt op een oracle 9 omgeving?

alvast bedankt.

[justmental]

Als je netjes geprogrammeerd hebt blijft alles gewoon werken en kun je zelfs met een performanceverbetering weglopen.
Problemen kun je verwachten als je trucjes uit hebt zitten halen zoals bijvoorbeeld met rowid's.
Daarnaast is de PL/SQL engine een stuk strikter geworden qua syntax, elke bewerking met een NULL levert nu ook een NULL als resultaat, wat in 7 nog wel eens anders was, vooral met booleans.

Een migratie als deze zul je altijd als eerste in een testopstelling moeten doen.

[Verwijderd]

Bedankt voor je snelle reply..

Een testopstelling wordt momenteel aan gewerkt.
Maar we weten nog niet zo goed wat we moeten testen, en wat we kunnen tegenkomen.... vandaar

Wat betrefd de null-values...
Kan ik problemen verwachten als ik een 'select into v_variable' uitvoer en vervolgens check of de v_variable null is?
Zo'n constructie heb ik nl vrij regelmatig gebruikt.

Een collega van me gebruikt regelmatig row-id's in z'n querys.
(volgens mij is dat een bij-effect van het niet kunnen structureren van zijn creativiteit nfi)
Wat kan hij verwachten wat betrefd de row-id's?

Op wat voor een manier gaat oracle 9 daar anders mee om dan oracle 7?

groetjes

[ Voor 16% gewijzigd door Verwijderd op 10-07-2003 18:10 ]

[justmental]

Die nuul waarden ga je vooral merken met functies een sum van geen waarden wordt bijvoorbeeld null.

offtopic:
Select into's zijn sowieso vies, om er redelijk netjes mee te werken heb je minimaal een programmblok extra nodig.

Het rowid is veranderd qua inhoud, dus heb je ergens rowid's opgeslagen dan gaan die niet meer werken. Een rowid zag er eerst uit als zoiets: '0001.000054777.5656'. Nu is het zoiets: 'aaAAbbZFQQfhjkkggj'. Verder is de functionaliteit van rowid's gelijk gebleven.
Een rowid in een query gebruiken is imnsho altijd overbodig, waarschijnlijk heeft je collega nog nooit een constructie als 'where (kolom1, kolom2, kolom3) in (select...' gezien.

Overigens gaf ik een paar voorbeelden van veranderingen, maar er zijn er natuurlijk veel meer.

[Verwijderd]

bedankt

ik zal morgen ff onze source doorzoeken op row-ids, en alle functies (pfff..zijn er nogal wat) bekijken of de waarden wel netjes afgevangen worden mochten ze null zijn.

[leuk_he]

Verwijderd schreef op 10 July 2003 @ 17:44:
Hallo,

Het bedrijf waar ik werk wil graag onze database (oracle 7) migrerenm naar oracle 9.
Nu heb ik ( en mijn collega's) uren lopen zwoegen om alle triggers, functies, procedures etc.. te optimaliseren onder oracle 7.

heel kort antwoord met een hele lange link:

http://metalink.oracle.co...base_id=NOT&p_id=132255.1

maar metalink heeft een enorme rijkdom wat dat betreft.

[curry684]

offtopic:
Titel opgeleukt, zet de volgende keer zelf even het 'hoofdonderwerp' tussen [rechte haken] ervoor

[Verwijderd]

@leuk_he: Na wat navragen hier bleek dat we idd een login hebben voor metalink.
Is inderdaad een schat aan informatie. Hier ben ik nog wel even zoet. thx
(..als ze nu meteen verteld hadden dat ik daar kon zoeken....)

@alle anderen: bedankt voor het meedenken. Ik ga hier ff hard aan de gang.

[JaQ]

Hopen (nog) geen mosterd na de maaltijd, maar zoals justmental al aangaf kan je nogal wat problemen gaan krijgen met je plsql code. De engine is niet alleen strikter geworden, ook zijn een aantal datatypes niet meer toegestaan als datatype voor een variabele (b.v. char, moet altijd varchar zijn) Ga er maar vanuit dat je elk stukje code mag gaan doorlopen en controleren.

Overigens ga je een select into voorbeeld en dan test je of de variabele leeg is... dat weet je dan toch al? (exception? not_found? of ligt dat nou weer aan mij?)

Verder krijg je een aantal nieuwe opties die oude code kan gaan vergemakkelijken (o.a. krijg je nu de mogelijkheid om native sql te gebruiken, geen dbms_sql package meer, maar dmbs_native. hoop leuke nieuwe opties waar je blij van kan worden)

Maareh.. niet lullig bedoeld, maar wordt 7.3 sinds 2001 al niet meer gesupport? Wordt wel tijd voor een upgrade als je systeem een beetje kritisch is. (En ik hoop niet dat het om een oude oracle apps gaat, want dan krijg je nog veel meer voor je neus.. o.a. dat de hele datastructuur is veranderd)

[Verwijderd]

DrFrankenstoner schreef op 11 July 2003 @ 11:45:
ook zijn een aantal datatypes niet meer toegestaan als datatype voor een variabele (b.v. char, moet altijd varchar zijn)

Eej, VARCHAR2 toch wel he? Stoutert....
Voor het gebruik van CHAR moeten ze helemaal de straf van 10 zweepslagen zetten (per occurrence).

Testen lijkt me niet zo lastig, je gebruikt gewoon de migration wizard van Oracle (kan je ook eea terugvinden op Oracle Technology Network) en daarna je applicatie over die nieuwe db draaien. Dan zie je de meest grove fouten direct boven komen drijven, geloof me

[JaQ]

Verwijderd schreef op 11 July 2003 @ 11:51:
[...]
Eej, VARCHAR2 toch wel he? Stoutert....
Voor het gebruik van CHAR moeten ze helemaal de straf van 10 zweepslagen zetten (per occurrence).

Testen lijkt me niet zo lastig, je gebruikt gewoon de migration wizard van Oracle (kan je ook eea terugvinden op Oracle Technology Network) en daarna je applicatie over die nieuwe db draaien. Dan zie je de meest grove fouten direct boven komen drijven, geloof me

Ik zeg toch niet dat ik t gebruik? Ik meld alleen dat t niet meer mag in 9i. Ik kan me overigens best situaties voorstellen waarmee je waarden in een char wilt drukken (een variabele die atlijd gevuld is en altijd dezelfde lengte heeft... dan heeft varchar namelijk geen voordelen meer, maar goed, dat terzijde).

Met de migratiewizard heb ik voor plsql niet zulke goede ervaringen. Voor het overzetten van je tabellen, constraints en data geen probleem, maar als je wat intelligente plsql hebt gebruikt in triggers en of packages dan raakt ie nog wel eens de weg kwijt. Sinds versie 9 is die draak wel iets beter geworden, maar nog niet perfect. (10 komt eind dit jaar uit volgens Oracle, wordt dus begin volgend jaar op z'n vroegst, ben benieuwd of ze dan eindelijk een echt goed migratietool hebben)

[Mc.Boldy]

OK, je hebt ondertussen al aardig wat nuttige reakties gehad dus laat ik er ook eens eentje proberen.

Focus je tijdens een upgrade niet alleen op de database. Ik weet niet welke en hoe je applicaties deze benaderen, maar ook dit onderdeel lijkt me redelijk belangrijk. Op mijn huidige traject bleken er achteraf nogal wat interfaces om te kukelen. Niet omdat ze niet meer zouden werken, maar gewoon doordat ze niet certified waren onder 9i. Denk hierbij bijvoorbeeld aan C-compilers.

Voor de rest is onze upgrade gewoon dmv een import-export gegaan. Voordeel hiervan is dat je de nieuwe database zelf kunt (moet ) opbouwen en daardoor geen oude wijn in een nieuwe zak krijgt .

Testen is en blijft noodzakelijk!!!

[Verwijderd]

DrFrankenstoner schreef op 11 juli 2003 @ 11:56:
Ik zeg toch niet dat ik t gebruik? Ik meld alleen dat t niet meer mag in 9i. Ik kan me overigens best situaties voorstellen waarmee je waarden in een char wilt drukken (een variabele die atlijd gevuld is en altijd dezelfde lengte heeft... dan heeft varchar namelijk geen voordelen meer, maar goed, dat terzijde).

Geintje joh. En je noemde VARCHAR, dat is weer een ander type dan VARCHAR2 maar wordt ook niet meer gebruikt.

Met de migratiewizard heb ik voor plsql niet zulke goede ervaringen. Voor het overzetten van je tabellen, constraints en data geen probleem, maar als je wat intelligente plsql hebt gebruikt in triggers en of packages dan raakt ie nog wel eens de weg kwijt. Sinds versie 9 is die draak wel iets beter geworden, maar nog niet perfect. (10 komt eind dit jaar uit volgens Oracle, wordt dus begin volgend jaar op z'n vroegst, ben benieuwd of ze dan eindelijk een echt goed migratietool hebben)

Daar ben ik ook wel benieuwd naar. Oracle versies gaan harder dan konijnen de laatste tijd trouwens


Hey McBoldy, nog steeds AAOPS verschlaafd?

[Verwijderd]

Het front-end programmeren we in magic( www.magic-sw.com). Die heeft een gecertificeerde link naar de oracle 9i database. Met oracle-apps hebben we niets te maken.
Een deel van de business-rules zijn geprogrammeerd op de database, een beperkt aantal in magic. Dit omdat we eventueel in de toekomst vanuit een ander front-end de database willen kunnen benaderen. (denk aan gebruikers die in access zelf een querietje in elkaar flansen)

Omdat oracle 7 idd niet meer gesupport wordt, en het om een bedrijfskritische database gaat, staat het management op z'n achterste benen en moeten we als de wiede-weerga over naar oracle 9.

exception? not_found? is idd de manier om op null-values te valideren. Helaas wist ik echter pas na een cursus plsql van deze functie af, en had ik al het eea geprogrammeerd. Management maakt soms wel goede beslissingen...eerst iemand iets laten maken, en dan op cursus sturen om het te leren....beetje hoog dilbert-gehalte.

Ik heb ook alle code nagekeken, (export gemaakt en een zoekprogje geschreven... lang leve de automatisering!!) en gelukkig blijken we nergens CHAR te gebruiken in variabelen.

Ik heb ook nog niet alle plssq-functies doorlopen, maar wat ik tot nu toe zie is dat null-values netjes worden afgevangen.

De migratie zelf wordt door een extern buro gedaan. Maar die kunnen niet verantwoordelijk zijn voor de code die we geprogrammeerd hebben, alleen voor het overzetten ervan.
Zelf moeten we zorg dragen dat onze code blijft werken.

Al met al lijkt het erop dat het allemaal wel z'n beloop zal hebben.
In de testomgeving zullen de grootste fouten wel aan het licht komen. En omdat het een bedrijfskritische applicatie betrefd zal er wel goed getest moeten worden........als we tijd krijgen om een testplan te maken tenminste.......(prince2 anyone?)

Ik wist niet dat er nog zoveel oracle-kennis onder de tweakers zat. Ik ben erg blij verrast.

groetjes