Grid Control und die Sommerzeit

Wie bereits befürchtet, hat uns die Zeitumstellung am gestrigen Sonntag bei Grid Control Probleme bereitet. Ganz knapp: Nahezu alle unsere Datenbanken hatten den Status Pending und konnten nicht mehr überwacht werden.

Stoppen und Starten des Agenten via emctl ist genausowenig hilfreich wie die Erneuerung der Grid Control Konfiguration.

Das Internet brachte einmal mehr die Lösung:

1. Stoppen des Agenten

oraadmin@deerlf0vl1 [AGENT]  /opt/oracle/oraadmin/admin/AGENT
> emctl stop agent
Oracle Enterprise Manager 10g Release 4 Grid Control 10.2.0.4.0.
Copyright (c) 1996, 2007 Oracle Corporation.  All rights reserved.
Stopping agent ... stopped.

2.  Zurücksetzen der Zeitzone

oraadmin@deerlf0vl1 [AGENT]  /opt/oracle/oraadmin/admin/AGENT
> emctl resetTZ agent
Oracle Enterprise Manager 10g Release 4 Grid Control 10.2.0.4.0.
Copyright (c) 1996, 2007 Oracle Corporation.  All rights reserved.
Updating /opt/oracle/oraadmin/product/10.2.0.4/initial/agent10g//sysman/config/emd.properties...
Successfully updated /opt/oracle/oraadmin/product/10.2.0.4/initial/agent10g//sysman/config/emd.properties.
Login as the em repository user and run the  script:
exec mgmt_target.set_agent_tzrgn('deerlf0vl1.erlf.siemens.de:3872','Europe/Berlin')
and commit the changes
This can be done for example by logging into sqlplus and doing
SQL> exec mgmt_target.set_agent_tzrgn('deerlf0vl1.erlf.siemens.de:3872','Europe/Berlin')
SQL> commit

3. Verbindung mit sqlplus wie gefordert

SQL> exec mgmt_target.set_agent_tzrgn('deerlf0vl1.erlf.siemens.de:3872','Europe/Berlin')
SQL> commit;

4. Agent neu starten
emctl start agent

Et voila .. unser Ziel schaltet in der Ansicht von Grid Control wieder auf verfügbar um.

Interessanterweise trat dieses Problem nicht bei allen Datenbanken auf – warum kann ich im Moment noch nicht sagen.

Ergänzung: Es ist wichtig die Schritte in der absolut richtigen Reihenfolge auszuführen:

1. emctl stop agent
2. emctl resetTZ agent
3. SQL set_agent_tzrgn
4. emctl start agent

Update: Eine interessante Entwicklung: Ich stieß ein Script an, welches eben diese vier Schritte auf allen Solaris-Zonen ausführen sollte. Nachdem das geschehen war, kamen die entsprechenden Datenbanken wie gewünscht wieder online .. und dazu auch alle anderen Datenbanken. O_o

Das heisst: Tatsächlich muss das Problem an einem mir nicht bekannten Agenten gehangen haben und dessen Sauberstellung sorgte dann dafür, dass sich überall – sogar bei den Windowsmaschinen – die Klemme von allein löste. Faszinierend. :/

Controlfiles bei 11.1.0.7

Ein für mich neues Feature von 11.1.0.7 (ich habs bei 11.1.0.6 nicht getestet): Offenbar werden die Controlfiles nur noch zum starten und stoppen der Datenbank benötigt.

Der Entdeckung ging ein „klassisches“ Recovery-Szenario zur Übung voraus: Verlust sämtlicher Kontrolfiles der Datenbank.

Bei 9.2.0.8 und 10.2.0.4 ergibt der Versuch etwas über die DB-Struktur zu erfahren folgenden Fehler:

SQL> select name from v$tempfile;
select name from v$tempfile
                 *
ERROR at line 1:
ORA-00210: cannot open the specified control file
ORA-00202: control file: '/opt/oracle/orarman/oradata/RAPOS/control_1/RAPOS_01.ctl'
ORA-27041: unable to open file
SVR4 Error: 2: No such file or directory
Additional information: 3

Bei 11.1.0.7 habe ich dagegen überhaupt kein Problem: Brav wird mir die Struktur angezeigt, ich kann Änderungen vornehmen (Datenfiles adden beispielsweise) und schliesslich sogar ein alter database backup controlfile to trace durchführen.

Erst wenn ich versuche die Datenbank immediate herunterzufahren bekomme ich einen Fehler – und sobald ich sie mit abort in den Sand gesetzt habe, kann sie natürlich nachher nicht mehr starten.

Das Recovery ist jedoch denkbar einfach: Solange die Datenbank noch läuft, wird mit alter database backup controlfile to trace ein Trace erzeugt und anschließend benutzt. Sogar die noresetlogs-Version funktioniert tadellos.

Waitevents beim Erstellen eines OMS

Nachdem nun seit einigen Tagen Grid Control in Version 10.2.0.5 für Windows und Linux verfügbar ist, habe ich mich entschlossen einen ersten Test durchzuführen. Dafür sollte die brav laufende OMS-Landschaft (Repository auf 10.2.0.4, ein OMS auf Windows, ein OMS auf Solaris) nicht angetastet werden.

Also installierte ich auf einer freien Maschine zuerst eine 10.2.0.1 DB-Software samt Datenbank in Defaulteinstellung und schob dann die Installation des OMS in Version 10.2.0.2 an.

Dabei waren an der Datenbank noch ein paar Extraeinstellungen notwendig:

• session_cached_cursors auf mindestens 200
• aq_tm_processes auf mindestens 1
• DBMS_SHARED_POOL erstellen: @?/rdbms/admin/dbmspool

Danach lief der Installer brav an .. und lief .. und lief .. und lief …

2 Stunden später begann ich mich ernstlich zu fragen, was da eigentlich noch passierte.

Ein Blick in v$session_wait zeigte mir knapp 20 sehr lange andauernde Waits der wait_class <b>Scheduler</b> mit dem Even: <b>resmgr:become active</b>.

Mhm. Noch nie gesehen. Danach schaute ich in v$sql um zu sehen, ob überhaupt etwas neues kommt – Fehlanzeige.

Google hilft weiter:

resmgr:become active (Oracle 10g and higher)

* Meaning: Preventing database connections due to an active QUIESCE session
* Optimization steps:

Generally, this wait situation occurs when you execute certain EMCA operations such as the operation for creating the EM repository. As a result of these operations, the systems implicity switches to QUIESCE mode. Therefore, all database connections (except users SYS and SYSTEM) must wait for „resmgr:become active“. In this case, refer to Note 1044758 and execute the following command if necessary:

ALTER SYSTEM UNQUIESCE;

Nach diesem schönen Statement verschwanden die Waits augenblicklich, v$sql wurde mit neuen Anweisungen geflutet .. alles lief weiter.

Wunderhübsch.