I’m a SQL*Plus junkie. I have loads of scripts that do exactly what I want them to do, so for most tasks I am more productive from the command line than using other tools. If I do find something difficult, I just flick across to SQL Developer or Cloud Control. I’m not a snob about it, but I prefer the command line.
A couple of weeks ago I was playing with the ORDS stuff in SQLcl.
I forgot the 12.2 SQL*Plus client I was using could also do this, even though I had written about it (here), but the SQLcl formatting is more flexible anyway. 🙂
So after that I decided to try an experiment and go cold turkey from SQL*Plus and only use SQLcl. I think today is the 1 week anniversary. 🙂
The only real problem has been muscle-memory. My hand naturally types “sqlplus” rather than “sql”. It’s going to take a long time to get out of that habit. 🙂
I’m not using all the extra features all the time, so I can’t claim it’s revolutionised my life, but having them at hand is certainly … handy. 🙂
I’ve also started using it on some of my application servers. On some of them I have to check for the presence of the database before starting the application server. Just the standard race condition stuff you get during failover events. I was using the instant client before, but I’ve switched to SQLcl now because it is smaller. That’s especially nice on Docker.
So that’s one week down and I’ve got no plans (yet) to switch back. 🙂
If you’ve never heard of “pretrospectives”, that’s because it’s a made up word.
I was working in a team who were “a little frustrated”, so we vented by writing our Fragile Manifesto. It wasn’t a new idea, but it served its purpose and made us chuckle. It came up in conversation a few days ago so I took a look at it again, and one of the things that stood out was the “pretrospective”, which continues to be a problem. So here’s our definition.
“Pretrospectives : Similar to the Retrospectives of Agile, but they are done before any work is started, hence the “Pre”. These should last as long as it takes to identify any possible problem you may encounter during the lifespan of the project. Possible problems should not only be discussed, but documented thoroughly. Remember to include many blank pages, with the words “Page left blank intentionally”. This will increase the page count, and therefore the value of the documentation. Pretrospectives should be by far the longest phase of any Dawdle.”
I guess you now realise this is a jab at that waterfall approach of trying to define everything up front, only to find all the requirements have changed by the time you actually start to code, if you ever start that is. I’ve worked on projects where external consultants have produced hundreds of thousands of pages of documentation, at a cost in excess of £1 per page, only to have the whole lot scrapped.
I tend to think good DBAs are worriers, constantly thinking about what could go wrong and trying to figure out how to avoid it, or what they will do to fix it if it does happen. You have to be careful how you present this information to others or it can feed into the mindset that leads to pretrospectives. In a list of pros & cons, some people can’t see past the cons. 🙂
You have to break down large ventures into smaller, easily accomplishable tasks or you don’t stand a chance of even getting started, let alone finishing. I often say the thought of writing a book is really daunting, but everyone can write a page. A book is a collection of pages. You can call things user stories and story points or magic pixies steps. I don’t care. You’ve just got to stop sitting around “planning” and get something done…
I don’t really know what the point of this post was, but I suspect it was another way of me venting. 🙂
In a recent LinkedIn conversation I was asked the question,
“Are you friends with all the other big names in the Oracle world?”
My first reaction was to respond with,
“A more important question would be, are they friends with me?”
I decided not to go that route in case the person didn’t get the joke. 🙂 It’s not always obvious, even with emojis. My actual answer was this.
“Pretty much. Most of the folks are really normal in person, so it kind-of sounds cool, but it’s just normal when you are interacting with people on a daily basis, or traveling with people for a couple of weeks. You just get to know each other. I’ve been doing this for 22+ years, the website for 17 years and speaking at conferences for about 10 years, so it would be kind-of weird if I didn’t know a lot of people. 🙂 As you get a bit of a name for yourself, people come to find you, which helps. 🙂 Just because someone writes or presents it doesn’t mean they are the best in the room. Lots of people are great, but don’t like presenting or blogging. That’s part of what I mean about people being normal. People will tell you something amazing, then following it up with a question that makes you think, “Really? You don’t know that?”
Let’s break that down a bit.
Like most people I have several levels of friends, and the word “Friend” in this context is like “community friend”, if you know what I mean. They are people I interact with regularly on social media, email or IRL with reference to technology. I’m not expecting invites to family events or to help them bury a dead body, but I mean something more than “they follow me on social media” or “I follow them on social media”. I feel that should be pretty obvious, but I don’t want people thinking we are at each others houses every five minutes. 🙂
Over the years I’ve had the pleasure to meet a bunch of really cool people, sometimes being a little star-struck when I met them. The vast majority of the time these people were really normal. Often doing regular jobs. Not everyone is a consultant to the stars. You know I’m not!
“If there’s one thing I’ve learnt about experts, they’re experts on f*ck all!”
Jake Green (Revolver, Guy Richie)
I like this quote because it can be read two ways, with quite different meanings:
Most experts aren’t really experts.
Most experts have such a specific focus, when you look at their knowledge as a whole, their expertise amounts to nothing. You might be able to perform hip surgery, but can you build a house or fix a car?
The second point is very true in the IT industry. It’s important to remember that some people have quite extreme specialisms. They can melt your brain when speaking about some aspects of Oracle, but are not so special at other aspects. I feel that should be obvious, but I’ve fallen into the trap of elevating some people to a God-like status in my own head, then been really surprised by their lack of knowledge in other areas.
Being willing to stand up on stage, publish a blog post on the internet or write a book doesn’t make you an expert. The only thing you can guarantee when you see someone on stage, is they are willing to get up there. Judge people by what they do, not by what they say they can do, or what you want to believe they can do. 🙂
That’s it really. I’ve got to catch a private jet to meet up with all my celebrity friends to do crocodile wrestling and save the world, while the rest of you wish you were me! *
Cheers
Tim…
* Just in case, that was a joke OK! We are not going crocodile wrestling! **
** We’re also not saving the world! ***
*** Just thought I better mention I’m not going on a private jet or meeting any celebrities either. ****
One of the questions I’m asked, and indeed have asked myself on numerous occasions, is how do databases fit into the Docker world? More specifically, how does the Oracle database fit into the Docker world?
There is some Boring Context at the end of the post. Happy for you to ignore it, but please read it before giving me aggro. 🙂
I don’t feel the typical lifespan of a production Oracle database fits well into the Docker world. Lots of people, myself included, have been quick to show examples of Oracle databases running on Docker, because it’s really easy and it works, but the examples are all one-off builds. There is little in the way of realistic life-cycle discussed. Maybe I’ve missed the memo on that, or I’m following the wrong people. 🙂
The issues with Oracle on Docker come about when you try to do things “the Docker way”, which works great for application servers and small footprint databases with a simpler approach to patches and upgrades, but not so well for Oracle databases. In my opinion Oracle database patches and upgrades are clumsy from a Docker perspective. I wrote about this here. I know at least one person I respect that disagrees with my opinion on this (you know who you are 🙂 ). You can choose manual intervention in the upgrade process, but I feel like that is removing some of “the magic of Docker”. It’s well within Oracle’s capability to make database patching and upgrades more Docker-friendly, but time will tell if they think it is worth the effort.
From a monitoring and tuning perspective I’m not sure Docker really fits into what most Oracle DBAs are used to either. If Oracle start making DBA tools that are a bit more “Docker aware”, that could change of course. Once again, it depends on their priorities.
So what’s the sweet spot for Oracle databases on Docker? Well I think it’s great from a Dev, Test and QA perspective. I had a great example of this last night. I was doing some APEX patching (5.1.3 to 5.1.4) at work yesterday and hit a problem. I went home and tested the APEX upgrade (5.1.3 to 5.1.4) on four environments and they all worked.
Oracle Database 12.1.0.2 using multitentant architecture with APEX installed in a PDB.
Oracle Database 12.1.0.2 using non-CDB architecture.
Oracle Database 12.2.0.1 using multitentant architecture with APEX installed in a PDB.
Oracle Database 12.2.0.1 using non-CDB architecture.
I never use non-CDB architecture at home anymore, so I had to spend about 30 seconds altering two Dockerfiles for that, but the process of getting clean environments up and running was quick and simple. It was so quick in fact that when I finished I had time to update my database Dockerfiles to install APEX 5.1.4, and update my ORDS Dockerfile to use APEX 5.1.4 and Java 8u161. All built and tested.
I’ve been using virtualization for well over a decade and I have gold images, snapshots and build scripts coming out of my ears, but Docker is head and shoulders above everything else for pushing out these small short-lived clean environments.
A while back I watched an online presentation by Seth Miller about RAC on Docker. I guess some of you are thinking WTF at this point, which was pretty much how I felt before watching it. 🙂 Watch the presentation and see why it makes sense for Veritas to invest effort in this from a Dev/Test perspective. They have a use case that fits.
The important thing is to focus on the use cases where it adds value, rather than the typical “Emperor’s New Clothes” approach assuming it’s all things to all people. Sounds obvious, but it is so often lost on the IT world. 🙂
So in conclusion, I remain sceptical about me ever running an Oracle database on Docker for production, but I can see a bunch of situations where it is useful in the Dev, Test and QA space, where you need relatively small, clean, well-defined environments for short periods of time. That seems like the sweet spot to me at this point, but I reserve the right to change my mind over time. 🙂
I’m really interested to know what you think, especially if you think I’ve missed the point. I am still a Docker newbie. Like I said earlier, read the Boring Context before jumping to conclusions though. 🙂
Cheers
Tim…
Boring Context: I feel I need to make a few points so people don’t pounce on me. 🙂
I am talking about databases in the sense of the monolith running on Docker. The microservice approach where the data is self-contained as part of the microservice is different.
I’m not trying to make out every database engine has the set of same issues, although I suspect there will be some commonality when you start talking about long-term production usage.
There’s nothing wrong with using Docker like lightweight virtualization and doing manual installations, patches, upgrades and maintenance inside your container. It’s going to bloat the hell out of it, and it’s not how I want to use it, but you can choose to do that if you want. The Docker police will not arrest you. 🙂
There’s nothing wrong with you going off piste with how you organise your builds and images. You can have separate Dockerfiles per database or use build arguments rather than first-run configuration based on environment variables. Once again, you are going to waste lots of storage and that’s not how I like to play the game, but that is your choice.
I know that Docker was developed with application delivery in mind and databases probably weren’t at the forefront of the developers minds when it started. I hope it stays that way!
Some of the same issues exist when dealing with complex web applications like OBIEE. Yes, you can install them on Docker for a demo, but does it really work for the normal lifespan of that product?
I realise well planned virtualization can have many of the benefits of Docker, but it feels a little heavier in comparison. Each to their own.
I realise there are products out there for data virtualization (like Delphix), that are capable of doing some cool things for Dev, Test and QA environments. If you are using something like that, that’s great for you. 🙂
Docker is changing fast. My thoughts might be very different over time as Docker develops.
I realise there are a lot of “we just need to keep the lights on” databases that are small and don’t have extreme requirements. Maybe I’ll find Docker to be a good home for these. Maybe not.
I’m not a Docker hater. In fact I’m quite the opposite.
Yesterday’s rant about the bad reporting of Oracle 18c got quite a lot of attention, but it seems the reaction from some people was a little odd IMHO. I wrote some updates to the post during the day, but I would just like to address them here to hopefully make a few things clear.
Who was the post directed at?
I got the distinct impression that some people thought I was “sticking it to Oracle” with that post. If you read it that way I really don’t understand how. Here are two quotes from the post.
“From the get-go Oracle has been talking about the Autonomous Database as a cloud service based on Oracle Database 18c, but I can’t remember them once saying Oracle Database 18c is an Autonomous Database.”
“I am disappointed at how lazy the Oracle blog-sphere has been in reporting this”
If you read that as a dig at Oracle you are wrong. It was definitely dig at bloggers promoting untruths.
Are you sure 18c is not an Autonomous Database?
I got a few people contacting me who were so convinced Oracle 18c was an autonomous database, because of what they had read, they wanted to make sure I was not mistaken. 🙂 I guess if something is said enough times it starts becoming reality…
For those that thought I was mistaken, the mighty Maria Colgan has added a couple of updates to her blog to make it super-super clear.
If you know who Maria is, you will know this is the end of this point. If you don’t know who Maria is, she was “the optimizer lady”, then the “in-memory lady” and now she is (in my words) “the database”.
Just to confirm.
If you buy an Autonomous Database Cloud Service on Oracle Public Cloud or Cloud@Customer, that’s a service that specifically includes the words “Autonomous Database” in the name of the service, you are getting an Autonomous Database.
If you buy regular 18c DBaaS on Oracle Public Cloud or Cloud@Customer you are not getting an Autonomous Database.
If you install 18c yourself on any cloud provider, including Oracle Public Cloud or Cloud@Customer, you are not getting an Autonomous Database.
If you install 18c yourself on-prem you are not getting an Autonomous Database.
Thank God for that!
Some people were genuinely happy with this “revelation”. I guess this comes from the concern about their future job prospects. I understand this, as it affects me too, but I am disappointed that people don’t see this for what it is.
It has been possible to automate the vast majority of operational DBA tasks for a long time. Amazon have been doing this with RDS for Oracle for years. Good DBAs have been following this lead for years. This is not a new concept. Oracle are just taking it a step further with the automatic tuning etc.
It has been clear this is the way the market is moving for the last decade. If your only role is basic database operations you need to start getting skilled up. Whether 18c is autonomous or not isn’t really the issue…
I knew it!
Some people couldn’t help themselves and started rolling out the whole line about Oracle always claiming the end of the DBA. I have some sympathy for this point in the past having lived through all those death of the DBA announcements, but in this case not so much.
First, you are speaking like this is some sort of back-track on what 18c can do, when actually I was responding to the fiction created by bloggers that weren’t paying attention. From the information I’ve read from Oracle, I think it was clear this was a cloud service, not native 18c functionality.
Second, they are still claiming the cloud service is autonomous. Can we reserve the “I knew it” and “I told you so” comments until after it’s been released and we see what it can actually do.
I, for one, welcome our new autonomous database overlords!
Conclusion
I’m not claiming Oracle haven’t done some terrible reporting in the past, because they clearly have, but in this case I think the misconception is not their fault. I think the fault sits squarely at the feet of those in the blogging/news community, who read the headline and ran with it. The people who actually paid attention to the official announcements and subsequent posts from Oracle knew the score already. Here’s a quote from a post I wrote the day after the OOW17 announcement (2nd October).
“Although Oracle 18c has new features that make it easier to build an autonomous database, the “Autonomous Database” is a cloud service, so you will need to run your database on Oracle Public Cloud, or possibly on Cloud@Customer. Just installing 18c on-prem will not get you an autonomous database.”
I really hope I don’t feel the need to write another update to this issue… 🙂
From the get-go Oracle has been talking about the Autonomous Database as a cloud service based on Oracle Database 18c, but I can’t remember them once saying Oracle Database 18c is an Autonomous Database. There is a reason for that. It’s because it isn’t. It’s not meant to be. It’s basically a big patchset on what we already have. We currently have 12.2.0.1 and Oracle 18c is 12.2.0.2, with a different name because of the new yearly release cycle.
I am not disappointed by this, but I am disappointed at how lazy the Oracle blog-sphere has been in reporting this. I keep reading posts where people mention that 18c is autonomous and how 18c will be the death of DBAs. Come on people, we can do better than this. I know what’s going to happen. Oracle 18c will be released and when it doesn’t contain all the autonomous goodness people will lose their minds and say, I told you it wouldn’t work!
Let me say this loud and clear!
Autonomous Database : It’s a cloud service that happens to use the Oracle 18c database.
Oracle Database 18c : It’s not autonomous!
This is not the first time I’ve said this. I mentioned it here when I wrote about the Autonomous Database announcement. I even mentioned using the cloud service here when I did the hands-on lab at OOW17.
Can we please have a little integrity and stop this junk reporting, or have we also entered the post-truth, fake-news world too? If you’ve written a blog post describing Oracle 18c as autonomous, please go back and correct it because you are making yourself look foolish and misleading people.
Sorry for the rant, but I felt it had to be said!
Cheers
Tim…
Update: At least one person seems not to have understood this post. I am not saying the Autonomous Database Cloud Service isn’t autonomous. I’ve used it briefly and from what I can see it seems pretty cool. This post is totally about the misreporting of the Oracle Database 18c product by bloggers (and some news outlets), which is not and doesn’t claim to be autonomous.
Update 2: So now I’m getting people asking me if I’m sure about this. As I said, people are being mislead by rubbish reporting. Come on people, fix your stuff! If you don’t believe me read what Maria Colgan said when she retweeted my post here.
Update 3: Some extra bullet points above to make things even more explicit.
If you buy an Autonomous Database Cloud Service on Oracle Public Cloud or Cloud@Customer, that’s a service that specifically includes the words “Autonomous Database” in the name of the service, you are getting an Autonomous Database.
If you buy regular 18c DBaaS on Oracle Public Cloud or Cloud@Customer you are not getting an Autonomous Database.
If you install 18c yourself on any cloud provider, including Oracle Public Cloud or Cloud@Customer, you are not getting an Autonomous Database.
If you install 18c yourself on-prem you are not getting an Autonomous Database.
