Skip to content

Installing Oracle 11gR1 on a Fedora Core 10 64 bit VM

Just a note, to myself more than anything, about what extra packages are required by a 64 bit installation of Fedora Core 10, when trying to install Oracle 11gR1.

The installation I undertook was on a FC10 64 bit VM running under VMWare Server 2.0 running on top of FC10 64 bit OS.

Tim, as usual, has a lovely guide which told me almost everything I needed to know, however the guide says “If you are performing the 64-bit installation, make sure both the 32-bit and 64-bit libraries are installed.” rather than explicitly stating the packages for a 64 bit install. Until I tried to install Oracle 11gR1, I didn’t know what these were. The Oracle installer for 11g soon told me in the pre install checks it does, so I went about installing the following packages, in order:

glibc-2.9-3.i686.rpm
libaio-0.3.107-4.fc10.i386.rpm
libgcc-4.3.2-7.i386.rpm
glibc-devel-2.9-3.i386.rpm
compat-libstdc++-33-3.2.3-64.x86_64.rpm
compat-libstdc++-33-3.2.3-64.i386.rpm
libstdc++-4.3.2-7.i386.rpm

That got me past the pre install checks of the Oracle installer and on to a successful install.

I’ve added the list to the comments on the guide Tim produced as well.

Cursor keys not working in Virtual Server 2 VM

Posted as a reminder to myself about how to fix this issue…

I couldn’t get some of the cursor keys to work properly on my virtual machines running under VMWare Virtual Server 2 on Fedora 10 x86_64. Kept giving funny behaviour like bringing up the screen capture applet!

A bit of searching the net came up with this one, which although not referring to Virtual Server 2 specifically, seems to work all the same…

Essentially, adding the line below to the following file fixes the problem

File (create it, if not already present):

~/.vmware/config

Line:

xkeymap.nokeycodeMap = true

My thanks to “The Monkey Jungle”!

Disable password ageing on Windows 2008 Server Standard

Password ageing in Windows 2008 Server Standard edition (the one I generally use) is set to automatically requre passwords to be changed after 42 days…obviously a Douglas Adams fan responsible for that bit of the codebase!

NOTE – I don’t have access to other version of Windows Server (2003 or 2008) so I can’t speak for them, but I imagine it’s the same on them too.

That’s annoying for home use, where I have tons of VMs for research that I use periodically, so I asked my brother Steve how to stop this happening and he gave me some simple instructions…

First start the Local Security Policy editor by typing secpol.msc in the start/run box..

secpol.msc

and then select Account Policies / Password Policy on the nagivation tree on the left. On the right hand side select Maximum Password Age and set this from the default of “42″ to “0″. You’ll notice it now says “Password will not expire” above the value “0″.

Set Password Ageing off.msc

Seems to have done the trick.

Kinda handy having a brother who’s an MCSE and a VCP too. Useful when I get stuck with OS or VM stuff for my Oracle research!

By the way, if anyone happens to be looking for some skilled contract resource in the Virtualisation field (VMWare, ESX Server etc…) then Steve has just become available…please feel free to contact me, or Steve, via his website

VM articles on my new Wiki

I wanted a place to store notes that I could write up from anywhere…but weren’t necessarily relevant to put in a blog, so I now have a Wiki on my website.

Don’t get excited, I’m not planning on hosting a full blown wiki for open editing – it’s just for me.

Amongst the things on there are some short “How to” articles relating to VMWare.

I’m sure I’ll have made mistakes along the way – feel free to point them out via this blog or email me and I’ll sort them out. Comments welcome as well.

TPC-H Query 20 and optimizer_dynamic_sampling

I was working with Jason Garforth today on creating a TPC-H benchmark script which we can run on our warehouse to initially get a baseline of performance, and then, from time to time, rerun it to ensure things are still running with a comparable performance level.

This activity was on our new warehouse platform of an IBM Power 6 p570 with 8 dual core 4.7GHz processors, 128GB RAM and a 1.6GB/Sec SAN.

Jason created a script to run the QGEN utility to generate the twenty two queries that make up the TPC-H benchmark and also a “run script” to then run those queries against the target schema I had created using some load scripts I talked about previously.

The whole process seemed to be running smoothly with queries running through in a matter of seconds, until query twenty went off the scale and started taking ages. Excluding the 20th query, everything else went through in about three to four minutes, but query twenty was going on for hours, with no sign of completing.

We grabbed the actual execution plan and noticed that all the tables involved had no stats gathered. In such circumstances, Oracle (10.2.0.4 in this instance) uses dynamic sampling to take a quick sample of the table in order to come up with an optimal plan for each query executed.

The database was running with the default value of 2 for optimizer_dynamic_sampling.

After reading the TPC-H specification, it doesn’t say that stats should or should not be gathered, but obviously in gathering them, there would be a cost to doing so and, depending on the method of gathering and the volume of the database, the cost could be considerable. It would be interesting to hear from someone who actually runs audited TPC-H benchmarks to know whether they gather table stats or whether they use dynamic sampling…

We decided we would gather the stats, just to see if the plan changed and the query executed any faster…it did, on both counts, with the query finishing very quickly, inline with the other twenty one queries in the suite.

So, our options then appeared to include, amongst other things:

  1. Gather the table stats. We’d proved this worked.
  2. Change the optimizer_dynamic_sampling level to a higher value and see if it made a difference.
  3. Manually, work out why the plan for the query was wrong, by analysis of the individual plan steps in further detail and then use hints or profiles to force the optimizer to “do the right thing”.

We decided to read a Full Disclosure report of a TPC-H benchmark for a similar system to see what they did. The FDR included a full listing of the init.ora of the database in that test. The listing showed that the system in question had set optimizer_dyamic_sampling to 3 instead of the default 2…we decided to try that approach and it worked perfectly.

In the end, given we’re not producing actual audited benchmarks then we’re free to wait for the gathering of optimizer stats, so we’ll go with that method, but it was interesting to see that option 2 above worked as well and illustrates the point that there is a lot of useful information to be gleaned from reading the FDRs of audited benchmarks – whilst, of course, being careful to read them with a pinch of salt, since they are not trying to run your system.

Another thing of interest was that in order to get the DBGEN utility to work on AIX 6.1 using the gcc compiler, we had to set an environment variable as follows otherwise we got an error when running DBGEN (also applies to QGEN too):

Set this:

export LDR_CNTRL=MAXDATA=0×80000000@LARGE_PAGE_DATA=Y

otherwise you may get this:

exec(): 0509-036 Cannot load program dbgen because of the following errors:
0509-026 System error: There is not enough memory available now.

Fedora 9 on Hyper V on Windows 2008 Server x64 – Firefox IPv6 DNS issue

I’ve been playing with Hyper V this week and came across an issue with Firefox, whereby I thought that the networking setup for Fedora 9 on a Hyper V virtual machine wasn’t working.

The environment is Windows 2008 Server on x64 with the RTM release of Hyper V. I then created a VM and installed Fedora 9 x64 from a DVD ISO – it took a while as I started with a multiple CPU, standard network adapter approach and it kept crashing during the install; when I changed to single CPU and “Legacy” network adapter it installed cleanly – given that Fedora isn’t a “supported” Hyper V OS I can’t really complain.

The problem I then came to was that it appeared that DNS wasn’t working, i.e. in Firefox, if I stuck in a URL, it came back with an error rather than showing the page. I then proceeded to go off on a wild goose chase checking all the Fedora networking setup and reading about Hyper V and it’s “synthetic” network adapter approach, but still couldn’t solve it. Everything seemed to be installed and configured exactly as everybody who had written about it had said…so it should be working right?

It was…but the problem is that Firefox was trying to resolve the name of the URL using IPv6 rather than IPv4…and my network was configured without an IPv6 DNS – I don’t need IPv6 and I’m perfectly happy with IPv4 so that’s what I use. I only discovered this by chance as I wondered whether it might be a Firefox issue (everything else ruled out kinda thinking), so I used the Konqueror web browser to see if it had the same issue and hey presto it was working fine whilst Firefox wasn’t.

How to fix Firefox? Well, basically as indicated in this post on the OpenSUSE website – essentially, you go to the URL “about:config” in Firefox, filter for “network.disable.IPv6″ and set it to TRUE instead of FALSE (double click it to change the value). Then it all works fine.

OS trials and tribulations

I got tired of my apps not working on 64 bit Vista so I figured I’d bin the dual boot Vista 64 and Enterprise Linux 5 and just go Linux. EL5 wasn’t up to date (kernel wise) and I was unable to easily bring it up to date, without paying Oracle a licence fee, so I figured I’d just used Fedora 9 instead.

Then I saw this from Tim on ESX and I figured that sounded like a good idea…so I spent some time trying to get that working…only to realise that ESX needs SCSI for the disks (or one of the very specific SATA interfaces – that I don’t have)…so that idea also ground to a halt. ESXi, being more restrictive than ESX on hardware compatability, didn’t even install, whilst ESX managed to install after a bit of effort, but I couldn’t create any VMFS filesystems – that’s when I RTFM’d that it was not going to work without SCSI – even after much surfing travels.

I do hope that they get ESX to work with more SATA (i.e. mine) so I can use it…seemed like a good idea for my home research requirements. Never mind, will have to manage with Fedora 9 for now.

I’ve got Fedora 9 installed now and it was reasonably painless, except that the networking wasn’t working when it booted up – no access to the internet. After a bit of surfing, I found the website of Mauriat Miranda, who seems to have some great stuff, including an installation guide for Fedora 9, which covers the fix to my networking issue.

Big thanks to Mauriat there.

Scripts for loading up DBGEN TPC-H data

If you’re interested in creating a TPC-H schema for testing purposes, then the following scripts may be of use to you:

Unix Scripts:
Multi Load TPCH
Load TPCH Stream

SQL*Loader Control files:
REGION Table
NATION Table
SUPPLIER Table
CUSTOMER Table
PART Table
PARTSUPP Table
ORDERS Table
LINEITEM Table

You may wish to read and check them before you use them – they’re not exactly rocket science but they seem to do the job.

I have all the files in the same directory for simplicity sake.

I then use them to create a scale factor 1 target TPC-H schema using the following calls:

# “l” loads the REGION and NATION tables
./multi_load_tpch.sh 1 l “tpch/tpch@test” 1

# “s” loads the SUPPLIER table
./multi_load_tpch.sh 1 s “tpch/tpch@test” 10

# “c” loads the CUSTOMER table
./multi_load_tpch.sh 1 c “tpch/tpch@test” 10

# “p” loads the PART and PARTSUPP tables
./multi_load_tpch.sh 1 p “tpch/tpch@test” 10

# “o” loads the ORDERS and LINEITEM tables
./multi_load_tpch.sh 1 o “tpch/tpch@test” 10

Obviously, you need to change the connection string to match your environment.

Caveats:

  1. Obviously, they are supplied as is – use at your own discretion and risk.
  2. You need to have created the target schema tables and made sure they are empty as the SQL*Loader control files use APPEND.
  3. Bear in mind that choosing too high a number of parallel streams (the last parameter in the calls) will overload your machine so try and balance it against the available system resources.

Bugs, issues or questions, please get in touch…enjoy.

Creating a TPC-H schema with DBGEN on HP-UX

I wanted to try out this HammerOra product from Steve Shaw, both at work and on my box at home…but after playing with it at home, I realised that it takes quite some time to build even a small (scale factor 1) TPC-H schema…I know it runs serially, but I’m still not quite sure why it’s that slow (on my system that is), but Steve does say it can take a while and that you might wish to consider using the TPC utility DBGEN to generate and load the schema quicker…particularly if you use some manual parallelisation.

Given that I also need to use this tool to help with some benchmarking at work, I decided to try to get DBGEN to run on a HP-UX box today and had one or two problems which I managed to sort out. The machine in question is an RP8420 running HP-UX B.11.11.

DBGEN is a utility that allows you to create a series of flat files which contain the data for a TPC-H schema. You can then use SQL*Loader to load these into appropriately constructed tables in an Oracle database – any database actually…but I only care about Oracle of course ;-)

The utility can be called with various parameters including making the target datasets in smaller “child” files which can be created in a manually parallelised fashion to speed the whole process up. You have to download the DBGEN reference data set from the TPC website (lower right hand side).

This reference data set contains the ANSI C source code which makes the DBGEN executable (and QGEN also…but more on that another day)…unfortunately it’s just the source code, so that means you need to compile it yourself…which of course leads to the first problem…that I know diddly squat about C…yeah I know, not very manly! Luckily I can sometimes follow instructions (which come with the reference data set)…

1. Copy makefile.suite to makefile
2. Edit makefile and make the following amendments (in red):

################
## CHANGE NAME OF ANSI COMPILER HERE
################
CC = gcc
# Current values for DATABASE are: INFORMIX, DB2, TDAT (Teradata)
# SQLSERVER, SYBASE
# Current values for MACHINE are: ATT, DOS, HP, IBM, ICL, MVS,
# SGI, SUN, U2200, VMS, LINUX, WIN32
# Current values for WORKLOAD are: TPCH
DATABASE= ORACLE
MACHINE = HP
WORKLOAD = TPCH

That’s it for the makefile.

Now, as I mentioned, the ORACLE database is not a listed database variant in the DBGEN C code – it’s got all the other popular RDBMS which I find quite bizarre…I’m sure there’s a reason, but I can’t think of one. To get around this, as per Chapter 5 in “Pro Oracle Database 10g RAC on Linux” by Steve Shaw and Julian Dyke, I added a section to the tpcd.h for the ORACLE database:

#ifdef ORACLE
#define GEN_QUERY_PLAN “”
#define START_TRAN “”
#define END_TRAN “”
#define SET_OUTPUT “”
#define SET_ROWCOUNT “”
#define SET_DBASE “”
#endif

I thought that was it – but it still would’t compile, giving the error:

config.h:213:2: #error Support for a 64-bit datatype is required in this release

Looking at the config.h – and bearing in mind I’m no C programmer – it struck me as odd that all bar the HP machine section, had stuff about DSS_HUGE and 64 bits…so I took a punt and copied some lines (in red) from the IBM section into the HP one to see if it worked…and it did. The HP section now looks like this:

#ifdef HP
#define _INCLUDE_POSIX_SOURCE
#define STDLIB_HAS_GETOPT
#define DSS_HUGE long long
#define HUGE_FORMAT “%lld”
#define HUGE_DATE_FORMAT “%02lld”
#define RNG_A 6364136223846793005ull
#define RNG_C 1ull
#endif /* HP */

Typing make at the command prompt then compiles the code and produces the dbgen executable…which I then spent a few hours playing with to create a scale factor 1 TPC-H set of files.

My next problem was one of my own making really in that I copied the CREATE TABLE statements for the TPC-H target tables from HammerOra’ TCL script for TPC-H creation, but unfortunately, the column ordering is slightly different in those DDL statements as compared to the DBGEN output files…which meant that I created the tables OK, but since I’d copied the column ordering to make the SQL*Loader control files, I got errors when I tried to load some of the files as the column order is different in one or two cases.

I then downloaded the TPC-H specification document which has, amongst other things, the data model, from which I cross checked the column ordering of the data model against the columns in the output files and then managed to rerun the data in without any further issues.

Tomorrow I’ll try running HammerOra against the target TPC-H schema and make some shell scripts to try and automate most of the process so we can build different scale factor schemae and do so in a manually parallelised fashion – scripts the amiable Scotsman created for his parallel testing a while back should give me a good start with that.

PC for manly men?

So, after suffering a hard disk failure, I figured it was time to buy a new PC for (Oracle) research purposes and the choice seemed to boil down to:

  1. Buy a Dell or HP high end PC from their website and pay serious money for it.
  2. Pick a proper server off Ebay – cheaper but may have pitfalls including warranty, dodgy sellers and delivery. (it was interesting to look for E10K Sun boxes on there)
  3. Spec a PC myself and get a box shifter to build and ship it.
  4. Upgrade my current PC with a selection of new bits.

I chose #3 and bought it from a company call Scan. I’m pretty happy with the result and the service I received although due to some DOA parts it took a little longer than I’d hoped…at least they had the problems to deal with instead of me!

#1 is expensive and you’re sort of limited to the options they offer. I costed up something similar to what I’ve ended up buying and it was nearer 3,000 pounds rather than the 1800 ish that I paid.

#2 is cheaper than #1 but these type of machines are really noisy, albeit solid pieces of kit and more akin to what I’d work on during my day job.

#4 and #3 are similar except for who gets the grief of making all the new bits work together, and every time I try to build things myself I get grief with it (usually parts arriving DOA or incompatible with each other). Scan had to deal with a DOA motherboard and CPU amongst other things…rather them than me.

So, #3 it was…and it arrived a few days ago.

Specification is:

Pictures (Click on them for bigger images) below:

bigbox_closed_800x600.jpg

bigbox_open_800x600.jpg

Not quite an “enterprise server” and I’m sure it pales into insignificance against any of the kit Kevin uses, but pretty quick.

I’ve configured it for dual boot of Vista 64 Ultimate and Oracle Enterprise Linux 5 (using EasyBCD) and I’m about to start doing some installations and benchmarking…should be fun.

I installed VirtualBox on the Vista 64 OS and it’s working very nicely…well, it’s set up and working…we’ll find out how nicely it’s working when I install Oracle and HammerOra and give it a bit of a kicking!

Who knows, I might even find time to blog about it!