Wednesday January 11, 2006 
- Blogroll
- Adrian Cockcroft
-
Bart Smaalders
- Brendan Gregg
-
Darren
-
Jim Mauro
-
John Gardner
-
Jon Haslam
-
Joost Pronk
-
Nicolai Kosche
-
Phil Harman
-
Richard McDougall
- Links
- OpenSolaris
Today's Page Hits: 53
Wednesday January 11, 2006 I've just been googling news about
Oracle and Sun after today's Sun/Oracle Town Hall meeting at Oracle
Headquarters, a mini Oracle World keynote was my first impression -
lights/music - If you've been to an Oracle World keynote you know what
I mean. Then Scott and Larry on stage for an hour, 10
minutes of jokes mostly
around acquisitions, a 40 minute presentation, 10 minutes of questions.
Its interesting to see how a one hour event gets compressed into a paragraph or two by different news organizations and the points that they decide to focus on. If you read 5 or 6 articles you'll get a good overview of what when on.
Most of the news articles picked up on the Oracle preferred Sun, then Oracle preferred Linux, now Oracle prefers Sun again theme. You could just as easily interpret history as Oracle has always preferred Sun except for the time when the only easy way to use cheap x86/x64 machines was with Linux, when given the choice between cheap x64 boxes running Solaris or Linux Oracle choose Solaris.
There was one phone question "So what does this mean for DBAs?" which didn't get the follow up deserved
We could follow this train of thought - going forward you will be able to purchase a Sun server with Oracle pre-installed. This gives us an opportunity to do some configuration of the server while at the factory so you don't have to. There are some easy setup decisions since we know you are going to be running oracle you will need a dba group and an oracle user. We don't have to modify
I suppose what I really want to know is what setup would most System Administrations and DBAs agree on so we can make them the default. Less customization means less configuration issues.
Its interesting to see how a one hour event gets compressed into a paragraph or two by different news organizations and the points that they decide to focus on. If you read 5 or 6 articles you'll get a good overview of what when on.
Most of the news articles picked up on the Oracle preferred Sun, then Oracle preferred Linux, now Oracle prefers Sun again theme. You could just as easily interpret history as Oracle has always preferred Sun except for the time when the only easy way to use cheap x86/x64 machines was with Linux, when given the choice between cheap x64 boxes running Solaris or Linux Oracle choose Solaris.
There was one phone question "So what does this mean for DBAs?" which didn't get the follow up deserved
We could follow this train of thought - going forward you will be able to purchase a Sun server with Oracle pre-installed. This gives us an opportunity to do some configuration of the server while at the factory so you don't have to. There are some easy setup decisions since we know you are going to be running oracle you will need a dba group and an oracle user. We don't have to modify
/etc/system
since in Solaris 10 we can configure shared memory, semaphores on the
fly in /etc/project we could put oracle in the FX
scheduling class, use the fair share scheduler, configure a zone(s)
for oracle etc, all of these things will improve performance or ease of
use, we can do more but where do we stop? I suppose what I really want to know is what setup would most System Administrations and DBAs agree on so we can make them the default. Less customization means less configuration issues.
[ T: Solaris Oracle ]
Monday January 02, 2006 I just saw this here
Note:
- Many DBAs feel that if the data is already contained within the buffer cache the query should be efficient. This could not be further from the truth. Retrieving more data than needed, even from the buffer cache, requires CPU cycles and interprocess IO. Generally speaking, the cost of physical IO is not 10,000 times more expensive. It actually is in the neighborhood of 67 times and actually almost zero if the data is stored in the UNIX buffer cache.
One must always be careful when using the UNIX buffer cache with Oracle
The default Unix behavior is to comply with the POSIX standard for reading and writing files
So the default file system behavior is not optimal for oracle, since oracle can manage its' file accesses e.g. not reading a block while that same block is being written. The extra layer of protection that POSIX gives is not needed. You can improve your IO concurrency in Solaris by adding the directio mount option to the database partitions in /etc/vfstab, or you could set the
You may now want to increase the size of the buffer cache since oracle is now bypassing the buffer cache and some of that memory can now allocated directly for oracle buffers.
[ T: Oracle Solaris ]
Note:
- Many DBAs feel that if the data is already contained within the buffer cache the query should be efficient. This could not be further from the truth. Retrieving more data than needed, even from the buffer cache, requires CPU cycles and interprocess IO. Generally speaking, the cost of physical IO is not 10,000 times more expensive. It actually is in the neighborhood of 67 times and actually almost zero if the data is stored in the UNIX buffer cache.
One must always be careful when using the UNIX buffer cache with Oracle
The default Unix behavior is to comply with the POSIX standard for reading and writing files
Read-Write Locks and Attributes
Read-write locks (also known as readers-writer locks) allow a thread to exclusively lock some shared data while updating that data, or allow any number of threads to have simultaneous read-only access to the data.
So the default file system behavior is not optimal for oracle, since oracle can manage its' file accesses e.g. not reading a block while that same block is being written. The extra layer of protection that POSIX gives is not needed. You can improve your IO concurrency in Solaris by adding the directio mount option to the database partitions in /etc/vfstab, or you could set the
Oracle
Parameter FILESYTEMIO_OPTIONS to SETALLYou may now want to increase the size of the buffer cache since oracle is now bypassing the buffer cache and some of that memory can now allocated directly for oracle buffers.
[ T: Oracle Solaris ]
Tuesday December 20, 2005 It's finally official you can read about it here,
page 8 has Oracle's description of a processor for licensing
calculations.
So to summarize Oracle Enterprise license is $40000 or ($60000 with
RAC) per processor.
When a chip has multiple cores the rules change
A dual Xeon server 2 * 1 = 2 oracle licenses = $80000
[ T: NiagaraCMT Solaris Oracle ]
When a chip has multiple cores the rules change
- UltraSparc T1 core factor .25
- AMD or Intel core factor .5
- Everthing else core factor .75
A dual Xeon server 2 * 1 = 2 oracle licenses = $80000
[ T: NiagaraCMT Solaris Oracle ]
Tuesday December 06, 2005 Oracle Embraces CoolThreads
I just saw this on yahoo
“customers using Oracle products with CPU-based licenses on Sun Fire T1000 and T2000 systems will be able to count cores as .25 percent of a processor”
So your new Sun
Fire T2000 with 8 cores,
4 threads per core giving 32 simultaneous processing threads only
requires 2 Oracle CPU licences!
Tuesday June 14, 2005 I'm at the Oracle Applications Users Group Conference. It good to see what other folks are doing with big databases. I've spent most of my time in the Database SIG and at other sessions. The most impressive stuff I've see so far is during a tuning session the guy from oracle logged into the Oracle production ERP system and poked around on the cluster of Solaris E25Ks – wow.
Jserv was the next issue that people seem to be having trouble with these days. Understanding the problems you can have in a multi tier environment is hard.
Oracle trace files make my life hard the Hotsos profiling method was a simple way out of the mess without looking at the tracefile yourself.