Search

Top 60 Oracle Blogs

Recent comments

docker

Video : Podman : Generate and Play Kubernetes YAML Files

Today’s video demonstrates Podman’s ability to generate and play Kubernetes YAML files.

This is based on the following article.

You can might want to check out these also.

Video : Using Podman With Existing Dockerfiles (Oracle Database and ORDS)

Today’s video shows me using some of my existing Docker builds with Podman. Specifically a 19c database container and an Oracle REST Data Services (ORDS) container.

For those with an understanding of Docker, it should look really familiar, but it does introduce a twist in the form of a pod.

The video is based on this article.

You can see more information about containers here.

Oracle Linux 8 (OL8) : Podman

https://oracle-base.com/blog/wp-content/uploads/2020/05/king-tut-161521_... 272w" sizes="(max-width: 197px) 85vw, 197px" />

When Oracle Linux 8 (OL8) was released, one of the first things I did was check for the Oracle supplied Docker engine. Nothing.

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.

Oracle REST Data Services (ORDS) 19.4 : A quick life update…

https://oracle-base.com/blog/wp-content/uploads/2019/12/ords-2-258x300.png 258w" sizes="(max-width: 238px) 85vw, 238px" />

Almost 2 weeks ago I wrote about the release of Oracle REST Data Services (ORDS), SQLcl, SQL Developer and SQL Developer Data Modeler 19.4.

I spent the holidays playing around with ORDS quite a bit, so I came back to work today and pushed it out across all Dev and Test installations.

19c instant client and Docker

You should get there if you search for “ORA-12637: Packet receive failed” and “Docker”. Note that you can get the same error on old versions of VirtualBox and maybe other virtualized environments that do not correctly forward out-of-band data.

TL;DR: There are two workarounds for this:

  • get out-of-band correctly handled with a recent version of your hypervisor, or by disabling userland-proxy in Docker
  • disable out-of-band breaks usage by setting DISABLE_OOB=ON in sqlnet.ora (client and/or server)

But this post is also the occasion to explain a bit more about this.

19c instant client and Docker

You should get there if you search for “ORA-12637: Packet receive failed” and “Docker”. Note that you can get the same error on old versions of VirtualBox and maybe other virtualized environments that do not correctly forward out-of-band data.

TL;DR: There are two workarounds for this:

  • get out-of-band correctly handled with a recent version of your hypervisor, or by disabling userland-proxy in Docker
  • disable out-of-band breaks usage by setting DISABLE_OOB=ON in sqlnet.ora (client and/or server)

But this post is also the occasion to explain a bit more about this.

APEX 19.2 : Vagrant and Docker Builds

I’m sure anyone who cares knows that APEX 19.2 was officially released on Friday. I did an upgrade of one of our development instances straight away and it worked fine. it’s subsequently gone to a bunch of other development instances. I’ll be pushing to get this out to production as quickly as possible.

Over the weekend I worked through a bunch of my GitHub stuff.

High CPU usage in docker-proxy with chatty database application? Disable userland-proxy!

Or just keep database and application co-located :)

It is well-known from the get-go, but very often overlooked because of ignorance or laziness: the database application must be co-located with the database server. Row-by-row roundtrips between the application and the database are expensive. Not only due to the network latency, but also because of the many CPU cycles wasted to switch the context between the two engines, or the two processes, and maybe the two servers.

In modern architectures, with microservices and containers, this means that a business service must be implemented in one microservice containing the business logic and the business data. Separating the application and the database into two microservices is a wrong design, non-efficient, non-scalable, and also non-green because of the unnecessary CPU usage.