Ask Slashdot: On Oracle and Linux 243
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?
Why Linux? (Score:1)
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.
Why Linux? (Score:1)
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.
My Oracle/Linux experience (Score:1)
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
Oracle and the Sun Starfire (Score:1)
To those less informed... (Score:3)
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.
Linux could be fine for smaller applications (Score:4)
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
Ok have any of you actually USED Oracle on Linux? (Score:1)
Heh, just kidding (sort of)!
Different spin on your question ... (Score:3)
Register windows (Score:1)
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 hasn't shipped yet! (Score:1)
Solaris or Linux - who cares? (Score:1)
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.
Oracle bug rates under Solaris and Linux (Score:1)
>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.)
Solaris Intel vs. Linux Intel (Score:1)
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!
Maturity... (Score:1)
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
Oracle on LInux (Score:1)
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
Maturity... (Score:1)
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
Oracle stability and speed vs. NT or solaris (Score:4)
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
Partial BZZZZZT! (Score:4)
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
Platforms (Score:1)
However, good luck getting it working under FreeBSD.
take the price angle (Score:1)
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
Why Linux? (Score:1)
Maturity... (Score:1)
Mathijs
Why Linux? (Score:1)
33 MHz * 32 bits = 1.056 Gb/sec
For high end Alpha: 66Mhz * 64bit = 4.224Gbit
Why Linux? (Score:1)
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.
Rock solid except for this (Score:1)
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.
Hardware NOT the same cost, what planet are you on (Score:1)
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.
Veritas (Score:1)
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_
/
Oracle + Java (Score:1)
m.
Same Situation (Score:4)
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
Platforms (Score:1)
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
Solaris vs. Linux (Score:1)
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
64 vs 32 bit (Score:1)
"rbf"
--
ALPHA POWERED and loving it!
Go back to sleep (Score:1)
Why Linux? Wake up! (Score:1)
I think my statement was far from being "a bigger dick statement".
'Nuff said.
"rbf"
--
ALPHA POWERED and loving it!
Why Linux? Wake up! (Score:1)
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!
Why Linux? Wake up! (Score:1)
"rbf"
--
ALPHA POWERED and loving it!
Maturity... (Score:1)
Maturity... (Score:3)
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.
Argggghh! (Score:1)
http://www.news.com/News/Item/0,4,31691,00.html
-Jake
Oracle on Linux (Score:3)
Go for it.
motherboards (Score:1)
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.
Application Vehicles (Score:1)
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.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 ).
6 hours to install! (Score:1)
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.
DBI/Perl beats OWS, and check out the licensing (Score:1)
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.
Maturity... (Score:2)
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.
RAID Support, HP-UX, etc...Đ?ø^???ø????ø ???ù????ú (Score:1)
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
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.
Details? (Score:1)
>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.
Why Linux? (Score:1)
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.
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.
Register windows (Score:1)
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.
Register Windows Only suck A Little (ws:Why Linux) (Score:2)
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?
Why Linux? (Score:1)
"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.
Oracle bug rates under Solaris and Linux (Score:1)
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
Details? (Score:1)
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.)
Argggghh! (Score:1)
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.
take the price angle - $$!! (Score:1)
Linux' stability (Score:1)
2-gig file limit? (Score:1)
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
Solaris vs. Linux (Score:1)
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.
File vs. Raw (Score:1)
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.
Summary of Points.... (Score:1)
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
Solaris vs. Linux (Score:3)
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.)
Does anyone really buy databases "pre-installed"? (Score:1)
There are glitches (Score:3)
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
PDP11s and Linux (Score:1)
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.
Why Linux? (Score:1)
Oracle stability and speed vs. NT or solaris (Score:1)
Linux, Oracle, Mirroring and Striping (Score:1)
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.
Ah, then NT would be just as secure as Solaris... (Score:1)
I think you would find general consensus being open source is more reliable because the holes are in the open for anyone to fix.
--
Why Linux? Wake up! (Score:1)
greetings,
seb.
--
Why Linux? - WHY ORACLE? (Score:1)
greetings,
seb
--
Solaris Intel vs. Linux Intel (Score:1)
We'd need more information. (Score:1)
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 Access not big issue for Oracle 8 (Score:1)
Oracle Enterprise on Linux Available. (Score: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.
Solaris vs. Linux -- We use both (Score:1)
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.
Ok have any of you actually USED Oracle on Linux? (Score:1)
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
Oracle on LInux (Score:1)
The company that I used to work for tried Oracle on NT, but went back to HP/UX.
That's pretty darn foolish (Score:1)
There are glitches -- Not Linux only (Score:1)
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.
Hardware NOT the same cost, what planet are you on (Score:1)
Linux, Oracle & Network Appliance (Score:1)
You might want to check them out if your looking at netapp's. http://www.emc.com.
PdM
You are incorrect in your citations (Score:1)
I have done this, and here are my results (Score:1)
Without posting detailed results, we found:
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).
Summary of Points.... (Score:3)
OK, I've read everyone's posts, and am going to summarize the arguments here, plus include my own short opinion/experience.
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:
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
Maturity... (Score:1)
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.
--
Flamer! (Score:1)
Why Linux? Wake up! (Score:2)
PDP11? (Score:1)
Ok have any of you actually USED Oracle on Linux? (Score:1)
Ok have any of you actually USED Oracle on Linux? (Score:1)
2-gig file limit? (Score:2)
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?
Maturity... (Score:1)
Disclaimer: I'm not saying that Linux is the right tool for every job.
Don't get me started on registers (Score:1)
Different spin on your question ... (Score:1)
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.
Different spin on your question ... (Score:3)
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?
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.
Solaris (Score:1)
Why Linux? (Score:2)
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.
Think on it (Score:3)
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
Scalability would make sun a clear choice. (Score:4)
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 (Score:2)
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.