Of course, if the author of this message's parent had been running Oracle in archivelog mode, he/she could just have backed up the physical database files and the archivelogs, instead of using Oracle's crappy exp/imp tools and putting the data at risk of irretrievable loss.
The moral of the story: never forget that there is more than one way to backup your data, and if you're going to spend US$40k/CPU on database software, be sure you can also afford to hire someone who knows how to run it.
1) When you hyperthread the physical CPU is shared, so you may see what looks like a performance hit. In reality, one task might do 100 units of work with out HT disbled. With HT, one task will do 80 units while the other does 30, a NET gain over BOTH tasks of 10 units.
True, however, only true for single-CPU HT machines. In a dual-CPU system (or greater), where physical CPU 0 is logical CPU 0 & logical CPU 1, and physical CPU 1 is logical CPU 2 & logical CPU 3, the potential exists for the scheduler to assign tasks only to logical CPUs 0 & 1, thereby overloading physical CPU 0 while leaving physical CPU 1 twiddling its' thumbs. That's where the big performance hit comes in, but, like I said, this should disappear with an HT-aware 2.6.
I don't know where you're getting your info about Oracle, but it's wrong. Oracle licensing is determined per-physical CPU. This was something we made doubly-sure to check up on when migrating from our old Oracle server to our new one (dual Xeon w/HT).
On the downside of HT, until the 2.6 (or 3.0, subject to Linus' whim) kernel comes out, there's no point in enabling HT on a Linux box; because the 2.4 scheduler is unaware of HT, all CPUs are treated the same, and the scheduler ends up starving one physical CPU. Performance on a dual-1.8Ghz Xeon, 1Gb RDRAM with HT enabled under 2.4.10 is roughly 5-15% slower than with HT disabled.
2.5.31 with the HT patch dramatically reverses these numbers, providing an average performance that is 30% better than 2.4.10 without HT. YMMV, of course, and I'm not talking about OS performance, I'm talking about Oracle's performance. Still, 30% increase just for flipping a switch in the BIOS and recompiling the kernel is nothing to sneeze at.
Slashdot Mirror
Of course, if the author of this message's parent had been running Oracle in archivelog mode, he/she could just have backed up the physical database files and the archivelogs, instead of using Oracle's crappy exp/imp tools and putting the data at risk of irretrievable loss.
The moral of the story: never forget that there is more than one way to backup your data, and if you're going to spend US$40k/CPU on database software, be sure you can also afford to hire someone who knows how to run it.
But in all seriousness, and at the risk of sounding incredibly arrogant, I've not met someone who can keep up with me when writing code.
That went way beyond risk. Oh, and as any unit testing tool will tell you - being able to code quickly != being able to code well.
1) When you hyperthread the physical CPU is shared, so you may see what looks like a performance hit. In reality, one task might do 100 units of work with out HT disbled. With HT, one task will do 80 units while the other does 30, a NET gain over BOTH tasks of 10 units.
True, however, only true for single-CPU HT machines. In a dual-CPU system (or greater), where physical CPU 0 is logical CPU 0 & logical CPU 1, and physical CPU 1 is logical CPU 2 & logical CPU 3, the potential exists for the scheduler to assign tasks only to logical CPUs 0 & 1, thereby overloading physical CPU 0 while leaving physical CPU 1 twiddling its' thumbs. That's where the big performance hit comes in, but, like I said, this should disappear with an HT-aware 2.6.
Of course, you're correct. My bad for not mentioning this in the first place.
I don't know where you're getting your info about Oracle, but it's wrong. Oracle licensing is determined per-physical CPU. This was something we made doubly-sure to check up on when migrating from our old Oracle server to our new one (dual Xeon w/HT).
On the downside of HT, until the 2.6 (or 3.0, subject to Linus' whim) kernel comes out, there's no point in enabling HT on a Linux box; because the 2.4 scheduler is unaware of HT, all CPUs are treated the same, and the scheduler ends up starving one physical CPU. Performance on a dual-1.8Ghz Xeon, 1Gb RDRAM with HT enabled under 2.4.10 is roughly 5-15% slower than with HT disabled.
2.5.31 with the HT patch dramatically reverses these numbers, providing an average performance that is 30% better than 2.4.10 without HT. YMMV, of course, and I'm not talking about OS performance, I'm talking about Oracle's performance. Still, 30% increase just for flipping a switch in the BIOS and recompiling the kernel is nothing to sneeze at.