Oracle Tools

Enterprise Manager 13c – Change Memory Settings with emctl

In Enterprise Manager Grid Control 11g, changes in the Oracle Management Server JVM memory settings could be done in a file called startEMServer.sh located in a domain subdirectory like /u00/app/oracle/product/gc_inst/user_projects/domains/GCDomain/bin/

And after an OMS restart, the JVM has used this new settings for the OMS.  Since 12c, it can be done by an emctl command.

emctl – Get your actual Settings OMS_HEAP_MAX

emctl – Change the Value

For example, the Memory will be resized to 2304M.

Verification

Restart your Oracle Management Server. In one of my tests this did not work. The OMS still used the old memory value. Another start/stop with emctl stop oms -all has worked.

The new value is now active:

In Linux, you can search for the java process with ps -ef | grep “java -server -Xms256M -Xmx”  – here are the first lines from my output where the Xmx parameter is located:

As you can see, the -Xmx Parameter is now set to 2304M, the Java virtual machine for EMGC_OMS1 is now using 2304M.

Link

Enterprise Manager Cloud Control Advanced Installation and Configuration Guide – Sizing Your Enterprise Manager Deployment

Oracle Enterprise Manager 13c – KILL SESSION for Application Administrators – Part 1

Basically to execute a ALTER SYSTEM KILL SESSION command you have to be a) a DBA or b) you need the ALTER SYSTEM privilege. Granting the ALTER SYSTEM privilege to a Non-DBA has big risks. This user is now able to change a lot of parameters like memory parameters, NLS settings etc.

In one of my projects, a small team of well known application administrators is having a read-only account in Enterprise Manager 12c to verify the performance, see the user sessions and many more of their subset of databases. And sometimes, they have to kill a hanging Oracle session. Until now they called the DBA: “Please do it for me”. Sure, we can build a small PL/SQL procedure on every database and give them the executions rights so they can kill a session in their terminal theirself. But this is not very user friendly.

Here is an approach to manage the small path between security and manageability. I am aware that this is – like we say in Switzerland – a “Kompromiss”. But in fact we have implemented this solution in a production environment two months ago without any negative impacts.

Note: All the steps which are show below in Enterprise Manager 13c can be executed in 12c too.

The Concept

  • we create a new database user in the target databases
  • we create a new role with ALTER SYSTEM privilege in the target databases
  • we enable auditing for ALTER SYSTEM commands in the target databases
  • we create a new Enterprise Manager role for the application administrators
  • we create a new named credential with the new user and grant it to the application administrators
  • we build an Enterprise Manager report which shows us the ALTER SYSTEM actions based on a metric extension

The New Database User

This user has to be created in every target database.

The New Database Role

This role has to be created in every target database.

Grant role to the user:

Enable Auditing for ALTER SYSTEM Commands

For ALTER SESSION and ALTER SYSTEM:

Verify the enabled audit settings:

Verify the audit parameterin the target database. If audit_trail is not set to EXTENDED, the SQL command which was executed is not recorded. How it works with Unified Auditing will be verified in a later blog post.

In the example below you can see the difference in the column SQL_TEXT.

Enterprise Manager Role

Setup – Security – Role – Create

em13c_role1

Set name and description – Next

em13c_role2

Next

em13c_role3

Activate the checkbox for the privilige Connect to any viewable target and scroll down

em13c_role4

Add database targets and set the Manage Targets Privilege Grants

  • For EM12c use: View
  • For EM13c use: Manage Database Sessions

Next

em13c_role5b
Next

em13c_role6

Select the user to grant the role – Next

em13c_role5b

Finish

em13c_role8

The role is now created and be granted to a user.

em13c_role9

Enterprise Manager Named Credential

The application adninistrators don’t have to know the password for the created user with the ALTER privileges. We create a named credential and give the admins the permission to use it.

Setup – Security – Named Credentials – Create

Set Credential Name, Authenticated Target Type, Credential Type and set Scope to Global. The Credential Properties are according to our new created user APPL_ADMIN.

Scroll down to set Access Control

em13c_nc1

Add Grant

em13c_nc2

Search for the user, in my case it is APPL_BERGER

Select

em13c_nc3

Feel free to test ist against a target which contains the APPL_ADMIN user.

Save

em13c_nc5

Test

Now we test the configuration. The role APPL_ADMIN was granted to my user APPL_BERGER. On the target database TVD12 user SCOTT has locked some data.

em13c_test1

On the target site we go to the Blocking Sessions page

em13c_test2

The Named Credential is already filled in.

Login

em13c_test3

Select the session – Kill Session

em13c_test4

Confirm the action to kill the selected session immediate – Yes

em13c_test5

Session has been killed.

em13c_test6

Verification

On the target database, an audit record was generated. Login as user SYS and execute this query. You can see the TIME, the USERNAME, the EM13c USERNAME in column CLIENT_ID and the SQL statement which was executed in background.

Summary – Part 1

As I said in the introduction, giving some other users than DBAs the ALTER SYSTEM privilege is risky. But when the DBAs and application adminstrators are working as a team, then this can be a possible solution to make their daily business easier.

In the next blog post I will show how you can create a Enterprise Manager report based on a Metric Extension to produce daily reports of the ALTER SYSTEM actions.

EM12c Agent – java.lang.OutOfMemoryError: Java heap space

After an AIX 7.1 server reboot, there was one agent which did not started. The command emctl start agent resulted in a java.lang.OutOfMemoryError: Java heap space message. In the agent subdirectory some dumpfiles were created:

First I took a look in the agent logfiles to gather more information.

/u00/app/oracle/product/agent12c/agent_inst/sysman/log/emdctlj.log

There are a log of MOS notes available for the search term peer not authentificated, but none of them were helpful.

/u00/app/oracle/product/agent12c/agent_inst/sysman/log/emagent.nohup

Here we see that the EM12c agent had a JVM memory problem at startup. Let’s try out the emctl clearstate agent command.

emctl clearstate agent

From the Oracle documentation about the clearstate command – http://docs.oracle.com/cd/E29597_01/doc.1111/e24473/emctl.htm#r21c1-t27

emctl clearstate Clears the state directory contents. The files that are located under $ORACLE_HOME/sysman/emd/state will be deleted if this command is run. The state files are the files which are ready for the agent to convert them into corresponding xml files.

The emctl clearstate agent command produced the same error:

After some research in My Oracle Support for OutOfMemoryError: Java heap space, I found this note:

Duplicate 1952593.1 – EM12c: emctl start agent Fails With ‘ Target Interaction Manager failed at Startup java.lang.OutOfMemoryError: Java heap space’ reported in gcagent_errors.log (Doc ID 1902124.1)

From the MOS note:

  1. Kill any leftover process -> not for me, the agent was no started at all
  2. Move old files from  /agent_inst/sysman/emd/state/* to a new directory -> sounds very interesting
  3. Execute clearstate command -> let’s try it out

The directory u00/app/oracle/product/agent12c/agent_inst/sysman/emd/state/

There was a lot of stuff in this directory – time to move:

emctl clearstate agent – 2nd run

Now the clearstate command has worked without errors.

emctl start agent

The start was successful – fine.

Summary

The cleanup of the state directory solved the problem. But why does a emctl clearstate agent command not clean up the state directory as described in the documentation? Aaah, and do’t forget to clean up the moved files. They are not needed anymore.

Oracle 12c – Zwei Minuten bis “Connected to an idle instance.”

Ausgangslage

  • Eine neue 12c Installation auf einer AIX 6.1 LPAR
  • Auftrag Upgrade einer bestehenden 11.2.0.4 Datenbank mit der “Out-of-Place” Variante auf 12.1.0.2
  • Die Installation der 12.1.0.2 RDBMS-Software lief sauber durch

SQL*Plus bleibt hängen

Nach der Installation der 12c Software habe ich auf dem Server versuchsweise die Variable ORACLE_HOME auf das neu erstellte Verzeichnis gesetzt, um rudimentär SQL*Plus zu testen. ORACLE_SID wurde auf einen Dummy-Wert gesetzt damit die Meldung “Connected to an idle instance” angezeigt werden sollte. Doch wie heisst es immer so schön: Erstens kommt es anders, zweitens als man denkt!

Nach ungefähr 2 Minuten kam dann endlich der gewünschte SQL> Prompt

Auf einem anderen Server konnte das Verhalten mit einer Dummy-SID nicht reproduziert werden, da funktionierte der lokale Verbindungsaufbau verzögerungsfrei.

Interessant war auch, dass es keine Wartezeit gab wenn man mit dem 12c SQL*Plus auf eine laufende Datenbank zugreifen wollte. Nur wenn die Datenbank nicht verfügbar war oder eine Dummy-SID verwendet wurde, gab es mit dem 12c SQL*Plus die Verzögerung.

Mit SQL*Plus der alten 11.2.0.4 Installation gab es überhaupt keine Probleme. Weder mit einer Dummy-SID noch mit einer gestoppten Instanz.

Analyse 1 – truss -d

Als erstes habe ich es mit einem truss -d versucht um das Verhalten von sqlplus genauer zu analysieren. Und hier an dieser Stelle war die Wartezeit. Wir sehen dass ziemlich genau 120 Sekunden verstrichen sind bis es weitergeht.

Ein Trivadis-Kollege hat mich darauf aufmerksam gemacht, dass es für Linux einen 12c Bug gibt, wo SQL*Plus ebenfalls an der Stelle bevor das File oraus.msb gelesen wird hängen bleibt. Da hier aber AIX im Einsatz ist habe ich bei Oracle einen Service Request eröffnet.

Analyse 2 – Umgebungsvariablen

Parallel zum eröffneten Service Request habe ich nach weiteren Hinweisen gesucht. Dabei habe ich alle Umgebungsvariablen für den User oracle analysiert, deaktiviert und in einem neuen Terminalfenster Variable für Variable schrittweise neu gesetzt.

Nach einem Login auf den Server als user oracle mit nur wenigen gesetzten OS-Variablen funktionierte SQL*Plus problemlos (“Connected to an idle instance”). Es musste also an einer der Variablen liegen.

Nachdem ich bereits 50 Umgebungsvariablen durch hatte, blieb ich bei der Variable TNS_ADMIN hängen. Das hängende Verhalten trat ein, sobald diese gesetzt war.

TNS_ADMIN

Das TNS_ADMIN Verzeichnis beinhaltete vier Files:

Mein Blick fiel auf das vierte File, das ldap.ora. Denn das wurde hier in diesem Umfeld eigentlich gar nicht benötigt, LDAP war in diesem Oracle-Umfeld nicht im Einsatz. Das File beinhaltete die LDAP-Verbindungsdaten wie DIRECTORY_SERVERS, DEFAULT_ADMIN_CONTEXT und DIRECTORY_SERVER_TYPE.

Test ohne ldap.ora

Ein erster Test ohne das ldap.ora File führte bereits zum gewünschten Erfolg. Sowohl die Verbindung zu einer Dummy-SID als auch zu einer Instanz welche runtergefahren war passierte verzögerungsfrei.

Diese Info habe ich auch My Oracle Support mitgeteilt.

My Oracle Support

Mit meiner Information konnte der Herr von My Oracle Support innert Kürze was anfangen.

I found that actually there is a bug opened for this kind of issue as : Bug 20562898 – CONN / AS SYSDBA TAKES MORE THAN A MINUTE ON A NOT STARTED INSTANCE

Reason:
LDAP port is blocked by firewall

Solution:
As a solution you may either apply patch or remove $ORACLE_HOME/network/admin/ldap.ora and $ORACLE_HOME/ldap/admin/ldap.ora if exists.

Fazit

Mit den angegeben Vorschlägen von My Oracle Support kann ich arbeiten. Das Entfernen vom nicht mehr benötigten ldap.ora File hat den gewünschten Effekt gebracht. Den Patch habe ich testweise einfach mal angefordert.

Noch offen ist meine Anfrage wieso

  • a) das bei 11g problemlos geht
  • b) wieso Oracle das File ldap.ora verwendet, selbst wenn im sqlnet.ora nur NAMES.DIRECTORY_PATH = (TNSNAMES) drin steht

TVD-HA – Data Guard im Schnelldurchgang

Trivadis Toolbox

Die Trivadis Toolbox – http://www.trivadis.com/de/infrastructure-toolbox – beinhaltet verschiedene Werkzeuge und Komponenten, um den täglichen Datenbankbetrieb zu vereinfachen und zu standartisieren. Jede der Toolbox-Komponenten ist eine Sammlung von Scripts, Tips und Tricks für den Betrieb, Unterhalt, Automatisierung und Monitoring von Oracle Datenbanken und Middleware.

TVD-HA und Aufbau von Oracle Data Guard

Meine Lieblingskomponente aus der Trivadis-Toolbox ist TVD-HA – http://www.trivadis.com/de/tvd-hatm – ein Paket für Setup und Monitoring von Oracle Data Guard und RAC Cluster. Ich verwende TVD-HA, um schnell und einfach Data Guard Umgebungen aufzubauen.

Um eine Data Guard Umgebung aufzubauen sind manuell viele einzelne Schritte notwendig:

  • Anpassung vom Listener
  • Erstellen der Verzeichnisstrukur für die Standby-Umgebung
  • Kopieren und Anpassen von Parameter- und Passwortfile
  • Standby Datenbank aktiv oder aus der Sicherung erstellen
  • Standby Redo Logfiles erstellen
  • Erstellen eines Read-Write Triggers für den Service
  • etc.

Mit TVD-HA reduziert sich der Aufwand auf ein Minimum und es wird sichergestellt, dass die Standby-Datenbank analog der Primary-Datenbank aufgebaut ist. Dabei wird die Standby je nach Wunsch aus dem Backup oder via Active Duplicate erstellt und Data Guard fixfertig konfiguriert.

dgadd.ksh – Erstellen einer Standby-Datenbank

Das Script dgadd.ksh – Bestandteil von TVD-HA – erstellt die Standby-Datenbank interaktiv oder mit einem Konfigurationsfile im Hintergrund. Umfangreiche Pre-Checks stellen sicher, dass keine Konfigurationsfehler übernommen werden und alle Parameter richtig gesetzt sind, bevor die Standby erstellt wird.

Ein Beispiel für den Aufbau:

  • Primary: TVD12CDA_SITE1 – solothurn.trivadistraining.com
  • Standby: TVD12CDA_SITE2 – olten.trivadistraining.com

Da hier kein Konfigurationsfile mitgegeben wurde, wird die Erstellung interaktiv durchgeführt. Ein paar Auszüge:

Das Ergebnis ist eine voll funktionsfähige Data Guard Umgebung:

Monitoring mit TVD-HA

Wer eine Enterprise Monitoring Lösung sein eigen nennt wie Oracle Enterprise Manager Cloud Control 12c, hat ein komplettes Data Guard Monitoring zur Überwachung von Log-Transport Gaps, Apply-Problemen bereits inbegriffen. Da sich EM12c Cloud Control aber nur für grössere Umgebungen lohnt, kann man seine Oracle Data Guard Umgebung mit TVD-HA überwachen. Das Script heisst dgmon.ksh, erkennt Switchover-Aktionen, Konfigurationsänderungen und Gaps aller Art. Wird ein Problem erkannt, so wird unmittelbar ein Email verschickt. Hier wurde beim Check der Switchover erkannt:

TVD-HA bietet noch mehr

Das Erstellen einer standartisierten Standby-Umgebung mit der Toolbox-Komponente TVD-HA war noch nie einfacher. Das Erstellen einer Standby-Datenbank mit dgadd.ksh und das Monitoring mit dgmon.ksh sind nur zwei der zahlreichen Möglichkeiten welche die Komponente bietet. Weitere Funktionen zur Logfile-Analyse oder Scripts zum Erstellen von RAC-Services, VIP-Adressen etc. gehören auch dazu.

Für weitere Informationen wie Preise, Verfügbarkeit etc. einfach hier klicken: