Introducing Asquith

In life, Herbert Henry Asquith was prime minister of the United Kingdom from 1908 to 1916.

In the context of this blog, however, his is the name that will be attached to a new way of auto-building Oracle servers, of the standalone, RAC and RAC+Data Guard variety.

Salisbury, of course, has been doing that job for several months now, so why the need for Asquith? Well… Salisbury works fine… but is maybe not very realistic, in the sense that Salisbury’s use of NFS for shared storage has put some people off. So Asquith is effectively the same as Salisbury -except that he uses ASM for his shared storage, not NFS.

In my view, that perhaps makes him a little more ‘realistic’ than the Salisbury approach, but definitely results in a more useful learning environment (because now you can get to play with the delights of ASM disk groups and so forth, which is an important part of managing many production environments these days).

1. Asquith v. Salisbury

Other than his choice of storage, however, Asquith is pretty much identical to Salisbury: an Asquith server, just like a Salisbury server, provides NTP, DNS and other network services to the ‘client servers’, which can be standalone Oracle servers, part of a multi-node RAC or even part of a multi-node, multi-site Data Guard setup. If you’re doing RAC, the shared storage needed by each RAC node is provided by Asquith acting as an iSCSI target. The clients act in their turn as iSCSI initiators.

The only other significant difference between Salisbury and Asquith is that Asquith never auto-builds a database for you, not even in standalone mode. I figured that if you’re going to go to the trouble of using ASM, you’re doing ‘advanced stuff’, and don’t need databases auto-created for you. If automatic-everything is what you’re after, therefore, stick to using Salisbury. For this reason, too, Asquith does not provide an auto-start script for databases: since it uses ASM, it’s assumed you’ll install Oracle’s Grid software -and that provides the Oracle Restart utility which automates database restarts anyway. A home-brew script is therefore neither needed nor desirable.

All-in-all, Asquith is so similar to Salisbury that I’ve decided that the first release of Asquith should be called version 1.04, because that’s the release number of the current version of Salisbury. They will continue to be kept in lock-step for all future releases.

And this hopefully also makes it clear that Asquith doesn’t make Salisbury redundant: both will continue to be developed and updated, and each complements the other. It’s simply a question of which shared storage technology you prefer to use. If you like the simplicity of NFS and traditional-looking file systems, use Salisbury. If you want to learn and get familiar with ASM technology, then use Asquith. Each has its place, in other words, and both are useful.

2. Building an Asquith Server

In true Salisbury fashion, the job of building the Asquith server itself is completely automated, apart from you pointing to the asquith.ks kickstart file when first building it.

Your Asquith server can run OEL 6.x, Scientific Linux 6.x or CentOS 6.x -where x is either 3 or 4. In all cases, only 64-bit OSes are allowed. The Oracle versions its supports, like Salisbury, are, or The Asquith server needs a minimum of 60GB disk space, 512MB RAM, one network card and two DVD drives. The O/S installation disk goes in the first one; the Asquith ISO goes in the second.

The server is built by hitting <Tab> when the installation menu appears, and typing this on the bootstrap line:


Once built, you need to copy your Oracle software to the /var/www/html directory of the new Asquith server, using file names of a specific and precise format. Depending on which version you intend to install on other client servers, you need to end up with files called:


You can, of course, have all 10 files present in the same /var/www/html directory if you intend to build a variety of Oracle servers running assorted different Oracle versions.

You can additionally (but entirely optionally) copy extra O/S installation media to the /var/www/html directory if you want future ‘client’ servers to use an O/S different to that used to build Asquith itself. Asquith automatically copies its own installation media to the correct sub-directories off that /var/www/html folder -so if you used CentOS 6.4 to build Asquith, you’ll already have a /var/www/html/centos/64 directory from which clients can pull their installation media. You would need to copy the DVD1 installation media for OEL and Scientific Linux to corresponding “oel/xx” and “sl/xx” sub-directories if you wanted to use all three Red Hat clones for the ‘client’ servers (where ‘xx’ can be either 63 or 64).

3. Building Asquith Clients

When building Asquith clients, you need to boot them with appropriate, locally-attached installation media. The netinstall disks for each distro are suitable, for example.The distro/version you boot with will be the distro/version your Asquith client will end up running. You cannot, for example, boot with a Scientific Linux netinstall disk, point it at Asquith and hope to complete a CentOS kickstart installation. As a consequence, what you boot your clients with must match something you’ve already copied to Asquith in full. If you boot a client with an OEL 6.4 netinstall disk, the DVD 1 media for Oracle Enterprise Linux 6.4 must already have been copied to Asquith’s own /var/www/html/oel/64 directory, in other words.

4. Asquith Bootstrap Parameters

You build an Asquith client by again pressing <Tab> on the boot menu at initial startup and then passing various parameters to the bootstrap line that’s then revealed. All bootstrap lines must start:


You then add additional parameters as follows:

Parameter Compulsory? Possible Values (case sensitive)
distro Yes centos, oel or sl
version Yes 63 or 64
hostname No any valid name for the server being built
domain No any valid domain name of which the server is a part
rac No Is this server to be part of a RAC? If so, it will find its shared storage on the Asquith server. If not, no shared storage will be configured (any future database would be stored on the local server’s disk).
ip No IP of the server (the public IP if a RAC)
ic No IP of the server’s interconnect (if it’s to be part of a RAC)
dg No Is this server to be part of a Data Guard site? If so, it will find its shared storage on a Rosebery server, not on Asquith.

The parameters can come in any order, separated by ampersands (i.e., by the & character), and there must be no spaces between them. For example:


(That example might wrap here, but is in fact typed continuously, without any line breaks or spaces).

Note that “rac=” and “dg=” are mutually exclusive. One causes the built server to use Asquith as its source of shared storage; the other directs the server to use Rosebery for its shared storage (I’ll talk more about Rosebery in Section 7 below). If your Data Guard servers are themselves to be part of a cluster, therefore, you just say “dg=y”, not “rac=y&dg=y”.

After you construct an appropriate bootstrap line, you must additionally add three space-separated Kickstart constants, as follows:

Constant Compulsory?
ksdevice= No eth0, eth1 or any other valid name for a network interface
oraver= Yes 11201, 11203, 12101 or NONE
filecopy= No y or n

ksdevice and filecopy are only relevant if you’re building a RAC: a RAC node must have two network cards, and you use ksdevice to say which of them should be used for installation purposes. The usual answer is eth0. If you miss this constant off, the O/S installer itself will prompt you for the answer, so you only need to supply one now if you want a fully-automated O/S install.

The second node of a RAC needs to have paths and environment variables set up in anticipation of Oracle software being ‘pushed’ to it from the primary node -but it itself doesn’t need a direct copy of the Oracle installation software. Hence ‘filecopy=n’ will suppress the copying of the oradb…zip files from Asquith to the node. If you miss this constant off, an answer of ‘y’ will default, which will mean about 4GB of disk space may be consumed unnecessarily. It’s not the end of the world if it happens, though.

The oraver constant is required, though. It lets the server build process create appropriate environment variables and directories, suitable for running Oracle eventually. You can only specify 11201, 11203 or 12101 depending on which version of Oracle you intend, ultimately, to run on the new server. If you don’t ever intend to run Oracle on your new server, you can say “oraver=none”, and after a basic O/S install, nothing else will be configured on the new server.

A complete bootstrap line, suitable for the first node of an intended 2-node RAC, might therefore look like this:

ks= oraver=12101 filecopy=y ksdevice=eth0

Notice there are spaces between the three constants, and between them and the original part of the bootstrap line. Here’s another example, this time for the second node of a Data Guard RAC:

ks= oraver=12101 filecopy=n ksdevice=eth0

5. Asquith Speed Keys

It’s not really that much typing when you come to do it, but if you want to make things even quicker, there are four ‘speed keys’ available to you:

Speed Key Effect
sk=1 The server will be called alpher.dizwell.home, with IP and Interconnect IP of It will run as the first node of a RAC and is configured to look to Asquith as its shared storage source.
sk=2 The server will be called bethe.dizwell.home, with IP and Interconnect IP of It will run as the second node of a RAC and is configured to look to Asquith as its shared storage source.
sk=3 The server will be called gamow.dizwell.home, with IP and Interconnect IP of It will run as the first node of a RAC but is configured to look to Rosebery as its shared storage source.
sk=4 The server will be called dalton.dizwell.home, with IP and Interconnect IP of It will run as the first node of a RAC and is configured to look to Rosebery as its shared storage source.

If you want to use one of these speed keys, your bootstrap line becomes:

ks= oraver=11203 filecopy=n ksdevice=eth0

Note that you still have to supply the three Kickstart constants -but at least you don’t have to supply any of the normal parameters. In fact, you only have to supply the oraver constant, so it could be even shorter to type, if you’d prefer.

6. Creating Databases and Clusters

All Asquith client servers end up being created with a root user, whose password is dizwell and an oracle user whose password is oracle. Use the operating system’s own passwd command to alter those after the O/S installation is complete if you like.

All Asquith client servers are also built with an appropriate set of Oracle software (if requested), stored in the /osource directory. Grid/Clusterware will be in the /osource/grid directory and the main Oracle RDBMS software will be in the /osource/databasedirectory. Your job is therefore simply to launch the relevant installer, like so:


If you don’t want to run a RAC or use ASM, just pretend the grid software’s not there! If you do, standard operating procedures apply:

  • Run the /osource/grid/runInstaller
  • Do an advanced installation
  • Select to use ASM, keep the default DATA diskgroup name
  • Change the Disk Discovery Path to be /dev/asm*
  • Use External redundancy levels (at this stage, Asquith doesn’t do redundancy)
  • Click ‘Ignore All’ if any ‘issues’ are discovered
  • Run the root scripts on the various nodes when prompted

Once the Clusterware is installed, you can install the database in the usual way:

  • Run /osource/database/runInstaller
  • Do a typical installation
  • Select to use Automatic Storage Management -the DATA disk group should be automatically available
  • Supply passwords where appropriate
  • Ignore any prerequsite failures
  • Run the root script when prompted.

It’s all pretty painless, really -which is precisely the point!

7. Rosebery

Just as a Salisbury server is accompanied by a Balfour server when building a Data Guard environment, so Asquith has his Rosebery. (Archibald Primrose, 5th Earl of Rosebery, Prime Minister of Great Britain 1895-1896). A Rosebery server is built in the same way as an Asquith server (that is, 60GB hard disk minimum; 512MB RAM minimum, 1 NIC), but doesn’t need a second DVD drive from which to find its kickstart file: for that, you simply point it at Asquith.

The bootstrap line to build a Rosebery server is thus:


After that, the Rosebery server builds automatically. It then provides a new iSCSI target for client servers built with the dg=y parameter in their bootstrap lines to connect to. In short, Rosebery provides shared storage to clients, just as Asquith does -and therefore provides a secondary, independent storage sub-system for Data Guard clients to make use of.

8. Conclusion

Asquith (and Rosebery) provide a conveniently-built infrastructure in which Standalone, RAC and Data Guard Oracle servers can be constructed with ease. It automates away a lot of the network and storage “magic” that is usually the preserve of the professional Systems Administrator, leaving the would-be Oracle Database Administrator to concentrate on actual databases! By employing ASM as its shared storage technology, Asquith/Rosebery allow the DBA to explore and learn an important aspect of modern Oracle database management.

I’ll be putting up a section of the site for Asquith to match the one that already exists for Salisbury. Until then, the only place for any Asquith documentation (and the only link to download the all-important Asquith ISO) is this article itself.

Sharing with iSCSI

Salisbury shares its storage out amongst its client servers via NFS, the Network File System. It works well, is compatible with RAC and is pretty simple to set up at both the server and client end of things (which is why Salisbury uses it in the first place, of course).

But as someone pointed out to me recently: it’s not very realistic, is it? And he had a point, for my own production RAC at work uses ASM for its shared storage -and I would imagine that would be true for a majority of similar RACs around the globe. So, my critic said, it would be better not to use NFS and instead use ASM.

It’s a reasonable point, though in fact, the two aren’t mutually exclusive: dd a few null-filled files onto an NFS share and you can present them to a client as ASM candidates. But in the realism stakes, that’s probably worse than using just plain NFS in the first place …which is why I’ve never bothered doing it.

No: if you want to use ASM on top of raw devices, you really need something a bit like NFS in the sense that it shares stuff between machines… but it needs to share out devices, not file systems. Which brings me to my topic of the day: iSCSI, for that is indeed exactly what this standard networking protocol does.


The overall name of this sharing protocol is confusing if you’re not used to it: it makes you think SCSI devices have to be involved somehow -and we know they are niche, fast and thus hairily expensive! But don’t let the name fool you: it’s actually just a way of sharing any disk device over the network and works just as well with plain SATA disks as much as anything else. The reason for the “SCSI” bit of the name therefore is not because it uses SCSI disks, but that clients talk to the shared devices using the same commands as they would to a directly-attached, genuine SCSI disk. Or, as the Oracle documentation for iSCSI in Solaris puts it: By carrying SCSI commands over IP networks, the iSCSI protocol enables you to access block devices from across the network as if they were connected to the local system.

Machines which share out their storage are called iSCSI Targets, because they are the targets of the clients’ attentions. Those clients seeking to use the shared storage are called iSCSI Initiators -presumably because they initiate the storage requests.

All of the common operating systems you’re likely to encounter can be both iSCSI targets and initiators, though separate configuration is required for each role. It’s also perfectly possible for a target to be used by initiators which don’t use the same operating system at all -because SCSI commands over TCP is about as OS-agnostic as you can get.

Windows boxes can certainly act as an iSCSI target, for example, but doing this involves downloading stuff from Microsoft and is only supported on server operating systems, which makes it potentially expensive for this kind of article! As I’ve already mentioned, Solaris boxes can easily be iSCSI targets, too -and I look forward to documenting that some day soon. But for now, because it’s easy and dirt-cheap, I’ll use this article to show how to create a basic Linux iSCSI target.

Configuring the Target

Let us say you build a modest CentOS 6.4 server with the following disk partitioning scheme:

Here you see a 10GB hard drive on which has been created a small 150MB /boot partition and a 500MB swap partition. The remaining disk space has been turned into a single large physical volume, with a capacity displayed as being 9577MB. I’ve then created a Volume Group, called “vg1″ within that physical volume, so that vg1 is shown as being 9576MB in size. Finally, I’ve created a single logical volume of 4096MB within that volume group and mapped it to the root (/) mount point.

This means I have 5480MB of unused space within the vg1 volume group that hasn’t been used for anything yet.

I could have achieved the same sort of outcome by creating traditional partitions for root, swap and /boot, but LVMs do the job perfectly well -and are on-line expandable and re-configurable, too. Either way, I have a 5480MB “disk” I want to share out over the network.

Doing so is quite easy. You need to install just one new software package, do a little bit of logical volume management and alter one configuration file. First, the software (as root):

yum -y install scsi-target-utils

Next, we need to create (again as root) a new logical volume to use up that free space I showed you earlier:

lvcreate -L 5480 -n shared_storage vg1

That creates a new logical volume that is 5480MB big inside the vg1 volume group, named “shared_storage” (just as the one shown in the above screenshot is called “LogVol00″). It hasn’t been formatted, though, so at the moment, it’s a ‘raw’ device: a bit like an unformatted logical partition.

Finally, for the bit of configuration file editing, add these lines to the very end of the /etc/tgt/targets.conf file:

<target iqn.2013-08.home.dizwell:testbed.myshare>
       backing-store /dev/vg1/shared_storage

The targets.conf file contains a lot of configuration details that can alter the way iSCSI works, but here we are just adding a new “target stanza” -a discrete piece of code that describes the storage device we wish to share. If I had multiple devices, each would get its own discrete stanza.

The first line of the stanza declares the iSCSI Qualified Name (iqn) of the device to be shared. This is formatted in the way RFC3720, the specification for the iSCSI standard, dictates. That is, it begins with the literal string “iqn”, the year-date, the domain name in reverse order and then, after the colon, the hostname and sharename of the device to be shared. That sharename is the name by which you want the shared device known to the world, and can be pretty much anything you like.

The second stanza line declares what physical storage device is to be shared. In this case, my name is “/dev”, plus the name of the volume group (“vg1″), plus the name of the logical volume I created with the previous lvcreate command (“shared_storage”).

The final line simply closes the stanza. There can be loads more lines included in the stanza than this: lines to restrict the share to certain IP addresses, for example. But I’m keeping things simple for now!

To wrap the iSCSI target up, you now simply need to start the iSCSI processes -and ensure they re-start every time the server is bounced in the future:

chkconfig tgtd on
service tgtd star

And that’s all there is to setting up a (very) basic iSCSI Target.

Configuring the Initiator

As I mentioned before, iSCSI initiators can be run on lots of different operating systems: one is built-in to Windows, for example. In Windows 7, just click Start > Control Panel > System & Security > Administrative Tools > iSCSI Initiator. God knows what you do on Windows 8, but WinKey+”iscsi” turns up the relevant application for me. Good luck!

If it’s the first time you’ve run this program, you’ll be asked if it’s OK to start the relevant service. Say ‘yes’ to that and then you’ll see something like this:

Just type in the IP address of your Target and hit the ‘quick connect’ button. If the firewalls have been opened on both client and server (usually 3260, UDP and TCP), then you’ll soon see this sort of thing:

Notice how the “myshare” public name is displayed: my Windows box knows how to talk a Linux server’s language. Click the Done button there, and close the initiator tool. Now open the Disk Management tool (Control Panel > Create and format hard disk partitions), and the first thing you’ll see is this:

This is already interesting: it’s the sort of thing Windows asks to do when you add a new physical disk to a PC. It tells you that, unlike NFS and Samba, which share file systems, iSCSI is sharing devices -and in such a way that it makes the clients think they have new, native hardware installed. Agree to initialize the disk, and you’ll then see it appear as an unallocated device in the main display:

At this point, you could right-click the drive and select to create a new volume on it, formatting it with NTFS. If you did that, you’d be in the interesting position of having a Linux server hosting and sharing an NTFS partition, which is not the normal order of things at all!

I won’t do that, though. Instead, I’ll now tackle the question of how you’d achieve the same sort of initiator configuration in a small Linux box. Before I leave Windows, though, I would make sure to relaunch the iSCSI initiator tool, highlight the discovered target and click the Disconnect button: I don’t want my Windows box using the device I’m about to get a new Linux client to use.

Assume that my second, small Linux box was installed as a minimal install, but with networking set up so that it can at least ping the iSCSI target I’ve just set up. To get it to act as an iSCSI initiator, you need first to install one piece of new software:

yum -y install iscsi-initiator-utils

Once that’s installed (and still as root), you type this command:

iscsiadm -m discovery -t st -p

The last part of that command is the IP address of my iSCSI target, of course. You should get a message back that mentions the ‘public name’ of the shared device. Here’s a screenshot showing that:

You’ll also see there that I follow up my discovery command by ensuring the various iSCSI initiator services re-start every time this client PC reboots:

chkconfig iscsi on
chkconfig iscsid on

Now that the device has been discovered, we need to actually connect to it:

iscsiadm -m node --targetname iqn.2013-08.home.dizwell:testbed.myshare --login
iscsiadm -m node --targetname iqn.2013-08.home.dizwell:testbed.myshare --logout

The long ‘targetname’ there is just the output that the earlier discovery command caused to be displayed.

At this point, you should have access to the new device, but you won’t know what it’s called by your PC. So, let’s correct that now:

dmesg | grep sd

…and that should yield you output like this:

You’ll see various drive designators mentioned here: sda is the original drive, directly attached to this server. But sdb is now also mentioned -and is the iSCSI-shared device coming from my testbed server. The last line of that screenshot, though, tells you that though the device might be physically housed in my server, it’s now attached via iSCSI magic to this new PC.

That means you can treat it as a local disk drive. First, you’d create a partition:

parted -s /dev/sdb mklabel msdos mkpart p 1 5480

Then you’d format it:

mkfs.ext4 /dev/sdb1

…and although you’re issuing the format command on your little PC, if you keep an eye on your disk drive access lights, it will be the one on the server that flashes a lot as the format proceeds.

Finally, you’d create a mount point for the new drive and mount is as though it were just another local drive:

mkdir /shareddisk
mount -t ext4 /dev/sdb1 /shareddisk

…and at that point, the thing is fully usable:

Of course, you don’t have to format it like that. An unformatted device that’s locally available but is also shared across the network sounds to be just exactly what you need if you want to install things like Oracle’s ASM and RAC. (Which is exactly why I’m writing this article, of course!) But those things are best left for a different article altogether, I think, since this one’s gone on quite long enough!


Mention of my copy of the original 1944 recording of Britten’s Serenade for Tenor, Horn and Strings (see last post) prompted me to search the archives for reviews of it when it was first released. I therefore came across the Gramophone Notes from the December 1945 Spectator archive:

I haven’t chuckled quite so much in a while! Gershwin’s Rhapsody in Blue is “much over-rated”, apparently. And Britten’s Serenade itself is merely “a welcome novelty”. So much for being on the wrong side of history!

But what tickled me the most was the way that the OCR technology used to turn a 65 year-old magazine article into a web page had failed at a crucial moment: the renowned conductor, Sir Adrian Boult, being memorably transfigured into the much sleezier-sounding Sir Adrian Bonk. (You may need to be aware of the apparently peculiarly British English meaning of this word to fully appreciate the reason for my quiet merriment when reading that).

I have provided feedback to the Spectator, so it’s possible that error may be corrected by the time you read this. I can’t help feeling it shouldn’t be, though! In any event, I have preserved my copy of Sir Adrian Bonk’s contribution to gramophone history for posterity’s sake!

Brittenish Art

I am aware that Salisbury documentation for 12c has been promised, along with a series on how to do tape virtualization …and neither have yet to materialize. I blame the pressures of work… and the fact that, my complete works of Benjamin Britten having arrived, I’ve been busy ripping them.

On this occasion, getting the ripping right means, essentially, two things: first, the rip must be as accurate (and lossless) as possible. For me, this has usually meant ripping with something like Exact Audio CD. But, though I’ve been a paid-for customer for years, I’ve only recently just worked out that dbPoweramp also does secure, validated rips, as good as anything EAC is able to do. It also happens to do them in a much less peculiar way than EAC, so that’s the tool I’ve been using this time. Works a treat.

Second, I’ve been making sure to get the CD artwork right, as much as possible. I hadn’t realised that this was an issue before, but the Complete Works CD set comes with a hardback book that includes some 47 pieces of artwork for the original LPs as they were released through the 1950s, 60s and 70s. Not every piece of artwork is present, and they’re printed in such a dark, matte way that they’re not often useful in and of themselves… but they made me realise (or remember) that there was a time when LPs came with expressive artwork that told you something about the contents… and that when CDs came out, they quite often didn’t.

Take just one example. When I re-bought Britten’s Turn of the Screw in about 1989, here’s what the CD box set looked like:

Well, it’s an interesting picture of Benjamin Britten at around the right sort of time (he composed the opera in about 1954) and you at least get to know that the contents are something called “the turn of the screw”, even if you happen to be allergic to the incorrect use of all-lower case. But you certainly wouldn’t know from that lot what a spooky ghost story the opera happens actually to be.

Courtesy of the Complete Works hardback book, I learned that this was actually the LP artwork that was used when the piece was originally issued on Long Play vinyl:

It’s clearly a cover of its time, but at least you get to know who’s singing -and the photographs appear to be from the opera’s first production, which makes them interesting in their own right. You also get to know the opera’s about a ghostly male figure outside a leaded window and looking like he wants to get in; a panicked woman inside and looking like she’s prefer to be out; and an innocent child at prayer is clearly involved in it somewhere along the line. All in all, it’s a far more informative LP cover than we CD-buyers got landed with in the 1980s.

As it happens, when I first bought this LP set (from a music store in Cambridge in about 1983), the thing came with this cover:

Clearly a product of the late sixties, it manages nevertheless still to tell you who’s doing the singing and playing …and that there’s a principle female character, two wild characters somehow related to a spooky country house and two kids standing, literally (and one guesses metaphorically, too), in their shadow… it’s still a hell of a lot more informative than the “modern” CD cover. It’s also more attractive.

As another for-example: Here’s what Billy Budd looked like when Decca bought it out on CD:

So you might figure that it involves a young boy, someone in a flat cap, a guy in a sweater who looks a bit like Benjamin Britten (for it is he) -and the continuing inability to use case properly.

Here’s the LP cover I got when I bought the same piece 30 years ago:

So now it’s a bit clearer that it has something to do with the 18th century, naval vessels, a court martial -and that Glossop, Pears and Langdon and others are singing in it, with the LSO conducted by Britten himself doing the playing. We’re apparently now suffering from a bad case of all upper case, but I nevertheless know which version I find more useful (as well as more visually appealing).

I could go on, but I will spare you the details. The short version is that I’ve spent three weeks or so trying to get hold of the “correct” imagery for each piece contained within the Complete Works set… and it’s sometimes very difficult, if not outright impossible.

Where there are two or more versions (as with the Turn of the Screw covers shown above), I’ve gone with the one I remember being on the LPs I purchased or borrowed from the library all those years ago, even if they happen not to be the truly “original” ones that were used when the LP was released for the very first time. But for some works, there doesn’t appear to be any good, original artwork that I can track down: if you happen to have an original LP of the Sechs Hölderlin Fragmente or the Poets Echo for example, I’d be very grateful for a scanned copy of them. I’ve made do with “something appropriate” from time to time, too: Britten’s version of “God Save the Queen” was never released on LP in the first place (so far as I know)… so I’ve nabbed a photo of the Queen opening the Maltings Concert Hall in 1967, at which it was definitely played. Similarly, I can find no original release of the Welcome Ode in 1977 …so I’ve used a photograph of the Ipswich Corn Exchange, which is where the first performance took place. And so on.

The artwork I used for the 1944 historic recording of the Serenade for Tenor, Horn and Strings is of the first disk of my own copy (as in the thumbnail image that starts this entire blog piece)… one of my more prized possessions, up there with Nixon’s Vice Presidential signature and my Maria Callas signed photo.

As it is, I have ended up with mostly-suitable artwork for everything in the set: to spare me having to do it ever again, and in case there are Britten fans out there who might want to take a shortcut, this zip file contains all the artwork I could ferret out. It’s still not perfect, but it’s better than what I started with …and now that the ripping’s been done to my satisfaction, perhaps it’s time to turn back to Salisbury and tape changers!

Oracle 12c and Salisbury

Version 1.04 of Salisbury is now available. It contains two key enhancements over the previous version: (1) it automatically initialises hard disks, even when they contain no previous partition information; and (2) it works to create standalone, RAC or RAC+Data Guard Oracle Version 12c setups.

I have not updated the Salisbury home page yet, though, to link to the new release (this post is the only place to do so at the moment). That’s because I have yet to update all the associated articles to reflect a bit of syntax-tweaking I’ve had to introduce. Once I do that, I’ll make 1.04 available from the “proper” place.

In the meantime, here’s a quick explanation of that syntax change, brought about because of a silly design flaw I introduced to begin with.

When you’re setting up a Salisbury RAC, you probably and usually want the Oracle software copied across to the first node, but not to the second (because the second node doesn’t need it: it gets the software ‘pushed’ to it during the Oracle installation anyway, from the first, as part of the standard RAC installation process). To accomplish this, I originally had you say ORAVER=1120x on the bootstrap line when building your first node, and ORAVER=NONE when building the second.

Even though you said ORAVER=NONE, I still set up paths and environment variables which are correct for running Oracle 11g …because that was the only version of Oracle then available.

You now see the problem, I hope! Saying ORAVER=NONE certainly tells me you don’t want the Oracle software copied to your new server… but now I don’t know whether I should set paths and variables to expect, eventually, an 11g or 12c installation. The arrival of a new Oracle version creates an ambiguity that using one bootstrap parameter cannot overcome.

The solution was to invent a new bootstrap parameter: FILECOPY=y or FILECOPY=n. It does what it says on the lid: a value of “y” means you do want the Oracle software copied from Salisbury to the new server’s /osource directory. A value of “n” means you don’t. Meanwhile, ORAVER changes meaning ever-so-slightly: it now says what version of Oracle you intend to run, regardless of whether the installation software is to be copied to the new server or not.

In other words, for the first node of a new RAC, you’d say something like:

...oraver=12101 filecopy=y

…and for the second node, you’d say:

...oraver=12101 filecopy=n

This applies to 12c installations and to 11g ones, equally well. Technically, you can still say “ORAVER=NONE”, but this now means you don’t intend to run Oracle at all, so no directories or environment variables associated with running Oracle will be created for you at all. If you’re building 11g RACs using Salisbury, you will need to remember this new need to specify two parameters where one previously sufficed.

Other than that slight change to bootstrap options, everything else remains as it was. In particular, the “speed keys” still work for 12c, just as they did for 11g, so “sk=1″ builds you a node called “alpher” with IP address, “sk=2″ builds you “bethe” on, and so on.

Of course, you will need to upload 12c software to the Salisbury server before you can build subsidiary Salisbury nodes at all: Oracle themselves made a change here by making the Grid Clusterware come in two zip files instead of one.

As before, you are required to change the names of the downloaded files before Salisbury can make use of them. In the case of 12c, you will need to end up with files named:


Under the hood, as I explained in my last post, I’ve had to relax the NFS settings to be “insecure” so that 12c’s propensity to use Direct NFS doesn’t cause the database creation process to blow up. This new setting back-applies to 11g installations, too -not that you’d notice.

As I say, once I get a chance to update the doco linked to the home page, I’ll link to version 1.04 from there, too. In the meantime, this post will be the only place to link to it. Have fun!

Oracle 12c and NFS

Here’s a little something that can trip you up if you’re not expecting it. The standard NFS exports options (the ones used by, for example, Salisbury) expect to handle I/O requests on ports lower than 1024. However, the new Oracle 12c defaults to using Direct NFS -which uses ports above 1024.

The result is that if you are using the Oracle Universal Installer to create a starter database on an NFS mount, by default, the thing will fail with nasty-looking ORA-17500 and ORA-17503 errors (the message text will suggest that it’s not able to open various files).

Happily, the fix is to add the insecure option to the end of your various export options in the /etc/exports file on the NFS server itself. The next release of Salisbury will be doing this automatically. Secure NFS is obviously there for a reason, but when it trips up your laboratory-only 12c RAC installs, “insecuring” it is the kindest option!