Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
![]() |
![]() |
Home -> Community -> Usenet -> c.d.o.server -> Re: A move from UNIX to NT
Nigel Wingate wrote:
> I have been given a task to move an Oracle database from a DG-UNIX
> server to an NT server. The database is accessed by the users from NT
> Workstations via Procomm 3 (Telnet) and a series of menus.
> Install Oracle on NT
> Export the existing database to NT
> Re-compile all the COBOL programs for NT
> Convert the shell scripts to Korn Shell so they can run under MKS
> Toolkit on NT. Also adjust scripts for new paths, disks, directories,
> etc
> Test new system until it replicates old one
> Go live
>
> I'm sure there is more to it than this and if anyone can help, I'd
> love to hear from you. I can't be the first to do this and if there
> is any Web based documentation on how to do it, please point me in
> that direction.
Consider getting the Cygnus b19 GNU compiler and shell tools. I've long
been a fan of the MKS
stuff, but having a real compiler means you could probably run the (even
more unix-like than MKS)
tools. I't doesn't come with a vi tho (unless you get elvis or the like
and compile it up). You can
probably compile up a real csh (which I admit hating), or unless bash has
"C shell mode" (which I
doubt). Also compile up the standard GNU stuff like gzip, RCS,
ghostscript, etc. The bash
is more Unix compatible in quite a few aspects than MKS ksh, as it uses
//C/ for the root of C:
whereas c: required by the Korn shell can cause some parsing problems
unless you start
quoting everything, which may not always be possible or easy.
Also, get the official perl for win32 and put int DBI/DBD::Oracle. These
are available as binaries.
(www.perl.com is your top-level site). They will come in handy. Using
the Tk widget set (if
you are not already doing it for X-windows terms you may have) will let
you write scripts
doing Oracle admin stuff that is portable between X and Win32. As long
as you have SQL*Net
on the workstations, they can run such scripts to talk to the database on
the hosts. You'll
need Win32 for these functions on Microsoft platforms.
OPS$Logins might also be a problem.
Remember that NT Oracle does not have the elegance of $ORACLE_BASE
architecture which
I hope you have been using.
Also, consider having a Linux box with RCS (as MKS have bastardized their
RCS) for your
scripts. You'll need to control your scripts a lot with all the
changes. Linux can export files
as Samba/Lanmanager but can also mount disks from your NT. You'll have
less conversion
to do for script backup and the rest if you are running them from a Unix
box - and it will perform
better anyway. Thus NT users can use their files as normal, use RCS
compiled for NT under
the Cygnus b19 win32 GNU compiler. But as they are REALLY on a linux
box, you can point
your RCS directory to a directory on another machine using symbolic links
and NFS, which
will really give you some insurance. You don't need a big linux box. I
managed this task
on a 486/66 joining Win32 boxes and AIX boxes, and I was running X
sessions and NFS
serving from my own disk at the same time. Samba will compile on almost
any Unix box,
but it was originally written for Linux. Even HP and Cisco use samba.
set smartarse on
You also forgot a couple of tasks:
Restoring the data back to a Unix box when blue screen of death rears its ugly head and you
realize that Oracle software is more reliable than the NT OS. In fact, Oracle can sometimes
keep responding over SQL*Net when everything else about the NT is dead - even the
console.
Turning your fat NT workstation into a sexy X-workstation so you can
really get some
work done.
Getting the person who decided on NT to sign in blood that THEY are
responsible for
the consequences of any increase in machine crashes, downtime (especially if you lost
a Win32 registry). If they don't like DG, then Solaris might be more appropriate.
--
![]() |
![]() |