In doing so, you get to experience the two-stage nature of a complex Oracle installation (that is, having to install the Grid Infrastructure before you install the software). You also get to experience how you manage an Oracle server where different parts of the software mix are owned by different users. Obviously, too, you get to learn how to work with -and manage successfully- the ASM stack that Alpher uses as its database storage technology. In short: standalone Alpher is a worthy learning exercise in its own right!
2.0 Hardware Configuration
Alpher needs to be a relatively heavyweight virtual machine, with at least 2 CPUs, one network card, one DVD, 5 GB RAM and a 40 GB virtual disk. The disk space requirements are relatively modest -because the database you build will actually end up consuming space on the Churchill server. Nevertheless, think of 40 GB as a usable minimum: if you can allocate more, it makes things like patching and upgrading a lot simpler.
In VirtualBox, my standalone Alpher looks as follows:
Note how the VM has 2 CPUs, 5120MB of base memory, a single ‘optical drive’ into which a RHCSL ISO (in this case, CentOS 6.8) has been ‘inserted’, and a 40GB virtual hard drive. At the bottom of the screen, you can see how I’ve provisioned this VM with a single, host-only network device. That’s important to remember to do because VirtualBox always provisions its VMs with NAT devices by default -and those won’t be able to contact Churchill properly. So, once you’ve built your basic VM, make sure to click into its settings and alter the networking tab:
The “vboxnet0” interface should be available to you to select, once you pick ‘host-only adapter’ as the type of networking: you created it before you built your Churchill server.
In VMware, you similarly build a 2-CPU, 5GB RAM, 40GB hard disk machine using host-only networking so that it ends up looking like this:
In any event, once you’ve built your new Alpher server, you also need to make sure that Churchill itself is running in the background (and that you can reach it with a “ping” from your physical PC).
Remember, too, that if you built Churchill with CentOS, so now Alpher has to be configured to boot from a suitable CentOS boot medium. If you built Churchill with Scientific Linux, Alpher similarly must be an SL machine… and so on. The O/S Churchill uses defines the O/S that the entire Churchill framework must use.
The big difference now, though, is that Alpher can be booted from the netinstall disk of your chosen distro. That’s a relatively small (~200MB) ISO, rather than the full-on 4GB one that Churchill had to use. The reason is simple: Churchill has all the software needed to build a complete RHCSL box; all we need to boot Alpher with is enough O/S to get a network connection to Churchill!
That said, you can choose to boot Alpher with the full distro ISO (the one you used to build Churchill) if it makes it simpler for you. Alpher will still end up pulling most of its software from Churchill rather than off that full ISO, but it will nevertheless work fine.
3.0 Booting Alpher
When you are ready (and with Churchill running in the background), boot your new Alpher server. You’ll first see something resembling this boot menu screen:
The specific menu screen you see will depend on your choice of RHCSL distro: if you’re using OEL, for example, your eyes will be bleeding right about now as you deal with the pulsating red mess that is Oracle’s choice of boot menu colour scheme:
But blue or red, you want to make sure you are sitting on the ‘Install or upgrade an existing system‘ menu option… and then press <TAB>. This will reveal a “bootstrap” line:
On to the end of its existing contents, you’re now going to type the command which will tell this new server to build itself using an auto-configuration that can be found and fetched from the Churchill server.
The basic form of this new bootstrap command will be:
That is, use Churchill as a web server to ‘feed’ the new VM the contents of ks.php as a Kickstart file, filtered by the fact that we are using “speed key 1”. Speed key 1 is what we use to define “Alpher”, the first of the Churchill framework servers. We are also making the point that this Alpher is going to be a non-RAC server (i.e., not part of a cluster, just a standalone server). Note that everything you type on the bootstrap line must be in lower case.
If “sk=1” bothers you as a bit “code-y”, you can modify the bootstrap line to mention Alpher by name:
(You can use upper or lower case for the variable values, as you please; Churchill lower-cases everything internally anyway).
So one or other of those bootstrap variants is your starting point. If you are booting with CentOS 6.8 (and Churchill was built with CentOS 6.8), it’s also your ending point, because then the default O/S Churchill expects will match what you’re actually using. But if you are using another distro or version, you must specify that now. You do so by bolting on suitable “distro=X&version=Y” parameters. For example:
And so on.
Basically, you can choose from centos, sl, oel and rhel as possible distros, and anything from 6.3 to 6.9 as possible versions, stripped of their decimal points (so 6.5 becomes 65 and so on).
You can also choose one other characteristic of this framework build: are you going to use the ‘split ownership’ model for the various bits of Oracle software? Or are you instead going to use the ‘unitary ownership’ model? The difference is that in split ownership, someone called “grid” owns the Grid Infrastructure install, whilst someone called “oracle” owns the Oracle database software install. In unitary ownership, someone called “oracle” owns everything.
Practically, your choice of ownership model makes quite a difference: if you want to add a new ASM disk or perform some ASM re-balancing, you’d first have to remember to log on as ‘grid’ instead of ‘oracle’ in the split model, for example. If you were to try patching things in the split ownership environment, you’d find you would fail if you were trying to do it whilst sitting in the /home/oracle directory -because user ‘grid’ has no rights there. Little niggles like that make split ownership a bit more challenging to work with -but it also happens to be the way most production environments in my experience are created, so to that extent it’s the more ‘realistic’ way of doing things.
By default, the Churchill framework assumes that you will operate in split ownership mode. That is, the bootstrap parameter split defaults to a value of y. If you don’t want split ownership, therefore, you must say so by adding an additional &split=n onto your bootstrap line, somewhere. For example:
The ordering of the parameters is not important. You could successfully boot with this, for example:
When you type your decided-upon bootstrap line, it may be long enough to wrap unpleasantly onto the next line of the screen:
It doesn’t matter if it wraps: just keep typing and do it without adding any spaces. Your bootstrap line must be continuous and syntactically correct, but any wrapping that takes place won’t affect those qualities.
The Churchill framework uses Kickstart technology to automate the building of servers. Getting this bootstrap line right determines whether Kickstart can do its job properly or not. So mastering the bootstrap line is a vital Churchill skill!
4.0 Building Alpher
Once you’ve worked out what you’re going to type on your bootstrap line, type it continuously and carefully and then press [Enter] to begin the entire server construction process. Here’s me kicking off a CentOS 6.8 Alpher build:
Since I’m booting with CentOS 6.8, I don’t need to specify distro and version, because those are the assumed defaults anyway. Similarly, I am happy with split ownership, so I’ve not added a ‘split=n’ parameter. So my bootstrap line is nice and short -and all I need do now is press [Enter]… and sit back and relax. Everything from this point on is automated for you.
You’ll see files being copied:
Once that part of the process is finished, you’ll see this message appear:
That will display for quite a few minutes because now all the Oracle software you previously loaded onto Churchill gets copied across to Alpher and unpacked (in a directory called /osource). There’s no progress bar to tell you how far things have got, though, so just be patient. Eventually, you’ll see this:
Press [Enter] at that point and your new server will reboot and (assuming your boot media still isn’t in the CD drive -eject it if so!) come back up in fully-working order:
I say, ‘fully working order’; but from that screenshot you can tell immediately that we’re talking ‘minimalist, non-GUI, working order’! Alpher is a command-line only environment, in other words. That presents us with a problem which we’ll solve shortly.
For now, take a moment to log on as root (password oracle) and get familiar with your new server. In particular, check its IP address (ip addr), check its hostname (cat /etc/hosts and hostname) and check out the contents of the /osource and /u01/app/oradata directories: the one contains the Oracle software you’re about to install, the other files which represent the disks you are going to layer ASM onto and thus convert into database storage disks.
5.0 Remotely Connecting to Alpher with X
You now need to switch away from Alpher, letting it (and Churchill) tick along quietly in the background.
Your focus instead changes to the physical PC on which you’re running Churchill and Alpher and, in particular, on how you get it to make a remote connection to Alpher with X-capabilities. That is, although Alpher itself is command-line only and has no ability to display graphical applications (like the Oracle Universal Installer), it is able to use the X graphics stack over a network link and run graphical applications whilst drawing their output onto our physical desktop.
I wrote an entire article about doing ‘remote X’ years ago, which you might want to read to give you some background.
The short version is this, however: if your physical PC is running Windows, you’ll be able to connect to Alpher using something like Cygwin or (much more simply) MobaXterm. If your physical PC is running Linux, things are even simpler, because you can just ssh to Alpher using the “-X” switch and immediately get X forwarding capabilities.
5.1 Using Windows
Let’s assume you’re running Windows 10 as your physical machine’s operating system (though things work pretty much identically in Windows 7 or even XP).
In that case, I’d recommend you visit the MobaXterm website and download the installer-edition of their Home version of MobaXterm (which is free for personal use in a non-corporate environment). Install it as you would any other Windows application (i.e., double-click the installer MSI file and follow the prompts). When you are ready, launch the application.
When you do so for the first time, you should get a firewall warning:
Allow the application to communicate via the private network. Then click the Start local terminal button that will be displayed:
Now I connect to the Alpher server as the user grid (because I let the split-ownership model happen by default. If you were doing split=n, then the only user account you could use at this point would be “oracle”). Supply the password oracle when prompted (all Churchill framework passwords are ‘oracle’ by default). Note how I’ve added a “-X” parameter in the connection string: it is this which permits ‘X forwarding’, and thus lets graphical apps paint their screens on my desktop even though they are running on Alpher.
The first time you make this sort of connection, you’ll probably see this:
I let the application store the Grid user’s password -and I also select to not be prompted about this again in the future. Whether you choose similarly is up to you, of course.
Anyway: you should now be connected to Alpher and launch a graphical application to make sure everything works OK:
Here, I’ve typed the command xclock and, obligingly, the Xclock application is then displayed on my Windows desktop. You may find that it pops under to start with: keep an eye on the taskbar to see if any new icons get created and bring the associated application to the front if so.
So here we have xclock running on Alpher, but displaying its output on my Windows PC. If xclock can do that, then so can anything else… including Oracle’s installer.
Note that an error message appears in the MobaXterm display at this point, too: Warning: Missing charsets in String to FontSet conversion. Don’t worry about it: it doesn’t affect functionality in any way and is perfectly normal. If it really bothers you, though, you can make it go away:
The export LC_ALL=C command sets a locale (over-riding the correct ones set throughout the system normally) in which the character set used is just plain ASCII instead of the usual UTF-8. As a simple, single-byte characterset, the X applications have no problem with untranslatable font output, so the error disappears. But I really wouldn’t worry about the error in the first place and I wouldn’t go around changing system locales to make it disappear.
5.2 USINg linux
If your physical PC’s operating system is any flavour of Linux at all, you probably already have what’s required to make a connection to Alpher: the ssh client. Chances are, that gets installed by default -but if not, just use your standard package manager to install it. For example, sudo dnf -y install openssh-clients would do the job on Fedora.
Once you have a client installed, you simply connect in a terminal session exactly as shown previously for MobaXterm on Windows: ssh -X username@remote-ip-address. Here’s me using my Fedora 25 laptop, for example:
The first time you make a connection in this way, a bunch of ‘RSA fingerprint’ messages are displayed as you can see above; you then get asked whether you wish to continue. Just type ‘yes’ to do so and then supply the grid user’s password (oracle) when prompted.
As on Windows, once you are connected, you can type any command that Alpher can execute and have the output painted onto your desktop:
Also as you saw earlier with Windows, the complaint about the FontSet conversion will appear -but can equally well be ignored.
6.0 Installing Grid Infrastructure
Once you have established a connection to Alpher from your desktop as the grid user (whether that’s actually a username of grid or oracle depends on whether you accepted the split- or unitary-ownership model, as previously explained), you are ready to perform the first of the two Oracle software installations.
This first install is of the Grid Infrastructure, which is the bit of software which provides us with clusterware (if we’re building a cluster, which we’re not) and with ASM capabilities (which we definitely do need now!)
All the software has already been placed on Alpher for you by the automated build process we saw back in Section 4 above. All you have to do, therefore, is invoke it as follows:
Alpher and your desktop will respond accordingly:
You’ll get some messages displayed as Oracle checks that your system can display its wares, then you’ll see the first screen of the Grid Infrastructure installation wizard appear. For the most part, your job is now to click [Next] quite a lot of times!
Here’s a walk-through of the complete wizard:
At the end of the installation, it might not be obvious that anything particularly has happened on Alpher. But if you look carefully, you will see that a lot has happened:
That’s me typing a “ps -ef | grep pmon” command immediately after the installation has finished. It returns a row which shows that a process called “asm_pmon_+ASM” is running: this is one of the many background processes which Oracle uses to manage its physical storage. The fact that it exists tells you that an ASM instance exists -which you can connect to:
Here, I’m connecting “as sysasm”, who is the god-like administrator of any ASM instance. The show sga command displays the number of bytes of memory your new ASM instance is consuming: as these things go, it’s relatively svelte at just 1.1GB (but you start to see why we needed to build Alpher with at least 5GB of memory!)
You can begin to play around in this ASM instance -for example, query V$ASM_DISK to see what physical disks make up the storage which the ASM instance is managing for you. You should see 8 disks listed, though only 5 of them will be listed as “MEMBERS”, whilst the others are listed merely as “CANDIDATES”:
SQL> set lines 192 SQL> set pages 4000 SQL> col path format a50 SQL> select path, header_status from v$asm_disk; PATH HEADER_STATU -------------------------------------------------- ------------ /u01/app/oradata/disk8 CANDIDATE /u01/app/oradata/disk7 CANDIDATE /u01/app/oradata/disk6 CANDIDATE /u01/app/oradata/disk5 MEMBER /u01/app/oradata/disk2 MEMBER /u01/app/oradata/disk4 MEMBER /u01/app/oradata/disk3 MEMBER /u01/app/oradata/disk1 MEMBER 8 rows selected.
There’s obviously a lot more to be done with ASM instances than this, but you can get to that later. For now, it’s enough to know that one exists, that it’s presenting some hard disks as suitable database storage… and that it’s ready to be used.
All that is required to do that is to install the database software …and create a database!
7.0 Installing Database Software
On your physical PC, you now need to log on to Alpher as the oracle user. In split-ownership systems, that will mean logging off as ‘grid’ and making a new connection to Alpher as the user ‘oracle’. In unitary-ownership systems, you can stay logged on as ‘oracle’:
grid@alpher:~ [+ASM]$ logout Connection to 192.168.8.101 closed. [hjr@purcell ~]$ [hjr@purcell ~]$ ssh -X firstname.lastname@example.org email@example.com's password: /usr/bin/xauth: file /home/oracle/.Xauthority does not exist oracle@alpher:~ [orcl]$
Note the use of the ‘-X’ flag when connecting: you’re going to need X forwarding working once more!
As the oracle user, therefore, you launch the database software installation with the command:
After thinking about it for a bit and flashing up an Oracle logo, you should be met with this:
Once again, the Oracle installation wizard is mostly a game of clicking [Next], but here’s a walk-through of the entire process:
Once the installation has completed successfully, it’s time to explore what has happened in consequence. For starters, whilst connected to Alpher, type this command:
ps -ef | grep pmon
You should see this sort of output:
oracle@alpher:~ [orcl]$ ps -ef | grep pmon grid 19902 1 0 11:15 ? 00:00:00 asm_pmon_+ASM oracle 27853 1 0 12:09 ? 00:00:00 ora_pmon_orcl oracle 29093 29064 0 13:56 pts/1 00:00:00 grep pmon
That shows you that there are now two PMON processes running on that box: one associated with the +ASM instance as before …and now a second, associated with an instance called “orcl”, which is your new 12c database.
We can connect to that database and execute a query like so:
Notice how I type the command sql? That’s actually just an alias of the proper command ‘sqlplus / as sysdba’. The alias version, however, has command-line history. That is, once you’ve issued a command inside SQL*Plus, you can hit the up-arrow key to recall it. And once you have lots of commands in the history, you can up- and down-arrow through them as you like. The ‘real’ command is without a command line history, which is sometimes required (because -very occasionally- SQL*Plus can get upset when wrapped inside a command-line history tool, so you need the option not to do that).
The other thing to notice about this query is: what a mess it is! The output is wrapped across the screen onto multiple lines, making it difficult to read -and, worse, the column headings keep being displayed every few lines!
There is a fix for this, provided by Churchill. As the oracle user, at the O/S command prompt, just type this command:
Now, re-launch SQL*Plus and try that earlier query again:
See how this time, the lines don’t wrap and the column headings don’t keep appearing? That’s because the script you just ran added lines to the $ORACLE_HOME/sqlplus/admin/glogin.sql file, to make page lengths and line sizes long.
It’s entirely optional whether you run this ‘churchill-postinstall.sh’ script or not, but I always do because I think the SQL*Plus defaults are a bit stupid!
Anyway: the point here is that you’ve got a database with data in it, and you’re querying it, successfully. From your ealier work, too, you know that the database is stored on ASM disks provided by the +ASM instance:
SQL> select distinct name from v$datafile; NAME -------------------------------------------------- +DATA/ORCL/DATAFILE/sysaux.257.935237161 +DATA/ORCL/DATAFILE/undotbs1.260.935237263 +DATA/ORCL/DATAFILE/system.258.935237207 +DATA/ORCL/DATAFILE/users.259.935237263
…and the “+DATA” at the start of each file path there tells you that this is no ordinary file system, but what happens when Oracle is running on ASM.
The SQL*Plus command line is really all the administration interface you need… but some people prefer to run things in a GUI. Oracle provides one -and even told you about it in that last pop-up you saw during installation:
The tool is called Database Express. Take a note of the URL highlighted in that pop-up and visit it in a browser such as Google Chrome or Firefox from your physical desktop PC:
As it happens, because my physical PC doesn’t know how to resolve the hostname ‘alpher’, I’ve resolved it for it and typed in a URL that makes mention of Alpher’s specific IP address (192.168.8.1010). Note that it’s an https address, not just an ordinary http one.
No matter either way, though: as you can tell from that screenshot, browsers don’t trust Oracle’s tendency to self-sign its web security certificates, so Firefox (on this occasion) doesn’t think the URL is very secure. As Oracle experts, we know better however! So click that ‘Advanced’ option:
…and then click on the ‘Add Exception’ link. We know it’s safe, even if Firefox doesn’t.
To confirm you know what you’re doing, you have to ‘get the certificate’ and then click the [Confirm Security Exception] button. It’s a good idea to make this a permanent exception, too. As soon as the exception is confirmed, the browser will start to load the DBExpress application:
Er. Um. Unfortunately, Database Express is built on Flash technology (for which design decision the relevant party at Oracle Corporation should be shot) and therefore you need to install the flash plugin for your browser and try again. I’d recommend using a dedicated VM for this if you can manage it -because in this day and age, running Flash in a serious environment is bonkers. You may just as well invite VirusWriters Anonymous for breakfast and the CIA for tea.
Installing Flash is done in different ways in different environments and is not something I can properly document here. I’ll just say that to install it on my Fedora desktop PC, I first visited Adobe and downloaded the tar.gz version of their software; I unarchived the download; inside the directory created there’s a file called libflashplayer.so. As root, I then issued the commands:
mkdir -p /usr/lib64/firefox/browser/plugins/ cp /home/hjr/Downloads/libflashplayer.so /usr/lib64/firefox/browser/plugins
I then closed Firefox and re-launched it, visiting the original Database Express URL once more:
This time: success! You now just log onto your new database. As you can see, I’m logging on as the SYS user and switching on the ‘as sysdba’ option (which is compulsory for any connection as SYS).
Finally, you’ll be rewarded with this rather handy overview of what your new database and the VM it’s installed on is up to:
There is a lot in DB Express to like (once you finally master the Flash business and the security certificate exception!): this article is already long enough, so here is not the place to take you on an exhaustive tour of it.
All I can do is point you at the menu options along the top of the screen: Configuration lets you configure the database’s memory and initialization parameter values. Storage lets you create and resize tablespaces. Security lets you create new users or drop existing ones, change their passwords and alter their privilege profile. Perhaps the most useful menu of all, however, is the Performance one, which really gives you insight on what is running inside the database and how it could be tuned to run better:
There is a lot to explore, in other words. All I can do now is encourage you to do so!
Don’t, however, forget good old SQL*Plus, with which you administer the ASM instance as well as the database one! Make friends with the asmcmd tool (run as the grid user in a split-ownership environment) when you want to play around in ASM, too.
In this article, I’ve shown you how to build a new server using automated Kickstart technology which leverages the fact that Churchill exists and is running in the background. With essentially one quick command (“sk=1&rac=n”) specified at boot-up time, all the correct bits and pieces are seamlessly stitched together to create a new server called Alpher that can work successfully as an ASM-based Oracle server.
I’ve shown you how to perform a Grid Infrastructure install, and then a Database software install.
And I finished off by showing you how you can use various command-line and web-based tools to interact with your new database and begin to manage it.
For the rest, it’s down to you: you have a database and the tools to administer it. Using SQL*Plus, ASMCMD, Database Express and similar tools, you can now learn for yourself how to interact with and administer an ASM-based standalone Oracle database. Good luck playing around with your new infrastructure!