| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Usenet -> c.d.o.server -> Re: Thinking of moving from MS-SQL 6.5 to oracle...Advice?
On Wed, 07 May 1997 21:53:44 GMT, iarld_at_connectnet.com (Lee Doty) wrote:
>Our company is attempting to install our warehouse automation project
>and we are encountering bug after bug (we have caused 4 MS official
>bug reports now) with SQL Server 6.5.
>
>We are now at the point where we are seriously thinking about cutting
>our losses and moving to Oracle 7.
>
>Any advice would be helpful, but I have some questions in particular:
>
>1) How difficult is the migration? We are using quite a few stored
>procedures and a few triggers, plenty of constraints etc. How
>different is the DB syntax, and Stored procedure syntax/capability?
I can't comment on this, as I have not personally done a "migration" from one product to another. But prior to coming to Oracle, I did deploy serveral solutions on SQL Server 4.21, 6.0, and Oracle7. A counterpart of mine worked with one of our partners to do exactly this (i.e., convert about 50K lines of Transact-SQL to PL/SQL). According to him, it was not fun.
What Oracle does offer are migration guides and tools. I was unable to locate a SQL Server 6.5 to Oracle7 Conversion Guide, but I was able to find the part number for the Microsoft SQL Server 6.0 to Oracle7 Database Conversion Guide. This part number is: C10687. I would contact your Oracle rep to track down the latest version of this.
>
>2) we are accessing the DB from C++ using ODBC, how much of our source
>is really going to have to change. (I know that the whole point of
>ODBC is that we shouldn't have to do rewriting, but life rarely goes
>like it's "supposed to")
My *opinion* is that you might be better off accessing the Oracle database through something other than ODBC. You could use Oracle Objects for OLE or you could use the native Oracle database driver. The long-term gain you will get from this short-term pain is an incredible boost in overall performance.
>
>3) What kind of performance increase/decrease can I expect? We have
>about 35 client workstations running win95 on 486s. The server is an
>IBM Quad PPro166 (128M (soon 256M) RAM, RAID-5, etc.). We do a
>grundle of transactions as near to "real time" as we can get.
>
You should check out the Compaq System Sizer, available at:
http://www.oracle.com/platforms/compaq/html/sizer.html
Although this was developed jointly by Compaq and Oracle, you should be able to use it to figure out what type of performance you could expect from your existing hardware. As well, this should be a little bit easier for you, as you already have defined your application, types of transactions, # of users, etc.
>4) Are we going from the frying pan to the fire? What problems with
>Oracle can we expect? The problems we are currently experiencing
>mostly arise from MS's goofy handling of SMP. (plus a whole lot more
>goofiness in the area of tempdb and allocation and handling of temp
>tables within stored procedures)
My very-biased opinion would be "no", you are not going from the
frying pan to the fire. Remember, Oracle7 runs exceptionally well on
low-end SMP systems all the up to a 128-processor Sequent NUMA-Q
and everything in between.
>
>5) has anyone else done a fairly large migration like this? If so,
>how did it go?
>
>All help is very much appreciated
>
>
>-Lee
>----
>"It can't rain all the time"
Thanks!
Joel
Joel R. Kallman Enabling the Information Age through Oracle Government Network Computing! Bethesda, MD http://govt.us.oracle.com jkallman@us.oracle.com http://www.oracle.com
 |
 |