The OS itself is quite nice, although it is a bit strange to get used to the finder looking like iTunes. Stacks is a great idea, but part of me wishes it behaved more like a launcher-type application than a different interface to folders. Who knows though. Maybe after using them, I will come to appreciate the feature a lot more.

One thing that I am very glad to see is “Spaces”. Basically virtual desktops, X Windows has had this feature since the very beginning, but it is just now becoming native in Mac OS. Granted, there has almost always been external applications that handle this, but it’s nice to see it wrapped in.

There is a lot of buzz about the “Cover Flow” features that have been added to the finder. I have to admit that it is extremely aesthetically cool and very very slick. How much I use it in my day to day life remains to be seen, but it will be nice to browse documents visually without having to depend only on the title to find them.

Time machine, basically well integrated filesystem snapshots, seems like it will be a wonderful addition, but I have not had the chance to use it yet because I don’t have an external fire wire drive. It’s on my shopping list though, so I will be enabling it just as soon as I have the gear to make it run.

All and all, I think it’s an outstanding upgrade, and well worth the money. Give it a shot… You won’t be sorry.

If you are interested, or would like any further information, please leave a comment or visit this link. Our university campus policy states that big ticket items like this must be sold using an auction style bidding system. I should add, however, that most items in the surplus system are sold with only one bid, so please don’t let the process discourage you if you are at all interested.

First, let’s take a look at exactly what VMware Fusion is. At its core, the package allows the user to create and run virtual machines on the Macintosh. For those who are new to virtualization, it is a way to run multiple virtual computers on one actual computer. The hardware resources are abstracted and shared to the virtual machines through the virtualization software — in this case VMware Fusion. A complete description on virtualization can be found here.

Previous to Fusion, only VMware player was available to Macintosh users, so it is nice to actually be able to create virtual machines locally. The snapshot feature is also very nice for development purposes since you can instantly roll back to a previous working state should you corrupt the software on the virtual machine.

Perhaps the problem that annoyed me most, however, was the fact that there is no clear way to delete virtual machines from within the software. I actually tried to get rid of one by deleting this folder:

/Volumes/Macintosh HD/Users/myaccount/Documents/Virtual Machines/Mymachine.vmwarevm

But I just ended up breaking the “Virtual Machine Library” application and having to uninstall and reinstall everything from scratch. The process detailing how to delete a virtual machine did not exist anywhere in the VMware Fusion FAQ or documentation as far as I could tell. Granted, it’s beta software, but I would think this should be a core feature of any virtualization product. At least they provide an “Uninstaller” script.

VMware Fusion is a basic piece of software that succeeds in fulfilling the most fundamental of virtualization requirements. If all you want to do is be able to run a virtual machine or two on your Mac, it will most likely work for you. If you are looking to deploy it as part of an enterprise solution, I would suggest letting the product mature a while and using something like Parallels instead.

I was also a bit concerned about what kind of performance I would get out of the new Intel processor because many of my applications are older and were compiled on the old PPC chips. This has turned out to be a total non-issue! I got the new Mini fully loaded with a 1.83Ghz Intel Core Duo processor, 2 Gigs of RAM, and a 160 Gig SATA drive, so even the older applications that require the carbon libraries scream right along.

While I would have obviously liked to get the Mac Pro, I am very much enjoying using my new Mini, and feel that I can recommend it fully.

If you are interested, or would like any further information, please leave a comment of visit this link. Our campus policy states that big ticket items like this must be sold using an auction style bidding system. I should add, however, that most items in the surplus system are sold with only one bid, so please don’t let the process discourage you if you are at all interested.

In order to manage the automatic mounting and unmounting of filesystems on RHEL, we use the Automounter service. Here is how.

First, The main configuration file is “/etc/auto.master”. It should look something like this:

#
# $Id: auto.master,v 1.3 2003/09/29 08:22:35 raven Exp $
#
# Sample auto.master file
# This is an automounter map and it has the following format
# key [ -mount-options-separated-by-comma ] location
# For details of the format look at autofs(5).
#/misc  /etc/auto.misc --timeout=60
#/misc  /etc/auto.misc
#/net   /etc/auto.net

Let’s assume that we want to set up an NFS mount on “/misc/backups”. We would first create an entry in this file that looks something like this:

/misc   /etc/auto.misc --timeout=120

This tells the autofs service that we want to use it to manage mounts from within “/misc”, that the configuration file is “/etc/auto.misc”, and that it should disconnect after 2 minuets of inactivity.

Now, let’s edit the “/etc/auto.misc” file. The file has three columns: the mount point from within the /misc directory, the options for mounting the filesystem, and the filesystem to be mounted. It also includes the remote server’s name since we are using NFS. It should look something like this when you are done:

#
# $Id: auto.misc,v 1.2 2003/09/29 08:22:35 raven Exp $
#
# This is an automounter map and it has the following format
# key [ -mount-options-separated-by-comma ] location
# Details may be found in the autofs(5) manpage

cd              -fstype=iso9660,ro,nosuid,nodev :/dev/cdrom
backups         -rw,soft,intr remoteservername:/path/to/nfs/export

# the following entries are samples to pique your imagination
#linux          -ro,soft,intr           ftp.example.org:/pub/linux
#boot           -fstype=ext2            :/dev/hda1
#floppy         -fstype=auto            :/dev/fd0
#floppy         -fstype=ext2            :/dev/fd0
#e2floppy       -fstype=ext2            :/dev/fd0
#jaz            -fstype=ext2            :/dev/sdc1
#removable      -fstype=ext2            :/dev/hdd

Next, we create the directory for the mount point in /misc:

# mkdir /misc/backups

And finally we restart the autofs service:

# service autofs restart

That should pretty much do it. If you don’t have autofs configured to start up, you can use chkconfig to enable it. “/misc/backups” will now be mounted whenever a user or process attempts to access data on it, and it will be automatically disconnected after 120 seconds of inactivity. Last, but not least, you can always confirm that it is running with the “service” command:

# service autofs status

As always, change the details to match your own requirements.

Labels are, of course, arbitrary, so there is no technical need to do this, and you could, instead simply change the mount point in the fstab file, mounting the partition by device name rather than label, but it is usually cleaner to change the label. Here is how you do it:

First, let’s figure out what the partition is currently labeled as:

[root@calvin /]# /sbin/e2label /dev/hda4
/database
[root@calvin /]#

It’s current label is “/database”, and, since we have moved the database data somewhere else, we now want to store our user account data here, we need to change it to “/users”.

[root@calvin /]# /sbin/e2label /dev/hda4 /users
[root@calvin /]#


That’s all there is to it, now we check to make sure we have done what we think we have done.

[root@calvin /]# /sbin/e2label /dev/hda4
/users
[root@calvin /]#

Sure enough, it’s now labeled “/users” and the data on the disk remains intact. Now all we have to do is change the appropriate entry in the “/etc/fstab” file to represent the change.

Change this:

LABEL=/database       /databases            ext3    defaults        1 2

To this:

LABEL=/users          /users                ext3    defaults        1 2

And you’re all set to go. Make sure you have unmounted “/databases” before making the change.

Now, just run:
[root@calvin /]# mount /users
[root@calvin /]#

And you’re all set to go. As always, change the values here to represent those in your environment.

You can also use my instructions for copying a Solaris boot drive to a disk with a different partition layout as a safer alternative.

The first thing you need to do is figure out if your disk layout will allow for this procedure. Usually the swap partition is the second one on the disk, making it partition number 1 (Partition number 0 is root). If partition number 1 is swap on your system, and partition number 3 or 4 are unused, you are in good shape, and this should work. To figure this out, you should do something like this:

# format
Select the boot disk – usually disk 0
Specify disk (enter its number): 0
format> partition
format> print
This will show you the current disk layout.

Current partition table (original):
Total disk cylinders available: 24620 + 2 (reserved cylinders)

Part      Tag    Flag     Cylinders         Size            Blocks
  0       root    wm       0 -   725        1.00GB    (726/0/0)    2097414
  1       swap    wu     726 -  9436       11.90GB    (8635/0/0)  24946515
  2     backup    wm       0 - 24619       33.92GB    (24620/0/0) 71127180
  3 unassigned    wm       0                0         (0/0/0)            0
  4 unassigned    wm       0                0         (0/0/0)            0
  5        usr    wm    9437 - 10888        2.00GB    (1452/0/0)   4194828
  6        var    wm   10889 - 18148       10.00GB    (7260/0/0)  20974140
  7 unassigned    wm   18149 - 24619        8.91GB    (6471/0/0)  18694719

Here we see that partitions 3 and 4 are unused and directly after partition 1, so we can take some space from swap and assign it to one of these. Partition 2 is, of course the entire disk. I have not tried it, so I don’t know if you could assign non-sequential cylinders to a partition that is not directly after swap.

So to take some space from partition 1 and add it to partition 3, the first thing we have to do is disable swap, so the format utility will let us change it.

Comment out the following lines in your /etc/vfstab file and reboot the system.

#/dev/dsk/c1t0d0s1         -       -               swap    -       no      -
#swap    -       /tmp    tmpfs   -       yes     -

This will bring the system up without swap enabled. You can now edit the disk label. Remember that our cylinders need to be sequential, so always work in cylinders when using the format utility.

Re-enter the format utility, select your system disk and view the partition table:

# format
Select the boot disk – usually disk 0
Specify disk (enter its number): 0
format> partition
format> print
Again we wee that partitions 3 and 4 are unused.

Current partition table (original):
Total disk cylinders available: 24620 + 2 (reserved cylinders)

Part      Tag    Flag     Cylinders         Size            Blocks
  0       root    wm       0 -   725        1.00GB    (726/0/0)    2097414
  1       swap    wu     726 -  9436       11.90GB    (8635/0/0)  24946515
  2     backup    wm       0 - 24619       33.92GB    (24620/0/0) 71127180
  3 unassigned    wm       0                0         (0/0/0)            0
  4 unassigned    wm       0                0         (0/0/0)            0
  5        usr    wm    9437 - 10888        2.00GB    (1452/0/0)   4194828
  6        var    wm   10889 - 18148       10.00GB    (7260/0/0)  20974140
  7 unassigned    wm   18149 - 24619        8.91GB    (6471/0/0)  18694719

The first thing we need to do is take some cylinders away from partition 1. In this example, we are looking to make partition 3 roughly 100MB, so we need to take about 75 cylinders from partition 1 so that we can add it to partition 3. Parititon 1 ends at cylinder 9436, so we need to subtract 75 from that number. 9436 – 75 = 9361, so that is the new ending cylinder for partition 1. We then subtract the beginning cylinder (726) from that number to give us the new total number of cylinders for partition 1. 9361 – 726 = 8635, so this is the number we enter when format asks for the size of the partition. Like so:

partition> 1
Part      Tag    Flag     Cylinders         Size            Blocks
  1       swap    wu     726 -  9360       11.90GB    (8635/0/0)  24946515

Enter partition id tag[swap]:
Enter partition permission flags[wu]:
Enter new starting cyl[726]:
Enter partition size[24946615b, 9436c, 12880.92mb, 12.00gb]: 8635c
partition>

Now we have to add these 75 cylinders to partition 3.

partition> 3
Part      Tag    Flag     Cylinders         Size            Blocks
  3 unassigned    wm       0                0          (0/0/0)            0

Enter partition id tag[unassigned]:
Enter partition permission flags[wm]:
Enter new starting cyl[0]:9361
Enter partition size[0b, 0c, 0.00mb, 0.00gb]:75c
partition>

Print out the new partition table to make sure everything lines up correctly:

partition> print
Current partition table (original):
Total disk cylinders available: 24620 + 2 (reserved cylinders)

Part      Tag    Flag     Cylinders         Size            Blocks
  0       root    wm       0 -   725        1.00GB    (726/0/0)    2097414
  1       swap    wu     726 -  9360       11.90GB    (8635/0/0)  24946515
  2     backup    wm       0 - 24619       33.92GB    (24620/0/0) 71127180
  3 unassigned    wm    9361 -  9436      107.21MB    (76/0/0)      219564
  4 unassigned    wm       0                0         (0/0/0)            0
  5        usr    wm    9437 - 10888        2.00GB    (1452/0/0)   4194828
  6        var    wm   10889 - 18148       10.00GB    (7260/0/0)  20974140
  7 unassigned    wm   18149 - 24619        8.91GB    (6471/0/0)  18694719

Partition 1 ends at cylinder 9360, and partition 3 picks right up at cylinder 9361. Partition 3 ends at cylinder 9436, and partition 5 begins at cylinder 9437. Partition 4, of course, remains unused. Since none of the cylinders overlap, we can go ahead and write the disk label out. DO NOT DO THIS if you have any doubt at all about what you have just done. By writing out the disk label, you could corrupt the data on your formated filesystems if any cylinders overlap into them. The format utility is usually pretty smart about keeping you from making mistakes, but be very careful anyway! You don’t want to end up with scrambled eggs on a disk that has valuable data on it.

partition> label
This writes out the disk label, so you can now exit the format utility and re-enable swap in your /etc/vfstab file. Simply uncomment out the following two lines and reboot the system.

/dev/dsk/c1t0d0s1         -       -               swap    -       no      -
swap    -       /tmp    tmpfs   -       yes     -

Reboot your system, and if all goes well, it will come up, and you will see that partition 3 will have a little over 100MB on it. Usually people want to do this so they can store the DiskSuite meta database on the newly created partition. If this is the case for you, you can now move on to mirroring the system disk.

This way of thinking has largely been correct over the years because most systems have traditionally used software RAID. This means that the CPU of the server itself had the job of doing all those parity calculations, and it really did slow down both the server and the disk when RAID 5 configurations were used. Oracle, in particular, had a hard time with these configurations for the exact reasons the DBA’s point to.

In many cases, software RAID is still used, and to be sure, it is wholly inappropriate to deploy RAID 5 in these environments. However, it is increasingly common to find IT departments using a SAN-type architecture where the RAID type and configuration are invisible to the host operating system. In these environments, the the disk array has a dedicated controller that is singly tasked with handling all read, write, and parity operations. The RAID controller is no longer software running on a generic CPU, but rather firmware that is optimized to handle parity calculations. This results in a system where parity is calculated so quickly by the dedicated controller that differences in speed between RAID 1 and Raid 5 should be virtually nonexistent.

To prove this, I carved up our new InfoTrend EonStor A12F-G2221 into three arrays – a RAID 5, a RAID 1, and a RAID 10. I then set out to run some benchmarks on these different arrays to see what, if any, the differences would be.

The hardware used was as follows:

• Dell OptiPlex GX260, 2.2 GHz Processor, 256 MB Ram
• RHEL 4 Linux
• QLogic QLA2340 HBA
• InfoTrend EonStor A12F-G2221 with 1GB cache

• The RAID 5 LUN consisted of 4 drives
• The RAID 1 LUN consisted of 2 drives
• The RAID 10 LUN consisted of 4 drives

I then identified the iozone tests that most accurately simulated Oracle disk activity. What I really wanted to do was to simulate select and update queries on various sized files and see how the different RAID types held up under the load. To do this, I ran iozone, a well-respected benchmark utility, with the following arguments:

/opt/iozone/bin/iozone -Ra -g 2G -b /home/sysop/new/raid5-2G-1.wks

This put the disk through its paces, as it ran the iozone tests in automatic mode on a 2 Gb file, but in the end, I was interested in analyzing the following tests because they were the ones our DBA team suggested would most closely represent database activity.

Random Read (select queries)

This test measures the performance of reading a file with accesses being made to random locations within the file. The performance of a system under this type of activity can be impacted by several factors such as: Size of operating system’s cache, number of disks, seek latencies, and others.

Random Write (update queries)

This test measures the performance of writing a file with accesses being made to random locations within the file. Again the performance of a system under this type of activity can be impacted by several factors such as: Size of operating system’s cache, number of disks, seek latencies, and others.

Strided Read (more complex select queries)

This test measures the performance of reading a file with a strided access behavior. An example would be: Read at offset zero for a length of 4 Kbytes, then seek 200 Kbytes, and then read for a length of 4 Kbytes, then seek 200 Kbytes and so on. Here the pattern is to read 4 Kbytes and then %%[Page: 3]%%

I ran several instances of the same tests using the same command line to ensure that there were no anomalies, and the machine was doing nothing else during the tests besides running the host OS. The results were pretty much as I expected, and I found little to no variation between the raid types on this disk subsystem.

Random Read Tests:

In this test, there seems to be the slightest advantage to the mirror-type RAID arrays when it comes to very small files. This, I suspect can be attributed to actual drive head latency as, in RAID 5 volumes, the correct block needs to be found on a larger number of disks. This advantage quickly falls off, however as the file size grows, meaning that this slight advantage would not be seen in an Oracle database.

Random Write Tests:

In this test, both RAID 5 and RAID 10 seem to hold a slight advantage over the direct mirror. This, I would imagine can be attributed to the fact that the writes are happening over a larger number of spindles. This indicates that the controller is calculating the parity faster than the 2Gb connection speed to the disk subsystem. Again, the variation is incredibly small, so there is no arguable performance advantage to using one type of RAID over another when using a hardware controller.

Stride Read Tests:

Here again we see no real advantage to one RAID type over any other. It could be said that the RAID 10 volume held up ever-so-slightly better on this test, but any edge is so slight that it would be hard to imagine how this could translate into a noticeable performance gain in an Oracle database.

In the end, these tests proved my suspicion that hardware RAID controllers have become so efficient and fast that it no longer makes any real difference what type of RAID you decide to use for your Oracle database. Largely gone are the days when your disk space and RAID volumes were inexorably tied to the server itself. So long as you are using hardware RAID, and the LUNS are abstracted from your operating system, you can largely feel free to make the most of your storage dollar by using RAID 5 in your production database environments.