-
Subscribe
Subscribed
Already have a WordPress.com account? Log in now.
Hello, friends!
Oracle 19c is now available for Oracle Cloud and Exadata. It’s not yet available for “on-premises”, but it will no doubt be available shortly. Well, hopefully.
19c is the terminal release of 12.2, which means that prior to Oracle’s versioning changes, it would have been referred to as 12.2.0.3. As of the time of writing, it will be supported for the next 4 years under Premium Support and 3 years under Extended Support.
This is probably going to be the version that those waiting to pull the plug on upgrading to 12c are going to move to as 18c is still quite buggy (especially for versions < 18.1.5)
Bear in mind that there is no support for 19c on Linux 6. The minimum versions of the O/S and kernels are as follows:
It’s been 17 years since I worked with an Oracle database running on SuSE, but there must be some hiding out there somewhere!
One thing to bear in mind, though, is that the upgrade to 19c on Exadata can be quite painful. If you moved to 18c and found it to be nice and (relatively) easy, don’t be surprised if 19c is trickier.
As we try and contain our excitement, here are some of the features I think are going to be the most useful.
A new video on how to make the most out of Collaborate 2019 is up on my YouTube channel.
Along with some handy tips, I also explain how to score a free Oracle certification exam AND how to get Oracle’s new Autonomous DBA certification!
Alas, my submission for this year’s Oracle OpenWorld was turned down by Oracle a little while ago.
Maybe I shouldn’t have installed this browser extension?
Tee-hee 🙂
I’m nothing if not persistent(ly annoying) – so I submitted a similar abstract to the 2016 RMOUG Training Days.
You know how people complain that Oracle licensing can be very complicated?
Well, Oracle 12.1.0.2 Standard Edition 2 has been released after being announced earlier in the summer. Great, but what about Standard Edition and Standard Edition One?
A bit confused? I know I was.
Basically, SE and SEOne (SE1?) are available options if you’re running a 12.1.0.1 database. However, if you like living your life in the fast lane (as well as making use of some really cool new features) and you’re running 12.1.0.2, both SE and SE1 editions are replaced by SE2.
The licensing restrictions are as follows. The bold emphasis is mine:
“Oracle Database Standard Edition 2 may only be licensed on servers that have a maximum capacity of 2 sockets. When used with Oracle Real Application Clusters, Oracle Database Standard Edition 2 may only be licensed on a maximum of 2 one-socket servers. In addition, notwithstanding any provision in Your Oracle license agreement to the contrary, each Oracle Database Standard Edition 2 database may use a maximum of 16 CPU threads at any time. When used with Oracle Real Application Clusters, each Oracle Database Standard Edition 2 database may use a maximum of 8 CPU threads per instance at any time. The minimums when licensing by Named User Plus (NUP) metric are 10 NUP licenses per server.”
By the way, SE2 does not support multi-tenant. Don’t forget, though, Oracle have deprecated non-“CDB / PDB” architecture from 12.1.0.2 onwards, so you should install SE2 as a single-tenant pluggable database with a container database to follow Oracle’s recommended path.
One wonders whether the “SE2” nomenclature will persist. Will Oracle only offer “Standard Edition 2” and “Enterprise Edition” for Database 13.1?
“What happened to Standard Edition 1?
Why don’t they just call it ‘Standard Edition’?”
I do not know, dear reader. I do not know.
This week, a client encountered a particularly nasty bug – 10194190 – which caused their ASM instance processes to “spin” and cause a bunch of errors, essentially leading to a instance crash on both of their RAC nodes.
In the ASM instance:
ORA-00490: PSP process terminated with error
PMON (ospid: 12345): terminating the instance due to error 490
In the database instance, we either saw an ORA-00240 or ORA-03113 error and an instance crash.
ORA-00240: control file enqueue held for more than 120 seconds
ORA-15064: communication failure with ASM instance
ORA-03113: end-of-file on communication channel
What triggered this was that the uptime of each node was greater than 248 days. On Solaris SPARC systems, there is a bug in the compiler which can cause either a database or an ASM instance crash if the server has been up for more than 248 days.
There are bug fixes available for versions 10.2.0.4 through 11.2.0.4, but there is no fix for any 12c database at the moment.
Larry’s Secret Number?
“248 days”, you ask? Curious, n’est pas? Indeed, especially when you learn that there are another couple of Oracle bugs out there which really seem to fixate on that number.
In a previous life, I encountered bug 4612267 while running the 10.2.0.1 Client for an EDW batch server.
It is looping on the times() function.
In addition to sqlplus, it has been reported that the netca and dbca tools also hang.
Changes
This may happen with a new installation of Instant Client 10.2.0.1.0 or Oracle 10.2.0.1.0 on UNIX platform, or it can just occur after some period of time with no other changes.
CauseThis is a known, unpublished bug.
Bug 4612267 OCI CLIENT IS IN AN INFINITE LOOP WHEN MACHINE UPTIME HITS 248 DAYS
This machine was critical to the enterprise and had to be rock solid, so once we got things stable, the project team were loathe to mess with it, even though it was running 10.2.0.1.
“Not messing with it” also involved maintaining server uptime, because we had a bunch of NFS mounts attached to it, which seemed to somehow cause the server to take a very long time to reboot.
Unfortunately, the platform was a bit too “solid” and we hit bug 4612267 during a particularly busy afternoon of batch processing. As with such things, it took a while to find the culprit, but it ended up being new sqlplus sessions started after 1pm that day on the EDW batch server. The server had been up 231 days.
We looked and we could see the sessions had started, but they had got no CPU time whatsoever. In typical IT fashion, we collected as much diagnostic info as we could and bounced the server. Naturally, the problem went away.
After much head-scratching and seeing the same issue once or twice more whenever the server uptime ranged between 60 and 248 days, we realized we were hitting the bug. As we were using a client install, we couldn’t upgrade to 10.2.0.2 and applying the patch failed for some obscure reason, despite assistance from Oracle Support. We only “fixed” the bug when we upgraded the client to 11g, which was deemed to be too much “messing about” until after our busiest period of the year was over.
Our workaround was to schedule a server reboot, which was a pain, though it was better than the alternative.
I always did wonder why someone would code something which would “spin” if the server uptime was between 60 and 248 days. What does that matter to SQL*Plus? Besides, once you went beyond 248 days of uptime, you were in the clear. This is why it took three years before it was noticed.
I wonder what significance 248 days has with Oracle? Maybe it’s a code which is somehow used to obtain privileged access somewhere in Redwood City? 🙂
As I’m still trying to get my feet under the door at my new gig, here’s another nugget in place of a real blog entry. While troubleshooting for a client, I noted that there were three types of materialized view. I knew this before, sort of, but this troubleshooting exercise was a great aide memoire.
The three types of materialized views:
The read-only MV omits the FOR UPDATE clause in its DDL during creation and does not permit DML.
The updateable MV includes the FOR UPDATE clause in its DDL and is included in a materialized view group. This allows changes made to the MV to be pushed back to the ‘master’ during a refresh.
The writeable MV includes the FOR UPDATE clause in its DDL, but does not belong to a materialized view group. All changes made to the MV are lost during a refresh.
Throughout my work week, I often learn something new and unexpected about my travels. Instead of writing a full blog post about the subject, I figure I’ll occasionally post these as “nuggets” – bite-size chunks which are easily digested!
Here is today’s “nugget”:
Oracle GoldenGate is certified to capture data from E-Business Suite databases, but it cannot be used to apply data to E-Business Suite databases.
This includes writing back to the source database in an active-active configuration.
Are you running Exadata Storage Server 12.1.2.1.0?
Have you tried to get a graphical tool, such as DBCA, DBUA or even VNC to run on your Exadata lately?
If, like me, you had quite the struggle until a friendly sysadmin installed a bunch of packages for you, you might be interested in reading this MOS note:
1969308.1 – Unable to run graphical tools (gui) on Exadata 12.1.2.1.0 or later.
I understand that Oracle have been increasingly hardening Exadata since the birth of their X3-2 machines, but you’d think that you wouldn’t need to add extra packages to a system that’s meant to be “ready to use” once your choice of consultant has finished with the Deployment Assistant.
After all, aren’t DBCA / DBUA Oracle’s tools of choice? Do they really want DBAs to spend their time creating response files and running these tools from the command line?
Odd.
It Was Like That When I Got Here 