Unter Verwendung des HTTP-Nachrichtensystems sendet SQL Remote Nachrichten über das Internet unter Verwendung des Hypertext Transfer Protocol (HTTP). Die Nachrichten werden in einem Textformat kodiert und über HTTP an die Zieldatenbank gesendet. Die Nachrichten werden mit einer als HTTP-Server fungierenden SQL Anywhere-Datenbank gesendet und empfangen.
Sie verwenden den SQL Anywhere-Datenbankserver als den HTTP-Server, der SQL Remote-Nachrichten zu und von entfernten Datenbanken überträgt. Standardmäßig sind für eine neu initialisierte SQL Anywhere-Datenbank nicht die Webdienste festgelegt, mit denen sie als Nachrichtenserver fungieren könnte. Drei gespeicherte Systemprozeduren, sr_add_message_server, sr_drop_message_server und sr_update_message_server, sind in neu erstellten SQL Anywhere-Datenbanken festgelegt und ermöglichen es Ihnen, die erforderlichen Datenbankobjekte so zu definieren, dass die Datenbank als HTTP-Server zum Übertragen von SQL Remote-Nachrichten eingesetzt werden kann.
Die Datenbank muss mit SQL Anywhere 16.0 und mit einem Datenbankserver mit Build-Nummer 3336 oder höher initialisiert werden. Führen Sie eine Abfrage der SYS.SYSHISTORY-Systemtabelle aus, um zu ermitteln, welche Version und welcher Build des Datenbankservers zum Initialisieren der Datenbank verwendet wurden. Wenn die Datenbank mit 16.0 und einer Build-Nummer vor 3336 initialisiert wurde, aktualisieren Sie die Datenbank, indem Sie "ALTER DATABASE UPGRADE PROCEDURE ON" ausführen.
Sie müssen entscheiden, ob Sie einen separaten Datenbankserver ausführen oder die vorhandene konsolidierte Datenbank als Nachrichtenserver einsetzen möchten. Berücksichtigen Sie Folgendes, wenn Sie diese Entscheidung treffen:
Wenn eine entfernte Datenbank sich beim Nachrichtenserver authentifiziert, verwendet sie für die Authentifizierung den Publikationseigentümer der entfernten Datenbank und das angegebene Kennwort. Obwohl der Benutzer in der konsolidierten Datenbank vorhanden ist, wurde für ihn möglicherweise kein Kennwort festgelegt (d.h., der entfernte Benutzer hat möglicherweise keine CONNECT-Privilegien), was jedoch eine Anforderung des HTTP-Nachrichtensystems ist. Wenn das Erteilen von CONNECT-Privilegien an die entfernten Benutzer in der konsolidierten Datenbank ein Sicherheitsproblem darstellt, können Sie eine separate Datenbank als Nachrichtenserver einrichten.
Wenn die konsolidierte Datenbank eine hohe Last aufweist, kann das Hinzufügen der Nachrichtenserver-Funktion dazu führen, dass die Ressourcen auf dem Computer überlastet werden, wenn die konsolidierte Datenbank läuft.
Um die erforderlichen Datenbankobjekte einzurichten, damit die Datenbank als Nachrichtenserver fungieren kann, rufen Sie die gespeicherte Prozedur sr_add_message_server auf, mit der die SQL Remote-Definitionen in der Datenbank abgefragt werden. Siehe sr_add_message_server-Systemprozedur.
Wenn Sie den Nachrichtenserver als separate Datenbank erstellen, müssen Sie eine zweite Datenbank mit SQL Remote-Definitionen festlegen, die mit denen der konsolidierten Datenbank übereinstimmen. Verwenden Sie das Dienstprogramm dbunload, um eine Kopie der konsolidierten Datenbank zu erstellen, und geben Sie die Option -n an, damit nur das Schema der konsolidierten Datenbank entladen wird und nicht die Daten:
dbunload -n -an -c "ENG=cons.DBN=cons;UID=DBA;PWD=sql" |
Wenn Sie eine separate Datenbank als Nachrichtenserver verwenden und Änderungen an die SQL Remote-Definitionen in der konsolidierten Datenbank vorgenommen werden, müssen entsprechende Änderungen auch in der Nachrichtenserver-Datenbank vorgenommen werden.
Damit der Nachrichtenserver eingerichtet werden kann, muss der Datenbankserver Zugriff auf das Verzeichnis haben, in dem SQL Remote-Nachrichten gespeichert werden. Um festzulegen, in welchem Verzeichnis Nachrichten gespeichert werden, führen Sie den SET REMOTE OPTION-Befehl aus und setzen den HTTP-Nachrichtenparameter root_directory auf das Verzeichnis, in dem SQL Remote-Nachrichten gespeichert werden. Wählen Sie als nächstes den Datenbankbenutzer, der Eigentümer der zu erstellenden neuen Objekte sein soll, und stellen Sie sicher, dass der Benutzer eine Rolle ist. Führen Sie abschließend die gespeicherte Prozedur sr_add_message_server aus und übergeben Sie dabei den Namen des Benutzers, der Eigentümer der Objekte sein soll. Siehe SET REMOTE OPTION-Anweisung [SQL Remote] und sr_add_message_server-Systemprozedur.
Bei Änderungen an der SQL Remote-Definition des Nachrichtenservers (wie z.B. Hinzufügen oder Entfernen von entfernten Benutzern) müssen Sie die gespeicherte Prozedur sr_update_message_system ausführen, um die Definition der erforderlichen Objekte für die Unterstützung des Nachrichtenservers zu aktualisieren. Der Nachrichtenserver ist für eine kurze Zeitspanne nicht für die Replikation verfügbar, während die gespeicherte Prozedur läuft und Objekte gelöscht und neu erstellt werden. Siehe sr_update_message_server-Systemprozedur.
Wenn Sie die Datenbank nicht mehr als Nachrichtenserver verwenden, können Sie die gespeicherte Prozedur sr_drop_message_system ausführen, um die Objekte zu entfernen, die zur Unterstützung des Nachrichtenservers erstellt wurden. Siehe sr_drop_message_server-Systemprozedur.
Nachdem die erforderlichen Objekte für die Unterstützung des Nachrichtenservers erstellt wurden, müssen Sie beim Starten des Nachrichtenserver-Datenbankservers die HTTP-Unterstützung (bzw. HTTPS-Unterstützung) für den Datenbankserver mithilfe der Option -xs aktivieren. Weitere Hinweise zur Verwendung der Option -xs finden Sie unter Datenbankserveroption -xs .
Die folgenden serverseitigen HTTP Protokolloptionen sind für die Benutzer von Interesse, die die für den Nachrichtenserver benötigten Objekte festgelegt haben:
ServerPort | PORT Gibt die Portnummer an, die der Datenbankserver auf HTTP- oder HTTPS-Anforderungen abhört, wenn die Standardports 80 und 443 auf dem Computer bereits verwendet werden. Siehe ServerPort-Protokolloption (PORT).
MaxRequestSize | MAXSIZE Gibt die maximale Größe einer einzelnen HTTP-Anforderung an. Der Standardwert ist 100 kB. Wenn Sie Ihre SQL Remote-Nachrichtengröße (Option -l in der dbremote-Befehlszeile) auf einen Wert festgelegt haben, der größer ist als 100 kB, müssen Sie auch die Größe der größten HTTP-Anforderung erhöhen, die der Datenbankserver akzeptieren kann. Der Standardwert für die SQL Remote-Nachrichtengröße ist 50 kB. Siehe MaxRequestSize-Protokolloption (MAXSIZE).
Identity (nur HTTPS) Wenn Sie HTTPS verwenden, enthält die Identitätsdatei das öffentliche Zertifikat und seinen privaten Schlüssel. Bei nicht selbstsignierten Zertifikaten enthält die Identitätsdatei außerdem alle signierenden Zertifikate, u.a. auch das Verschlüsselungszertifikat. Das Kennwort für dieses Zertifikat muss mit dem Parameter Identity_Password festgelegt werden. Siehe Identity-Protokolloption.
Identity_Password (nur HTTPS) Wenn Sie Transportschichtsicherheit verwenden, gibt diese Option das Kennwort an, das dem Kennwort für das Verschlüsselungszertifikat entspricht, das durch die Identity-Protokolloption festgelegt wurde. Siehe identity_password-Protokolloption.
Damit Sie SQL Remote und HTTP verwenden können, benötigt jede am System beteiligte Datenbank eine HTTP-Adresse sowie eine Benutzer-ID und ein Kennwort. Das sind unterschiedliche Bezeichner: Die HTTP-Adresse ist das Ziel der einzelnen Nachrichten. Die Benutzer-ID und das Kennwort sind der Name und das Kennwort, die ein Benutzer eingibt, wenn er sich beim E-Mail-Server authentifiziert.
Bevor der SQL Remote-Nachrichtenagent (dbremote) zum Nachrichtensystem eine Verbindung herstellt, um Nachrichten zu versenden oder zu empfangen, muss der Benutzer bereits einen Satz von Steuerungsparametern auf seinem Computer festgelegt haben, oder der Benutzer wird aufgefordert, die erforderlichen Informationen anzugeben. Diese Daten werden nur bei der ersten Verbindung benötigt. Sie werden gespeichert und bei späteren Verbindungen als Standardwerte verwendet.
Das HTTP-Nachrichtensystem verwendet die folgenden Steuerungsparameter, die mithilfe der SET REMOTE OPTION-Anweisung gesetzt werden:
certificate Um eine sichere (HTTPS-)Anforderung durchführen zu können, muss der Client Zugriff auf das vom HTTPS-Server verwendete Zertifikat haben. Die benötigten Informationen werden in einer Zeichenfolge von durch Semikola getrennten Schlüssel/Werte-Paaren angegeben. Sie können mithilfe des Dateischlüssels den Dateinamen für das Zertifikat angeben. Sie können nicht sowohl einen Dateischlüssel als auch einen Zertifikatschlüssel angeben. Folgende Schlüssel sind verfügbar:
Schlüssel | Abkürzung | Beschreibung |
---|---|---|
file | Der Dateiname des Zertifikats | |
certificate | cert | Das Zertifikat selbst |
company | co | Die im Zertifikat angegebene Firma |
unit | Die im Zertifikat angegebene Firmeneinheit | |
name | Der im Zertifikat angegebene allgemeine Name |
Zertifikate sind nur bei Anforderungen erforderlich, die entweder an den HTTPS-Server gerichtet sind oder von einem nicht-sicheren zu einem sicheren Server umgeleitet werden können. Nur PEM-formatierte Zertifikate werden unterstützt. certificate='file=filename'
client_port Kennzeichnet die Portnummer, auf der SQL Remote unter Verwendung von HTTP kommuniziert. Sie wird nur für Verbindungen über Firewalls bereitgestellt und empfohlen, die "ausgehende" TCP/IP-Verbindungen filtern. Sie können eine einzelne Portnummer, Bereiche von Portnummern oder eine Kombination aus beiden angeben. Die Angabe einer niedrigen Anzahl von Clientports kann dazu führen, dass SQL Remote nicht in der Lage ist, Nachrichten zu senden und zu empfangen, wenn das Betriebssystem die Ports nicht rechtzeitig freigibt, nachdem SQL Remote den Port bei einer früheren Ausführung geschlossen hat. client_port=nnnnn[-mmmmm]'
debug Wenn dieser Parameter auf YES eingestellt ist, werden alle HTTP-Befehle und -Antworten im Ausgabelog angezeigt. Diese Informationen können zur Fehlerbehandlung von HTTP-Problemen verwendet werden. Der Standardwert ist NO.
https Geben Sie an, ob HTTPS (https=yes) oder HTTP (https=no) verwendet werden soll.
password Das Kennwort für die Nachrichtenserver-Datenbank. Dient zum Authentifizieren bei HTTP-Servern und Gateways anderer Hersteller, die RFC 2617 Basic-Authentifizierung verwenden. password='password'
proxy_host Gibt den URI eines Proxyservers an. Wird verwendet, wenn SQL Remote über einen Proxyserver auf das Netzwerk zugreifen muss. Zeigt an, dass SQL Remote eine Verbindung zum Proxyserver herstellen soll, um die Anforderung durch ihn an den Nachrichtenserver zu senden.proxy_host=' http://proxy-server[:port-number]'
reconnect_retries Gibt an, wie häufig die Verbindung versuchen soll, einen Socket zu öffnen, bevor der Versuch abgebrochen wird. Der Standardwert ist "4". Wenn Sie diesen Parameter setzen, sind nur erneute Verbindungen betroffen. Die ursprünglich vom FTP-Link erstellte Verbindung ist nicht betroffen.
reconnect_pause Die Zeit in Sekunden, die zwischen den Verbindungsversuchen abgewartet wird. Der Standardwert ist 30 Sekunden. Wenn Sie diesen Parameter setzen, sind nur erneute Verbindungen betroffen. Die ursprünglich vom FTP-Link erstellte Verbindung ist nicht betroffen.
root_directory Dieser HTTP-Steuerungsparameter wird ignoriert, wenn er auf Clientseite festgelegt wurde. Sie müssen diesen Steuerungsparameter im Nachrichtenserver festlegen, bevor Sie die gespeicherte Prozedur sr_add_message_server oder sr_update_message_server aufrufen. Geben Sie das für den Nachrichtenserver zugängliche Verzeichnis an, in dem die SQL Remote-Nachrichten gespeichert werden. Bei der Verwendung des HTTP-Nachrichtensystems kann die für einen entfernten Benutzer oder Publikationseigentümer angegebene Adresse nur ein einziges Unterverzeichnis enthalten und nicht mehrere Unterverzeichnisse. root_directory='c:\msgs'
url Geben Sie den Servernamen oder die IP-Adresse sowie optional die Portnummer für den verwendeten HTTP-Server an, durch Semikola getrennt. Wenn Anforderungen durch den Relay Server übergeben werden, können Sie optional eine URL-Erweiterung hinzufügen, um anzuzeigen, an welche Serverfarm die Anforderung übergeben werden soll. url ='server-name[:port-number][url-extension]'
user Die Benutzer-ID für die Nachrichtenserver-Datenbank. Dient zum Authentifizieren bei HTTP-Servern und Gateways anderer Hersteller, die RFC 2617 Basic-Authentifizierung verwenden. user='userid'
![]() |
Kommentieren Sie diese Seite in DocCommentXchange.
|
Copyright © 2013, SAP AG oder ein SAP-Konzernunternehmen. - SAP Sybase SQL Anywhere 16.0 |