The other day, I was obsessing over an alert in Oracle Enterprise Manager Cloud Control 12c Release 4, because the error message was cryptic. In the Incident Manager console, I got the following line for an Oracle Database 12.2 target :
I expected to have some value or an explicit error message. I did not understand why I would get an “ORA-00942: table or view does not exist”. When drilling down on this alert, I noticed it belonged to a Metric Group called “Deferred Transactions” (and of course I had no idea what it was) :
But I still did not understand why I would get such an error (instead of a numeric value for example) and why the Event Type was “Metric Evaluation Error”.
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 18.104.22.168.
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.
By chance, right after my “ODC Appreciation Day” post, I’ve been asked to convert a database from character set WE8ISO8859P1 to AL32UTF8 with DMU. Apart from a few well-known issues described in MOS note 2018250.1, I got a “Need conversion” row on table WRI$_SQLSET_DEFINITIONS in data dictionary.
Section D.11 of MOS note 2018250.1 states that you can remove “Invalid Binary Representation” in AWR tables (WRI$_%, WRH$_%, WRR$_%) by following MOS note 782974.1 to drop and recreate AWR. I tried this solution as a last resort. Unfortunately, after using catnoawr.sql, most of WRI$_% tables are still there, only 3 of them are dropped. And of course, WRI$_SQLSET_DEFINITIONS remains intact.
I currently work on a 4-node cluster with 22.214.171.124 Grid Infrastructure installed, hosting several 11g and 12c databases. As it is a cold failover cluster, databases are not RAC databases and are active on only one node at a time.
Thoses databases share the same action script. The “start” section of this action script is quite complex and also manages the relocation of the database target on Enterprise Manager 126.96.36.199. But this specific task is time-consuming (approximately 30 seconds for 1 target) and is not always successful. Which means I often have to relocate some targets in Enterprise Manager by hand.
Recently, 2 nodes of our cluster did not survive a major storage outage. After their reboot, the databases restarted (quite slowly) according to the action script. But target relocation did not work as expected for all targets and I had to manually fix the mess.
When I first started as a DBA two years ago, the colleague in charge of my training thought that I would rather use several GUIs to complete most of the tasks. He said it was because of my age … But he quickly found out that I was more comfortable with CLIs.
For this very first blog post, I would like to participate in the ODC Appreciation Day and talk about a tool I really recommend : EM CLI.