An Eye for Efficiency : Why you are crap at your job!

One of my colleagues says that I think everyone is crap at their job, and to be honest that’s probably true. Most people are terrible, but they have so little self awareness they actually think they are good. The few people I think are good are those that have some self awareness and have an eye for efficiency. This isn’t just about technology, you can exercise these muscles in everyday life. I mentioned one example of how people approach parking barriers here, but here are some other things I’ve witnessed/experienced.

Shop Checkout

There’s a small, but busy, shop I go to several times a week. The process all the checkout staff go through is like this.

  • Scan all items, leaving them balanced on the checkout in a rather messy fashion.
  • Ask if you want a bag.
  • Pack all those scanned items into the bag.
  • Ask how you want to pay. If you pay by card, which most people do, they type in a code, wait a couple of seconds, then you touch your card to pay.

This drives me insane for a couple of reasons.

  • If they asked about the bag at the start, they could scan straight into the bag. This would save a significant amount of time in itself.
  • They could ask, “Are you going to pay by card?”, whilst they are scanning, and type in the code immediately once the last item is scanned.

Both items would shave quite a number of seconds off the transaction time. For each basket it might be just 30 seconds or so, but when there is a queue of people, which is very often, it makes a big difference. I stand there going crazy wanting to say something, but realising they will think I’m being a dick…

I worked in shops as a kid. I know how you should handle a checkout. In my day we didn’t have the scanners, so you would memorise the prices of popular items so you could get them through the checkout quicker than having to read the price tag then type it.

It amazes me the people on the checkout can’t see this and fix it themselves. It saddens me that their boss hasn’t taken the time to observe them and see this issue, then correct it. I guess they think they just need more staff. πŸ™

Production Line

I’ve done a couple of production line jobs in summer holidays during University. In one job I worked packing garlic bread for 3 months. There were several stations in the line, and not surprisingly the line manager tried to move people between the stations to keep the flow of product consistent between all stations. I worked on the last station, which involved putting the packaged garlic bread into a cardboard sleeve. It was murder on your hands. Although the line manager would add and remove people from our station, they never dealt with the final link in the chain, which was the real problem. Once we filled up a crate, someone had to walk it over to the other side of the room and bring back a new empty crate. That was one person missing from the station a lot of the time. I moved the crates next to our station and it was like I had done some witchcraft. It seemed like an obvious waste of time to me, so I dealt with it. I’m sure as soon as I left the crates were moved back to their original location, because that’s where they were meant to go…

In both these cases, and in the case of the parking barrier, all I’ve done is observe what is happening and think how it could be done better. I don’t think this needs a brain the size of a planet. It’s more about having the desire to see things running smoothly. Unfortunately, most people don’t seem to give a crap about that, which is why most people are crap at their jobs…

Now I could link this back to some discussion on automation, or the principle of flow in devops, but you should already be able to make that connection for yourself, and if you can’t, I don’t think me telling you is going to make a difference…

Cheers

Tim…

Video : Oracle Linux 8 Installation

Today’s video is a quick run through a manual installation of Oracle Linux 8.

I put out a number of articles about Oracle Linux 8 when the beta was first released. I’ve now updated them where appropriate.

I’ve also gone through my Vagrant builds for 18c on OL8 and 19c on OL8. They work fine, although there isn’t a Vagrant box for OL8 yet, so I had to make my own using the method similar to this.

Remember, OL8 has only just come out, so the database is not certified on it yet. I’ve put at note a the top of the database installation guides saying as much.

The star of today’s video is Mahir M. Quluzade. He was grinning most of the way through filming this. πŸ™‚

Cheers

Tim…

Oracle Database 18.7 Patch : Summary

I wrote a bunch of angry tweets yesterday about the 18.7 patch, which probably weren’t very coherent. I just thought I would summarise them here.

Before we start, I think it’s worth saying I try to keep things as vanilla as possible, so we rarely have problems with patches. I guess this is why I launched into these so quickly, and was surprised by how much hassle I had. So far I’ve only been doing the 18.7 patches on servers running OL6 (hence not upgraded to 19c yet). I have no idea at this point if patches for 19c and the lingering 12.1 instances will have problems or not (see updates below).

Issue 1

A few days ago I had upgraded a development database from 12.1.0.2 to 18.6. The upgrade went fine. No worries. Yesterday I patched that same instance from 18.6 to 18.7. The datapatch run complained about invalid objects, specifically some of our packages (not Oracle packages) that were invalid, because database links they referenced were not working.

The schema in question contains some archived tables and code, and the servers these DB links reference no longer exist. In an ideal world all this would be cleaned up, but that would take development time that we don’t have. Welcome to the real world.

At the end of the datapatch run the PDB was left in restricted mode, so I did the following.

  • Granted restricted session to the user.
  • Proxied in.
  • Dropped the invalid objects in question.
  • Revoked restricted session from the user.
  • Ran datapatch again.

At the end of that I had a functioning instance.

That sounds like it was relatively smooth and controlled, but of there was lots of checking log files, Googling for bugs and all that stuff before I eventually just dropped the objects and moved on.

Issue 2 (Issue 1b)

The second issue was a kind-of rerun of the first. This time it was an upgrade from 12.1.0.2 to 18.7 directly. This instance was similar to the previous one, as they were both clones of the same production instance. Unfortunately, I was doing this at the same time as the patch, so I couldn’t learn the lesson from the previous one.

The upgrade went fine until datapatch ran, then boom. Same problem has before. Also, same resolution, so I got through this pretty quick.

If I had completed the patch before starting this upgrade, I might have got though this with the preemptive cleanup, but maybe not. See Issue 3.

Issue 3

Having got through two development databases and learned the lessons, I did a preemptive cleanup of the offending objects from the UAT instance. It also was based on a clone of the same production database as the previous two.

Having done the clean-up, I started the upgrade from 12.1.0.2 to 18.7 feeling pretty confident.

The upgrade went fine, but when it ran datapatch it failed with an issue that looked very much like that described in this MOS note Doc ID 2054286.1.

I say “looked very much like”, rather than “was this”, because that issue relates to patching multiple instances on the same machine at the same time. This was datapatch running against a single instance on this machine. The symptom looked the same…

The resolution for this was to run datapatch again. It just ran through fine. No drama.

Conclusion

I’m not looking forward to upgrading the production instance to 18.7. All these databases were clones of it, so I suspect I’m going to have some drama. Luckily the project can tolerate some downtime.

I’m also curious how the 12.1.0.2 and 19c patches are going to play out… (see updates below).

So if you were following my various rants on Twitter yesterday and wondered why I was so angry, this is why. Keep in mind also, these were “background tasks” I threw in on top of the rest of the stuff I was meant to be doing yesterday.

I hope this was just a problem with my instances or me, not indicative of the quality of the patch. It is interesting that 18.6 was happy with it, but 18.7 was a nightmare…

Good luck everyone, and remember, don’t give me a job. I can’t be trusted… πŸ™‚

Cheers

Tim…

Update 1: Sven-Olaf Hilmer wrote on Twitter.

“I have a problem with 12.1.0.2.190716DBBP. RMAN crashes on all patched DBs. Rollback to 190416 solves the problem. SR filed. 11.2, 12.2.0.1, 18, 19 are not affected.”

Update 2: Anil Vejendla wrote on Twitter.

“We are facing restricted mode issue for 12.2 after applying July patch and even after rollback also issue still persists.”

VirtualBox 6.0.10

VirtualBox 6.0.10 has been released.

The downloads and changelogs are in the usual places.

I’ve installed it on my Windows 10 laptop at work. I’ll install it on my Windows 10, macOS Mojave and Oracle Linux 7 hosts tonight and update here. (see update below)

I’ll be working through my Vagrant builds over the coming days, to check everything works OK. I’ll report back here if something comes out of the woodwork.

Cheers

Tim…

Update: The installations on Windows 10, macOS Mojave and Oracle Linux 7 worked fine. So far, all Vagrant builds are working as expecting.

Dbvisit 9.0.02 : Automatic Failover

I recently wrote about the release of Dbvisit 9, where I included a simple installation article and Vagrant build to get it up and running.

Yesterday I got an email about version 9.0.02, or 9.0.2 depending on how you want to write it. The interesting thing about this release is the introduction of an observer, which enables automatic failover. If you want to try it, there is a free trial available here.

Not surprisingly, the installation is very similar to the previous version, so I’ve updated my original article, and added the observer installation, setup and a quick automatic failover test.

I had to redo the screen shots as the “Configuratons” screen has changed a little to include the observer. I really don’t like taking screen shots!

My existing Vagrant build (here) worked fine. All I had to do was swap the version of the software in the directory, and Bob’s your uncle! Of course, that didn’t install and start the observer, so I did a couple of tweaks and now it does. If you fancy having a play with Dbvisit Standby, this Vagrant build is a really easy way to do it.

Happy days!

Cheers

Tim…

Video : CORR : Problem Solving using Analytic Functions

In today’s video we take a look at the CORR aggregate and analytic function.

This video is based on the information found here.

The star of this video is Vikki Lira, who used to be part of the team keeping the ACE program moving, but is now a Client Engagement Marketing Manager at Businessolver.

Cheers

Tim…

Video : AVG, MEDIAN, MIN and MAX : Problem Solving using Analytic Functions

In today’s video we take a quick look at the AVG, MEDIAN, MIN and MAX aggregate and analytic functions.

You can get more information on these and more analytic functions here.

The star of today’s video is Sten Vesterli, in one of the rare moments at OpenWorld when he’s not in a wetsuit. πŸ™‚

Cheers

Tim…

Enterprise Manager Cloud Control 13.3 Silent Upgrade

A few days ago I put out a post called Enterprise Manager Cloud Control 13.3 Vagrant Build. In a comment on that post Dinesh said,

“Would like to see the silent upgrade from oem12c to oem13c upgrade post from you”

I normally try to keep on top of upgrades, so I’ve never done a jump bigger than one version, but I was checking through the documentation, and assuming it’s a supported start version, there isn’t much difference between the upgrades from most versions, so I thought I would give it a go. As I mentioned in the last post, I already had a GUI upgrade article.

I didn’t have a silent upgrade though. I do now. πŸ™‚

In order to try this out I did a Vagrant build of Cloud Control 12cR5, to give me an easy way to get a clean starting point. You can see that here. If you want to practice the upgrade, it’s a really easy way to do it.

I’ve left the agent upgrade using the Cloud Control interface, but there is an example of how to do it silently using WLST here. It’s pretty simple.

So not only did I not expect to be writing that post a few days ago, but I certainly didn’t expect to be writing this one. πŸ™‚

Cheers

Tim…

Video : FIRST_VALUE and LAST_VALUE : Problem Solving using Analytic Functions

Today’s video is a quick run through the FIRST_VALUE and LAST_VALUE analytic functions.

You can find more information about these and other analytic functions in the following articles.

The star of today’s video is Lonneke Dikmans. She probably won’t believe me, but I probably quote/paraphrase her advice more often than any other person in the Oracle space.

Cheers

Tim…

Why Automation Matters : Reducing the Cost of Failure

Recently I watched a video called The Future of Faster Enterprises by AWS Enterprise Strategist, Miriam McLemore. I think its a really good video, even if you don’t care about AWS or cloud in general. There is a wider message there.

One of the points Miriam raised was “Reducing the cost of failure”, which sparked a conversation between myself and a colleague. When you’re trying to improve the way you work, you are going to have to try new things. Not all of those things are going to work out. The important point is you try them, see if they work for you. If they do great. If they don’t, you throw them away and move on. Reducing the cost of failure is a really important part of encouraging the culture of experimentation needed for continuous improvement.

Recently I wrote a post called you have to keep working just to stand still. Now add to that the work required to move your company forward and I think you’ll see why any barrier to progress is a problem.

So what factors affect the cost of failure? Here are a few.

  • Lack of automation. If humans are involved in providing infrastructure, it’s going to increase the time it takes to set things up (see lost time), and they will get disgruntled when you ask them to throw it away 2 hours after you’ve got it. You need to be able to build and burn kit rapidly to have any hope of experimenting. This is why the focus on the automation part of flow in DevOps is so important, for both business as usual and experimentation.
  • Bloated waterfall process. If your company expects a detailed plan of action before you so much as fart, you are going to fail. You have to be agile. I’m not using the term agile in the, “I’m too lazy to plan”, sense. I mean proper agile.
  • Time. Your company has to value progress and be willing to allocate time to it. You can’t rely on the fact Beryl and Bert go home every night and no-life their way through learning something new, so the business can reap the benefit of it for free. Yes that happens, but companies that rely on it will fail.
  • Be accepting of failure. I’m not talking about being happy to be rubbish. I’m not talking about being accepting of failure in well defined business as usual (BAU) work. I’m talking about being accepting of failure during experimentation. Not everything will work. Not everything will be the right solution for you or your company. You have to be willing to try and fail or you will fall at the first hurdle.

Check out the rest of the series here.

Cheers

Tim…