Following the first part of this blog serie, here are some new useful functions to automate CDB lifecycle on Exadata Cloud at Customer. Please make sure to read the previous post first, as it contains all the rudiments to build the PL/SQL package.Continue reading
Exadata Cloud at Customer offers a very convenient method to manage your Oracle Database Exadata Cloud Services : REST APIs \o/
I am currently working on a PL/SQL package to interact with Exadata instances, from a central administrative database. Let’s see, step by step, what are the prerequisite to achieve this goal. (Note : I am currently learning PL/SQL, and I use Trivadis PL/SQL Cop, especially the very useful plugin for SQL Developer.)Continue reading
Following up with this blog post, here is a quick overview of what is performed on Exadata Cloud at Customer nodes when a Grid Infrastructure patching is launched via the web interface, the Oracle Cloud control plane.
The whole patch process is not that different from the precheck process. Most of the steps are similar, and of course, the main difference is that the Opatch command actually … patches the Grid Infrastructure 😉
Let’s launch the patching process with a simple click on the Oracle Cloud control plane (sorry for the Fren-Glish screenshots …) :Continue reading
I am now exploring the brand new Grid Infrastructure patching method for Exadata Cloud at Customer. With Exadata Cloud at Customer version 184.108.40.206, it is now possible to patch Grid Infrastructure with a few clicks in the GUI. Let’s see exactly which steps are performed.
First, with my preferred method (CLI 🙂 ), I run opatch against Grid Infrastructure home to check the current patch level :
28656071;OCW RELEASE UPDATE 220.127.116.11.0 (28656071) 28655963;DBWLM RELEASE UPDATE 18.104.22.168.0 (28655963) 28655916;ACFS RELEASE UPDATE 22.214.171.124.0 (28655916) 28655784;Database Release Update : 126.96.36.199.181016 (28655784) 28547619;TOMCAT RELEASE UPDATE 188.8.131.52.0 (28547619)
Since the GUI now shows when a new patch is available for Grid Infrastructure, there is a new
Exadata Grid section with a
precheck option in its burger menu :
(Photo by Joël Assuied, on Unsplash)
I just started working on Exadata Cloud at Customer. And with this, come my first mistakes 😉
One of my compute node had all cloud tooling scripts located in the adequate directories :
# ls -l /var/opt/oracle/exapatch/ [...] -r-xr-xr-x 1 oracle oinstall 0 Feb 4 21:23 exadbcpatchsm -r-xr-xr-x 1 oracle oinstall 0 Feb 4 21:23 exadbcpatchmulti -r-xr-xr-x 1 oracle oinstall 0 Feb 4 21:23 exadbcpatch [..]
but for an obscure reason (made of failed update combined with full filesystem), they were all emtpy.
(Photo by Alex Guillaume, on Unsplash)
I recently encountered a problem, for which I do not have any clue yet. But at least, I have a workaround. The goal of this blog post is to remember the exploration towards this workaround. And then to switch back to a normal sitution when possible.
For some reason, 120 development databases were configured to use Shared Server Architecture. The day after this change of configuration, a lot of users started complaining about a fully-automatized-0-problem-encountered-in-the-last-2-years-procedure to duplicate a production database to development database … Indeed, this procedure begins with stopping target database, and this day, failed almost everytime during this step … Why ?
(Photo by Alfons Morales, on Unsplash)
There are several ways to dig for precious information in listener logs, for example this method described by Arup Nanda or this one by Liron Amitzi.
I currently work in an environment with 40+ servers and 550+ databases managed by Grid Infrastructure. I recently wanted to help a colleague who was experiencing problems with a brand new installed application. Her application should connect to a database in another VLAN. Our first intuition was to check if the application could, at least, reach the database. Since the database resides on a Grid Infrastructure cluster, it would have been tedious to check all (scan-) listener logs spread accross all servers. This is where Splunk has proven useful.
(Photo by Johannes Plenio, on Unsplash)
Conferences are great. Not only for the technical content, also for the people. Recently during DOAG, I had very interesting conversations (yes, several conversations 🙂 ) with Martin Berger about how to control who is connecting to which database in a complex environment. Among other topics, we mentioned that it was possible, starting with Oracle 12.2, to set Access Control Lists to allow connections to a database service (in Non-CDB or PDB) from specific IP addresses.
This new feature Database Service Firewall was introduced with Oracle 12.2. It should not to be confused with Database Firewall, which is a dedicated system used to monitor traffic from and to databases, and is part of Oracle Audit Vault and Database Firewall product.
As I never used Database Service Firewall, I decided to give it a try in a Multitenant environment with RAC.
My lab is a 2-node RAC cluster with Grid Infrastructure 18, a 18.3 RAC Container database called
metal, and one pluggable database called
(Picture by Rodion Kutsaev, via Unsplash)
I like CLIs. I really like CLIs. Especially when 90% of my previous and quite long blog post can be summarized with only 3 commands 🙂
It was about creating restricted read only access for users, using a role and a named credential. But EM CLI can greatly simplify this task. To better understand what follows, please read the previous post explaining how to Create READ ONLY + AWR access on database targets in Oracle Enterprise Manager 184.108.40.206 first.
A critical application is recently having a creepy behaviour in production, so its developers are willing to understand what is going on in the database and troubleshoot in an effective way. Let’s give them access to all the databases related to this application throught Oracle Enterprise Manager 220.127.116.11.
The following procedure is mainly relevant with this version, as Oracle Enterprise Manager 13c has a new set of privileges that should be more appropriate.