[SQL] Database omzetten van MSSQL naar Oracle

[didio]

Zoals de subject al zegt, ik moet een MSSQL 2000 database compleet met stored procedures en views omzetten naar een Oracle 8i database server.

Heeft iemand hier ervanring mee, kunnen hier nog grote problemen in voorkomen?

[Greyfox]

De data zal wel lukken, maar je moet in ieder geval door alle code in de stored procedures heen omdat Oracle dingen niet kan die SQL-Server wel kan. (en omgekeerd natuurlijk)

[didio]

Het gaat juist niet om de data, maar om het database ontwerp.

Het is eerst op MSSQL gebouwd en moet nu gaan draaien op Oracle, ik dacht ook al dat dat niet zomaar omgezet kan worden.

[whoami]

Het database ontwerp zal volgens mij niet echt het probleem gaan vormen. Het omzetten van de Stored Procedures zullen imho het grootste werk zijn en ook voor de meeste problemen geven.

[ACM]

Je kan de MSSQL database (via de Enterprise manager) gewoon naar Oracle exporteren.

Kijk wel uit dat de tabelnamen etc allemaal hoofdletter gevoelig overkomen (bij mij iig).
Dus je kan wellicht beter de MSSQL database naar een .sql file exporteren en handmatig nog doorlopen.

Ik weet niet hoe groot je database is en/of het een probleem is dat de MSSQL database niet 100% op de Oracle database afgebeeld wordt door allerlei van die kleine dingen.

Mij is het iig wel gelukt, maar die database had mar een stuk of 15 tabellen

[Goodielover]

Daarnaast heb een SQL-dialect verschil. Afhankelijk van de complexiteit van de views kan dit ook nog lastig worden.

[didio]

De database is niet ontzettend groot, ik denk zo'n 15 a 20 tables, maar wel zo'n 30 a 40 sp's en nog een stuk of 10 views.

Allemaal niet super ingewikkeld.

Die tables is geen probleem, of Oracle ook views aankan weet ik niet, en natuurlijk het verschil in T-SQL, geen idee hoe groot dat is.

[whoami]

Ik zou zeggen verdiep je eens in Oracle. Oracle kan zeker views aan, en er zijn zeker sites te vinden die aangeven wat Oracle kan en niet kan.

[Goodielover]

Op vrijdag 14 juni 2002 11:17 schreef didio het volgende:
De database is niet ontzettend groot, ik denk zo'n 15 a 20 tables, maar wel zo'n 30 a 40 sp's en nog een stuk of 10 views.

Allemaal niet super ingewikkeld.

Die tables is geen probleem, of Oracle ook views aankan weet ik niet, en natuurlijk het verschil in T-SQL, geen idee hoe groot dat is.

En of Oracle views aan kan. Het gaat alleen om de mate waarin de SQL in de view gebruik maakt van specifieke MS-SQL dialect functies of het moeilijk of makkelijk wordt.
Als je de lastigste view-def en stored proc hier post kan ik wel een oordel geven over de complexiteit in Oracle

[didio]

Op vrijdag 14 juni 2002 11:20 schreef Goodielover het volgende:

[..]

En of Oracle views aan kan. Het gaat alleen om de mate waarin de SQL in de view gebruik maakt van specifieke MS-SQL dialect functies of het moeilijk of makkelijk wordt.
Als je de lastigste view-def en stored proc hier post kan ik wel een oordel geven over de complexiteit in Oracle

Ik heb de database (nog) niet hier, ik ga wel even op onderzoek uit.

[mbravenboer]

Toevallig heb ik gisteren een babbeltje gehouden waarin views naar voren kwamen en ik kan je vertellen dat Oracle juist subliem met views kan omgaan.

Oracle support namelijk ook materialized views, die een query over een view enorm kan versnelen. In de meeste database systemen wordt bij een query over (o.a) een view namelijk gewoon de view-definitie ingevoegd. Als een database views echter ook gematerializeerd kan bijhouden, kan eventueel in de qeury gekozen worden voor het inlezen van deze view ipv het invoegen van de view-definitie.

Je kunt bij materialized views niet alleen kiezen voor handmatige bijwerking, maar Oracle kan ook zelf materialized views bijhouden. Subliem .

Overigens hebben andere database systemen ook zeker features in deze richting. Microsoft SQL Server (Enterprise edition) kan bijvoorbeeld ook materialized views aan, maar ik weet niet of deze ook automatisch bijgehouden kunnen worden, of alleen on demand.

Microsoft SQL Server gebruikt bijvoorbeeld zelfs de materialized views in queries die niet expliciet de view gebruiken. Dat is best wel erg leuk .

Linkjes:

Oracle:
http://www.oracle.com/oramag/oracle/99-Sep/index.html?59bob.html
http://www.dba-oracle.com/art_9i_mv.htm

SQL Server:
http://tutorials.beginners.co.uk/read/id/159

Als je meer over de technische achtergrond wilt weten:
http://citeseer.nj.nec.com/chaudhuri95optimizing.html
(geschreven door iemand van Microsoft Research ).

[Goodielover]

Op vrijdag 14 juni 2002 11:36 schreef mbravenboer het volgende:
Toevallig heb ik gisteren een babbeltje gehouden waarin views naar voren kwamen en ik kan je vertellen dat Oracle juist subliem met views kan omgaan.

Oracle support namelijk ook materialized views, die een query over een view enorm kan versnelen. [..]

Het is de ideale uitvoering van gecontroleerde redundantie. Ik had er al van gehoord, maar niet mee gewerkt.

Kan jij ook aangeven wat de de belangrijkste beperkingen aan zulke views? Ik kan me voorstellen dat een view met een join over meerdere tabellen lastig wordt om automatisch bijgewerkt te houden. Dan moet Oracle bijna bij elke update in één van de tabellen die hele view opnieuw opbouwen.

[JaQ]

om een of andere reden gaat je I/O wel door het plafond als je zo'n materialized view gebruikt. Dat is (zoals je wel snapt) niet prettig.

Zelf maar ik eigenlijk nooit views aan. Ik maak zoveel mogelijk gebruik van zogenaamde inlined-views. Het is mij gebleken dat (zeker op grote databases) dit vele malen sneller is dan een view. Er wordt dan namelijk veel beter gebruik gemaakt van indexen.

Echt een verklaring waarom een inlined view hier beter gebruik van maakt dan een normale view heb ik (nog) niet, ik weet alleen dat het verschil opmerkelijk is.

[raptorix]

Zijn materialised views het zelfde als geindexeerde views?

Edit: kennelijk wel dus, documentatie zegt:

Indexed Views
The SQL Server 2000 relational database engine supports creating indexes on views. The result set of the index is materialized at the time the index is created, and is maintained as the underlying base data is modified. Creating an index on a view that performs complex calculations on large amounts of data can speed subsequent queries by orders of magnitude. The performance benefits are not limited to queries that specify the indexed view in their FROM clause, the performance benefits apply to any query that references data covered by the indexed view. This means existing queries can realize performance gains from using the view without having to be recoded to explicitly reference the indexed view. Indexed views substantially improve the performance of large, complex reporting applications that access SQL Server databases.



Overigens om op topicstarter terug te komen zou je ook eventueel een programma als powerdesigner kunnen gebruiken om de boel te reverse engineren.

[Goodielover]

Op vrijdag 14 juni 2002 12:32 schreef DrFrankenstoner het volgende:
om een of andere reden gaat je I/O wel door het plafond als je zo'n materialized view gebruikt. Dat is (zoals je wel snapt) niet prettig.

Zelf maar ik eigenlijk nooit views aan. Ik maak zoveel mogelijk gebruik van zogenaamde inlined-views. Het is mij gebleken dat (zeker op grote databases) dit vele malen sneller is dan een view. Er wordt dan namelijk veel beter gebruik gemaakt van indexen.

Echt een verklaring waarom een inlined view hier beter gebruik van maakt dan een normale view heb ik (nog) niet, ik weet alleen dat het verschil opmerkelijk is.

Voor horizontale afscherming van data maak ik altijd gebruik van views. Hierdoor kan je programmatuur gelijk blijven en heb je niet overal in je queries de autorisatie geprogd. Bovendien moet je dan de gebruiker toch toegang geven tot al je data. Gaan ze buiten de app om naar de database, ben je het lulletje.

[Verwijderd]

Op vrijdag 14 juni 2002 11:36 schreef mbravenboer het volgende:
Toevallig heb ik gisteren een babbeltje gehouden waarin views naar voren kwamen en ik kan je vertellen dat Oracle juist subliem met views kan omgaan.

Tuurlijk. TPC's benchmarks worden bereikt met views, dus als je slecht scoort op views, haal je daar nooit een hoge score

Oracle support namelijk ook materialized views, die een query over een view enorm kan versnelen. In de meeste database systemen wordt bij een query over (o.a) een view namelijk gewoon de view-definitie ingevoegd. Als een database views echter ook gematerializeerd kan bijhouden, kan eventueel in de qeury gekozen worden voor het inlezen van deze view ipv het invoegen van de view-definitie.

Dit doet SQLServer in de optimizer. Bij een view is het altijd zo dat je als RDBMS moet kiezen tussen cached opslag van de viewquery results en at runtime die results bij elkaar zoeken. SQLServer is speciaal geoptimaliseerd voor views (en met name gepartitioneerde views), omdat je met views pas echt snelheidswinsten kunt halen.

Je kunt bij materialized views niet alleen kiezen voor handmatige bijwerking, maar Oracle kan ook zelf materialized views bijhouden. Subliem .

Mja, ik zie het nut van handmatige bijwerking van materialized metadata niet echt. Immers: de optimizer weet pas at runtime wat sneller is, door het raadplegen van cache, statistics en aangeboden data.

Overigens hebben andere database systemen ook zeker features in deze richting. Microsoft SQL Server (Enterprise edition) kan bijvoorbeeld ook materialized views aan, maar ik weet niet of deze ook automatisch bijgehouden kunnen worden, of alleen on demand.

SQLServer heeft een van de beste optimizers die er zijn, (veel beter dan Oracle's) en dit gebeurt volautomatisch: als developer definieer je de views en SQLServer regelt de rest.

Microsoft SQL Server gebruikt bijvoorbeeld zelfs de materialized views in queries die niet expliciet de view gebruiken. Dat is best wel erg leuk .

Bekijk maar eens wat grote execution plans van grote queries op views . Voer die een paar keer uit en je ziet hoe die kick ass optimizer zn werk doet. Daar heb je wat aan, als developer: doen wat je moet doen en de database regelt de rest. Natuurlijk moet je wel zorgen dat je de optimizer voert met een model waar hij iets mee kan.

[didio]

Ik vond dit:

http://otn.oracle.com/tech/migration/workbench/content.html

iemand hier wel eens mee gewerkt, en werkt dit een beetje?

[mbravenboer]

Goodielover: Kan jij ook aangeven wat de de belangrijkste beperkingen aan zulke views? Ik kan me voorstellen dat een view met een join over meerdere tabellen lastig wordt om automatisch bijgewerkt te houden. Dan moet Oracle bijna bij elke update in één van de tabellen die hele view opnieuw opbouwen.

Inderdaad, daar moet haast wel een beperking zitten. Helaas weet ik niet welke beperking Oracle door op legt, alhoewel je natuurlijk wel wat logisch kunt verzinnen. De meeste eenvoudige beperking zou zijn om te eisen dat een relatie wel beperkt mag worden qua selectie, maar niet qua projectie. Ik heb er echter alleen vanuit de kant van de implementatie van een query compiler naar gekeken, dus ik heb veder geen idee welke beperkingen de verschillende systemen opleggen.

[mbravenboer]

Mja, ik zie het nut van handmatige bijwerking van materialized metadata niet echt. Immers: de optimizer weet pas at runtime wat sneller is, door het raadplegen van cache, statistics en aangeboden data.

Mwah, het bijhouden van materialized views is een dure, lastige en beperkende aangelegenheid. Oracle biedt de mogelijkheid om een materialized view niet bij te houden en ik kan me best situaties voorstellen (bijvoorbeeld in data warehouses, OLAP) waar dat prima voldoet. Uiteraard is het on-demand updaten van materialzied views in een 'levende' database (OLTP) een stuk minder zinvol, maar ook hier kan je nog wel toepassingen bedenken.

SQLServer heeft een van de beste optimizers die er zijn, (veel beter dan Oracle's) en dit gebeurt volautomatisch: als developer definieer je de views en SQLServer regelt de rest.

Het opvallende aan de query compiler van SQL Server is dat z'n aanpak op een bepaald punt nogal afwijkt en in theorie zorgt deze aanpak niet voor een optimale oplossing: de query compiler werkt volgens mij top-down ipv van via een dynamisch programmeren oplossing (die dan bottom-up is). Deze dynamisch programmeren oplossing werd al in System R gebruikt en is nu nog steeds beschikbaar in vrijwel alle systemen... De SQL Server schaart zich met z'n topdown aanpak in een rijtje onbekende experimentele query compilers die over het algemeen niemand kent...

Microsoft SQL Server doet het voor materialized views inderdaad heel netjes en het is vooral wel grappig hoe het algoritme wat beschreven wordt in het artikel van Microsoft Research een aantal jaar later precies zo terugkomt in de SQL Server. Ook daar wordt er namelijk op gehamerd dat de materialized views ook gebruikt moeten worden als ze niet expliciet door de SQL auteur gebruikt zijn.