Oracle database gepruts

Door sys64738 op maandag 16 januari 2012 17:04 - Reacties (11)
Categorie: Programmeren en architectuur, Views: 4.720

Voor een project waar ik nu mee bezig ben, moet ik een Oracle database overzetten van een server naar mijn ontwikkelbak en daarna alles verhuizen naar een MySQL database. Normaal probeer is zo ver mogelijk weg te blijven van Oracle databases maar dit keer gaat het om een bestaand systeem en had ik dus niet zo veel keuze.

De database is niet zo groot en ook niet erg ingewikkeld qua model. "How hard can it be?" dacht ik nog heel even. Het antwoord is natuurlijk: very hard!

De export die ik aangeleverd kreeg was gemaakt met expdp (aka Data Pump) en bevat zowel de structuur als ook de data. Kwestie van even uitvogelen hoe impdp werkt (en dat is niet zo triviaal als je zou verwachten) en klaar is Kees. Niet dus. De character encoding van de bron en doel databases wijken blijkbaar af en daarom past VARCHAR data soms niet meer in de kolommen. Voor zover ik heb kunnen achterhalen, kun je zonder logfiles de encoding van de export niet meer achterhalen en omdat alles binair is kun je ook de data niet bekijken. Je zult het dus moeten doen met de errorcode en de foutmelding dat het niet past.

Dan maar door met een paar missende velden, niet het einde van de wereld. Maar dan kan ie natuurlijk ook zijn constraints niet aanmaken want er ontbreekt data die nodig is voor sommige relaties.

OK, dan maar door met wat missende velden en ontbrekende constraints. Om over te gaan naar MySQL heb ik vervolgens een export gemaakt van de tabellen in sql formaat. Dat er dan conflicten ontstaan met zaken zoals NUMBER, VARCHAR2 en to_date die door MySQL niet ondersteund worden, kan ik nog inkomen. Maar na al deze zaken te hebben opgelost, startte ik de import weer en kreeg ik de volgende melding voor mijn kiezen:

SQL Error (1136): Column count doesn't match value count at row 1

Enig speurwerk leidde tot de oorzaak van deze fout. SQL Developer gebruikt bij het maken van een export een komma als decimal seperator welke natuurlijk ook gebruikt wordt als field delimiter. Dus elk record dat een getal met cijfers achter de komma bevat, heeft bij het importeren één value te veel. Hier door kan zelfs Oracle zijn eigen export bestanden niet meer inlezen.

Nou zijn relationele databases natuurlijk al tamelijk onnatuurlijk in een object georiënteerde wereld maar Oracle doet er nog een schepje bovenop en maakt het nog onintuïtiever en minder werkbaar. Ik hoop dat ik de migratie er snel doorheen heb en dan gooi ik alles met Oracle in de naam van mijn laptop af (oh, minus Java natuurlijk).

Volgende: We bellen.... maar dan wel handsfree 01-'12 We bellen.... maar dan wel handsfree
Volgende: En toen was er muziek 01-'12 En toen was er muziek

Reacties


Door Tweakers user Beatboxx, maandag 16 januari 2012 18:24

Kan je niet zelf iets maken in PHP oid dat alles uit die oracle database pakt, en opslaat in de MySQL database?

Door Tweakers user sys64738, maandag 16 januari 2012 19:12

Wel grappig dat iedereen hier altijd terugvalt op PHP. Hoewel het vanaf versie 6 ook ondersteuning biedt voor unicode, zijn er voor dit soort dingen toch wel betere tools.

Ik zou eerder denken aan perl, python, ruby of java. Maar het is toch van de zotte dat ik een script / programma moet schrijven om een knappen export te maken.

Door Tweakers user Gomez12, maandag 16 januari 2012 20:08

sys64738 schreef op maandag 16 januari 2012 @ 19:12:
Ik zou eerder denken aan perl, python, ruby of java. Maar het is toch van de zotte dat ik een script / programma moet schrijven om een knappen export te maken.
Hoe kom je erbij dat je een script / programma moet schrijven om een knappe export te maken? Je moet gewoon de dbase management tools pakken...


Door Tweakers user Punkie, maandag 16 januari 2012 21:22

Dat je komma niet correct gebruikt wordt heeft waarschijnlijk te maken met je instellingen. Wedden dat je locatie en nummer formaat ingesteld staat op NL op je machine? Zorg dat je overeenkomstige formaten hebt, vooral voor de decimal seperator. http://detect-it.blogspot...-in-sqldeveloper-151.html

Dat je encodering van je de dump niet gekend is, klinkt me nogal .... amateuristisch in de oren. Maak een nieuwe export van de DB of kijk in de DB na welk formaat er gebruikt wordt.

Door Tweakers user VolvoGek, maandag 16 januari 2012 22:33

Tja.... het is natuurlijk een Oracle probleem.
Lekker makkelijk, misschien moet je eens een goed boek lezen.


Zoals Punkie hierboven al aangeeft. Een punt of een comma als seperator is een locale setting. Dat is namelijk wel zo makkelijk met een centrale database en gebruikers over de hele wereld. LOKAAL aanpassen.
De rest van het verhaal is natuurlijk ook lekker kort door de bocht. Kun je over elk product wat je niet snapt een blogje vol schrijven.

Dat de characterset anders is krijg je gewoon netjes gemeld.
en uit de 10.2 documentatie:
"Data Pump supports character set conversion for both direct path and external tables. Most of the restrictions that exist for character set conversions in the original Import utility do not apply to Data Pump. The one case in which character set conversions are not supported under the Data Pump is when using transportable tablespaces. [This info was added per mail from Simon Law/Bill Fisher on 2/23/05]"

ja goed gelezen 2005 !!!
Als je op support.oracle.com (Is wel handig als je daar kan inloggen als je met Oracle aan de slag gaat, en niet weet hoe het werkt) even note 788156.1 gaat lezen is alles helder.

Als je daar niet bij kan, moet je me maar even DM-en. Zal ik het je mailen.

Maar stop met je frustraties te botvieren op een product wat je niet snapt.

MySql is leuk en handig en ook goedkoop, maar kan op geen enkele wijze aan Oracle tippen.

Door Tweakers user sys64738, maandag 16 januari 2012 23:34

@VolvoGek: Als Oracle zo'n super product is, waarom laat ie mij dan exports (in sql insert formaat) maken die hij zelf niet eens meer kan lezen? Ik weet hoe LOCALS werken maar het kan toch niet zo zijn dat een export van een decimal afhangt van hoe ik heb aangegeven dat ik ze wil zien?

En dat datapump character conversion ondersteund hoor je mij ook niet ontkennen (je krijgt netjes een melding dat er conversie plaats vindt). Maar wat ik dus schreef is dat je de oorspronkelijke encoding niet kunt achterhalen puur op basis van je binaire dump file.

Ja, ik beken dat mijn Oracle kennis niet enorm groot is maar het is blijkbaar te moeilijk voor iemand met behoorlijk wat it ervaring om een export dump te importeren en dat lijkt me niet nodig.

Ook hoor je mij niet zeggen dat MySQL beter is dan Oracle. Ik weet ook wel dat Oracle enorm veel features biedt waar MySQL niet aan kan tippen. Ze bedienen dan ook allebei een andere doelgroep (of dat zouden ze moeten doen.... helaas wordt Oracle te vaak zonder na te denken ingezet. En dat zal voor MySQL ook wel gebeuren zo nu en dan). Maar sommige dingen gaan wel erg omslachtig in Oracle en dat was mijn punt hier.

@Beatboxx: Ja had al heel even op hun site rondgehangen en de trial geprobeerd. Denk dat deze route wel succesvol kan zijn en ga em waarschijnlijk morgen kopen.

@Gomez12: Ik geef alleen maar aan dat er betere alternatieven zijn dan php. En als je de blog gelezen hebt, heb je ook gezien dat ik juist met db management tooling in de slag ben geweest en dat niet echt opschoot.

[Reactie gewijzigd op maandag 16 januari 2012 23:38]


Door Tweakers user gtissink, dinsdag 17 januari 2012 00:16

@sys64378
Als MySQL zo'n goed product was..... ;)

Maar goed als je klein exports import wilt doen zonder veel rommel, dan neem je MS Access en maakt 2 ODBC koppelingen aan (let even op het hoofdletterconversie voor objectnamen). Downloaden in Access vanuit Oracle (Import) en uploaden naar
MySQL (Export) ..Tadaa.... klaar.

Verder gebruikt ik voor MySQL en Oracle T.O.A.D. voor, o.a., CSV export en import en dat scheelt een hoop problemen (zijn non-commerciele freeware versies van).

Oracle heeft inderdaad zijn eigenaardigheden, en ja het vergt wat kennis. Maar je laat de groenteman toch ook je auto niet repareren O-) . Zelf ben ik al meer dan 10 jaar Oracle Developer en "OCP Forms developer" en toch leer ik er nog steeds bij.

Overall kan ik zeggen dat ik MySQL prettig vind voor websites en Oracle voor grote applicaties. SQLserver mogen andere mensen over nadenken...

Door Tweakers user wallyberk, dinsdag 17 januari 2012 01:41

sys64738 schreef op maandag 16 januari 2012 @ 23:34:
En dat datapump character conversion ondersteund hoor je mij ook niet ontkennen (je krijgt netjes een melding dat er conversie plaats vindt). Maar wat ik dus schreef is dat je de oorspronkelijke encoding niet kunt achterhalen puur op basis van je binaire dump file.
Dit komt omdat oracle zijn export file optimaliseert voor snelheid. Wij (DBA's) houden niet van wachten :P.

Tevens kan je de encoding makkelijk achterhalen middels de parameter SQLFILE. Deze parameter zorgt ervoor dat je een ddl (create statements) script krijgt in de vorm van een bestand.

http://www.morganslibrary.org/reference/datapump.html

Door Tweakers user 0siris, donderdag 19 januari 2012 23:52

...en dan gooi ik alles met Oracle in de naam van mijn laptop af (oh, minus Java natuurlijk).
Pas je op met VirtualBox? ;)

Door Dennis Smit, woensdag 28 augustus 2013 15:04

Thanks voor de zeer nuttige informatie! Toch heb ik ook nog steeds mijn twijfels of Oracle wel zo'n super product is.

ps. Kijk ook eens op jouw <a hfref=”http://www.jouwictvacature.nl”>ictvacature</a> !

Reageren is niet meer mogelijk