Forgot your password?
typodupeerror
Linux Software

Ask Slashdot: On Oracle and Linux 243

Posted by Cliff
from the how-is-it dept.
Dirk Elmendorf asks: "A company I work with is looking at using Oracle as the database backend for a number of large scale intranet applications. They would prefer to go with Oracle under Solaris. I voted in favor of Oracle under Linux. They think that it isn't stable. Can anyone out there provide me proof or testimonials that will help me choose Linux?" How does the Linux version compare with the NT and Solaris versions of Oracle?
This discussion has been archived. No new comments can be posted.

Ask Slashdot: On Oracle and Linux

Comments Filter:
  • by Anonymous Coward
    You are absolutely correct. I've long preferred to use FreeBSD over Linux because many implementations are more mature. For example, trying to use linux as an NFS client to Solaris 7 server required modification (unfortunately, these cannot be distributed to other contractual obligations) whereas the FreeBSD implementation worked correctly out of the box.

    Besides, doesn't Oracle 8i have it's own operating system, thus making the system most optimum for use as a DB? Seems that throwing a multi-function environment that is doing a single function is a waste. That's why ASIC's are so damn fast when compared to a CPU doing the job, cause they have been streamlined for a very specific thing.

    --freak.

    It is NOT a religion. It is a tool. Get over it.
  • by Anonymous Coward
    Just wondering, how many of the Linux zealots out here who recommend Linux for running Oracle have actually run Oracle on Linux? I want to hear from someone who build a successful DBMS backed webservice with Oracle + Linux.

    You see, I am a risk averse person. Why should I put mission critical stuff on an untested platform. We all know that Oracle works great on Solaris, can you say that about Oracle on Linux? I don't know, don't forget that this is the FIRST release of Oracle for Linux and I believe it is not tested as much as on Solaris. Also, note that Solaris is the main development platform for Oracle. I'd say.. if you want to run Oracle, a unix box like sun or HP should be a _safe_ choice.
  • by Anonymous Coward
    I have worked for 5 years on Oracle running on a variety of platforms.

    I currently run Oracle 8.0.5 on Redhat 5.1 on a P100 with 64 mb ram.

    I have had no problems at all running Oracle on Linux. Since Linux is a great OS there are no issues there. Oracle runs quite fast and I have noticed no performance issues. Currently, I run Apache 1.3.4 and I use Java servlets to access the Oracle database.

    So in terms of performance and reliability I woudl say for small to medium sized databases, Linux/Oracle runs great.

    Another issue is features.

    Right now the version of Oracle available for Linux is only the Standard version not the Enterprise version. Therefore a number of features are not found on the Linux Oracle server. In most cases this is not an issue since the features you get are only used in certain special situations, ie. Parallel Server.

    So if these extra features are important, then this will be much more of an issue than performance/reliability.(For a list, check the Oracle page for details)

    in terms of RAW performance of Oracle and Linux
    on Intel platforms, check this URL out for some
    impressive numbers

    http://www.torrent.com/press/intelopenworld.htm

    hope this helps!

    Christopher Fitch
    http://www.tacticsus.com
  • by Anonymous Coward
    My last job involved Solaris administration on a Sun Starfire Enterprise 10000 server. We had the server full of processors, and that one server was handling our entire enterprise worth of transactions. Our database size was 2.3TB. There were 6000 to 7000 concurrent users during the day, and around 500 to 1000 at night. I can say that the server *NEVER* crashed, even though we had a processor board go bad. Solaris allowed us to isolate and disable the downed processor for replacement - all the while the system was still live. I can tell you from years of PC experience I will never see an x86 box do that without a reboot. The Sun/Solaris solution is truely an awesome performer. EH
  • by Anonymous Coward on Monday March 22, 1999 @10:50PM (#1968290)
    I truly find it amazing how completely un-informed and un-experienced people come here and make these rash "Linux Rules" statements. Please, for the sake of everyone's sanity, don't post unless you know what you are talking about!

    The comments I make come from a great deal of experience. I have a Linux machine on my desk, and work with Solaris machines in our server farms. I use all manner of OS and platform (I'll explain why later). Now that I've gotten that out of the way, let me comment on some of the points made above.

    For starters, NT sucks. Period.

    Next, Linux is a baby, an infant. Solaris has been around. Regardless of how nicely Oracle may run on Linux, Solaris is a mature commercial product. Please don't misunderstand, I love open source software and contribute to many projects myself. But Solaris is mature and rock solid. Linux is a developmental product. I could see Linux taking a major portion of the Unix market in mission-critical applications, just not yet.

    Several people have alluded to the possibility of running Solaris on Intel. I fail to see the advantage of this... Solaris is designed for Sparc hardware. Take this fact into consideration. Someone mentioned Linux having better hardware support, which I wholeheartedly agree with. But until very recently, Solaris didn't have to support anything other than Sun hardware, which has distinct advantages.

    One of which is scalability. Solaris is designed to be virtually unlimited in scalability.. look at Sun's Starfire machine.

    Many people mentioned other issues, such as better security on Solaris (VERY VERY true), the "cleaness" of Solaris compared with Linux (also true... Solaris has a nice polish, while Linux is very evidently a work in progress... you can feel this after working with both) and the superior Solaris hardware.

    These are all valid points, and I personally agree with them for the most part. But here are some simple facts. I work for a company (who shall remain nameless for obvious reasons) that provides international Internet bandwidth services and high-end server co-location facilities.

    In the facility I'm at, we have literally thousands of servers of every OS and platform... from a couple of Crays to SGIs to Solaris to Linux to BSD to NT to Mac. Every single machine is monitored via a proprietary network monitoring system that logs and alerts us to machine failures.

    Basically, it comes down to this: Solaris on UltraSPARC hardware is BY FAR the most reliable choice. Very rarely does a Solaris machine appear on our monitor, yet the Linux machines are topping the fail lists daily. The facility I'm at handles 2.5 billion requests a day (if you haven't figured out where yet, I'm sorry!). I feel I am in a unique position to make a determination of which operating system is the most solid and reliable.

    I can also say what truly mission-critical systems do. One in particular (a very large search engine, with a name similar to a chocolate drink) utilizes high-end Sun Enterprise systems to serve their database application to farms of low-end BSD webserver machines. This system (obviously) works very well. There is a reason it uses this system and has never changed.

    So while I may agree with the opinions of many people, and the things I stated above I truly believe, the fact remains... Solaris is a better product for mission-critical applications, for now. It'll be a few years before Linux reaches the "polished" state that Solaris is currently at.
  • We use Oracle almost exclusively at my company. My thoughts about Oracle on Linux is that 3rd party apps are lacking (hot backup, etc). And that if your application gets big at all, you'll have real trouble making Linux work on 64 processor boxes (if you succeed at all).

    Sun can handle this without any problem. Also, as a shop who runs a very large Oracle application on non-Sun hardware, I can tell you that it is no fun trying to Oracle to fix something on their non-favorite platform.

    New patches, fixes and product introductions for Oracle server will always happen first on Sun and sometimes that can be a real buzzkill.

    My $1.59 worth (if that).

    --Aaron Newsome

  • Why shouldn't they make an rpm? They are selling a product. The install has been a problem for several people i know, including myself. Several of these people are running Oracle on NT for major systems. Do you think they'll be encouraged to switch to linux after they couldn't install, much less benchmark, test or play with, the single most important piece of software they run. Anyway, why should installation be so hard?
    Because they should be making .deb's ... rpm sucks, wake up and smell the Debian roses!

    Heh, just kidding (sort of)!

  • by whoop (194) on Monday March 22, 1999 @04:43PM (#1968293) Homepage
    Where might one find the source for this stat, that 60% of oracle servers ship with Linux?
  • Can you say "Register Windows?"

    Of course -- very useful to decrease the performance loss due to context switching. Completely pointless in tasking system with one application running, and doing large amount of display output through the driver in kernel, but things of that kind don't run on sparcs.

  • DB2 for Linux is still in beta; why would someone deploy a mission critical database on beta software? Besides, the guy w/the question had already decided they wanted Oracle...the question was, which is better, Oracle on Solaris or Oracle on Linux?
  • If Solaris gives them the warm and fuzzies that's OK. Any UNIX is better than Windows. Solaris does scale to bigger hardware better than Linux for now but that may change in the future. Advocate Linux as the bulk of the workstations and support servers (mail, ftp, web, dns, file and print).

    Linux would do the job admirably for sure but so will Solaris.

    Here's an idea... see if you can run a Linux box with the same Oracle data on it and the same services as the Solaris box. If the Solaris box ever goes offline for whatever reason, the Linux box can step in and take up the slack. That would put a feather in your hat. I'm sure Oracle wouldn't mind - especially if it lead to another sale. :)
  • Posted by revdoc:

    >The thing that really annoys me about Oracle
    >though is that they don't publish their list of
    >known bugs; instead, you have to be bitten by a
    >bug first before they'll admit that they know
    >about it and supply you with a patch.

    Erm... you can search Oracle's problem database at http://technet.oracle.com. (You have to join, but it's free.)
  • Posted by bSMfh (bastard ScoutMaster fro:

    Yup I agree this is a more level playing field.
    It's hard to compare a jacked-up sun with a PC,
    cheap or otherwise.
    Some of my colleagues think Solaris on Intel will get them out of buying sun hardware...completely.
    I'm not sure about that, especially given some of the arguments elsewhere on these pages!


  • A lot of filesystem operations are significantly faster on linux then on solaris.

    Linux gives you more money and a better selection of hardware support (vs. Solaris/x86) to implement a full-scale oracle server. It also gives you additional cash to contribute to a caching* RAID controller (DPT, Myles...) and extra disks.

    *Oops. No pun intended there.

    -Peter
  • Till then Solaris or NT is probably the safest bet.

    Oracle on NT is not a safe solution. More then 10 to 1 DBA's on the oracle list curse the day their bosses put their database on NT. The general advice is that you should be prepared to reboot the system at least once a week or else your database will crash on you. Because of NT, apparently, since the DB2 sales/marketing folks at IBM have similar stories about their NT products.

    Considering the experience of both of these companies in making reliable servers I have to blame NT for the crashes, since at least one of oracle or NT should be able to code a stable server for NT.

    I have heard exactly 1 (one) testimonial that oracle on NT is stable, but not transaction count to back that up.

    It's far from a safe choice.

    -Peter
  • Certianly $600 is not "make or break". It's just money that can be better spent.

    And of course I meant "mylex". As far as drivers like that are concerned, you have the driver writer to call/write to. Since he works at VA now, if you really want to talk to him if you have a problem then buy a VA box. Sun doesn't seem to let you do that sort of thing anymore.

    -Peter
  • OBstability: so far it hasn't crashed on its own volition in my installation, or in that of a friend of mine. I'm doing very small stuff. Sean, what about you?

    OBSpeed: People doing informal speed tests on linux/oracle vs nt/oracle on the same hardware seem to show about a 3-5x speedup under linux.

    Also solaris/x86's filesystem speed tends to be a lot slower then linux/x86 - same hardware. I expect that linux would be an ideal database server for many GB of data, as long as the SGA doesn't have to get over a GB or so (these are different things - one is disk space, the other memory. Both are dependant on the expeceted use profile of the database). This is an *estimate* from people I've spoken to - I'm not an oracle expert myself... I'm just learning how to program for it, etc.

    Blow the extra money you'd have payed for a SPARC on a caching scsi controller and mirror all of your drives, and you'll have an increadibly reliable and fast server.

    -Peter
  • by spacey (741) <spacey-slashdot DOT org AT ssr DOT com> on Monday March 22, 1999 @05:15PM (#1968303) Homepage
    We use Oracle almost exclusively at my company. My thoughts about Oracle on Linux is that 3rd party apps are lacking (hot backup, etc). And that if your application gets big at all, you'll have real trouble making Linux work on 64 processor boxes (if you succeed at all).

    Well, Spectra Logic gave me a demo of Alexandria (the backup product that claims the fastest network backup. In spec'ing it in the past it looks like a great product). That demo cd has the following printed on it:

    Includeing... Hot Oracle Backup!

    Look at spectra logic's home page [spectralogc.com] if you want more inf.

    (Disclaimer - I don't work with or for them - I just think their product is worth evaluating).

    As for multi-processor - well sun is still behind SGI for that degree of scaleability. If you're intereseted in going to 64 CPU's then go SGI or wait until a big vendor adds patches to linux to make it do 64 processors well. Or gives davem or alan cox a 64+ cpu box to use. Don't hold your breath for the latter ;-)

    also...

    New patches, fixes and product introductions for Oracle server will always happen first on Sun and sometimes that can be a real buzzkill.

    But not on solaris/x86. This is one of the lowest platforms to oracle (at least in my experience in trying to get oracle (tm) consultants to put financial software on it). It seems that linux-specific patches do come out quite quickly. And the oracle 8i pre-release server for linux and sparc/solaris should supposedly arrive at around the same time.

    Sparc/solaris is definetely the unix development platform for oracle, but linux is hot right now.

    -Peter
  • by Dom2 (838)
    There speaks somebody who's never had to deal with Solaris 2.4...

    However, good luck getting it working under FreeBSD.
  • Take the price angle -- it's your only hope.

    I work for a large retailer, and we're running one of the largest customer databases in the world on Solaris and Oracle. It's rock solid.

    TedC

  • by pb (1020)
    ...and Linux runs on SPARC hardware. :)
  • This guy means Mylex.

    Mathijs
  • 33 MHz * 32 bits = 1.056 Gb/sec

    For high end Alpha: 66Mhz * 64bit = 4.224Gbit

  • Not bad at all. I was responding to a claim of 1 GigaBit for Suns. I'm glad to hear it was supposed to be GigaByte.

    The way CPUs keep speeding up, and with bus mastering PCI cards able to bypass the CPU entirely, we really need something better than a flat bus in standard PCs to break the I/O bottleneck.

  • For its primary use: a database, web, dialup,and email server, Linux is rock solid. If you want to get into esoteric uses like memory hogging video applications it crashes like an egg. The VM crash bug in 2.2.* is pretty horrible and not a big enough problem to get fixed by Linus.

    The IRQ lockup in 2.2.* is another monster bug. It got better in 2.2.3 but still happens during extremely rapid I/O shuffling like I was doing on Sunday. Crash, burn, heeyah, over and over and over and over again and not so much as a bedtime story from Linus.
  • I don't know what little Universe you are living in, but for people on a limited budget, Solaris is not anywhere near the same cost as far as hardware goes. Solaris is pig dog slow on Intel stuff compared to Linux. If you have to go with small to mid sized equipment, Linux will save you a bundle.

    And don't arrogantly assume that some one would choose Linux simply for "religious" reasons. My college choose Linux for stablity/cost reasons. As long as Solaris runs so poorly on Intel boxes and Sun wants rediculous amounts of money for their boxes, we will never be able to afford to use Solaris.

    There is a reason people have become so religious about Linux, and it ain't marketing, buddy.
  • by ader (1402)
    Strikes me that one could advance the case for Linux as an enterprise platform much further if Veritas could be persuaded to port Vxfs and Volume Manager to it. Lack of journalled filesystem support (beyond some experimental stuff in the very early stages) is a major drawback to Linux as a highly available, robust platform. And Vxfs would supply a common, portable filesystem format.

    Customers like Oracle on Solaris because Sun can point to hundreds of reference sites, many of which were installed by themselves in short periods. Buy the hardware (servers, arrays); buy the software (OS, disk management, backup); plug it all in; configure; it works. (Yes, you need to have done it before.) In contrast, Linux often seems to require a degree of tinkering by a knowledgeable admin to get the best from it.

    Ade_
    /
  • I develop a Java app using JDBC and Oracle's Type 4 driver, tied into the old Oracle 8 pre-release for Linux. I've never had a problem, and it is very fast.

    m.
  • by ChiefArcher (1753) on Monday March 22, 1999 @04:39PM (#1968314) Homepage Journal
    I was in the same situation.. We started out with Oracle on Dec Unix... Since Dec got bought out by Compaq, we decided to move to a different platform..
    The choices were solaris, and linux.... We choice linux because if we needed to upgrade, it was just a standard PC.... you can buy thoses a dime a dozen.... Solaris on the other hand.. gots lots of $$$ to upgrade..
    DELL put us together a nice RedHat Certified PIII with a nice raid controller..... (rackmountable!)..

    Email me if you need help in the process

    ChiefArcher
  • No Oracle expirence, but on a X86 I would tend to favor Linux over solaris as I think Linux does have better HW support than solaris does. Plus I won't even start to do anything on a Solaris system until it's had the recommended patches applied (There's some really scary things that are broken there in Solaris). I actually think the Linux environment is more stable.

    Considering you can get RAID solutions for Linux and it does work nicely with Network Applicance boxes I don't think that linux would be such a bad choice.

    -randy
  • One note on the Veritas and RAID. Do NOT let that be your security blanket. One of the servers at work went south and left the system completely unrecoverable. I had heard that it was a mismatch of the Veritas file system and the RAID.

    If I had my choice of journaling file systems, I'd go with AIX's JFS. That is a easy to configure and *solid* (in my expirence) file system. I wish IBM would port it to Linux. I'd even pay $ for it.

    -randy
  • It's not yet available for Alpha Linux, but is being worked on. Oracle for Tru64 (formerly Digital UNIX) is the fastest Oracle platform anywhere!



    "rbf"

    --
    ALPHA POWERED and loving it!
  • It's on it's way... And there is Tru64 (formerly Digital UNIX), which is the fastest Oracle platform anywhere!
  • Compaq has done more for Alpha in the last year then DEC ever did! Compaq even has a page listing which AlphaServer systems are ready to run Linux! Or did you miss the fact that they sent Linus a AlphaServer DS20 for Linux development just a few weeks ago???

    I think my statement was far from being "a bigger dick statement".

    'Nuff said.


    "rbf"

    --
    ALPHA POWERED and loving it!
  • Umm, Linux doesn't run on a Sun Enterprise 10000, mind you!

    I bet you a Wildfire with 32 21264 CPUs (due out in about 4 months) can beat your Sun Enterprise 10000!

    A Wildfire with 64 21264 CPUs (due out before the end of the year) can mop the floor with two of your Sun Enterprise 10000! And wait until next year when the 128 21264 CPU version is out, that will beat three of your Sun Enterprise 10000 systems!!!



    "rbf"

    --
    ALPHA POWERED and loving it!
  • I think it was great that DEC sent Linus (old) Alphas. If they hadn't, I wouldn't be typing to you from a Alpha Linux system right now! I didn't mean to make it sound like DEC didn't do anything at all, it's just that Compaq has done MORE in the last year then DEC did for Alpha. DEC supported Linux for quite some time now, but they never marketed the Alpha... Now that Compaq has Alpha, they have been advertising (yes really) including a TV comerical that shows a quick flash of a AlphaServer! DEC as it was would never have sent Linus a NEW Alpha (esp. a server). So I see the fact that Compaq sent him a NEW AlphaServer based on the newest generation Alpha (21264), as a good thing.



    "rbf"
    --
    ALPHA POWERED and loving it!
  • I was referring to religion in the context of the operating system war.

  • by sheldon (2322) on Monday March 22, 1999 @05:11PM (#1968324)
    You learn it eventually....

    Let's analyze this a bit.

    How much are you going to save going with Linux over Solaris? Maybe $600, the price of a Solaris license. Considering hardware and database software is going to be the same price no matter which solution is chosen.

    Is Linux signifigantly better than Solaris? No.
    Is the version of Oracle available for Linux signifigantly better than that for Solaris? No.

    In fact the opposite is true. Solaris is signifigantly better than Linux as a server platform, and Oracle has been available for Solaris for a signifigantly longer amount of time than Linux, which generally equates to a more stable product.

    I'm having a hard time trying to identify what you see as being positive about the Linux solution? You save very little money, and instead increase your risk by a large margin. That risk factor outweighs the initial cost by a huge margin.

    Please leave your religion at the door next time you go to work.
  • It's actually Solaris/Intel. The irony is that HP was the first vendor to sign on to actually build these boxes, not Sun. See, for example:

    http://www.news.com/News/Item/0,4,31691,00.html? st.ne.ni.rel

    -Jake
  • by glomph (2644) on Monday March 22, 1999 @04:25PM (#1968326) Homepage Journal
    Is as stable as it is on other platforms, and more efficient. We are running it on a multimillion-hit site, and it rocks.

    Go for it.
  • agree with you about abit.

    their motherboards are low-end but well-priced, and decent quality. their support is good aswell. my bios broke after i tried to flash the latest version, and abit sent me a new chip first class post without any fuss.
  • (sorry for the top level post, there were too many good points raised and I don't have time to reply to them all individually)
    • Vehicle vs. Passenger
      In a production environment, one should think of an OS as a vehicle for your applications ( first off, my preferred vehicle is Linux ). If the choices were:
      • { OS=Linux, APP=Oracle }
      • { OS=Sparc-Solaris, APP=Oracle }
      • { OS=ix86-Solaris, APP=Oracle }
      I'd say "Go with Linux." with little hesitation ( see Scaling ).
      In reality, however, the real choices are:
      • { OS=Linux, APP=Oracle-Linux }
      • { OS=Sparc-Solaris, APP=Oracle-Sparc }
      • { OS=ix86-Solaris, APP=Oracle-ix86 }
      So, assuming all else is equal, you've got to ask, "is Oracle-Linux a good motorist?" I don't know the answer.
    • Scaling
      As far as Oracle scaling goes, you're pretty much stuck with the (ugly+expensive) vertical scaling. ( that means you can't install PVM on a bunch of machines and sit back ).
      • With x86 hardware, you can't get much more than: (4x)xeon, (2x)wide-diff-ctlr, (1x)internal-scsi, (35x)disk
      • With Sparc hardware (for example), we've got an SunOS-UltraE4000 at work with: (8x)cpu, 8gb-ram, (2x)fibre-scsi-ctrl, (1x)wide-diff-ctlr, (64x)(SSA)disk, (9x)(bay)disk. It would be a no-brainer to add two more fibre-controllers and another 64 disks (an expensive no-brainer).
  • I can't speak to its stability compared to Solaris's version -- never had a speck of trouble with either, but I've never pushed either very hard.

    I can tell you, on a 586/133 (AMD) with 64 meg of ram, and a five year old slow-as-molassis IDE harddrive, it takes a good four hours to install. Most of it the process of setting up the initial database, AFAIK, and not needing any interaction. But it did work.

    A nice spankin' new Pentium II or III might work better. ;)
  • We've got a test Oracle/Linux box here, and are sufficiently impressed that we've ordered a multiprocessor box to build a production system on.

    Two things I'd point out are:

    - once you have Oraperl built, you have a great quick-and-dirty web interface happening with Apache/mod_perl/DBI (or other OSS web-db interface of your choice). Oracle's own solution (OWS/Developer 2000/PL-SQL )sucks badly cause of rotten performance, plus you don't have the huge range of existing Perl modules (or Python libraries, or PHP scripts, yadda yadda) to draw on. Oh, and when I had to hack apart someone else's OWS based system a few months ago, I discovered that the text editor in Developer 2000 wasn't even as good as Wordpad for finding and replacing. And you have to compile PL SQL. And it is so SLOOOOOW! And if you don't believe me, see Philip Greenspun. Meanwhile, we can now talk to Oracle on our AIX boxes from the Linux box. Yippee! (Did I mention the appalling huge Java applets that won't even run on a Mac JVM, thus obliterating the point of a cross-platform browser-based solution anyway?)

    - there seem to be some licensing cost differences for different platforms, ie it's cheaper per seat on lower spec'd hardware. At least it is for us. All other things being equal, Oracle on (commodity?) Intel linux boxen might be a great deal cheaper than proprietary Unix/Risc solutions.
  • Well - it depends. The original poster's context was "a large scale intranet backend".

    My (possibly quite incorrect, I admit) reading between the lines is that it therefore is not that big, or important, and that the main corporate databases livse somewhere else already. So cost may in fact be an important factor. There's other things too: what in-house expertise is there?

    I agree that a knee-jerk "Linux, right or wrong" approach is stupid, but you might still be able to build a reasonble case for Linux. So long as we all stick to replying with things we know of ourselves, we can let the original poster make up his own mind.

    Anyway, as long as I see management make decisions based on who bought them the best lunch, and which sales droids they trust, I'm not sure that deciding for religious reasons is that bad. :-)
  • Actually, the availability of I2O Linux drivers for the SmartRaid V series of controllers from DPT were just release (look at the Pengiun on their front page.)

    Likewise, Mylex has full support for RAID under Linux and HP has developed AmiRD drivers as well.

    Being HP-UX certified myself, I'll admit that the lack of a stable LVM at this point is a fairly big minus for large servers, as is the lack of a journeled filesystem for quick recovery in a crash situation.

    On the other hand, there are some stability problems in HP-UX 11.00 that I have noticed. After heavy modifications to a volume group, I was able to reboot my system simply by activating it. This was even after rebuilding the LVM structures on the drive. When I reported it, the answer was "well, we haven't heard that one before, so it's too rare to worry about."

    The network subsystem also seems to have some odd bugs - the telnet program will /NOT/ connect properly to an Openserver system (it hangs, though I get a response to an AYT), after several days of continuous use I lose all network connectivity and have to reboot.

    Installing the cumalitve lan patches that I assumed would fix some of these problems turned out to be a misadventure, as two of the patches depended on one another, so I had to unpack the patches and combine them into a single swdepot so they would install.

    The ldd command is simply broken on 32 bit systems - it exits with a message that the file is not a 64 bit executable.

    And the support technicians are not nearly as competant as I would hope - I had to guide the one sent out to replace a bad motherboard in my B160 through removal of the drive cage as well as the commands for the PDC. And the first two replacement motherboard were bad - one was completely gone and the other one did not have the LAN ID cleared at the factory. Another one I dealt with flat out refused to do a processor upgrade without a minimum of 1.5gb installed, when the manual clearly stated that 1gb was the requirement.

    All in all, I'll admit the feature set is more rich, the hardware design can be nicer to work with (I love that expansion cards have a hard set hardware path and you can list the hardware that isn't currently claimed by a driver). But the physical layout of the hardware is often very bad (the B series have front panel switches soldered directly to a portion of the motherboard held on by a piece of plastic only a few centimeters thick), the OS has more bugs than Linux, and there _ARE_ problems with stability.
  • by Galt (3624)
    >PC hardware failure problem spots in my
    >experience have been:

    > CD-ROMs (really flaky)

    Depends on what you buy. A lot of machines ship with piece-of-carp EIDE Mitsumi's or La Cie's.

    On the other hand, buy a Toshiba SCSI and you get the exact same product you would in an HP 9000 or Sun Sparc.

    Buy a Plextor and you get the best CD-ROM on the face of the earth. :)

    > RAM

    Depends on the manufacturer. Though I have not noticed this being more of a problem on PC's than RISC boxen. Most of the problems that arise are people using the wrong memory (which isn't helped by the ridiculous variety of RAM out there and that finding out what you SHOULD use is harder than on a Sun platform).

    > SCSI cards

    If you go with the garbage put out by Symbios, sure. Or if you get a bad driver from Ami (notoriously bad under Openserver and Unixwar).

    But the DPT cards are rock-solid and they don't needlessly change the interface to their cards (with the introduction of the V series, there are only three driver interfaces for virtually all their cards).

    I have an anchient ISA full-length card of their (a 9011B) that has been going for 9 years without a hiccup.

    > Motherboards

    This I'll agree with to some degree. Why expect decent performance and quality from a no-name motherboard you picked up for $40 though? Buy Tyan, Asus, or Micronics.

    I think the "problem" with the PC platform is that, since it is open, there is more opprotunity for garbage. But if you know what you're buying, you have, overall, a very good platform.
  • Its not about the chips, its about the IO.

    For databases it sure is. There are still applications that run out of CPU. For some reason raytracing sems to be the only one I run into.

    A lot of Sparcs these days have gigabit backplanes, so they don't spend 90% of their time waiting for the IO subsystem.

    I use both UltraSPARCs and PCs (both running BSD/OS). The PCs arn't noticable behind in disk I/O. The PCI bus is quite fast. Fast enough that Sun (and many other Unix hardware venders) has switched to it on their "newer" systems. Even the big E10000s have "I/O" boards that plug into the FHB (fire hose bus?) that do PCI I/O. The SBus was very fast when it was introduced (~1991), but it isn't faster then the 33Mhz 32bit PCI bus.

    SPARCs may well seem to have faster disk I/O then PCs, but I expect that is because most SPARCs have SCSI disks, and most PCs have IDE disks. For all the improvments in transfer rates IDE has seen over the years, I beleve it still can't queue many requests (so it can't usefully reorder reads, nor writes even if it has some sort of NVRAM), and I beleve it still interrupts you for every four (512 byte) blocks, that's 32 intrrupts for a 64K I/O which SCSI could easally do with one intrrupt. A smart SCSI controler (and they exist) could read commands from a list (that the CPU can expand while the controler is using it), and not gennerate intrrupts until the entire list is processed (or on commands that have an intrrupt on completion bit set). That reduces the CPU spent on intrrupt processing, which might be important, and definitly reduces the time the disk waits on the CPU!

    I have seen PCs with SCSI disks turn in great I/O numbers. Even when you put a RAM disk on the SCSI bus, the PC wasn't signifigantly slower then the SPARC (and both used nearly the entire SCSI bus, but I can't remember if it was a 20MB/sec bus, or a 40MB/sec bus).

    Where SPARCs beat PCs is backplane bandwidth, which matters if you have more then 132MB/sec of I/O going on, or tons of memory bandwidth you need to use. You can also get SPARCs with many more CPUs then I have seen PCs. On the other hand the single CPU proformance of the Intel CPUs is very hard to beat. Not because Intel has a better archature then the SPARC (variable length instructions make multiple instruction decoders a giant pain, which is why the PIII still only has two, and the K7 three vs. the Ultra2's five; register windows only cause minor pain for the SPARC, and the now-quaint beanch-delay slot isn't a huge problem). No, Intel is ahead because they sell so many CPUs that they can justify an unbelevable research budget. With enough thrust a barn can break the sound berrier.

    That's what we have here, lots of thrust.

  • Can you say "Register Windows?"

    Of course -- very useful to decrease the performance loss due to context switching. Completely pointless in tasking system with one application running, and doing large amount of display output through the driver in kernel, but things of that kind don't run on sparcs.

    While they are sometimes useful for that, the only systems I have ever seen work that way are embeded applications with fewer important tasks then register windows, i.e. not Solaris, nor Linux, nor BSD/OS on the SPARC.

    What they do get used for is local variables, arguments, and returns from functions on the call stack. As long as the call stack grows no deeper then the register window depth the first 8 "arguments", "returns" and "locals" are stored in the register windows*. As long as the call stack depth doesn't excede the number of windows none of that memory traffic hits the cache, or the memory bus. If it does excede the depth then you have the overhead of an interrupt, and all that memory I/O in one bundle. Genreally enough leaf functions are called to make this a win. Also there are more collesed writes this way then even with a good write buffer.

    Unfortunitly it does have the negitave effect of making context switches more expensave (you have 100s of regesters to save rather then 32). It is also somewhat limiting on other parts of the design. If you force a pipeline stall when you switch register windows they have almost no effect on the design, but that would cost as many as 15 cycles on todays CPUs, almost as expensave as a cahe miss, far far more expensave then a cache hit. It also has a negitave impact if most of the function's stack frams that get written to (and read from) memory use signifigantly fewer then 8 inputs, output, or locals. (note some of these registers are tipically used to hold program counters of callers, memory addresses of stack frames, and other grot, you use more then it would appear just glancing at C source code)

    If you still want to know more, pick up a good CPU design book (I recomend Hennsey & Patterson, but only because I used it at the UofM, there may be better).

    * (actually the AMD 29K had variable sized windows, and other non-SPARc systems worked diffrent ways, but the SPARC is the only register windows system still in production that i know of, so I'm going to stick to talking about the SPARC's register windows, even where other implmentations may get around many or all of the problems the SPARC has.

  • I hate to disappoint you, but the Sparc chips SUCK. Can you say "Register Windows?" At least Intel chips seem to scale to faster clock speeds pretty well.

    Register windows isn't why the SPARC is behind the PIII. Try compairing the research budgets for the Ultra2, and the PIII. Or go read a good CPU arch. book like Hennesey & Patterson. Register windows are no longer thought of as much of a win, but they don't suck nearly as badly as variable length instructions.

    Variable length instruction make it much harder to decode multiple instructions per cycle. Here is a thought expariment. You have a decode unit for a "all instructions are 32 bits" machine. You want to decode two instructions per cycle (that is two instructions at the same time), so you use two decoders (one decodes the instruction ad PC, the other at PC+4). Let's say you have a decoder unit for a machine that has 16bit and 32bit instructions, and again you want to decode two instruction per cycle. You need one decoder for the instruction at the program counter, and another for the following instruction (just like the all32bit CPU), however since you don't know if the second instruction is at PC+2 or PC+4 you need three decoders!

    Now I don't know the exact numbers, but I think the x86 has at least four instruction sizes (and if I'm wrong I'm probbably guessing low), so to decode two instructions per cycle you need five decoders. To decode 3 instructions per cycle you need twenty-five decoders!

    Is it any wonder the as-yet-to-be-released AMD K7 is the first x86 that decodes 3instructions per cycle, while the TI SuperSPARC from ~94 was the first SPARC to do so?

  • You're scared of "async"?

    "synchronous" metadata only protects the *metadata*, not the *file content data itself*.

    So having mounts synchronous by default only ensures that the metadata is preserved correctly. This means that after an unexpected reboot, the data inside the files themselves may be junk, but at least it *looks* ok when you do an "ls -l". Is that so valuable?

    If you want a filesystem that doesn't lose data, use a journaling filesystem. It's that simple.
  • Unfortunately, it appears that no large commercial RDBMS available today is unconditionally stable, and Oracle is representative of the genre. If your application is database-intensive, you should expect to see bugs come out of the woodwork every now and then. With Oracle under Solaris, a bug a month seems to be par for the course, according to some senior DBAs with long experience in bug chasing. I wouldn't expect it to be very different under Linux: on the one hand Linux has far fewer known bugs than Solaris, but on the other hand Oracle under Linux has undergone far less testing in the field, so perhaps they even out.

    The thing that really annoys me about Oracle though is that they don't publish their list of known bugs; instead, you have to be bitten by a bug first before they'll admit that they know about it and supply you with a patch. If you ask me, that's an approach that is less than totally customer-friendly.

    As for NT, don't even joke about it ... Those that don't want a Unix server on the premises but have money to burn should head straight for the Oracle8i Appliance, a turnkey box that runs Oracle native rather than on top of an O/S. Well, we all know that there's an O/S under there somewhere, but hey, anything's better than NT. And turnkey appliances are cool for standard applications, as proved again and again by the lovely NetApp.
  • That's a good post.

    Could you break down the failures on Intel hardware for us a little? It would be good to know which components go down more often than others to get an idea of where to spend extra money if one is tied to a PC solution. Motherboards, power supplies, disk controllers, Ethernet, etc, which go down most often in your experience? (Disks die most frequently I reckon, but they're the same across all computer manufacturers.)
  • I just had an absolutely appalling thought. What if the (hidden) O/S on the Oracle8i Appliance is actually an NT kernel ... :-((((

    Nah, Oracle would be the joke of the planet. It's probably BSD, since they wouldn't have to release the source for it. That would be far more cost-effective than creating an O/S from scratch.
  • I just want to point out that something like 50% of the businesses in America including my company can't afford Solaris (at least for departmental servers.) Our accounting system gets an HP-UX because we can't do without it but the Art dept needs a database with a lot of disk space and their budget is $15000. Try buying a Solaris for that much...we priced essentially identical systems from Sun and VA Research - it was $13k vs $75k. Once we told the Sun rep our price range he wouldn't even return our calls. Fine...Linux is what I run at home so I'm comfy with it. I know problems will be fixed promptly (at least OS related ones) and I don't have to worry about buying more license if we decide to put another department on it.
  • Well, Linux' stability is now generally regarded as better than the hardware's stability...
  • >Is Oracle-4-Linux immune to the file size barrier?

    Nope, it's not immune. However, that's not a real problem. Just combine several 2-gig datafiles in one tablespace. On HP/UX 10.20, I have a DB with an 80-gig tablespace, made of 40 2-gig datafiles spread over several volume groups. Solaris goes beyond 2-gig, and so does HP/UX 11.0 64-bit with 64-bit Oracle8.

    >I saw you CAN use raw partitions to use as databases, but I wasn't sure that the option was available for the Linux port..

    Right again. Linux /dev/hdXX or /dev/sdXX refer to block (non-raw) device names.
  • Ok, here are my counterpoints. :)

    Mathew> You have to think about what drives Larry Ellison. First and foremost, he wants a successfull company/product/life. Secondly, and not too far behind, he wants to see Microsoft weakened. I think Linux / Oracle are here to stay.

    Don't get me wrong, I WANT to see Oracle on Linux grow. But I do sometimes wonder if Larry Ellison isn't a bit too obsessed with Microsoft (like many of us). Then again, the same might be said of Scott McNealy.

    Mathew> Not true. Oracle Enterprise Edition, with all included apps, is now available on Linux. This includes failover, ConText, and everything else bundled with Solaris OEE.

    What version of Oracle on Linux are you running today?

    Are you talking about the Oracle 8i developer release, or an official general release of Oracle8 EE? All I've seen so far is developer releases, but I'll be perfectly happy to be wrong on this point.

    Mathew> I don't know what Veritas is, but Oracle on Linux supports Raw partitions.

    Veritas is 3rd party JFS and LVM on Solaris, and it's a damn sight easier to use than the Solaris default.

    Oracle supports raw partitions, but Linux doesn't. Even if you define a datafile as '/dev/sda1', you are pointing to a block device name.

    Finally, Oracle on Linux is only on the x86 platform to date. I'm talking what's usable today, not what may be available tomorrow.
  • Religion alert! Religion alert! You have struck the filesystem vs. raw partition nerve. :)

    Basicly, Oracle stays out of this one. Well, mostly. Oracle has from time to time put out tuning guidelines and white papers that sometimes contradict each other on the benefits of filesystem vs. raw. In it's simplest form, it breaks down to:

    Filesystem: K.I.S.S.
    Raw: Fully optimized I/O

    The benefits of raw can vary from platform to platform. For example, Solaris allows async I/O for both filesystems and raw partitions. HP/UX only allows async I/O on raw partitions.

    If I/O is not a bottleneck on your system, then going raw will not improve database performance.

    If you plan to use Oracle Parallel Server, then you must build a raw database.
  • Excellent summary. Well put.

    One small nit about Oracle/Linux and raw partitions. Have you tried it, and does it work?

    Yes, Oracle supports raw datafiles. My concern is with the partition device names in Linux. I believe you can only use raw if you're writing to a raw (character) device name, not a block device name. Does Linux support character device names for SCSI partitions?

    My only Linux experience is with IDE drives :(, and IDE drives only have block device name definitions.
  • by Bolen (4896) on Monday March 22, 1999 @05:37PM (#1968347)
    Assuming you have to make a choice Real Soon Now (like by the end of this month), and company's budget isn't tight, Solaris is the better choice today.

    Why, you ask?

    1. Oracle on Linux doesn't have a long enough track record yet. It was ported just 6 months ago. As quickly as Oracle jumped on the Linux bandwagon, Larry Ellison could change his mind and jump off again.

    2. Oracle is developed on Solaris, then ported to other OS's. Any bugs get fixed in Solaris first.

    3. Right now, only Oracle Standard Edition is available for Linux. If you need Oracle Enterprise Edition features (table partitioning, object support, advanced replication, parallel server), then you need Solaris.

    4. Scalability. If you expect rapid growth in you database application, Sun will scale better than any current Pentium system (E10000 anyone?). Beowulf clustering is not a viable option for Oracle.

    5. Solaris has journaled file system and logical volume manager (Veritas), and it will suport raw logical volumes for datafiles.

    6. If you plan to use an Oracle application, like Oracle Financials, you can't use Linux, because no Oracle application is certified for Linux yet. Oracle Financials is a BIG pain. It is extremely sensitive to the particular Oracle rdbms release, patch level, application patches, OS release, and OS patches.

    Note that these considerations have more to do with the current state of Oracle on Linux, and current Pentium hardware limits, than with Linux per se. Ask this question again a year from now, and I hope to give you a different answer than today's.

    Meanwhile, you might still get the Linux foot in the door by starting off using Oracle on Linux for test and development. The good news is, if you do use Oracle on Linux and you find you've outgrown that Pentium, you can easily port your entire database to another Oracle system (Sun, HP, IBM, etc.)

  • Never seen this ... everyone I know builds them from scratch ... I wouldn't think of not doing it myself.
  • by Stick Boy (5386) on Monday March 22, 1999 @07:31PM (#1968349) Homepage

    I have installed Oracle for Linux and used it for some fairly grand things. I wouldn't use it again for a little while, however. Once things are right it's okay.

    But, it's REALLY finicky. The install program itself would random crash every now and then with odd scripting errors that were never repeatable. You could re-run it immediately after and blow by the same point even though you haven't changed a thing.

    The original Oracle for Linux CD came with almost completely non-shared libraries which means most executables, such as tnsping and svrmgr were 3-4 meg apiece. The re-linking process itself was a nightmare. I had tons of problems relinking executables which eventually came down to what I believe was a GNU linker or binutils bug but it could've been the library they distributed.

    The documentation for Linux is not awful but not grand either. Documentation for other platforms is significantly better.

    For awhile I would have trouble shutting down the database. It would refuse to shutdown with a 'shutdown immediate' even though there were no connections nor any rollback activity. Nothing short of a shutdown force would shut it down. This eventually went away for some unknown reason.

    The listener would occasionally core dump for little to no reason (that I could see anyway) under light load.


    However, mind you it was pretty damn fast and purred well once things got hammered out. The biggest problem I think is they really rushed to package the thing and just tested it to see that most things work.


    And some advice. Don't go anywhere NEAR Oracle Application Server for Linux. Particularly, their piece-o-crap Apache module.. (used to make Apache the web listener).


    StickBoy
  • I rather miss RT-11 and PDP-11s actually (I've still got 3 or 4 LSI-11s here, must boot them again one day if only to see how rusty my Macro-11 is)

    Actually, I rather think porting Linux onto a PDP11 would be a nice retirement project, it has a nice sense of historical completeness to it.
  • by jtn (6204)
    Sort of, and not on all SPARC hardware. Don't let your religion pull wool over your eyes.
  • And then watch as the Intel-based machine chokes starving for bandwidth between CPU, memory, and your SCSI bus. Moral? You get what you pay for.
  • I like Linux. A lot. I use it at home, and I use it at work. But right now, if I was to choose a platform for a large Oracle database, it would be Solaris, without hesitation.

    I'm not saying Linux will never do it, in fact I think it's pretty close, and I look forward to revising my opinion in the not-too-distant future.

    Now to the reasons:

    1) Hardware stability. I wouldn't want to run a large database on PC hardware. I think Sun's hardware is a more robust platform. And if we're talking *really* large databases, Solaris still scales better at the very high end than Linux.

    2) Striping, mirroring, and all things RAID. Sure you can do this with Linux, and it works pretty well, but support's an issue.

    I'm not FUD'ing here - if someone can point to an organisation which will provide 24/7 support for a 2.2 Linux kernel (on an SMP machine, with software RAID) today, I'll happily eat my words.

    Having vendor-supported 2.2 kernel distribs is going to change this a lot, I think. Having Veritas Volume Manager for Linux would also be fantastic.

    But for now, I'd go for Solaris.

  • At least as I follow your logic.

    I think you would find general consensus being open source is more reliable because the holes are in the open for anyone to fix.

    --
  • And what do you think about the fact that DEC has already sent Alpha Stations to Linus, even back when he still was in Finland ? i guess at the time it was at least a Jensen station.

    greetings,
    seb.
    --
  • why not mySQL over Oracle ? because MySQL doesn't handle very well multi-user access to tables or locks. And neither MySQL nor PostgreSQL can do distributed/parallels DB AFAIK.

    greetings,
    seb
    --
  • This is the question I was really interested in. On the same Intel platform which has better performance and support. I have seen some recent scary posts concerning Solaris Intel. It looks like Oracle is going to produce for Linux Intel before Solaris Intel... Just check the supported platform list for Oracle 8.0.5. Solaris Intel isn't even listed.
  • As other have pointed out, the answer depends on your situation. Oracle on Linux is probably stable enough and can probably take you easily to the order of 10GB of data (and likely more) without a hint of trouble if set up properly. But is it the sensible choice?

    NT's not a good choice for Oracle unless your IT department is unwilling to deal with Unix. Starting on NT with the intention of moving to Unix is not too smart, either. Administration skills from the NT side--to say nothing of backup scripts and the like--don't move to Unix very well.

    For an initial Oracle rollout on Unix, the first rule is to go with what you know. If you have HP/UX, use HP/UX. If you have Solaris, use Solaris.

    If your company is new to Unix, I'd go with an established Oracle platform, and Solaris is as good (or better) as any; whatever its performace shortcomings, it's usualy the first to get upgrades, it gets all the apps, it runs on big, scary hardware that can make up for a whole lot of slow code, and you can get decent support.

    Oracle on Linux seems fine. Oracle wouldn't release it if they didn't think so. Customers running it seem happy. But I'd venture a guess that most production sites deploying it already had expertise with another Oralce-on-Unix platform. If your company has Oracle expertise and real Linux expertise already, you can probably do it with confidence. If not, I'd recommend Solaris as a better way to kick off a deployment of Oracle. It's better-traveled ground.
  • Raw disk storage is the Right Way for Informix, Sybase and Oracle 7. With Oracle 8, the claim made is that the performance gap between filesystem and raw device access is well under 10% for most uses. Maybe they accomplished this by slowing down raw device access [grin].
  • Over on Oracle Technology Network [oracle.com], the following are available for x86 Linux, all final production releases:
    • Oracle8 Standard 8.0.5.1
    • Oracle8 Enterprise 8.0.5.1
    • Oracle Application Server 3.0.2
    • Patches to upgrade (preumably from the prelrelease version) of Standard to version 8.0.5.1

    It ain't an unsupported beta anymore. And yes, if you're up for 168MB of downloading, you can grab Enterprise to eval from the web. Registration for OTN is free.

    Tinkerers with limited bandwidth may want to wait a few more weeks to get 8i.

    What I do wish I could find are client installers, minus the server or the major tools. Not every machine I want to put the Net*8 client on has the necessary 450 MB disk space the installer needs to extract all the server stuff. Ah well. Soon.
  • I work for a software development company that develops for Oracle (and other DBs). One of our Development machines has Oracle on Linux (8.0.5) and we have several Sun Machines that have (8.0.5, 7.3.4 and 7.3.2 workgroup installed)

    My experience is that Oracle 8.0.5 on Linux on a PII-300mhz is faster than Oracle 8.0.5 on a UltraSparc 5- 233Mhz, but I'm sure the PII is a faster processor to begin with.

    The version of Oracle that was available for download for Linux does not have all the features that the shrink-wrapped Solaris version has.

    As far as stability-- the Linux Oracle has never failed us, I can't say the same of the Solaris, but we also have more, careless people banging on the Sun boxes.
  • They use the same install program on HP/UX and Solaris, and probably every other Unix.

    The Windows version uses a similar (but prettier looking) install, and doesn't even use InstallShield.

    No, I don't think they'll do RPMs
  • Most people I run across, even NT users, laugh or shudder at the thought of Oracle on NT.

    The company that I used to work for tried Oracle on NT, but went back to HP/UX.
  • Don't put Oracle Linux on mission-critical servers yet, but we are happily using Linux Oracle for development.
  • I often get fatal installation errors on Solaris too. If you try to install the "Unix installer" for instance, the install will fail."

    Also, if you forget to change the kernel parameters on Solaris, the Install will fail near the end without indication as to what the problem is.
  • I think the original post probably referred to Solaris x86
  • When I was at USA.NET, we used NetApp's for the Oracle databases there, but switched to the EMC symmetrix.

    You might want to check them out if your looking at netapp's. http://www.emc.com.

    PdM
  • The Yahoo (rhymes with "Yoohoo") database back end does not run on a Sun enterprise system.
  • For a project that I'm involved in, we decided to compare three database backends as an informal educational exercise: Linux+PostgreSQL, Linux+Oracle, and Solaris+Oracle. All tests were done on a PII 450MHz; Linux was Redhat 5.2, and Solaris was 2.6x86. Single 2GIG partition, Adaptec SCSI on PCI, and (this is important) no changes were made to the default OS installs--to wit, we did not go on a kernel tweaking rampage or anything.

    Without posting detailed results, we found:

    • Linux+Oracle was about 100% faster than Linux+PostgreSQL (about twice as fast) and
    • SolarisX86+Oracle was about 40% faster than Linux+Oracle.


    Solaris is a 15-year-mature product, so it makes perfect sense.

    Before you get your panties all in a wad, I run Linux at home and love it. But if I was running a mission-critical database backend, and had the choice between the two, I would go with Solaris. It can take an unholy beating and keep ticking.

    For the record, we went with PostgreSQL+Linux, because they were free and we didn't have money for Oracle ($1200 for Linux version).
  • by trims (10010) on Tuesday March 23, 1999 @04:45AM (#1968371) Homepage

    OK, I've read everyone's posts, and am going to summarize the arguments here, plus include my own short opinion/experience.

    1. Oracle/NT sucks - the universal experience is that NT isn't ready to run a serious production DB. My personal experience with both Oracle (in a test env.) and MSSQL 6.5/7.0 (in production) verify this.
    2. Oracle is more stable on Solaris than Linux - there is some debate about this. Oracle is indeed originally written on Solaris/SPARC; however, the Linux port is by far the easiest to do (from a friend at Oracle who works on Oracle/Linux). The deciding factor here is probably simple longevity. The longer something is publicly available to beat on, the more confidence I have in it's stability. Edge goes to Solaris.
    3. SPARC vs Intel - Oracle/Linux is Intel-only right now. I've repeatedly asked all Oracle reps and developers I know when Oracle/Linux AXP or SPARC will be out. No time guess at all . The problem with PC hardware (and, to a lesser extent, the SPARC ATX motherboards) is that commodity hardware sucks. It fails all over the place (from a production point of view). So, you can't buy cheap Intel stuff. A good DB server from IBM or Compaq (with the support contract, and Linux support) will run $10-20k at least. Sun hardware (Ultra 10, UE 450) starts at $10k and runs to $50k real fast. Still, Sun hardware fails at a far lower rate than PC hardware. Call it the simple law of combinations.
    4. Intel vs. SPARC (scalability) - SPARC hardware scales far better than Intel hardware. Period. If you look at the raw CPU numbers, Intel can be more than competative in CPU vs. CPU, but that's only part of the equation. The memory/bus architecture of a Sparc is far superior to even a high-end Intel box. Much greater Memory to CPU bandwidth, bigger backplane, etc. A DB server will stress virtually your entire system, so a balanced system design is much more important. Though Oracle 8 is still 32bit (and thus can't use more than 4GB of ram per instance), you can run multiple instances of Oracle per SPARC box, and can cram far more memory into a SPARC. Also, right now Linux has a 4GB limit on Intel (acutally, if you tune it, a 3GB usable). Most SPARCs can stuff well over 4GB of ram in them - you can't get more than 1GB in an Intel box unless you pay for Xeons. (which, by the way, eliminate most of Intel's price advantage).
    5. Linux vs. Solaris - from an OS point of view, which is better for Oracle? Oracle itself does smooth out alot of the differences (Oracle Linux can do raw volumes). Linux runs faster on less hardware than Solaris. As usual, though, Linux isn't really tested on the Big Iron stuff (I'm not sure it's quite as good on a 8-way box as it is on a 4-way box). Solaris scales virtually linearly (up to 64-CPUs). As previously mentioned, about the only other relevant point is total memory: you get 3GB usable in Linux, and lots more in Solaris. Also, the availability of a superior filesystem/software volume manager for Solaris is not to be underestimated (they really make a difference). The rest of the OS issues are religious, and reasonably irrelevant (or, at least, sufficiently ignorable).
    6. Oracle Support? - this is a valid concern. While I highly doubt Oracle will suddenly jump off the Linux bandwagon (though, it would certainly abandon Linux before Solaris, at least in the next 10 years), there is a more crutial problem: support. Yes, Oracle is mostly a self-contained env, so an Oracle DBA should be able to run/maintain Oracle on any platform. However, there are ALWAYS platform-specific dependencies. There are hordes more Oracle/Solaris DBAs, and more importantly, Oracle support itself is extremely familiar with Solaris. I'm not sure if they can even (really) deal with Linux-specific support calls yet. Oracle support is simply far more mature, available, and accessible for Solaris than for Linux.
    7. Oracle App availability - if you plan to use any of the suite of various Oracle Apps, many (if not most) are not yet available for Linux. There are a huge number being ported (since the work isn't terribly difficult), but others (like the Financial Suite) aren't, since people haven't demanded it yet. So, if any of these are a concern, Linux/Oracle loses right now. Check back on this is 6 months, though.

    I'm looking at your original post, and the main advantage of Linux over Solaris is price. Intel hardware (even the quite heavy-duty stuff you should buy for a serious DB server) is less than equivalent SPARC hardware. However, there are other concerns:

    • For this use, your Oracle license will dominate in cost. There is no difference between an Linux and Solaris license cost. The Oracle license is going to dominate your hardware costs (I'm looking to spend $100k for Oracle and $50k on Hardware for something similar to what you describe). So, the hardware savings looks less relevant.
    • Like I mentioned before, you really have to spend alot of money to get quality hardware. Otherwise, there's no sense in buying Oracle. Why would you put a 450cc big-block in a VW? Same principle here. I simply can't seen it being a sane choice to run Oracle on anything less than a high-end Dual P2/3 or Xeon with major RAID. $15k minimum for that. More like $25k for a good setup. $50k for a quad Xeon. A stocked UE 250 runs under $35k. A mid-range UE450 runs $60k.

      If you are running a small database (ie, 2-3GB max) that doesn't get hit extremely hard, Linux is certainly fine. However, given that you seem to be wanting a enterprise-level solution, Solaris is simply the better way to go. You might spend 25% more on the hardware, but remember, TCO is so much more than just the hardware. In the long run, Solaris is the much better choice from a feature set, performance/scalability, and support/maintenace viewpoint.

      Hopefully, in about 2 years, we can redo this comparison, and Linux will be a truly equal competitor. Right now, Linux really doesn't belong in the datacenter running hard-core enterprise apps. Soon, though.

      -Erik


  • If the $600 cost of Solaris is going to make-or-break your Oracle-solution, maybe you should go back and re-think whether you really can afford an Oracle-based solution.

    Also, I've never heard of a "Myles" RAID controller. No Name hardware is probably something to keep away from a production database box.

    As far as Linux's hardware suppport, there lots of support, but not everything is completely supported. Some of the kernal SCSI drivers, for example, are marked beta or even alpha. At least if your stuff is on Sun's hardware list, you can be pretty sure that it will work, and you'll have someone to call if it doesn't.

    Oracle on NT has been a disaster as far as I know. If you have to run NT, you might as well go with the undocumented API hooks and run MS SQL 7.
    --
  • by Lx (12170)
    And now you're telling people Linux is superior due to its stability. Notice a pattern? ;)
  • ahem? You have a flaw in logic there - the word 'compaq' was included in a bigger dick statement. Doesn't work.
  • by ultra1 (12214)
    More than you think. Hell, I've worked with PDP-11 systems running RT-11 (of all things) as recently as 1995, let alone UNIX.

  • I admit, it is a difficult installation, but take your time and it should come out ok. I didn't even change the shared memory values in the kernel, although I might when the Oracle box actually goes into heavy production. It could be easier, but do you really expect Oracle to make an rpm?
  • They shouldn't make an rpm because Linux is NOT the only thing going. They have a pretty standardized install for the different Unices. As for those considering NT for major systems, I hope they know they can't do an OFA install on NT. I learned to read before I lost my first tooth. I assume you can read too. Print out the installation guide and follow it. If you can't, you don't need to be running Oracle anyway.
  • Is Oracle-4-Linux immune to the file size barrier?

    I saw you CAN use raw partitions to use as databases, but I wasn't sure that the option was available for the Linux port..

    Anyone know?
  • Question: What is your justification for claiming that a man shouldn't consider his morals while at work?
    Disclaimer: I'm not saying that Linux is the right tool for every job.
  • Great: 32+ general registers, 32 more FP, plus some special-purpose Good: 16+ general registers, plus FP or special-purpose Fair: 16 general registers, stack or accumulator architecture Totally sucky: Sharing the same register bank by mutually exclusive functional units
  • There was an article over on Ziff-Davis a couple of weeks ago. They spoke with the director of sales.

    The article focused on how Microsoft may be killing themselves when they strong-arm OEMs.

  • by BitMan (15055) on Monday March 22, 1999 @04:39PM (#1968382) Homepage
    Different spin on your question ...

    60% OF ORACLE SERVERS ARE NOW SHIPPING WITH LINUX!

    Why? Because M$ does not allow top-tier vendors to bundle Oracle with Windows NT servers. This is designed so end-users are forced to go with M$ SQL Server. But the actual result is that the strategy is backfiring along a different path, people are chosing Linux over NT.

    I mean, if you are a Dell, IBM, Compaq or HP customer, what would you choose?

    • An NT server with Oracle SQL post-installed by either a 3rd party or yourself, unsupported by the OEM?
    • Or a Linux server with Oracle SQL pre-installed with vendor support?

    The same goes for the other non-M$ DB players, Oracle, Sybase, Informix, IBM, etc...

    Trust me, Oracle SQL Server on Linux is MUCH, MORE STABLE than NT! Against, Solaris, that is a completely different question (especially since it scales much higher). But for a workgroup/mid-enterprise server, I'd say you cannot got wrong with Linux.

    Don't be surprise when Linux outsells NT PRE-INSTALLED on servers this year.

  • Depending on what you are going to user Oracle for. If you are going to use it as a back-end for web applications and for that purpose alone and you can predict that you will have a fairly small environment that is going to be painless to manage then you should probably go with Linux. If you are expecting to grow the database farm and you are planning on using commercial database management tools (BMC Software, Platinum technology, etc...) then you should use Solaris since these tools are not yet and probably will never be available for Linux. It is also much easier to find DBAs and System Managers who have alot of experience on running Oracle on Solaris since Oracle for Linux has only been around for less than a year and there is a very low count of people who have experience in deploying, using, and supporting it in a business environment.
  • Its not about the chips, its about the IO.

    PCs spend most of their time waiting for disk
    drives. Watch your CPU usage on a PC sometime,
    and you'll notice that its usually 90+% idle,
    even under load.

    A lot of Sparcs these days have gigabit
    backplanes, so they don't spend 90% of their
    time waiting for the IO subsystem.
  • by syncsyncsync (26730) on Monday March 22, 1999 @04:52PM (#1968420)

    I've never used Oracle on any platform but HP/UX, but let me inject a few general observations about Unixes and third party products in general:

    Keep your critical systems away from anybody's first releases.

    Keep your critical systems off of NT.

    There are many fine *nixes out there, each with their own strengths and weaknesses. Linux is a fine *nix, but it has too many under-informed zealots that will tell you it's always the OS for the job at hand. It's not always that OS. In sheer years, it is way too young to offer the kind of feature set a more mature *nix might offer (of course it's also too young to offer the entrenched corporate philosophies and 10 years of backwards bug compatibility found in a more mature *nix :)

    In short, don't count Linux out, but don't automatically decide to use it because a bunch of Internet 12 year olds tell you it "rool3s". Linux does rule for the home PC, or for the ISP, but it's missing so many basic elements, like LVM, RAID, and a slew of things in the process and memory management department... all these things are in active development (yes, even LVM) but once again... do you want beta software a the box that makes your beeper go off if it goes down?
    Keep your eye on Oracle for Linux, though. It's a comer and I hope to be using it within a year :)


    --Sync

  • by SmartyPants (27576) on Monday March 22, 1999 @04:33PM (#1968425) Homepage
    If your firm had the $$, and most do then Solaris 2.x would be a superior choice for a LARGE system.
    you will find a lot more people with solaris sysadmin experience with large solaris systems.

    On the other hand if the database is a small one (1G) than a linux machine would be sufficent.

    Just think why you choose linux instead of solaris in the first place. is it because linux is 'cool' and flavor of the month ? or is it for cost reasons ?

    Try not to pick something just because it will be 'fun' and 'cool' to say you are working on it.

    Another question you should ask is what other machines the site has expierence with, because you will probably costing them more on support than what you would save implementing on linux.

    I am not saying that linux is bad, just make sure you choose it for the right reasons
  • Oracle on Linux suffers from what all software
    does on a first release and is
    less stable than for instances on Solaris
    and possibly less stable than under NT.

    I would not put mission critical stufff on
    Linux/Oracle before I see a strong indication
    that Oracle will continue to support it and
    a few more releases down the line.

    Larry is not known making choices he stands by
    really. (Anyone remember 4MB Javastations
    that would do EVERYTHING) ehe.

    But in a few years time Linux/Oracle might be
    ready for the mission critical things.

    Till then Solaris or NT is probably the safest bet.

Often statistics are used as a drunken man uses lampposts -- for support rather than illumination.

Working...