Enterprise Manager Cloud Control 13.3 on Oracle Database 19c

I’ve had some articles about Enterprise Manager Cloud Control 13.3 on the site for quite a while now. The first installation and upgrade articles were posted over a year ago.

More recently I posted about a Vagrant build and a silent upgrade.

At the time, the certification matrix said Oracle 19c was not certified to hold the OMS repository, so my article and Vagrant build didn’t include it. A few days ago someone asked me if it would work on 19c, and I was just about to reply and say it wasn’t certified, but I thought I better check first. It is now certified (if you are on the latest versions of the DB plugin), so I thought I better give it a run through.

The process was the same for 19c, so all I had do was unzip the 19c media into the renamed ORACLE_HOME and the rest went fine. I’ve done some minor updates to the articles and the Vagrant build to reflect this.

So if you are on OL7/RHEL7, you are good to upgrade to 19c for the OMS repository. 😉

Happy days!

Cheers

Tim…

Update: JE in the comments pointed out the requirement to be on the latest plugins for 19c to work (see here). They also pointed out the loss of the Top Activity screen. From my perspective:

  • I always run with the latest plugins if possible.
  • The Top Activity screen is replaced by the ASH Analytics screen, which does all the same things, but I would say the window adjustment makes it a bit better. It took a little time to get used to it, but I use it in the same way I used the Top Activity screen on versions from 11.2 to 19c with no drama.

Q: Is the CREATE JOB privilege required in 19c? A: No!

A couple of people have already written about a new feature in oracle 19c, which converts jobs created using DBMS_JOB into DBMS_SCHEDULER jobs.

I finally got round to writing up my notes about it here.

The conversion comes with rather interesting consequences.

The scheduler side of things is tighter. As Connor pointed out you now need the CREATE JOB privilege to use the DBMS_JOB package. That’s nice, but isn’t that the opposite of the title of this post? Yes, but…

The problem is the re-implementation of materialized refresh groups using the DBMS_REFRESH package didn’t seem to follow the same approach. You can create a refresh group, which creates a DBMS_SCHEDULER job, without needing the CREATE_JOB privilege. Once you own a job, you can amend it, which means there is now a method to create DBMS_SCHEDULER jobs without needing the CREATE JOB privilege. Doh! You can see an example of it in 19.3 here.

Thoughts:

  • It’s clearly a bug, and I’m sure it will be picked up in a future release.
  • Although it seems pretty bad, remember the DBMS_REFRESH and DBMS_JOB packages are available by default and in previous releases you didn’t need the CREATE JOB privilege to them.
  • If this is a problem you can revoke execute on DBMS_REFRESH from PUBLIC, like you may have been doing for DBMS_JOB already.

Cheers

Tim…

PS. SR raised.

SR 3-20860955641 : Jobs can be created without the CREATE JOB privilege.

Video : Docker : Oracle Database Build

Today’s video is a look at a simple Docker build for an Oracle database. In this example we are using Oracle database 19c on Oracle Linux 8 (oraclelinux:8-slim).

You can get an overview of this build in the following article.

You can see my other Docker posts and builds here.

The star of today’s video is “The Why Guy” Jim Czuprynski. 🙂

Cheers

Tim…

Oracle 18c and 19c on Oracle Linux 8 (beta)

Fresh on the back of yesterday’s Fedora 30 post, I noticed a post from Avi Miller about the release of Oracle Linux 8 Beta. I had a day off work, so once I had finished the Fedora 30 builds, I started on the Oracle Linux 8 builds.

It should be obvious, but this is a beta release of the OS, so everything below is just me playing. It will all have to be done again, and done “properly” once the final release appears. Even then, it will be a while before anything is certified against the new OS, so don’t take this seriously.

I’ve pushed some stuff up to GitHub. It uses a Vagrant box I created myself, in the same way I wrote about here.

I think it’s time I did something “real”, rather than playing around with stuff that doesn’t relate to something I would do at work. 🙂

Cheers

Tim…

Oracle 18c and 19c on Fedora 30

As is customary, Fedora 30 has been released and I’ve done some Oracle installations on it.

Before we get to the good stuff, let’s do the warnings.

With that out of the way, here are the articles.

Not surprisingly, things feel pretty similar to Fedora 29 from an Oracle perspective. There are a few small edits to the process due to the package changes with this OS version.

I’ve pushed some stuff up to GitHub, but there is no Vagrant box available for Fedora 30 yet, so I had to create my own, in the same way I wrote about here.

So now you know how to do it, please don’t. 🙂

Cheers

Tim…

Video : JSON_SERIALIZE Function in Oracle Database 19c Onward

Today’s video is a brief run through the JSON_SERIALIZE function, introduced in Oracle 19c. If you have used any of the other SQL/JSON functions, it’s going to feel pretty familiar.

For those people that prefer there information in written form, you can read about this function here.

The star of this video is Zahid Anwar, or ZedDBA. 🙂

Cheers

Tim…

Video : JSON_OBJECT Function Enhancements in Oracle Database 19c

Today’s video is a demonstration of some of the enhancements to the JSON_OBJECT function in Oracle Database 19c.

If videos aren’t your thing, you can get the same information, and more, from this article.

The star of today’s video is Patrick Jolliffe. 🙂

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…

Oracle 19c Released : How does that make you feel?

Back in 2017 I wrote a post about the move to the yearly release cycle for Oracle software. It’s over 18 months since that post and we’ve had 18c and now 19c released (on LiveSQL), so I thought I would reflect on some of the pros and cons I mentioned in that original post. If you want to know what I originally said about these points, go back to the original post.

Pros

  • Quicker release of features : It’s becoming clear to me that some of the 18c features were actually 12cR2 features that didn’t make it into the documentation, even though they were present in the product. I’m not sure if these were present in the initial release of 12.2.0.1, or got introduced in the proactive bundle patches later. I have no problem with this, but it feels like the documentation is not keeping up with the new features added in the release updates. Where 18c is concerned we’ve had 18.1, 18.2, 18.3, 18.4 and now 18.5, but I don’t see a change in the documentation. Now a drop of the documentation once a year that includes the latest changes is better than the once every 4 years, but it still feels odd that we’re getting new functionality added, but no way to see that except for scouring MOS notes. I wonder if this situation will continue in 19c release.
  • Predictable release cycles : Yes. Nice.
  • Stability : This was originally one of my cons, but I’m going to move it to the pros section. I was worried the quicker release cycle might lead to a lack of stability, rather than the improved stability. I don’t know how other people feel, but 12.2 and 18c have been pretty good for me. I try and apply the proactive bundle patches (BP), now Release Updates (RUs), so I’m going all-in and things have been good. We are a “middle of the bell curve” company, so I probably won’t experience some of the edge cases you might, but that’s what I feel about it. I hope 19c continues this trend, as I see it.

Cons

  • Upgrade/Patch burnout : I’m currently upgrading some databases to 18c, but part of me is thinking, “What’s the point?” Let’s say the on-prem 19c drops in April, and we will wait for the first RU after that which might be July. I’m potentially only 6 months from having a viable 19c upgrade path, which is after all the Long Term Support (LTS) release. Should I bother with 18c now? I can understand if some people say no. I’m still going to move forward, as this solves some other issues for me, including the conversion to Multitenant of some 11.2 instances, which will make future upgrades easier. Having said that, mentally it is a downer and I can feel an element of this burnout I predicted.
  • Product Support/Certification : Yep. As predicted, many companies don’t seem to recognise that 18c even exists, let alone support their products on it. If I were charitable I would say they are waiting for 19c as it’s a LTS release, but in reality they are still struggling to check that 12.2 PDBs work for their products. I hope vendors get their act together to provide support for these new versions more quickly. That includes Oracle too.

Unsure

  • Learning : This still concerns me. I got access to 18c straight away on Oracle Cloud and LiveSQL, so really I’ve had nearly a year of 18c. For those people that first experienced it after the on-prem release, they’ve had about 6 months experience and the 19c hype train has started. Now it will still be a year from one on-prem release to the next, but it just kind-of feels like it’s only a 6 month release, if you know what I mean. I’m currently still writing about 18c features, but part of me is thinking, “What’s the point?” My mind is looking forward to 19c. As we move forward I realise each release will be smaller, so working through the new features will not be so heavy, but I’m still worried people (and I really mean me) will disconnect.
  • Certification : I just checked today and they are still pushing the 12cR2 certification. Now this is still relevant, as 18c and 19c are effectively 12.2.0.2 and 12.2.0.3 respectively, but it just sounds bad. Hey, 19c has just been released and I’m working for the 12cR2 certification? I get the distinct feeling certification is dead to me now. Let’s see what Oracle Education do with this. Maybe I’ll change my mind.

Of course, it’s still early days so we will see how the cookie crumbles over the coming releases. I suspect I may be forced to cherry-pick a little.

Cheers

Tim…

PS. A Twitter comment from Frits Hoogland made me feel I should add something. If you are happy with what you have and don’t feel the need to upgrade often, that’s cool. Constantly chasing an upgrade can be problematic because of the instabilities it can cause. The new release cycle is allegedly meant to reduce that by drip-feeding change in smaller, manageable chunks…

Although a DBA may like some of the new features, they affect comparatively few people in the company. I feel development new features are a bigger draw for getting people to buy into the upgrade cycle. Just this week a project started on an existing 11.2 instance, but involved a bunch of JSON functionality, so it was moved across to an 18c instance. The developers only know this functionality is in 12.2 and 18c because I’ve actively promoted it. If I had not done this, they would have stuck with 11.2 and wasted a bunch of time manually coding stuff.

I’m a fan of keeping up with the latest versions, both personally and in the companies I work. In my experience avoiding upgrades and patches tends to cause more problems than keeping relatively up to date. Just my opinion though…