Seiten

Samstag, 26. Januar 2013

APEX 4.2: Apex-Listener-Installationshürde "images"

Ich habe diese Woche erstmals APEX 4.2 auf einer 11.2.0.3-DB installiert. Obwohl die Installation fehlerfrei durchlief, wurde die Loginseite nicht angezeigt bzw. lieferte einen Javascriptfehler: "...'apex' is undefined..."
[edit]04.02.2013: Ich war etwas ungenau. Die APEX-Installation selbst war sehr einfach und lief fehlerfrei durch. Probleme bereitete nur der APEX-Listener, den ich statt des HTTP-Servers nutze.[/edit]
Das hat mich Nerven gekostet, obwohl ich früh die richtige Idee hatte: APEX Der APEX-Listener kannte das Verzeichnis nicht, in dem sich die Grafiken/images befanden.
Hätte ich diesen niegelnagelneuen Community-Tip gekannt, wäre ich ein paar graue Haare ärmer. :)
Update:
Das hatte ich ganz vergessen zu schreiben: Die Lösung des Problems war, das images-Verzeichnis aus dem Installationspaket an die richtige Stelle im ORACLE_HOME zu kopieren:
Das alte Verzeichnis habe ich sicherheitshalber gesichert. (hier als images_11.2.0.3)

Update (19.03.2013): Der Vollständigkeit halber hier noch eine Ergänzung zur Konfiguration des APEX-Listeners

Der APEX-Listener legt seine Dateien in einem eigenen Verzeichnis an, welches man beim ersten Start in einem Dialog konfiguriert.
In diesem Verzeichnis liegen unter anderem diese beiden interessanten Dateien:
<LISTENER_CONFIGFOLDER>\apex\apex.properties
<LISTENER_CONFIGFOLDER>\defaults.XML

in der Datei apex.properties findet sich die Pfadeinstellung zu den Images und die Portnummer:
#Tue Mar 18 18:05:16 CET 2013
#apex.images.do.not.prompt=true
apex.images=d\:\\oracle\\product\\11.2.0\\dbhome_1\\apex\\images\\
http.port=8080

Donnerstag, 24. Januar 2013

Soft Skill

"One reason that women love men who are oracle professionals: we're not afraid to 'commit'."
( Steve O'Hearn, "SQL Certified Expert Exam Guide", S.112, Chapter 3)
Ein Fall von Zweckoptimismus? :)

Sonntag, 13. Januar 2013

SAP HANA

SAP macht mit HANA Schlagzeilen und hat es damit sogar in die FAZ geschafft. ("Die neue Walldorfschule" - 05.01.2013) Es ist also Zeit, sich mal genauer damit zu befassen.
Worum geht es? Zunächst: HANA ist nicht nur eine Datenbanksoftware, sondern eine Appliance. Man kauft also Soft- und Hardware von SAP:
"SAP In-Memory Appliance (SAP HANA) ist eine flexible, vielfältig einsatzfähige In-Memory Appliance. Sie umfasst eine Kombination aus unterschiedlichen SAP-Software-Komponenten und maßgeschneiderter Hardware, die führende SAP-Partner bereitstellen." (SAP)
Alles was auf dem System gelesen, geschrieben, berechnet wird, passiert im RAM, welches auf der HANA bis 2 TB groß sein kann. Die Hardware ist letztlich dafür da, die Schreiboperationen sicher von der oder auf die Platte zu bringen.
Das In-Memory-Konzept ist nicht wirklich neu und schon gar keine SAP-Erfindung. SAP setzt die Konzepte aber konsequent um:
  • In-Memory - alles liegt im RAM und wird dort verarbeitet.
  • Spaltenbasierte Verarbeitung der Datensätze - nicht zeilenweise wie bei RDBMS. Spalteninhalte lassen sich so schneller auswerten. Das ist ein klares Plus für die Auswertung großer Datenmengen. Geht es um einzelne Datensätze, bei denen man eine eine ganze Zeile aus dem System ziehen muss - wie bei OLTP, ist die zeilenorientierte Verarbeitung eines RDBMS natürlich keine schlechte Option.
  • Kompression - Die Spalteninhalte werden komprimiert. Kompression wird auch in RDBMS genutzt. RDBMS komprimieren aber den Inhalt der Datenblöcke und nicht die Spalten.
  • Insert (keine Updates) - Die HANA ändert also keine Datensätze, sie legt sie nur neu am Ende der Spalte an. Die Spalten beinhalten also mehrere Versionen eines Datensatzes und wachsen bei Änderungen schnell an.
Da SAP kein eigenes RDBMS im Angebot hat, dem HANA Konkurrenz im eigenen Haus machen könnte, muss SAP auch auf nichts Rücksicht nehmen und keine faulen Kompromisse eingehen, wenn es auf diese DB-Technologie setzt. Bei Oracle, Microsoft oder IBM mit ihren RDBMS sieht das etwas anders aus.
HANA ist also schnell. Okay... Die naheliegende Managerfrage lautet demnach: Ist mein SAP damit schneller? Nein. Wer sein gutes altes SAP-ERP im Einsatz hat, dem nützt HANA erst einmal nichts. SAP müsste zunächst seine eigene Software komplett portieren. Das kann dauern und wird kosten.

Oracles Antwort: Exalytics

Oracle gefällt der Hype um HANA natürlich nicht. Als Reaktion auf HANA wurde Exalytics auf den Weg gebracht. 
Exalytics ist ebenfalls eine Appliance-Lösung. Einen Vergleich versucht www.silicon.de. Der Titel des Artikels "Äpfel mit Birnen" sagt es schon: Die Exalytics ist konzeptionell etwas anderes als HANA.
In der Exalytics werden RDBMS und In-Memory mit einander kombiniert - mit allen Vor- und Nachteilen, die ein solcher Kompromiss mit sich bringt.
Mit der Exadata X3, die von Oracle als "InMemory Machine" beworben wird, sieht das ähnlich aus.
Oracle ist offensichtlich nervös und sieht HANA als Gefahr für das eigene Geschäft. Die Exalytics muss die Kundschaft sichern, bis Oracle ein echtes Konkurrenzpaket im Angebot hat.

Fazit

Eigentlich geht es um nichts Neues. Im Kern dreht sich alles um die Frage, ob In-Memory-Datenbanken die klassischen RDBMS ablösen können und wie die großen Hersteller (Oracle, IBM, Microsoft) damit umgehen.
HANA konkurriert bis auf weiteres eher mit Produkten wie Exasolution oder Terracotta und wildert damit im Segment der Analyse- und DataWarehouse-Lösungen.
Achja: Teuer ist der InMemory-Spaß auch. Die Lizenzpreise stellen die Enterprise-Versionen von Oracle 11g, MS SQLServer und IBMs DB2 in den Schatten.

Mittwoch, 9. Januar 2013

RAC Housekeeping unter Windows

Wie man seinen RAC sauber hält, wird in diesem Artikel der Deutschsprachigen DBA-Community von Sebastian Solbach beschrieben: Housekeeping 11gR2 RAC
Wie fast immer wird sich auf Linux bezogen. Ich fasse das Ganze für Windowsserver zusammen.
Ich bin einer der [ironie]Glücklichen[/ironie], der einen RAC auf WindowsServer2008 administriert.
Der Betrieb des RAC verläuft recht problemlos, was dazu verleitet, den vielen Log-Dateien nicht die Aufmerksamkeit zu schenken, die sie verdienen – und sei es nur, sie zu löschen.
Log- und Tracedateien fallen im Grunde in 2 Bereichen an:
  • In der Grid-Infrastruktur
  • Datenbanken

GRID-Infrastruktur

Ein Großteil der Logdateien wird von der Clusterware verwaltet. Unterhalb von %GRID_HOME%\log\<host>\ liegen diverse Unterverzeichnisse mit rollierenden Logdateien. Bis auf 2 Ausnahmen muss man sich um nichts kümmern.
Folgende Logs auf jedem Node müssen manuell behandelt werden:
  • Das Clusterware-alert.log: %GRID_HOME%\log\<host>\alert<host>.log
  • Die Logs unterhalb: %GRID_HOME%\log\<host>\client\*

Alert.log - Clusterware

Das alert<host>.log wächst langsam. Auf meinem Beispielcluster mit 2 Knoten sind es nach einem Jahr Betrieb 15 bzw. 50MB.
Unter Windows kann das Logfile aber nicht wie unter Linux bei laufender Clusterware rolliert werden, da sich die Datei im Zugriff befindet.
Es bietet sich also an, das Log manuell im Zuge eines Wartungsfensters bei Windowsupdates zu rollieren.
Eine jährliche Rotation sollte ausreichen.
Ein Skript könnte so aussehen und im Zuge der Wartung per Windows-Scheduler beim Serverstart ausgeführt werden:
set GRID_HOME=D:\oragrid\11.2.0.3
set GRID_HOST=RAC1
set LOGPATH=%GRID_HOME%\log\%GRID_HOST%
set jahr=%date:~-4%
set monat=%date:~-7,2%
set tag=%date:~-10,2%
set LOGDATE=%jahr%%monat%%tag%

copy %LOGPATH%\alert%GRID_HOST%.log %LOGPATH%\alert%GRID_HOST%_%LOGDATE%.log
type nul > %LOGPATH%\alert%GRID_HOST%.log

OCRDUMP, OCRCHECK, OCRCONFIG, CRSCTL

Unterhalb %GRID_HOME%\log\<host>\client\* finden sich viele kleine Logdateien, die bei administrative Aufrufen von z.B. ocrcheck erzeugt werden.
Auf meinem Produktivsystem summierte sich der Platzbedarf innerhalb eines Jahres auf 200-250MB je Node. Mit diesem Skript kann man der Plage Herr werden:
set GRID_HOME=D:\oragrid\11.2.0.3
set GRID_HOST=RAC1
set LOGPATH=%GRID_HOME%\log\%GRID_HOST%

forfiles /P %LOGPATH%\client\ /S /M *.* /D -7 /C "cmd /c del /q @path"
Es löscht alle Dateien älter als 7 Tage. Wenn man das täglich oder monatlich über den Scheduler startet, hat man seine Ruhe.

Listener.log, listener_scan<#>.log rollieren

Auf jedem Knoten die Listener.log- und listener_scan1.log bis listener_scan3.log-Dateien umbenennen. Zum Beispiel:
%GRID_HOME%\log\diag\tnslsnr\<host>\listener\trace
%GRID_HOME%\log\diag\tnslsnr\<host>\listener_scan1\trace
%GRID_HOME%\log\diag\tnslsnr\<host>\listener_scan2\trace
%GRID_HOME%\log\diag\tnslsnr\<host>\listener_scan3\trace
Es genügt, die ursprüngliche log umzubenennen/löschen. Beim nächsten Eintrag wird eine neue Datei generiert.
Die Größe der Logs ist natürlich abhängig von der Aktivität auf dem Cluster. Auf meinem Beispielsystem liegen nach einem Jahr insgesamt 1,5GB an Listener-Logs vor.
Eine monatliche Rotation ist empfehlenswert.

ASM

Die Log- und Trace-Files der ASM-Instanzen werden im Automatic Diagnostic Repository gespeichert.
Das Housekeeping ist automatisiert.
Einstellungen zum Löschen alter Informationen:
  • Default 30 Tage
  • 365 Tage für das mechanische Alert File
Das Alert-log der ASM-Instanzen findet sich hier:
%ORACLE_BASE%\diag\asm\+asm\asm<#>\trace\alert_ asm<#>.log
Zum rollieren einfach
  1. die alert_ asm<#>.log in alert_ asm<#>_YYYYMMDD.log umbennennen und
  2. eine neue alert_ asm<#>.log anlegen.
Außerdem muss man sich um die Tracefiles unter %GRID_HOME%\RDBMS\trace selbst kümmern.

Datenbanken

Die RAC-DB verhalten sich wie die ASM-Instanzen:
Das Housekeeping wird vom ADR erledigt und um das alert.log muss sich der Admin kümmern.

Alert.log

Wie bei der ASM-Instanz auf allen Knoten unter %ORACLE_BASE%\diag\rdbms\<database>\<instance>\trace:
  1. alert_<instance>.log in alert_<instance>_YYYYMMDD.log umbennennen und
  2. neue alert_<instance>.log anlegen.

Sonstiges

OCR

Weiterhin gibt es laut Housekeeping 11gR2 RAC  unter %GRID_HOME%\cdata\<cluster>\ Sicherungen der OCR, die periodisch erzeugt und gelöscht werden müssen. In meiner WindowsServer-Installation existieren die angesprochenen Sicherungen nicht an dieser Stelle oder anderswo im GRID_HOME. Ich sehe bei Gelegenheit nach, ob diese in der ASM zu finden sind.

Auditfiles der ASM- und Datenbankinstanzen

Anders als in Housekeeping 11gR2 RACbeschrieben, existieren unter Windows diese Logs nicht im Filesystem. Dieses Auditing findet man in der Ereignisanzeige:
Event Viewer

Enterprise Manager DB Console / Enterprise Management Agent

Unterhalb %ORACLE_HOME%\<knoten>_<dbuniquename>\sysman\log befinden sich logs und tracefiles der DBCansole. Innerhalb eines Jahres kamen hier 120MB zusammen.
Monatliches Rollieren und Löschen kann nicht schaden.

cfgtoollogs

Hier zitiere ich direkt aus Housekeeping 11gR2 RAC :
Zu den bisher erwähnten Dateien sollte man noch auf das cfgtoollogs Verzeichnis (im $ORACLE_BASE und $ORACLE_HOME) achten. Je nach dem ob man häufiger mit OPatch die Oracle Homes überprüft, EMCA verwendet, um den Enterprise Manager umzukonfigurieren, oder den DBCA um Datenbanken anzulegen. Jedes dieser Tools schreibt ein Log in das entsprechende cfgtoollogs Verzeichnis. Sollte man in Skripten oder ähnlichem diese Tools periodisch verwenden, sollte auch das cfgtoollogs Verzeichnis von den anfallenden Logfiles befreit werden.
Je nach Aufkommen monatliches oder jährliches Löschen.

Fazit

Ob es sich lohnt bei einem 2-Knoten-RAC alle Einzelschritte zu verskripten ist Geschmackssache. Da das Datenaufkommen so gering ist, dass es genügt, die logs monatlich zu rollieren oder zu löschen, ist es zu verschmerzen, dies manuell zu erledigen. Netter Nebeneffekt: Man hat regelmäßig die Verzeichnisstruktur vor Augen.
Wenn man das Ganze in ein oder mehrere Skripte gießen und das gleich richtig machen will, bietet sich auf einem WindowsServer natürlich PowerShell an, statt lauter Batchdateien anzulegen.

Montag, 7. Januar 2013

ORA_ROWSCN - Datensatzänderungen ermitteln

In einer von mir administrierten DB wird durch eine Web-Anwendung umfangreich Gebrauch von der Pseudospalte ORA_ROWSCN gemacht.
Diese Spalte gibt die SCN der letzten Änderung aus.
In der Anwendung soll über die ORA_ROWSCN ermittelt werden, ob ein bestimmter Datensatz seit dem letzten Zugriff geändert wurde.
Hierbei ist aber zu beachten, dass standardmäßig die SCN der letzten Änderung des Blocks ausgegeben wird. Da in einem Block für gewöhnlich mehrere Datensätze gespeichert sind, gehören zu einer ORA_ROWSCN also auch mehr als 1 Datensatz.
Das Ganze ist demnach erstmal recht unscharf.
Will man die ORA_ROWSCN datensatzscharf haben, muss die betroffene Tabelle korrekt angelegt werden:
CREATE TABLE test
   (col1 number, col2 varchar2(10), 
   constraint test_pk primary key(col1))
   ROWDEPENDENCIES;

Über ALTER TABLE lässt sich eine Tabelle leider nicht "datensatzscharf" schalten.

Natürlich lässt sich über die SCN auch der Zeitpunkt der Änderung ermitteln.

Quellen:
Oracle: http://docs.oracle.com/cd/E11882_01/server.112/e26088/pseudocolumns007.htm#SQLRF50953
AskTom: http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:517105100346104196