Old Books, Russian Hip-Hop, and Database Imports

The value of learning about lots of different topics really comes to the fore when you spot a connection, however tenuous, between things that on the surface have no bearing on each other at all.

I recently picked up a copy of the first Joel on Software book having read the second book in the series and once been a fan of the blog, it seemed only right to revisit the insights into software development that Joel Spolsky shared with the world in the early 2000’s. In the fast paced world of technology the interest in this material, dating as it does from a pre-Agile and pre-Cloud age, is in considering what foundational and unchanging lessons are worth a refresher on as well as considering how things have changed since that time. The biggest surprise so far has been somewhat foundational as the chapter on character sets (The Absolute Minimum Every Software Developer Absolutely, Positively, Must Know About Unicode and Character Sets (No Excuses!)) has really made me reconsider a topic I felt I was pretty familiar with already.

So, this is the “old” book, but what’s that got to do with Russian hip-hop?

I’ve discussed my love of German industrial metal music in the past (in this post), safe in the knowledge that like many fans of the genre around the world, my inability to speak German has little to do with my enjoyment of the music and can in many ways heighten it through the air of mystery that surrounds the unknown. This mindset has proven useful in building an appreciation for other international music (Swedish Melodic Death Metal, obviously, but also French rock/metal, but that’s another story), and into this open-mind dropped some Russian hip-hop.

While watching a very dodgy Russian action movie late one night, I was rather taken with the track that played over the end credits, in that “I don’t understand the lyrics, but I love the tune” way familiar to Rammstein fans. However, not wanting to get caught out humming along to something grossly inappropriate, I decided to check out the lyrics on iTunes and found myself a most wonderful surprise in how they were presented in Russian Cyrillic, something I thought particularly cool as I still had thoughts of character sets dancing through my head along with a new found appreciation of how hard this type of thing can be to deliver. (I don’t know if there’s an official video anywhere, but check out this link to the tune that caught my attention: https://youtu.be/7yW0T04DCQ0)

So, here’s the Russian hip-hop, but where’s the (inevitable) database connection?

My recent interest in building an Oracle environment is related to restoring a dump file of a very old database of mine for educational purposes. A very, very old database of mine that was originally hosted on a Windows server many, many years ago. The dump file is intact however and the import was going fine right up until it until it wasn’t and a review of the log file was needed. In there lurked this error (more than once):

ORA-12899 value too large for column

This odd contradiction (how could a column be created too small when the import was creating the column as well as importing the data into the column so is fully “aware” of every aspect) is one of those misleading errors – the problem is character set related, caused by a mismatch between the source database and the target being too great to be resolved by the import process.

The solution to the import problem was to create another throw-away database configured with the character set of the import and from there to either clone the PDB or more interestingly to take a look at the Database Migration Assistant for Unicode (DMU) as a more permanent fix, but for me the funny thing is how you notice how the dots can be joined between radically disconnected things when you know or are at least aware of what to look for.

Why Install Oracle 21c on OL8 via RPM?

Far too often in home lab situations, where there’s some interesting idea to be explored, efforts get derailed as a result of sinking too much time into the environment setup particularly when something like Oracle Database is involved. Maybe the the initial idea is to play with data migration or to investigate some new feature or just to brush up on skills, but whatever the scenario there’s a need for an environment and then, just like that, a week has passed and you’re just about ready having hunted down all the obscure errors and issues thrown up as the setup has progressed, when you get distracted by something else as the idea you wanted to work on has been crushed by the weight of getting things ready.

For reasons that I suspect are more related to Cloud automation than home labs, Oracle has managed to package up the install of the database on Linux (up to Enterprise Edition!) into an RPM that actually works. They’ve been trying to do this for a while and previous efforts were a mixed bag of results that were better regarded as interesting curiosities as opposed to real and useful things, but now the 21c release RPM seems to be both very real and actually useful, in certain circumstances anyway.

Oracle has used an RPM to prepare hosts for database installation for some time now but the main install via RPM was just not right or simply didn’t work first time and as it wasn’t something worth putting time into as you’d never want to install this way for real the RPM install just wasn’t a thing, but times have changed and whatever the reason behind the development the RPM database install now works to the point where it’s useful for home labs, demos, and other throwaway scenarios, making it far easier to setup an environment with a handful of commands; one for the pre-install RPM, one for the Database install RPM, and one for a basic database configuration the sets up a container database and a pluggable database.

The RPM based install is incredibly handy for setting up non-production, “throw away to the point of being ephemeral” style environments or for testing out automation but the lack of control over the installation rules this approach out for production or other long-living systems where you’d need to know what was going on under the hood or if there were any configuration elements you want to change at install time; in many ways the RPM install is a lot like using a managed database from a cloud provider where the internal workings have been abstracted away and some functionality lost or restricted, which can be ideal depending on the use case.

From the perspective of the home lab the RPM based install is perfect for rapidly setting up a system for testing and learning, as long as the topic under consideration isn’t “How to setup Oracle in Production”.

Links:
Oracle RPM installer can be found here: https://www.oracle.com/database/technologies/oracle21c-linux-downloads.html

Playing with Oracle Enterprise Manager

Quiet Friday’s are a nice treat but something too often squandered. This past Friday I found myself left to my own devices as the rest of the DBA team were working from another location. This left me free to get a few things about running our environment straight in my own mind with the most notable being was how to use CommVault for database backup and recovery beyond simply copying RMAN output to tape.

I have access to a test server for playing about with such things so I created a test database with the sample schemas to use for my backup and recovery testing. This also presented an ideal opportunity to look at the capabilities of OEM in and around monitoring databases while something bad happens to them (ahead of my recovery tests) so I first needed to install the OEM agent and the relevant options (host, databases, listener, ASM). The OEM agent went in without too much fuss (just a few things needed editing regarding SUDO and the DBSNMP database user account) and OEM got down to its monitoring duties quickly. This was a little unexpected as yesterday I had an issue with OEM getting stuck in “status pending” for one of our database instances (in that case the EMCTL command CLEARSTATE fixed it) so I was half expecting to hit a problem today. Our OEM system is configured with groups like “Database Instance” set up to send monitoring emails to the DBA team so the addition of my test system into the appropriate groups did trigger email notifications as I brought the database up and down as part of my CommVault tests.

On the CommVault front, the agent went onto the server also with surprising ease once you know to how to properly configure access permissions for the agent on Linux systems (I’ve seen this trip up administrators in the past so I knew that there were additional steps to be performed on the host beyond just deploying the agent). Once the database had the correct media policy applied it was a simple matter to run a backup. The hard part about CommVault is remembering that, with regards to Oracle, it is essentially running an RMAN backup, so dealing with database issues like dropped objects and schemas (which is what I was testing) need to be dealt with via a Point in Time recovery in order to be successful. Also, whenever CommVault throws an error, it’s best to analyse the associated RMAN log for the cause as the CommVault GUI (version 9 anyway) doesn’t reveal too much in the line of detail.

Last Friday thankfully wasn’t squandered and my initial foray into deploying OEM and CommVault now opens the door to some further adventures; I am particularly interested in deploying both of those systems to SQL Server (especially OEM!).