Sorry Sebastian,
I meant moving from Oracle to SQL server whilst being on XE. WE are
currently on XE/Oracle and might need to move to XE/SQL Server.
THanks,
Stuart
| | Sajaroff |
| | Sebastián |
| | <SSAJAROFF@grupoa|
| | ssa.com> |
| | |
| | 03/05/2003 11:08 |
| | AM |
| | |
>------------------------------------------------------------------------------------------------------------------------------|
| |
| To: "'
[email protected]'" <
[email protected]> |
| cc: "'
[email protected]'" <
[email protected]> |
| Subject: RE: Moving from Oracle to SQL Server 2000 |
>------------------------------------------------------------------------------------------------------------------------------|
Stuart :
Don't mention it!
Here is my data on the Xe move :
Xe Pro's :
* You have JDE ASUs (Updates) and ESUs to install fixes on BSFNs and NER
code.
On earlier releases (up to B7331), you had to modify OneWorld code by
reading a MSWord document
and applying its instructions on the toolkit. It was obviously hard to
maintain and very
time consuming too.
* Developer activities tend to be cleaner by using OMW. Older tools such as
OL, OT, PM usually
leaded your installation to an 'object hellish mess'.
* JDE Web Server runs pretty well on Xe and its latest service packs.
* Data consistency is better on Xe than on earlier releases.
Xe Con's
* You have JDE ASUs (Updates) and ESUs to install fixes on BSFNs and NER
code. >
When you install an ASU, you deploy a bunch of objects (up to 9000 on
Update6!) and you
don't know what is going on there... It's like diving into the Caribbean
without knowing
if you're gonna meet mermaids or hungry sharks!
However, I still prefer to install an Update instead of several dozens of
isolated ESUs.
* Client and server packages are much larger.
* Transaction consistency behaves better on Xe than on B7331, but is still
far from perfect.
BEGIN TRANS, ROLLBACK TRANS and COMMIT are still arcane words to Denver
software engineers.
Regards, Sebastian Sajaroff
-----Mensaje original-----
De:
[email protected] [mailto:
[email protected]]
Enviado el: Miércoles, 05 de Marzo de 2003 11:00 a.m.
Para: Sajaroff Sebastián
CC: '
[email protected]'
Asunto: RE: Moving from Oracle to SQL Server 2000
Sebastian,
Thanks for all the information - very kind. Can I be cheeky and ask
you for the same kind of information for your XE move as that is what we
are on now - I know the proceedure and how to do the move, I just need to
know the pro's / con's as you listed and any "suprises"
Thanks again,
Stuart
| | Sajaroff |
| | Sebastián |
| | <SSAJAROFF@grupoa|
| | ssa.com> |
| | |
| | 03/05/2003 10:39 |
| | AM |
| | |
---------------------------------------------------------------------------
---------------------------------------------------|
|
|
| To: "'
[email protected]'" <
[email protected]>
|
| cc: "'
[email protected]'" <
[email protected]>
|
| Subject: RE: Moving from Oracle to SQL Server 2000
|
---------------------------------------------------------------------------
---------------------------------------------------|
Stuart :
I moved from Oracle 8.0.4 (B7331 SP19.1) into SQL 2000 SP2 in a Bolivian
client.
I copied all System, Server Map, Object Librarian, Data Dictionary,
Business
Data - TEST,
Control Tables - Test, Central Objects - DEVB733 and Versions - DEVB733
from
Oracle 8.0.4
into SQL 2000 by using R98403. Later, we moved CRP733 (aka PY7333 in Xe)
and
PRD733 to SQL2000.
There have been performance differences, but they were mostly due to
hardware upgrade; Oracle
server was 2*Pentium II/450 Mhz + 2 Gb RAM while SQL2000 box is
8*Xeon/700Mhz + 8 Gb RAM.
SQL pro's are :
* Lower DBMS licensing and technical support costs.
* SQL DBAs are cheaper and easier to find than Oracle's (at least in South
America).
* This client is a Select Microsoft Customer and they want to use as many
MS
products
as possible. This is more a political than a technical fact.
* Veritas backup times were lower with MSSQL2000 agent than Oracle's. Don't
know if this is
due to the agent itself or their server replacement.
SQL con's are :
* MSSQL2000+OneWorld resulting locking strategy is horrible. There are many
locked tables
situations, even when users are running 'data-reader' reports such as
statistical listings.
If an user launches a F4101 'data-reader' report, it seems that nobody can
insert or modify
any data on it until this report finishes. On Oracle, 'data-reader' reports
gets data from
a consistent snapshot of F4101 while other users can simultaneously insert
and modify data
on the table itself. Oracle seems to be dealing with locks on a smarter way
than MS SQL.
* MSSQL control, diagnose and tuning tools are poorer than Oracle's.
Stability : this account has 150 users, and stability was acceptable on
both
Oracle and MSSQL.
I still insist that most stability problems are not due to DBMS but to
OneWorld itself.
Regards, Sebastian Sajaroff
-----Mensaje original-----
De:
[email protected] [mailto:
[email protected]]
Enviado el: Miércoles, 05 de Marzo de 2003 10:19 a.m.
Para: Sajaroff Sebastián
CC: '
[email protected]'
Asunto: RE: Moving from Oracle to SQL Server 2000
Thanks Sebastian -
I would like to know what you moved from in Oracle to what you moved to in
SQL server.
Where there any performance differences?
What were the pro's and cons of the move?
In your experience which Database is more stable?
THese are the kinds of questions I would lik to know the answers to.
Regards,
Stuart
| | Sajaroff |
| | Sebastian |
| | <SSAJAROFF@grupoa|
| | ssa.com> |
| | |
| | 03/05/2003 08:11 |
| | AM |
| | |
---------------------------------------------------------------------------
---------------------------------------------------|
|
|
| To: "'smorrison '" <
[email protected]>
|
| cc: "'
[email protected]'" <
[email protected]>
|
| Subject: RE: Moving from Oracle to SQL Server 2000
|
---------------------------------------------------------------------------
---------------------------------------------------|
Stuart :
I've done it three times (on B7321, B7331 and Xe).
Feel free to ask me,
Sebastian
OneWorld XE SP20_C1, Oracle 8.1.7.3.0 on WIN2K.
Citrix clients running WIN2K.
