re: Informix to Oracle migration

#1 (**permalink**) 04-19-2008, 09:34 PM

<html>
<head>

<title></title>
</head>
<BODY text="#000000" link="#0000FF">
With our toolset
(sorry okay so I'm blowing my own trumpet), the central issues tend to be:
1/ The presence/absence of stored procedures, since any form of automated
migration of these is quite tricky.
2/ Volume of data, although this is typically a secondary consideration. The
quantity of data simply indicates the amount of time it will take to load the
data. You can typically convert the informix export files into files suitable
for oracle's SQL loader to load. This can usually load data in an efficient
form (off the top of my head you should be able to load a 10GB database in a
few hours).
3/ Use of various Informix specific constructs.
A/ The major construct which tends to cause issues is the "MATCHES"
clause in WHERE conditions. This is because Oracle doesn't really have a
direct equivlent, so if the authors have done some cool and hoopy stuff with it
(for example SELECT * from tab1,tab2 where tab1.col matches tab2.col) you can
wind up with quite a headache.
Typically all MATCHES statements have to be converted to LIKE statements.
B/ ISOLATION level and locking
Oracle has a fundamentally different locking model to Informix. Practically
this means that statements like SET ISOLATION LEVEL are not required/not
supported. Programs which behave critically on locking behaviour may also not
work as expected.
C/ Other issues.
Most of what I have listed here are the issues you experience when porting with
Querix's Hydra compiler. At can't comment on other porting schemes (such as
those provided by 4js) other than to say that my undestanding is that there is
considerably more work required. Hydra uses on the fly SQL translation to
ensure that you don't have to rewrite all your dynamic SQL.
In particular if you were using another tool, you may need to worry about the
behaviour of SERIAL columns, the use of ROWID within the program (which exists
on oracle, but is a CHAR type) and the behaviour of temporary objects.

Hope this helps anyway,

----------------------- Original
Message ----------------------- 
 
 
>> A potential customer has asked me to provide an estimate of how long
it 
>> will 
>> take to migrate their 4GL suite running on Informix "to
Oracle". 
 
>> (I'm reminded here of Obnoxio's post of a while ago ridiculing
another 
>> rather vague question: "I have a piece of string in my pocket.
How long 
>> is 
>> it? It's red by the way ...&quot

>> Seriously, though, what sort of things should we be asking beyond
these?: 
 
>> 1. Complexity of schema (what sort of things, other than serial, are
going 
>> to be difficult to convert?) 
>> 2. Number of lines of 4GL 
>> 3. Number of stored procedures and triggers 
>> 4. Total number of tables 
>> 5 Volume of data 
>> 6. Availability of original programmers/BAs 
>> 7. Quality of documentation 
 
>> Assuming they don't want to re-write their app, they have to use
a 
>> third-party "universal" compiler like 4Js or Querix (or of
course 
>> Websphere 
>> EGL, if they've the time to kill). Any other options? 
 
>> All (constructive) comments gratefully received. 
 
>> thank you. 
>> Capt. P 
 
 
 
 
 
</body>
</html>
sending to informix-list

#2 (**permalink**) 04-19-2008, 09:35 PM

Rod Chamberlin wrote:

>
> <html>
> <head>
> 
> <title></title>
> </head>
> <BODY text="#000000" link="#0000FF">
> With our toolset
> (sorry okay so I'm blowing my own trumpet), the central issues tend to
> be: 1/ The presence/absence of stored procedures, since any form of
> automated migration of these is quite tricky.
> 2/ Volume of data, although this is typically a secondary consideration.
> The quantity of data simply indicates the amount of time it will take to
> load the
> data. You can typically convert the informix export files into files
> suitable
> for oracle's SQL loader to load. This can usually load data in an
> efficient form (off the top of my head you should be able to load a 10GB
> database in a few hours).
> 3/ Use of various Informix specific constructs.
> A/ The major construct which tends to cause issues is the
> "MATCHES"
> clause in WHERE conditions. This is because Oracle doesn't really have a
> direct equivlent, so if the authors have done some cool and hoopy stuff
> with it (for example SELECT * from tab1,tab2 where tab1.col matches
> tab2.col) you can wind up with quite a headache.
> Typically all MATCHES statements have to be converted to LIKE
> statements. B/ ISOLATION level and locking
> Oracle has a fundamentally different locking model to Informix.
> Practically this means that statements like SET ISOLATION LEVEL are not
> required/not
> supported. Programs which behave critically on locking behaviour may also
> not work as expected.
> C/ Other issues.
> Most of what I have listed here are the issues you experience when porting
> with
> Querix's Hydra compiler. At can't comment on other porting schemes (such
> as those provided by 4js) other than to say that my undestanding is that
> there is
> considerably more work required. Hydra uses on the fly SQL translation to
> ensure that you don't have to rewrite all your dynamic SQL.
> In particular if you were using another tool, you may need to worry about
> the behaviour of SERIAL columns, the use of ROWID within the program
> (which exists on oracle, but is a CHAR type) and the behaviour of
> temporary objects. 
> Hope this helps anyway,
> 
> style="font-family:'Arial';font-size:10pt;">-----------------------
> Original Message ----------------------- 
> 
> color="#0000FF"> 
> >> A potential customer has asked me to provide an estimate of how
> long it 
> >> will 
> >> take to migrate their 4GL suite running on Informix "to
> Oracle". 
> 
> >> (I'm reminded here of Obnoxio's post of a while ago ridiculing
> another 
> >> rather vague question: "I have a piece of string in my
> pocket.
> How long 
> >> is 
> >> it? It's red by the way ...&quot

> 
> >> Seriously, though, what sort of things should we be asking
> beyond
> these?: 
> 
> >> 1. Complexity of schema (what sort of things, other than
> serial, are
> going 
> >> to be difficult to convert?) 
> >> 2. Number of lines of 4GL 
> >> 3. Number of stored procedures and triggers 
> >> 4. Total number of tables 
> >> 5 Volume of data 
> >> 6. Availability of original programmers/BAs 
> >> 7. Quality of documentation 
> 
> >> Assuming they don't want to re-write their app, they have to
> use
> a 
> >> third-party "universal" compiler like 4Js or Querix
> (or of
> course 
> >> Websphere 
> >> EGL, if they've the time to kill). Any other options? 
> 
> >> All (constructive) comments gratefully received. 
> 
> >> thank you. 
> >> Capt. P 
> 
> 
> 
> 
> 
> </body>
> </html>
> sending to informix-list

<grumble, grumble, grumble> fscking HTML posting crap <grumble, grumble,
grumble)

--
"C'est pas parce qu'on n'a rien à dire qu'il faut fermer sa gueule"
- Coluche

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode