Wednesday January 25, 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 25, 2006 Well the OpenSolaris Appliances community is beginning to take shape. Now the fun part is deciding what it is :) A few wish lists are starting to appear in blogs and on the discussion pages. We have ideas around Qube or Media PC replacement. To Me the media PC is not that interesting without first creating the “Qube” with 2005 technology.
My requirements for OpenSolaris Appliances 1.0
NAS server SMB and NFS
High performance and low cost
My requirements for OpenSolaris Appliances 2.0
NAS server SMB, CIFS, NFS
DHCP Server
Firewall
Name Server DNS and LDAP
Print Server
Nice to have in OpenSolaris Appliances 2.0
Web Server
Mail server
Simple & easy management
Easy interoperability with other home network devices
So for Me the problem I want to solve first is sharing and securing of several hundred GB of data, this is the key area where I think OpenSolaris can outperform all other appliances. Once We have that done then all the other features should just be software upgrades.
[ T: OpenSolaris Qube Solaris Appliances ]
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 ]