Data Guard and RAC on Docker : Perhaps I was wrong?

I’ve talked a lot about Docker and containers over the last few years. With respect to the Oracle database on Docker, I’ve given my opinions in this article.

Over the weekend Sean Scott tweeted the following.

“A while back @oraclebase said Data Guard didn’t make sense on Docker.

For those of us disinterested in the sensible I present #Oracle#DataGuard on #Docker. 19c only for now. Please let me know what’s broken. Enjoy!

https://github.com/oraclesean/DataGuard-docker

This was in reference to a statement in my article that said the following.

“Oracle database high availability (HA) products are complicated, often involving the coordination of multiple machines/containers and multiple networks. Real Application Clusters (RAC) and Data Guard don’t make sense in the Docker world. In my opinion Oracle database HA is better done without Docker, but remember not every database has the same requirements.”

For the most part I stick by my statement, for the reasons described in my article. Although both Data Guard and RAC will work in Docker, I generally don’t think they make sense.

But…

A few years ago I had a conversation with Seth Miller, who was doing RAC in Docker. In his case it made sense for testing because of his use cases. I discussed this in this post.

For that use case, Seth was right and I was wrong.

What about Data Guard?

For a two node data guard playground I don’t see any major advantages to using two containers in one VM, compared to two VMs. The overhead of the extra VM and OS is not significant for this use case. Remember, most of the resources are going to the Oracle instances, not the VM and OS. Also, the VM approach will give you something similar to what you will see in production. It feels like a more natural testing scenario to me.

But Sean’s scenario was not this simple. When I questioned him over the value of this, considering the two VM approach had so little extra overhead, he came back with the following.

“There I’ll disagree. I have a Docker/sharding build I’m working on. 7 databases. Starts in moments. On my laptop. I can’t do 7 VM. No way!”

Now this scenario changes the game significantly. All of a sudden we go from the overhead of one extra VM to an overhead of six extra VMs. That’s pretty significant on a laptop. All of a sudden the Docker method probably makes a lot more sense than the VM approach for testing that scenario on a laptop.

Once again, I’m wrong and Sean is correct for this use case.

Conclusion

If you are building a two node RAC or Data Guard playground, I still think the VM approach makes a lot more sense. It’s going to be a lot more like what you use at work, and you don’t have to deal with some of the issues that containers bring with them.

Having said that, if you are looking to build something more extreme, or you are just trying stuff for fun, then Docker may be the right solution for you.

I still don’t see a realistic future for an RDBMS monolith on containers. I don’t care if it’s a single container or a giant Kubernetes cluster. This is not a criticism of the RDBMS or of containers. They are just things from different worlds for different purposes and continuing to treat them differently seems totally fine to me. Having said all that, it doesn’t mean combining the two can’t be useful for some use cases.

Remember, this is just my opinion! 🙂

Cheers

Tim…

PS. As a general point, trying to build your own data service on containers feels like a mistake. I would just use a cloud service that gives you the features, performance and availability you need. Concentrate on your apps.

Oracle Database 19c (19.3) : Installations, RAC, Data Guard etc.

A few weeks ago I put out a post about 19c installations and all that good stuff. That post was using the 19.2 release, which was not the official on-prem release of the product. Now Oracle 19c (19.3) has dropped and is available from here, and here, this post is just to say all those builds have been updated to use this 19.3 release. I also noticed the 19c preinstall package is available from yum.oracle.com.

Not surprisingly, I took the Vagrant and Docker builds I did for 19.2 and just changed the environment variables holding the software zip names, and everything worked just fine. Here are the associated articles, with those minor edits to reflect this version change.

I’ve committed a whole bunch of stuff to GitHub.

  • Vagrant build of 19c on OL7 with APEX and ORDS (here).
  • Vagrant build of 19c on Fedora 29 (here).
  • Vagrant hands-off build of 19c RAC on OL7 (here).
  • Vagrant hands-off build of 19c Data Guard on OL7 (here).
  • Docker 19c on OL7 build (here).
  • Docker 19c RPM on OL7 build (here).
  • Docker compose (here) and swarm (here) stacks.

Automation is awesome! 🙂

Cheers

Tim…

Oracle Database 19c : Installations, RAC, Data Guard and Upgrades

I’ve been playing around with Oracle Database 19c on LiveSQL since it was upgraded, and I pretty much thought that would be what I was stuck with until the on-prem release, as I don’t have an Exadata and it’s not on Oracle Cloud DBCS yet. Having seen a bunch people doing stuff on VMs, I got a bit frustrated and looked on eDelivery and low and behold the 19c software is available for download, even if you don’t have a Exadata CSI. I’m sure 18c was restricted during this period…

I’m pretty sure you wouldn’t be supported to use this for anything real (that wasn’t Exadata of course) until the on-prem drop, which will probably be 19.3 if they repeat what happened for 18c, but it does allow you to have a play.

Having a bunch of Vagrant environments for 18c already, meant it was pretty easy to test a whole bunch of 19c stuff within a few minutes, as most of the basics are very similar. Just minor changes to package recommendations. As a result I’ve pushed out the following stuff in the last couple of evenings.

Along the way I’ve committed a whole bunch of stuff to GitHub.

  • Vagrant build of 19c on OL7 with APEX and ORDS (here).
  • Vagrant build of 19c on Fedora 29 (here).
  • Vagrant hands-off build of 19c RAC on OL7 (here).
  • Vagrant hands-off build of 19c Data Guard on OL7 (here).
  • Docker 19c on OL7 build (here).
  • Docker compose (here) and swarm (here) stacks.

It should be obvious, but remember this is literally the first time I’ve done this stuff with 19c, so things will change over time. I just wanted to try some stuff out to see what happened, and have some test environments to play with while I’m checking out the new features. Once the real on-prem drop happens I’ll bring these up to date.

If nothing else, this is once again proof of how awesome automation is. A few minor tweaks and boom, there’s a new set of test environments. 🙂

Now I can get back to doing what I was meant to be doing… 🙂

Cheers

Tim…

Video : Oracle Data Guard Broker

Today’s video is a quick demonstration of the Oracle Data Guard Broker.

Having recently written an article on it (here), I though a quick run through might help people see how easy it is. Maybe they will get converted like me. 🙂

The star of this video is Liron Amitzi, whose shopping habits have probably boosted the Canadian economy since his move there. By now I expect all the shelves in all the shops in Vancouver have been emptied. 🙂

Cheers

Tim…

PS. I know I kept exiting to reconnect when I could have used CONNECT. I told you I’m new to this broker stuff. 🙂

 

Data Guard Broker : 11g and 12c

vault-154023_640I’ve been using standby databases, on and off, since Oracle 8i. I first wrote about Data Guard for Oracle 9i. I’ve had an article on 11gR2 Data Guard for ages, but up until recently I’ve always used the manual setup.

We’ve got a project coming up that *may* use Data Guard and *may* be installed by a 3rd party, so I figured I better get up to speed with the Data Guard Broker, in case they go that route. It’s been on my list of things to look at since 10g, but I’ve never got round to it until now. 🙂

At this point, I still don’t know if the project will use 11g or 12c, so I had a play with both, which resulted in a couple of overview articles.

From the overview perspective, the usage is pretty much the same. I really only did the 11g one in case that’s the route this project goes. I didn’t bother putting the 11g one on the front page of the website, because I consider it a “backfill” article. 🙂

After having a play with the broker, I actually quite like it. It definitely feels like a simpler and neater solution than doing all the configuration manually.

Remember, this Data Guard stuff is for EE installations. If you use SE, you might want to take a look at Dbvisit, who have a product that allows you to manage standby databases for Oracle SE.

Cheers

Tim…

PS. I’m not sponsored by Dbvisit and I have no business links with them. I just think they are a great bunch of people and I like what they do.

New Disaster Recovery Blog (Dbvisit)…

While I was in Chile at the CLOUG event I met Arjen and Bertie from Avisit Solutions Limited, who produce an alternative to Oracle Data Guard called Dbvisit. Unlike Data Guard, you can use Dbvisit with Standard Edition, so it can be a real money saver.

The company have started a new blog, so if you have an interest in disaster recovery (and if you don’t, you should) you might want to keep your eye on it.

Cheers

Tim…