Understanding “occurrences before alerts” in oracle enterprise manager 13c

The Incident Manager within Oracle Enterprise Manager 13c is a powerful tool for monitoring a wealth of target types such as databases, hosts, middleware or just services in general from a bird’s eye view or right down into the manifold details of a dedicated application. As with all powerful means around, where there is a lot of power, there also usually is a lot to do wrong (or even employ counterproductive). This is why it is important to understand the Incident Manager concepts from bottom up and be able to identify the knobs and wheels to poke with to meet a certain requirement.

Basically, Incident Manager is a professional toolset to facilitate the management of non-critical and critical system alerts against metric values (registered as problems and incidents, see About Incidents and Problems) in a larger quantity and time scale along with alert management templating and alert assigment and so forth.


Splitting a btrfs 4.1x root partition with debian live system gparted btrfs tools 3.17-x

This is a short picture log of doing a btrfs 4.1x root partition split on a (down) oracle linux 7.2 using a debian live system applying gparted based on btrfs tools 3.17-x. Lot’s of names and version codecs, right? But this is what matters. The important message is : it works using this flavours.
Actually, running oracle or redhat linux as the live system may have been much more appropriate concerning compatibility reasons. The odd things is, no redhat-based (enterprise) linux system features gparted. Only fedora does, sourcing the epel-repository but not having kinf of a live system release as debian.


Tracking down “ntpdate[18168]: no server suitable for synchronization found”

After installing and getting up ntpd on a RHEL-like Linux system, see for example, you may want to double check iff ntpd is actually able to perform successfully. There’s a couple of shell commands to employ, most notably ntpstat and ntpq as well as timedatectl more recently with version 7 and up systems. ntpstat will tell you about the status of the time synchronisation, whereas ntpq, being executed a few times in a row, shows the servers being selected for synchronisation, the one prefixed by an aterisk as the current master, and the time left since the last synchronisation up the the synchronisation interval in the when and poll columns, respectively. timedatectl furthermore includes timezone and daylight saving information, however, the synchronisation status given here is about to be called into question, see later. So far, iff anything runs fine, you may expect something like this (consider the values changing in the when column for the second call):


Locating kernel headers for vmware tools on an uekr3 oracle linux 6.7

Continuing, if you like, on an admin topic concerning UEKR3 Oracle Linux 6.5, see: Missing kernel-firmware 3.8.13-16.2.1.el6uek on Oracle Linux 6.5, I’ going to give a recipe and some explanations for getting vmtools modules successfully built in a VMware guest after complains about an invalid kernel header path.
Immediately after installing vmtools in a VMware guest, usually using /vmware-tools-distrib/, another script, usually /vmware-tools-distrib/bin/ comes up, asking whether you want to configure vmtools just now. Configuration essentially comprises the opt-in/out of functionality as well as building and integration of kernel modules into the running kernel. Iff you furthermore run a recent UEKR3 kernel without the according development packages, the console output may read like this:

Before you can compile modules, you need to have the following installed... 
kernel headers of the running kernel

Search in repoquery --list kernel-uek-devel-3.8.13-68.3.5.el6uek.x86_64 for GCC...
Detected GCC binary at "/usr/bin/gcc".
The path "/usr/bin/gcc" appears to be a valid path to the gcc binary.
Would you like to change it? [no] 

Searching for a valid kernel header path...
The path "" is not a valid path to the 3.8.13-68.3.5.el6uek.x86_64 kernel headers.
Would you like to change it? [yes] y

Enter the path to the kernel header files for the 3.8.13-68.3.5.el6uek.x86_64 kernel

The path "/usr/include/linux" is not a valid path to the 3.8.13-68.3.5.el6uek.x86_64 kernel headers.
Would you like to change it? [yes] n

WARNING: This program cannot compile any modules for the following reason(s)...

- This program could not find a valid path to the kernel headers of the running
kernel.  Please ensure that the header files for the running kernel are 
installed on this sytem.

[ Press Enter key to continue ] 

What actually happens here is quite simple but however also expressed in a misleading way such that she/he may just suppose, installing the kernel headers will fix the problem (I even tried this /usr/include/linux thing, as of the old days, won’t work you see, is none of uekr3 anyway).


Client-failover for dataguard switchover and failover


The following is nothing more than some extension of the oracle metalink document:

[ID 740029.1] Step By Step Guide On How To Configure And Test Client-Failover For Dataguard Switchover And Failover

That is, the article does not only present the cookbook how-to of its anchestor but also examines what happens in the database and what the clients experience will be concerning a so called transparent application failover (TAF). The scenario has been tested on an oracle on windows, please note that the metalink document points to a some more applicable technique available with oracle 11gR2 (Client Failover Best Practices for Highly Available Oracle Databases: Oracle Database 11g Release 2).

Client-failover for dataguard, away from other failover scenarios, essentially aims at using a general tnsnames entry against some server-side database endpoint, no matter what server-side database instance is currently running in a dataguard primary role. This is actually the transparency in a transparent application failover where the application, client here, does not have to care to switch its network configuration in any way (some simple implementation would be, not uncommonly, to provide some tnsnames.ora, tnsnames.ora.prm and tnsnames.ora.stb and rename the files) during a failover or switchover.