Um den PL/SQL Embedded Gateway zu verwenden, führt man als SYS zuerst das folgende

SQL> @$ORACLE_HOME/apex/apxconf.sql;

Konfigurations-Skript aus. Dieses SQL-Skript fragt nach dem HTTP-Port, über den später PL/SQL per URL angesprochen werden kann. Mit

SQL> EXEC DBMS_XDB.SETHTTPPORT(8080);

kann dieser Port nachträglich verändert werden. Ein Aufruf mit Port 0

SQL> EXEC DBMS_XDB.SETHTTPPORT(0);

deaktivert den PL/SQL embedded Gateway und mit

SQL> SELECT DBMS_XDB.GETHTTPPORT FROM DUAL;

wird der zur Zeit verwendete Port ausgegeben.
Nach der Konfiguration durch apxconf.sql kann mit dem Listener Status-Kommando

$ lsnrctl status

geprüft werden ob der Port aktiv ist. Es sollte eine Zeile ähnlich der folgenden

$ (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=...)(PORT=8080))(Presentation=HTTP)(Session=RAW))

mit aufgeführt werden.
Um bsp. PL/SQL Prozeduren über den PL/SQL Embedded Gateway zugänglich zu machen, benötigt man außerdem einen freigeschalteten

SQL> alter user ANONYMOUS account unlock

ANONYMOUS Benutzer.
Des Weiteren wird ein Database Access Descriptor (DAD) benötigt. Ein DAD übernimmt in etwa die Arbeit wie mod_plsql für den Apache.
Sozusagen ein Servlet für den XML DB HTTP Listener. Unter http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28424/adfns_web.htm im Abschnitt Table 10-2 Mapping Between mod_plsql and Embedded PL/SQL Gateway DAD Attributes sieht man zum Vergleich eine Gegenüberstellung der DAD und mod_plsql Attribute.
Ein DAD wird später durch einen Teil in der URL repräsentiert bzw. angesprochen.
Mit

SQL> EXEC DBMS_EPG.CREATE_DAD('PL_SQL', '/plsql/*');

erstellt man ein DAD mit der Bezeichnung PL_SQL und dem URL-Teilpfad /plsql/.
Damit der ANONYMOUS Benutzer für das DAD als eine Art “Schnittstelle” zwischen der DB und dem DAD zu fungieren kann, stellt man mit

SQL> EXEC DBMS_EPG.SET_DAD_ATTRIBUTE('PL_SQL', 'database-username', 'ANONYMOUS');

den ANONYMOUS Benutzer für das DAD ein.
Ab hier wäre der PL/SQL Embedded Gateway grundlegend konfiguriert. Um nun eine Prozedur eines Benutzers öffentlich über den
PL/SQL Embedded Gateway zur Verfügung zu stellen, muß die Prozedur für PUBLIC per

SQL> GRANT execute on PROZEDUR_NAME to public;

die Ausführbarkeit dieser Prozedur erlaubt werden. Wird in dieser Prozedur auf andere Objekte zugeriffen, müssen auch für diese die entsprechenden
Rechte (bsp. für Tabellen GRANT select on TABELLEN_NAME to public) vergeben werden. Erst anschließend ist nach folgenden URL-Schema

http://www.domain.de/plsql/objekt_inhaber.objekt_name

das Objekt aufrufbar.

Fazit

Der PL/SQL Embedded Gateway ist eine einfache Methode um datenbanknah Objekte oder APEX-Applikationen per Browser ausführbar zu machen. Es entfällt
die umfangreiche Konfiguration eines Apache Webservers. Auch sichere Verbindungen per SSL sind möglich. Benötigt man keine Sonderfunktionen á la
URL-Umschreibung (mod_rewrite) oder einen Auslagerung des Webserver (Perormanz-und Sicherheitsaspekte) und Ähnliches, dann reicht ein PL/SQL
Embedded Gateway für die meisten Fälle aus.

Hinweis

Diese Anleitung ist ein praktischer Leitfaden ohne Gewähr.

Weiterführende Literatur

empfehlenswert sind folgende Bücher:

• Oracle APEX und Oracle XE in der Praxis von Dietmar Aust, Jens-Christian Pokolm und Denes Kubicek
• Oracle 10g für den DBA: Effizient konfigurieren, optimieren und verwalten von Johannes Ahrends, Dierk Lenz, Patrick Schwanke, und Günther Unbescheid
• Oracle 11g: Das umfassende Handbuch von Lutz Fröhlich

Das Binary Log schreibt zur Laufzeit alle auf dem Server ausgeführten SQL-Transaktionen mit, dies wiederum verbraucht Ressourcen (je nach Frequentierung >= 1% CPU), weshalb manche Administratoren die Aktivität des binären loggen eingrenzen oder gar ausschalten. Die Vorteile die das Binary Log mitbringt sind aber enorm, insbesondere wenn neue Applikationen fehlerhafte SQL-Anweisungen absetzen.

Binäres Loggen konfigurieren

Alle Einstellungen die das Binary Log betreffen werden in der /etc/mysql/my.cnf vorgenommen

log_bin                 = /var/log/mysql/mysql-bin.log
expire_logs_days        = 10
max_binlog_size         = 100M

Durch log_bin wird der Speicherort der Log-Dateien bestimmt. expire_logs_days bestimmt den Zeitraum, in welchen die Logs aufbewahrt werden sollen, in dem Beispiel werden alle Logs die älter sind als 10 Tage entfernt. max_binlog_size gibt die maximal zugelassene Dateigröße für ein Log-File an. Die Angabe von max_binlog_size sollte unter Debian Systemen nie ohne die Einstellung log_bin aufgeführt werden, da hier der Server abstürzen würde. Je nachdem wieviele SQL-Statements erzeugt werden ist abzuwägen welche Größe und welcher Zeitraum berücksichtigt bzw. zugelassen werden soll. Unbedacht erstellte Applikationen können manchmal riesige Mengen an SQL-Anweisungen innerhalb eines Tages erzeugen, wenn diese Anwendung auch noch von mehreren Benutzern gleichzeitig benutzt wird, kann man sich ausmalen, dass die Grenzen eines zu klein gewählten Log-Files schnell erreicht sind und dann wäre der Vorteil dahin. Um Änderungen an der my.cnf wirksam zu machen, muß der MySQL Server neugestartet werden.

Einfaches Wiederherstellen

Durch das binäre Loggen in Verbindung mit der Sicherung der binären Log-Dateien ist es möglich ein vollst. Backup-Konzept zu erstellen. Empfehlen würde ich in Hinsicht auf die mitgeführten redundanten Daten nicht. Praktikabler ist das normale tägliche Backup (bsp. per MySQL Dump oder ähnliches) in Kombination mit dem Binary Log.
Ein alltägliches Backup Szenario könnte folgendermaßen aussehen, vorrausgesetzt das tägliche Backup (bsp. immer um 00:00Uhr) und das Binary Log sind aktiv. Angenommen alle Daten gingen aus irgendeinem Grund verloren, dann ist der erste Schritt den Zugriff auf die Datenbank exklusiv für den Administrator zu setzen:

$ mysqld --socket=/tmp/mysql_restore.sock --skip-networking

skip-networking ermöglicht den Zugriff nur über SSH oder direkt an der Server Konsole.
Nach der Einschränkung des Zugriffs von außen, kann das tägliche Backup per Konsole eingespielt werden um so den Datenstand vom Vortag zu erhalten:

$ mysql -u root -ppassword  --socket=/tmp/mysql_restore.sock \
    < /var/backup/20080325.sql

Mit diesem Befehl wird das SQL Backup direkt auf den mysql_restore.sock geleitet. Anschliessend müssen noch die interim Daten wiederhergestellt werden, also die Daten die nach 00:00Uhr entstanden sind. Dazu verwendet man das Werkzeug mysqlbinlog. Vor Benutzung des Tools muß herausgefunden werden welche Log Dateien den jetzigen Tag betreffen, ein einfacher ls -la auf der Konsole im Binary Log Verzeichnis wird alle nötigen Informationen liefern. Nun kann von der kleinsten laufenden Nummer auftsteigend zum neuesten Log folgendermaßen vorgegangen werden:

$ mysqlbinlog /var/log/mysql/mysql-bin.000xxx \
   | mysql -u root -ppassword \
           --socket=/tmp/mysql_restore.sock

Mit diesem Befehl werden alle Statements die durch das Binary Log in der Log Datei aufgezeichnet wurden direkt auf der MySQL Datenbank abgesetzt und erneut ausgeführt. Wenn man alle Log-Daten so abgearbeitet hat, hat man alle Daten bis zum DB-Crash wiederhergestellt. Ein abschliessender MySQL-DB Neustart wird die Datenbank wieder zur Verfügung stellen.

Manuelles Wiederherstellen

Es kann vorkommen, dass man nicht alle Daten wiederherstellen möchte, da nur eine fehlerhafte Anweisung Daten gelöscht hat. Dazu piped (umleiten) man die Ausgabe nicht direkt auf den MySQL Socket um, sondern in ein seperate Textdatei:

$ mysqlbinlog /var/log/mysql/mysql-bin.000xxx \
    > /tmp/tmp_mysql-bin-000xxx..sql

Danach kann mit vi oder vim oder einem anderen Texteditor die temporäre erstellte Datei bearbeitet werden, eventuell fehlerhafte Anweisungen entfernt und danach erneut in die DB eingespielt werden.

Punktgenaues Wiederherstellen (Zeitstempel)

Ab MySQL Version 4.1.4 sind die Parameter –start-date und –stop-date hinzugefügt wurden. Diese ermöglichen punktuelles Recovery. Beispielsweise löschte eine Anweisung die um 12:00Uhr am 23.03.2008 ausgeführt wurde einige Daten. Die Vorgehensweise wäre die gleiche wie die eben beschriebene, man spielt das tägliche Backup zurück und führt anschliessend folgendes Kommando aus:

$ mysqlbinlog --stop-date="2008-03-23 11:59:59"
      /var/log/mysql/bin.000xxx |
    mysql -u root -ppassword \
          --socket=/tmp/mysql_restore.sock

Hiermit werden alle SQL-Statements die bis 11:59:59 aufgelaufen sind neu auf der Datenbank ausgeführt. Wenn man die fehlerverursachende SQL-Anweisung nicht exakt ausfindig machen kann, dann möchte man vielleicht an dieser Stelle alle Anweisungen die nach dem Fehlerzeitraum abgesetzt wurden wiederherstellen:

$ mysqlbinlog --start-date="2008-03-23 12:00:01"
      /var/log/mysql/bin.000xxx |
    mysql -u root -ppassword \
          --socket=/tmp/mysql_restore.sock

Mit diesen beiden Parametern kann man sehr punktuell Daten wiederherstellen und fehlerhafte SQL-Anweisungen zu umgehen.

Punktgenaues Wiederherstellen (Positionsangabe)

Nach dem gleichen Prinzip wie start-date und stop-date funktioniert start-position und stop-position. Wenn man eine binäre Log-Datei in eine Textdatei ausgibt, dann erkennt man das jedes SQL-Statement eine eindeutige Log-Positionsangabe mitführt, auf dieser Basis kann man genauso punktuell Daten wiederherstellen. Wann wird diese Vorgehensweise notwendig? Ganz einfach, wenn man den ungefähren Zeitpunkt des Problemfalles nicht kennt, dann führt kein Weg an dieser Methode vorbei.

Fazit

Die Nachteile liegen in dem Verbrauch der Ressourcen, SQL-Statement lastige Anwendungen fluten die Logs, es gilt abzuwägen, wieviel Ressourcen man hierfür als notwendig ansieht. Die Vorteile heben sich aber deutlich von den Nachteilen ab. Ich kam selbst in den Genuß eine MySQL Datenbank in 5 Minuten wieder in ordnungsgemäßen Zustand versetzen zu dürfen, seitdem ist für mich ist das Binary Log Recovery unverzichtbar um eine bessere Datensicherheit bzw. geringere Ausfallzeiten zu gewährleisten.

Hinweis

Diese Anleitung ist ein praktischer Leitfaden ohne Gewähr.

Weiterführende Literatur

empfehlenswert sind folgende Bücher:

• Das offizielle MySQL 5-Handbuch von MySQL MySQL AB
• MySQL 5. Einführung, Programmierung, Referenz (Open Source Library) von Michael Kofler
• MySQL 5. Für Professionals von Axel Bornträger

Mit Hilfe der Volltextindizierung, bietet MySQL die Funktionalität der Volltextsuche in MyISAM Tabellentypen an. Mit dem Indextyp FULLTEXT versehene CHAR-, VARCHAR- und TEXT-Spalten ermöglichen die benutzerfreundliche Suche. Näheres unter http://dev.mysql.com/doc/refman
/5.1/de/fulltext-search.html einsehbar.

1. Schritt – Volltext Index erstellen

Es existieren zwei Wege einen Volltextindex zu erstellen, bei der Neuerstellung einer Tabelle oder dem nachträgliche Hinzufügen. Bei der Erstellung einer Tabelle sehe dies auf dem MySQL-Prompt wie folgt aus:

mysql> CREATE TABLE testtabelle (
-> id INT UNSIGNED AUTO_INCREMENT NOT NULL PRIMARY KEY,
-> testspalte1 VARCHAR(200),
-> testspalte2 TEXT,
-> FULLTEXT (testspalte1,testspalte2)
-> );

Das nachträgliche Hinzufügen des Fulltextindex ist mit der ALTER-Anweisung möglich:

mysql> ALTER TABLE testtabelle ADD FULLTEXT (testspalte1,testspalte2);

2. Schritt – Eigene Stopwortliste

Eine Stopwortliste ermöglicht bei der Volltextsuche Füllwörter (und, als, der etc.) bei der Relevanzberechnung zu ignorieren. Je nach Kontext der Seite möchte man eine eigene Stopwortliste verwenden um dem Webseiten-Besucher relevantere Ergebnisse zu liefern.
In der my.cnf meldet man die eigene Stopwortliste wie folgt an:

[mysqld]
ft_stopword_file=”PFAD/stopword_de.c
ft_min_word_len=”3″

Mit ft_min_word_len=”3″ gibt man die Mindestlänge eines Suchbegriffes an, alle Suchbegriffe die kürzer sind werden ignoriert. Wird dieser Wert nicht gesetzt, gilt der default-Wert von vier Zeichen Mindestlänge.
Die Stopwortliste ist eine Anreihung von Begrifflichkeiten mit Komma getrennt:

“dann”,
“das”,
“dass”

Lesezugriff (644) auf die Stopwortliste ist vollkommen ausreichend.

DOWNLOAD: Beispiel Stopwortliste für deutschen Sprachraum

stopword_de.c

3. Schritt – Die Such-Query

Um die Volltextsuche auch benutzen zu können, bedarf es eines abgeänderten SELECTs:

mysql> SELECT id, MATCH (testspalte1,testspalte2) AGAINST (‘Suchwort‘) AS rang
FROM testtabelle
WHERE MATCH (testspalte1,testspalte2) AGAINST (‘Suchwort‘);

Die unterstrichenen Bereiche der SELECT-Abfrage ermöglichen die Volltextsuche. Der Alias rang wird nach der Abfrage den Wert (0-1, wobei 0 unrelevant wäre und 1 die maximale Relevanz darstellt) für die Relevanzbestimmung annehmen.
Nun kann man (hier mit PHP) dem Benutzer den Relevanzwert etwas schmackhafter servieren, indem man rang als prozentualen Wert umrechnet.

<?
number_format(($ergebnis['rang'] * 100),0).”%”;
?>

Voila!

Hinweise

Die Volltextsuche lohnt sich erst bei einer hohen Datendichte. Bei ein, zwei Webseiten in der Datenbank wird die Volltextsuche kaum relevante Ergebnisse liefern, denn MySQL prüft ob der Suchbegriff in mindestens 50 Prozent der Datensätze vorhanden ist und erklärt diesen dann als unrelevant für die Abfrage. Macht ja auch Sinn, wenn man bedenkt, dass das Wort Auto auf einer Automobilhersteller-Webpräsenz ziemlich unnütz für eine Suchanfrage erscheint.

Diese Anleitung ist ein praktischer Leitfaden ohne Gewähr.

Weiterführende Literatur

empfehlenswert sind folgende Bücher:

• Das offizielle MySQL 5-Handbuch von MySQL MySQL AB
• MySQL 5. Einführung, Programmierung, Referenz (Open Source Library) von Michael Kofler
• MySQL 5. Für Professionals von Axel Bornträger

Die Replikation ermöglicht eine exakte Kopie der Master Datenbank als redundante Sicherung. Man sollte sich bewusst darüber sein, dass alle SQL-Befehle die beim Master abgesetzt werden 1 zu 1 auf dem Slave übernommen werden.
Vor einer fehlerhaften Anwendung, die bsp. Datensätze korrumpiert, ist die Replikation nicht gefeit. Nichtdestotrotz eröffnet die Replikation Wege in Bezug Ausfallsicherheit oder Lastverteilung.
Ich empfehle bei der Replikation gleiche MySQL Versionen von Master und Slave zu benutzen. Unter http://mysql2.mirrors-r-us.net/doc/refman/5.1/de/replication-compatibility.html kann man Details zur Kompatiblität erfahren.

1. Schritt – Master Datenbank vorbereiten

Zuerst muss ein Benutzer auf der Master-DB mit Replikations-Berechtigung erzeugt werden. Dieser Benutzer-Account dient später zur Replizierung der Daten. Auf der Kommadozeile in MySQL sähe das folgendermaßen aus:

mysql> GRANT REPLICATION SLAVE ON *.* TO slave@’%.ihredomain.de’ IDENTIFIED BY ‘ihrPasswort’;

Wenn man später mit LOAD DATA FROM MASTER agieren möchte dann benötigt dieser Account ein paar Rechte mehr (SELECT, RELOAD, SUPER, REPLICATION SLAVE).
Als nächstes muss die my.cnf des Master editiert werden

[mysqld]
log-bin
server-id=1

Hiermit aktivieren wir das binäre loggen des Masters, welches notwenig für die Replikation ist. Des weiteren geben wir dem Master eine eindeutige ID.

2. Schritt – Master Datenbank sichern

Diesen Schritt kann man sich auch sparen, wenn der Master keine oder nur wenige Daten zu diesem Zeitpunkt führt. Dann setzt man einfach nach Schritt 4 folgendes Kommando auf dem MySQL-Prompt ab:

mysql> LOAD DATA FROM MASTER;

Wie bereits erwähnt benötigt der Replikations-Account hierfür weitere Rechte (RELOAD,SUPER).
Mit dem Kommando holt sich der Slave alle Daten vom Master, aber Vorsicht er blockiert hiermit den Master über den Zeitraum des Ladeprozesses, bei vielen Daten ist dieses Vorgehen nicht zu empfehlen.

Nun müssen wir den IST-Zustand der Master-DB-Daten erfassen und dem Slave später als Ausgangspunkt zur Verfügung stellen. Als erste Handlung hierbei, muss man die Master-Tabellen sperren, das erfolgt am MySQL-Prompt mit:

mysql> FLUSH TABLES WITH READ LOCK;

Jetzt erfolgt ein Full-Backup der Master DB aus der Kommandozeile mit (bsp. in /var/lib/mysql/):

tar -cvf /tmp/master-backup.tar

Zur Sicherheit legt man eine Kopie von diesem Backup zurück, um eventuell später weitere Slaves mit diesem Datenbestand zu initialisieren.
Als nächstes benötigen wir noch die Binary Log Position um den Slave später den Anfangspunkt der Replizierung mitzuteilen. Auf dem MySQL-Prompt geschieht das mit:

mysql> SHOW MASTER STATUS;

Diesen Wert notieren wir. Nun haben wir alle nötigen Daten des Masters und können dessen Tabellen entsperren:

mysql> UNLOCK TABLES;

3. Schritt – Ausgangs-Backup in Slave einspielen

Im Slave Datenverzeichnis entpacken wir das eben angelegte Backup mit

tar -xvf master-backup.tar

Dieses Backup dient dem Slave als Ausgangspunkt für das spätere unidirektionale, asynchrone replizieren.

4. Schritt – Slave Datenbank vorbereiten

Der Slave benötigt nun auch eine eindeutige ID, diese tragen wir in die Slave my.cnf folgendes ein:

[mysqld]
server-id=2

Jetzt füttern wir den Slave mit den notwenigen Daten des Masters auf dem MySQL-Prompt:

mysql> CHANGE MASTER TO
-> MASTER_HOST=MASTER-IP,
-> MASTER_USER=Name des Replikation Account,
-> MASTER_PASSWORD=Passwort des Replikations-Accounts,
-> MASTER_LOG_FILE=Name des Binary-Logs aus dem Snapshot,
-> MASTER_LOG_POS=Binary Log Position;

Anschliessend muss der Slave nur noch seinen Dienst aufnehmen mit:

mysql> START SLAVE;

Nach absetzen des Befehls nimmt der Slave sofort Kontakt mit dem Master auf und orientiert sich am Binary Log um die Replizierung durchzuführen.

Voila!

Mit

mysql> SHOW MASTER STATUS;

und

mysql> SHOW SLAVE STATUS;

kann man nun Master und Slave kontrollieren. Hierbei ist darauf zu achten, dass auf dem Slave die Stati Slave_IO_Running und Slave_SQL_Running auf YES stehen.

Unter http://mysql2.mirrors-r-us.net/doc/refman/5.1/de/replication.html findet man weiterführende Informationen und Hilfestellungen. Aus meiner Erfahrung heraus sind bei Master-Slave Gefügen auftretenden Probleme oft bei der Berechtigung des Replikations-Accounts und/oder des Verbindungsaufbaues zu suchen.

Hinweise

Man sollte sicherstellen, dass der Master Verbindungen von ausserhalb zulässt, sofern der Replikant nicht im selben Netz (localhost) integriert ist, aber Vorsicht dies ist ein Sicherheitsmanko. Auch diese Einstellung nimmt man in der my.cnf vor, in dem man die Zeile

#skip-networking

mit # auskommentiert. Taucht diese Zeile

#bind-address = 127.0.0.1

in der my.cnf auf, muss auch diese auskommentiert werden. Sie bedeutet nichts anderes als das nur von localhost verbunden werden darf.

Diese Anleitung ist ein praktischer Leitfaden ohne Gewähr.

Weiterführende Literatur

empfehlenswert sind folgende Bücher:

• High Performance MySQL. Optimierung, Datensicherung, Replikation & Lastverteilung von Jeremy D. Zawodny und Derek J. Balling
• Das offizielle MySQL 5-Handbuch von MySQL MySQL AB
• MySQL 5. Einführung, Programmierung, Referenz (Open Source Library) von Michael Kofler
• MySQL 5. Für Professionals von Axel Bornträger