Cluster Time Synchronization bei Solaris Zonen

In der Kundenumgebung hat die korrekte Konfiguration des Cluster Time Synchronization Services (CTSS) der Grid Infrastructure (11.2.) unter Verwendung von Solaris Zonen für Verwirrung gesorgt. Der Aufbau war wie folgt:

Server A mit den Zonen PROD-1 und TEST-1
Server B mit den Zonen PROD-2 und TEST-2

Die Zonen PROD-1/2 und TEST-1/2 bildeten jeweils ein 2-Knoten-RAC.

In der globalen Zone lief ein NTP-Dämon, der die aktuelle Uhrzeit vorgab. In den Zonen war kein NTPD konfiguriert, so dass der CTSSD wie dokumentiert im Active-Mode lief — und das in allen Zonen.

Die Folge war, dass jede Zone aktiv die Uhrzeit nach eigenem Ermessen verstellen konnte. Wenn also PROD-1 der Meinung war, dass die Zeit mit PROD-2 auseinander lief, korrigierte sie die Zeit. Das wiederum hatte Auswirkungen auf TEST-1 (denn die Zeit gilt für alle Zonen), die gegensteuerte. In Folge dessen schaukelte sich die Zeitumstellerei so auf, dass irgendwann keine Zeit mehr die richtige war.

Das korrekte Vorgehen in dieser Konfiguration wäre:

• Konfiguration und Start des NTP-Dämon in der globalen Zone
• Konfiguration des NTP-Dämon in allen lokalen Zonen
• Den Dämon in den lokalen Zonen NICHT (!!!) starten
• Allein die Konfiguration des NTPD reicht aus, damit der CTSSD im Observer-Mode läuft und künftig die Clusterzeit nicht mehr eigenmächtig verändert.

Es reicht hierzu, dass man /etc/inet/ntp.client nach /etc/inet/ntp.conf kopiert. Wenige Sekunden später lässt sich mittels

crsctl check ctss

ermitteln, dass der Cluster Time Synchronization Service nun im Observer-Mode läuft.

ORA-16664 und ORA-00604 beim DataGuard Broker DGMGRL

Bei aus Ausführung des Dataguard Broker DGMGRL bekommt man auf Primärseite einen ORA-16664 und — viel interessanter — auf Standbyseite einen ORA-604. Die Situation stellte sich wie folgt dar:

Primary:
DGMGRL> show
configuration;
Konfiguration – dg_orcl

Schutzmodus:     MaxPerformance
Datenbanken:
orcl  – Primärdatenbank
orclstb – Physikalische Standby-Datenbank
Fehler: ORA-16664: Ergebnis von einer Datenbank kann nicht empfangen werden
Fast-Start Failover:
DISABLED
Konfigurationsstatus:
ERROR

Standby:
Datenbankstatus:
DGM-17016:
Status für Datenbank „orcl“ konnte nicht abgerufen werden
ORA-00604: Fehler auf rekursiver SQL-Ebene
ORA-16625: Datenbank „orcl“ ist nicht zugänglich

Die Lösung war ein LOGON-Trigger, der feuert, wenn sich der User SYS anmeldet. So weit nichts besonderes. Allerdings handelte es sich um den Trigger SYS.LOGON_AUDIT_TRIGGER, der standardmäßig beim SYS-Audit aktiviert ist. Der Fehler bestand darin, dass der DBA gleichzeitig den Audit Trail auf „DB“ eingestellt hat.

Was passiert? Der Trigger schreibt bei jeder Anmeldung von SYS eine Zeile in die Audit-Tabelle. So weit, so gut. Nur leider will er das auch auf der Standby-Datenbank, denn DGMGRL meldet sich ebenfalls als SYS an, kann das aber nicht, weil die Datenbank naturgemäß im MOUNT-Status ist. Das wiederum erzeugt den ORA-604.

Abhilfe schafft hier entweder den Parameter AUDIT_TRAIL nicht auf „DB“ zu setzen, oder das SYS-Auditing ganz abzuschalten. Alternativ könnte man den Trigger so umschreiben, dass er vor der Aktion prüft, ob die DATABASE_ROLE in V$DATABASE zufällig „PHYSICAL STANDBY“ ist — und dann nichts tut.

SQL> show parameter audit_trail

NAME                                 TYPE        VALUE  
------------------------------------ ----------- -----------------------------  
audit_trail                          string      DB

SQL> select owner, trigger_name, status  from all_triggers where triggering_event like  '%LOGON%';  
OWNER                           TRIGGER_NAME                   STATUS  
------------------------------  ------------------------------ --------  
SYS                             LOGON_AUDIT_TRIGGER            ENABLED

SQL> alter trigger  sys.logon_audit_trigger disable;  
Trigger wurde  geändert.  

SQL> alter system  switch logfile;  
System wurde geändert.  

DGMGRL bringt nun keine Fehler mehr.

11g: RMAN-Klon einer bestehenden Datenbank ohne verfügbares Backup

Seit 11.2. kann man mit RMAN aus einer bestehenden und laufenden Datenbank einen Online-Klon erzeugen, ohne vorher ein Backup machen zu müssen. Dies bietet sich z.B. an, wenn man kein transportables Medium zur Verfügung hat, das die bisher notwendigen Backup-Daten aufnehmen kann. Exemplarisch sei hier ein Vorgehen dokumentiert:

Definition: P0 = Quellserver, P1= Zielserver, ORCL = Oracle SID (auf P0 und P1 identisch)
P0 und P1 haben *exakt* die gleiche Verzeichnisstruktur

1. Neuer Klon

1.1. Alle Verzeichnisse anlegen, Orte auf P0 abfragen:
-> select name from v$datafile
-> select name from v$tempfile
-> select member from v$logfile
-> show parameter recovery
-> show parameter control
-> show parameter dump

1.2. Auf P0 ein PFILE aus SPFILE erstellen und auf P1 kopieren

1.3. Password-File von P0 auf P1 kopieren

1.4. Statischen Listener auf P1 erstellen:

SID_LIST_LISTENER =
(SID_LIST = (SID_DESC = (GLOBAL_DBNAME= ORCL.mycompany.com)
(ORACLE_HOME = /u01/app/oracle/product/11.2.0.3/dbhome_1)
(SID_NAME=ORCL)))

1.5. TNSNAMES auf P0 und P1 anpassen

ORCL_P0 =
(DESCRIPTION =(ADDRESS_LIST =  (ADDRESS = (PROTOCOL = TCP)(HOST = <Hostname von P0>)(PORT = 1521)))
(CONNECT_DATA =  (SERVICE_NAME =  ORCL)))

ORCL_P1  =
(DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = <Hostname von P1>)(PORT = 1521)))
(CONNECT_DATA = (SERVICE_NAME = ORCL)) )

1.6. P1 in NOMOUNT starten

1.7. Testen:
-> SQLPLUS sys@ORCL_P1 as sysdba
-> SQLPLUS sys@ORCL_P0 as sysdba
muss von beiden Servern funktionieren

2. Klon erstellen

2.1. Platz auf den verwendeten Filesystemen prüfen

2.2. P1 herunterfahren

2.3. Alle Datendateien von P1 löschen (mindestens aber die Tempfiles)

2.4. P1 in NOMOUNT starten

2.5. Klonen:
# rman
Recovery Manager: Release 11.2.0.3.0 – Production on Tue Aug 21 09:50:36 2012
Copyright (c) 1982, 2011, Oracle  and/or its affiliates.  All rights reserved.

RMAN> connect target sys@ORCL_P1
target database Password:
connected to target database: ORCL (DBID=1247605523)

RMAN> connect auxiliary sys@ORCL_P1
connected to auxiliary database: ORCL (not mounted)

RMAN> run {
2> allocate channel d1 device type disk;
3> allocate channel d2 device type disk;
4> allocate auxiliary channel d3 device type disk;
5> allocate auxiliary channel d4  device type disk;
6> duplicate target database to ORCL from active database spfile nofilenamecheck;
7> }

[…]

Sollte der Zielserver nicht die gleiche Verzeichnisstruktur  haben, oder  sollte sich der DBNAME ändern, oder auch andere  Initialisierungsparameter, ist dies mittels des „CONVERT“- bzw. „SET“-Kommandos zu erreichen; z.B.

duplicate target database
to ORCLC from active database spfile
set „DB_UNIQUE_NAME“=“ORCLC“
set LOG_FILE_NAME_CONVERT ‚/ORCL/‘,’/ORCLC/‘
set DB_FILE_NAME_CONVERT ‚/ORCL/‘,’/ORCLC/‘
nofilenamecheck;

In diesem Fall sind die Listener- und TNSNAMES-Einträge ebenfalls entsprechend anzupassen.

RMAN klont nun die Auxiliary-Datenbank  und öffnet sie mit RESETLOGS. Der Stand der Datenbank ist der von P0 zum Ende des Clonings — das aktuellste Archivelog wird  übernommen.

2.6. Nacharbeiten
z.B. Initialsierungsparameter für die geklonte Datenbank anpassen.

Fertig!

Cluster Events per Mail verschicken

Wenn Sie ohne Software Installation per Mail über Ereignisse in Ihrem Cluster informiert werden wollen, können Sie mit einem Callout Script die wichtigsten Informationen zu Cluster Events protokollieren lassen.

Das Skript finden Sie hier. In diesem Script müssen Sie diese beiden Zeilen anpassen und die E-Mail Adressen eintragen:

echo „from: <Mail Adresse at RAC Server >“ >> $FAN_LOGFILE
echo „to: <Empfaenger at Domain>“ >> $FAN_LOGFILE

Dieses Script in das Callout Verzeichnis vom Grid Home ($GIRD_HOME/racg/usrco) kopieren und mit chmod 755 callout.sh ausführbar machen.

UPDATE: Oracle VM 3.1

Oracle hat kürzlich die Version 3.1 seiner Virtualisierungsumgebung „Oracle VM“ freigegeben. Diese soll sich wiederum als virtuelle Maschine betreiben lassen, so dass man keine freie Hardware benötigt, um den VM-Server testen zu können.

Ich werde, sobald die Zeit es zulässt, darüber berichten.

UPDATE:
Die Deutsche Oracle Anwender Gruppe hat einen Bericht veröffentlicht, der Probleme beim Einsatz von Oracle VM 3 beschreibt:
http://www.doag.org/home/aktuelle-news/article/erhebliche-probleme-beim-einsatz-von-oracle-vm-3.html

Ist ein Single-Node-RAC supported?

Die Frage stellte sich kürzlich bei einem Kunden, der zwar mittelfristig eine Cluster-Landschaft aufbauen wird, zunächst aber mit nur einem Knoten starten möchte.

Da die Dokumentation an keiner (mir bekannten) Stelle auf die Möglichkeit eines 1-Knoten-RACs eingeht (ein RAC besteht laut Oracle-Definition immer aus mindestens zwei Servern), haben wir die Frage an den Oracle Support adressiert.

Die Antwort kam prompt: ja, es ist offiziell supported, ein RAC mit nur einem Knoten aufzusetzen und zu betreiben.

PS: die neue 11g-Möglichkeit, ein „RAC One Node“ zu betreiben, ist nicht Bestandteil der Überlegung. Hier handelt es sich auch lizenztechnisch um etwas völlig anderes.

Oracle provoziert (wieder einmal) Lizenzverstoß

In einem RAC- / Data Guard-Umfeld und Oracle 11g läuft man schnell in die Lizenzfalle: Der Cluster-Manager startet es eine physikalische Standby-Datenbank als default in den READ-ONLY-/OPEN-Modus, wenn der Server neu startet oder man ein

srvctl start database -d orcl

absetzt. Das alleine wäre nicht schlimm, aber eine aktivierte Data Guard Konfiguration appliziert gleichzeitig noch Archivelogs in die Datenbank, während diese als Read-Only geöffnet ist.

Praktisch, mag manch einer denken, doch aufgepasst: die Kombination „zum Lesen geöffnete Datenbank“ und „Data Guard appliziert Archivelogs“ heißt bei Oracle „Active Data Guard“ und ist eine lizenzpflichtige Option der Enterprise Edition.

Das heißt also konkret: eine out-of-the-box-Installation mit Data Guard und RAC führt nach einem Reboot des Standby-Systems oder einem Switchover unweigerlich in die Lizenzfalle.

Die Lösung des Dilemmas beschreibt die MOS Note 1271003.1: CRS Configuration for RAC Primary or Standby Managed via Data Guard Broker

Darin heißt es, dass man den Startup-Modus der Standby-Datenbank mittels

srvctl modify database -d orcl -s mount

ändern soll. So wird verhindert, dass nach einem Reboot des Standby-Servers oder der Datenbank diese wieder in den OPEN-, also den Active-Dataguard-Modus startet.

Nach einem Switchover muss man natürlich daran denken, dass man den Startup-Modus wieder auf OPEN setzt, sonst fährt die dann produktive Datenbank nicht alleine hoch. Die dann Standby-Datenbank muss man im Gegenzug so konfigurieren, dass nun diese nur im MOUNT-Modus startet.

Oracle wird wolkig

Nach Auslieferung des Enterprise Managers 12c (Cloud Control), dessen Sinn sich dem geneigten Betrachter nicht richtig erschloss, erahnt man nun das große Ganze:

Oracle Virtual Server 3.1 steht in den Startlöchern. Diese Version hebt sich bedeutend von 2.x und 3.0 ab; man verabschiedet sich quasi von der reinen Virtualisierungslösung und macht OVM zum ultimativen Tool für die Wolke. Ganz einfach lassen sich mittels der lizenzfreien Software ganze Infrastrukturen „zaubern“, verbinden, starten, stoppen und migrieren. Administriert wird das Ganze, jetzt schließt sich der Kreis, mittels Enterprise Manager 12c.

Einen Eindruck von dem, was Oracle da in den nächsten Wochen auf uns loslässt, soll man schon bald in der „Oracle Public Cloud“ bestaunen können:

http://cloud.oracle.com

Registrieren kann sich jeder und nach dem Lauch soll man (wohl nach Einwurf kleiner Münzen) sich seine eigene Cloud-Infrastuktur „bestellen“ können.

Wir sind gespannt.

Offenes Scheunentor in allen Oracle-Datenbanken

Oracle hat den Security Alert CVE-2012-1675 veröffentlicht, den man wirklich ernst nehmen sollte, denn hiernach ist ziemlich jede Datenbank so gut geschützt wie das berühmte offene Scheunentor.

Details erfährt man u.a. hier

http://www.heise.de/security/meldung/Oracle-aendert-Lizenzmodell-wegen-verplapperter-Sicherheitsluecke-1564995.html

Interessant ist, dass Oracle statt eines Patches einfach das bislang teuer verkaufte SSL-/TLS-Feature lizenzfrei abgibt.

Gefixt ist das ganze wohl, so hört man, in 12c.

11gR2 für Windows verfügbar!

Seit dem Osterwochenende ist die Datenbank Version 11.2 für Windows-Betriebssysteme verfügbar und kann vom Oracle Technet heruntergeladen werden:

http://www.oracle.com/technology/software/products/database/index.html

Damit unterstützt Oracle mit seinem Datenbankprodukt nun auch endlich aktuelle Microsoft-Betriebssysteme wie Server 2008 R2 oder Windows 7.