[CLUE-Tech] Oracle on Linux in production?

[Jeffery Cann]

On Friday 15 February 2002 10:13 am, Jim Ockers wrote:

Jim,

I have worked with Oracle (as an application developer) on various flavors of 
UNIX and Windoze for the past 5 years.   To truly evaluate your position, I 
would like to know how much data you plan to store and how the users will use 
the data.

To summarize my position -- I have no doubt that Linux would support your 
application requirements easily unless you are building a database that is 
over 500 GB.  I doubt your application will approach even 10 % of this size, 
as 75% of databases that exist today are not even in the 100s of GB in size.

> As most of you know I am a huge Linux evangelist.  However, I am also very
> aware that Linux is a low-end OS and only recently in the 2.4 kernel have
> enterprise-grade features started to show up.  The things I'm concerned
> about are the ability to handle large files, large data sets, move large
> files around over the network, etc.  As you may know NFSv2 is still the
> default, I think, in the Linux kernel, and you can't copy more than 2GB
> files to or from any NFSv2 software.  NFSv3 is not in the 2.4 kernels yet,
> AFAIK.

I am troubled by your NFS statements. Maybe you can elaborate?  Here's what I 
thought when I read your statements:

1.  Why would you restrict yourself to NFS to move files around?  
2.  Why would you move Oracle dbf files around a network?  (There are 
reasons, are you aware of them?)
3.  Why would you have a database with its data files spread over NFS?  (The 
performance would eliminate any database performance).
4.  The 2.4  kernel removed the 2.0 GB file size limit of 2.2 kernel.

If this is a large database, I would assume that you would want to spread 
out the data files over as many spindles as possible in your RAID array to 
maximize your I/O performance.  NFS would be a Really Bad Idea (tm) for a 
storage solution.  In fact -- forget NFS and any type of networked storage 
for your database files.  It will not work for any reasonable performance for 
any database, including MS-SQL.

At S&P, we do not use NFS on Solaris (remember that they _invented_ NFS) 
because the performance is terrible.  When our Oracle DBAs do want to move 
dbf files around (to facilitate simpler database copies), they use FTP.  In 
addition, they rarely allow individual physical database files to get too 
large because of the high costs of maintenance.

So, just because you want to build a 20 GB database does not mean you want a 
single 20 GB Oracle dbf file (that would be a serious performance problem).  
Nor would you even necessarily want 10 x 2 GB files.  It's really a matter of 
the logical layout and usage of the database that drives the physical layout.

One thing I can tell you is that Oracle has excellent features for handling 
large tables -- you can break them up into several dbf files without exposing 
this to the application developers.  Not sure about MS-SQLs abilities in this 
arena.

> I just don't want to get bitten by the low-endedness of the Linux
> architecture on this critical application.  

I am troubled by this statement as it relates to the size of your 
application.  Your claim about the low-endedness of Linux is relative to the 
application, not relative to other operating systems.  Unless you are 
building a 1 TeraByte database (which, BTW would cost _millions_ of dollars), 
then I am confident that Linux will handle the load for the average corporate 
databases -- including yours!

IMHO - your best planning recourse for such a project is to spend as much 
money as possible on (in order of importance):

1.  A _fast_ RAID array -- this is because I/O is generally the performance 
bottleneck for most databases.
2.  A lot of memory (as in many GBs).  The amount can be calculated as a 
function of the database size and the number of expected concurrent users.
3.  An SMP database server (4 CPUs are good, 8 would be better).

Here's what I do know about Linux 2.4 and 'enterprize' features:

+ Oracle runs their business on Linux 2.4
   (This should be the end of the discussion, IMHO).
+ Files no longer restricted to 2.0 GB in Linux 2.4
+ Supports limit of 32 SMP processors.  
   (Last I checked NT was 8.  Not sure about W2K.)
+ Addresses up to 64 GB of physical RAM on x86 and IA32
+ Supports IA64 (Itanium)
+ Journaling Filesystem -- actually you have two choices here
+ Kernel is configurable.

This last point is important for Oracle and Linux.  Rracle recommends that 
you tweak kernel parameters and then recompile to maximize the performance of 
the database.  Most UNIX boxes allow at least a relink of the kernel.  With 
Linux you can recompile and relink.  With NT/2K, I do not think you can do 
either.  

I recommend the following article for a technical (manager level) overview of 
the features in Linux 2.4.  I hope that it will help dispel your 
'lowendedness' sentiment.

http://linuxtoday.com/news_story.php3?ltsn=2001-01-05-007-04-NW-LF-KN

Finally, I would recommend that you seek out help with the Oracle side of 
things and find yourself an experienced DBA to consult on the project.  
Oracle is extremely flexible and configurable.  It also requires a good 
working knowledge to get the best performance.  The physical layout of the 
database is the most critical factor followed by tuned SQL queries written by 
competent application developers.  

I hope this helps your quandry.
Jeff