Re: native Oracle-port on Linux -- what would it take?

"S V" <sv1_at_mindspring.com> writes:
>Linux is missing many features for any OS to be worth considering
>as a viable database platform.

Oracle already _is_ running on Linux, via the iBCS system call converter (I would not want to call that 'emulation', because as an emulator, iBCS has not that much to do).

The thing that is being called for is a native version of Oracle on Linux. And it is not being called for because of speed (iBCS "emulation" costs not much speed, because of its simplicity), but because of better support and easier installation.

>1. Linux has no logical volumes layer.

Linux ha the md driver, which does build RAID 0, RAID 1, RAID 0+1 and RAID 5 arrays from a number of physical drives.

>2. Linux has no transaction-oriented filesystem.

True. But Oracle does not need a transaction oriented filesystem, because it does implement transactions and logs itself, as does any database worth its money.

>3. Linux has no support for raw devices - hence NO even remote possibility
> to run Oracle Parallel Server.

Linux has support for raw devices, but not for character special raw devices. That is not really a problem, because there is really no difference in the access method from the viewpoint of a program. The difference between character special raw devices and block special raw devices is the buffer cache (which is NOT being used with character special devices).

Oracle wants to use character special (unbuffered) devices to make sure that all data is on disk and not in a buffer cache when a transaction is complete. That can be had with Linux block special devices as well (just flush them).

>4. Linux networking is flaky at best.

That has been true for the very first Linux networking stack. Linux is at it's third revision of networking code now and the Linux networking stack is in the best-of-class league now. Linux networking implements many performance enhancements and redesigns that Van Jacobson suggested for the 4.3BSD networking stack networking and Linux networking is fastest over the wire and even outperforms Sun. Go to Dejanews ad seek out the discussion Alan Cox had with the BSD bunch over Linux NET3 vs. BSD networking and you will learn some very interesting facts.

>5. Linux OS block size is what? 512 bytes? It would make even MS Access
>laugh and puke steam.

The ext2 file system as a block size of either 1024, 2048 or 4096 byte per block. But that is only relevant, if you are going to put your database into dbf-files. If you do that, you are not using raw devices (see your point 3).

>6. Linux SMP is rudimentary and flaky at best.

I am writing this answer from a Dual Pentium 200 (Asus Board). This machine is useable and stable. I am using Linux 2.0.32, because I found that to be faster and more stable than Windows NT 4.0 SP3 on the same hardware.

>7. The same for multithreading.

Linux has the clone() system call, which is a very beautiful and clever generalization of fork(). On top of clone() exists the linuxthreads library, which uses clone() to implement kernel level threads. Both clone() and linuxthreads are quite stable and very useable.

>8. Oracle requires efficient IPC and record-locking mechanisms. Linux
> cannot do record-locking at all, last time I checked.

You should check again to bring your linux knowledge up to date. In this particular case you should have a look at /usr/src/linux/fs/locks.c, which contains the code for the fcntl() and lockf() system calls (Posix compatible locks) and for the flock() system call (which has a different locking personality and semantic).

Linux does have deficiencies and limitations, for example with very large files and very large filesystems. These limitations are being worked on at the moment with the 2.1.x development kernels and will be publicly available in the 2.2.x stable kernel.

Until that these limitations can be worked around by using raw devices instead of dbf-files in a filesystem or by splitting the database into multiple dbf-files. Actually, the latter is recommended for certain setups even _if_ your filesystem can handle larger files.

Kristian

-- 
Kristian Koehntopp, Wassilystrasse 30, 24113 Kiel, +49 431 688897
                    http://www.koehntopp.de
             "Bitte zwei Zeilen Rangierabstand lassen."