I’ve been a little quiet on the blog lately, mostly because I’ve been spending my time freaking out about the arrangements for the OTN Yathra 2014 tour of India. I had to apply for a visa, which in itself was not too bad, but I spent quite a long time without a passport, thanks to the courier not bothering to attempt a delivery. All that time I didn’t know if my visa application had been successful, so I wasn’t sure if I would have to submit it again. By the time that arrived, it was so late that booking the flights became interesting… At one point I wrote to Debra Lilley and said words to the effect of, I think this is just not meant to be!
Well tonight (Tuesday evening) I got my flights confirmed for my trip that I start on Sunday. 🙂
This is proving to be quite an expensive trip.
- Visa: $130.00 – About £110 for the visa itself, and about £20 for the courier service.
- Vaccinations: £250 – I feel like a human pincushion now. I had a bunch of boosters that were due, as well as stuff specifically for India.
- Malaria Pills: £80 – We are in low risk areas (cities), but we are doing a couple of journeys between cities by bus, which travel through high-risk areas (countryside), so they advised me not to take any chances. I could have got the cheaper pills for about £8, but I decided to go for the ones with less side affects. I don’t see the point in travelling all that way to stand on a stage and feel like crap because of the anti-malaria pills. At least these should minimise the chances of that. If so, that’s worth a few extra quid.
For those that think this Oracle ACE thing is a free ride, you don’t get any of this money back!
I’ve still got stuff to get, like insect repellent. My pastey white skin seems to be very appetising to insects and I am not a stranger to infections when I do get bitten. Fingers crossed I can avoid the worst of it…
Getting to this point has been a bit of a trial. 🙂 Thanks to everyone who has helped. Murali put together a great pack to help the speakers plan the trip and Lillian and Vikki from the Oracle ACE Program have done a great job pushing through my last minute travel bookings!
Normally I’m doing the thanks when the events are over. 🙂
Let’s hope everything from now on goes a little smoother than it has up until now!
KeePass 2.25 has been released. The changelog and downloads are in the usual places.
You can read how I use KeePass across all my machines and devices here.
I was a little surprised by the reaction I got to my previous post on this subject. A number of people commented about the problems with automation and many pointed to this very appropriate comic on the subject.
There are one of two conclusions I can draw from this.
- My definition of automation of tasks is very much different to other people’s.
- It is common for DBAs and middle tier administrators to do everything by hand all the time.
I’m really hoping the answer is option 1, because I think it would be really sad if being a DBA has degenerated to the point where people spend their whole life doing tasks that could be easily scripted.
So what do I mean when I speak about automation? Most of the time I’m talking about basic scripting. Let’s take and example I went through recently, which involved cloning a database to refresh a test system from production. What did this process entail?
- Export a couple of tables, that contain environment specific data.
- Generate a list of ALTER USER commands to reset passwords to their original value in the test system.
- Shutdown the test database.
- Remove all the existing database files.
- Create a new password file.
- Remove the current spfile.
- Startup the auxillary DB using a minimal init.ora file
- Do an RMAN duplicate. In this case I used an active duplicate as the DB was relatively small. If this were a backup-based duplicate, it would have required an extra step of copying the backups using SCP to somewhere that could be seen on the test server.
- Replace some environment-specific directory objects.
- Unregister the old test database from recovery catalog.
- Register the new test database with the recovery catalog.
- Remove the old physical backups.
- Drop all database links and recreate database links to point to the correct location for the test system.
- Reset the passwords to their original values from the old test system.
- Lock down all users, except those I’ve been asked to leave open.
- Truncate and import the tables I exported at the start.
None of those tasks are difficult. It requires only a basic knowledge of shell scripting to allow me to start a single shell script and come back later to see my newly refreshed test environment.
What’s the alternative? I perform all the same tasks individually, but have to sit there waiting for each step to finish before I can move on to the next. No doubt, during this time I will be distracted by phone calls or colleagues asking me questions, which drastically increases the risk of human error.
When I talk about automation, I’m not talking about some Earth shattering AI system. I’m talking about scripting basic tasks to make myself more efficient.
At times you have to draw a line. There is no point making your automation too clever because it just becomes a rod for your own back. I’m a DBA, not a software house. This is what people are really warning about, which I did not really make clear in my first post. If something is liable to change each time you do it, you are better having a written procedure to work from, reminding you of the necessary steps and how to determine what needs to be done. You can’t become a slave to automation.
I’m in the process of taking on some of the MySQL databases in my company. The first ones are MySQL 4.1 running on Windows, so we are upgrading them to MySQL 5.6 on Oracle Linux. As with many of our systems, these will be running on VMware virtual machines.
Since the current installations are so old, we are planning on dumping out the data and creating fresh installations on the new systems. Based on the advice I got from Ronald Bradford and Sheeri Cabral, we are also taking this opportunity to switch to InnoDB and utf8, rather than MyISAM and latin1 that are currently used.
We are using the MySQL yum repository for the installation, so we can be on the latest MySQL version, rather than that shipped as part of Oracle Linux (or RHEL) 6.5. The other neat thing about this is it takes care of point release upgrades as part of the “yum update” process.
So far all my testing has been done on VMs running on my PC, but we are soon going to start rolling this out. It should be an interesting piece of work. The developers are doing a bunch of testing with InnoDB and utf8 to see what issues we come up against…
Update. For those new to MySQL, you might like to read this post by Patrick Hurley.
Basically I’m a lazy person with a short attention span, so when I’ve done something once, I get kind-of bored of doing it again and again. As a result, automation is a perfect solution to me. Figure out how to do something, script it so I can repeat it easily, then move on! *
In my current role I’ve been a little sloppy about automating things. In part, this is because I’ve been doing such a random variety of things it’s been quite hard to see the patterns of repetitive tasks and it’s been difficult to find the time to actually automate the things I have spotted. The fact I’m currently the only DBA in an organisation that believes DBA stands for Do Bloody Anything, means I’ve been slowing sinking into the weeds of late. Over the last week or two I’ve drawn a mental line in the sand and decided I won’t do anything without scripting it or automating it in some fashion. It requires a lot of discipline to do that when it means potentially missing deadlines, but it really is the only way to work.
Most of what I’ve been doing is standard stuff. Scripting cloning procedures, so I can refresh an environment by starting a script and leaving it to do it’s thing. Making sure developers can get their own application server logs without having to ask me. Making sure applications can be deployed by nominated people without my intervention. Hopefully over the coming weeks I will be able to get things to a state where I can actually see some light at the end of the tunnel.
* It seems people take everything so literally. 🙂 This does not mean I only ever do something once. The, “figure out how to do something”, part is a process of investigation and testing, not just some random crap that gets thrown together in a script. This is true of any process, manual or scripted. 🙂