Eine Archivsicherung sichert die komplette Datenbank in eine oder mehrere – abhängig von der Größe der Datenbank – Dateien, die alle erforderlichen Sicherungs- und Wiederherstellungsinformationen enthalten.

Wichtig: alle angegebenen Pfade gelten aus Sicht des Datenbank-Servers, nicht des Clients!

Archivsicherung per iSQL

BACKUP DATABASE TO 'D:\\TEMP\\SQLA\\Archivsicherung\\database_backup'

Die Sicherung erfolgt ins Verzeichnis D:\TEMP\SQLA\Archivsicherung. Dabei ist database_backup der Basisname der Sicherungsdateien. Die erste Datei heißt database_backup.1. Abhängig von der Größe der gesicherten Datenbank entstehen weitere Dateien mit den Dateiendungen “.2”, “.3”, “.4”, usw.

Wiederherstellen aus einer Archivsicherung

Die Wiederherstellung einer Datenbank aus einer Archivsicherung kann entweder über iSQL erfolgen oder über den Wiederherstellungs-Assistenten in SQL Central (früher: “Sybase Central”).

Wiederherstellen über iSQL

RESTORE DATABASE 'D:\\NeueDatenbank\\datenbankdatei.db'
FROM 'D:\\TEMP\\SQLA\\Archivsicherung';

Beim Wiederherstellen gibt man den Pfad zu der neuen Datenbankdatei an (die erzeugt werden soll). Als Quelle für die Wiederherstellung wird jetzt (im Unterschied zum Sichern) nur noch der Name des Sicherungsverzeichnisses angegeben.

Mehr dazu auf Technotes.

#Admin #Backup

Aktuell (12/2020) ist nur noch die Hauptversion 17 von SQL Anywhere eine aktive und unterstützte Version und wird von SAP durch Updates und Patches gepflegt. Diese Version wird bis 2025 unterstützt werden.

Für SQL Anywhere 16 ist am 31.12.2018 der Support ausgelaufen (genauer: End of Mainstream Maintenance). Es werden für diese Version nur noch Bugfixes veröffentlicht.

SQL Anywhere 17.0

• SQL Anywhere 17.0 SP0 PL39 Build 4935 (01.02.2019)

SQL Anywhere 16.0

• SQL Anywhere 16.0 SP87 Build 2798 (04.02.2019)

Weitere Informationen

Es gibt im SAP-Wiki eine Seite mit Informationen über die verschiedenen Versionsstände und Unterstützungs-“statusse” der Versionen: SAP SQL Anywhere Supported Platforms and Engineering Support Status

#Admin

SQL Anywhere installieren

Wer SQL Anywhere testen und evaluieren möchte, ob es für seinen Bedarf in Frage kommt oder auch einfach nur für SQL Anywhere entwickeln will, der kann die Software einfach auf dem lokalen Rechner installieren.

Diese sogenannte Developer Edition von SQL Anywhere kann schnell und unkompliziert heruntergeladen werden. Notwendig ist dazu lediglich eine kurze Registrierung mit Name und E-Mail-Adresse. Anschließend bekommt man eine E-Mail zugesendet mit Informationen und Links zum Download der Installationsdatei.

In Bezug auf die Inbetriebnahme der Developer Edition unterscheiden sich die beiden aktuellen Versionen 16 und 17. Bei der Version 16 muss man die lokale Installation mit einem Registrierschlüssel füttern – dieser wird in der o.g. E-Mail aber bereits mitgeliefert. Die Version 17 lässt sich ohne Registrierschlüssel installieren und in Betrieb nehmen.

Generell unterscheiden sich die Developer Edition und die “normale” Edition, die man dann auf einem Server im eigenen Netzwerk betreibt, technisch nicht. Der Unterschied liegt nur in der Registrierung. Die Developer Edition hat keinen Registrierschlüssel (bei V17, s.o.) und schaltet dementsprechend nur die Funktionen für den Developer- oder Test-Betrieb frei. Für einen produktiven Einsatz muss man in der Installation einen entsprechenden Registrierschlüssel hinterlegen und bekommt dann die Nutzung im Netzwerk und mit Mehrbenutzerbetrieb freigeschalten (vereinfacht dargestellt).

Registrieren und Herunterladen

Über die SQL Anywhere-Landing-Page auf der SAP-Website kommt man mit einem Klick auf Try now auf das Registrierformular.

Nach der Registrierung bekommt man sofort eine E-Mail mit den Downloadlinks zu den Installationsdateien. Ich beschränke mich hier auf die Beschreibung der Installation unter Windows, jedoch ist die Software auch für andere Plattformen verfügbar (u.A. Linux, ARM, Apple, Solaris, usw.).

Für Windows gibt es für 32- und 64-Bit nur eine gemeinsame Installationsdatei. Diese ist ca. 320 MB groß und landet als SQLA17Developer.exe auf der Festplatte.

Installation

Die Installationsdatei startet dann das Setup. Nach wenigen Klicks (naja ...) ist man durch und die Installation beginnt:

Zu Beginn erfolgt die Frage nach dem Registrierungsschlüssel. Möchte man wie oben beschrieben nur eine lokale Entwicklerinstanz betreiben, dann kann man die erste Option SQL Anywhere Developer Edition installieren belassen. Die Installation geht dann ohne Eingabe eines Registrierungsschlüssels weiter.

Die weitere Installation ist praktisch selbsterklärend. Bei der Frage nach dem Setuptyp kann man getrost Standard wählen. Wer möchte, kann sich mit Angepasst ansehen, welche Bestandteile und Einzelkomponenten SQL Anywhere mitbringt.

Nach erfolgter Installation finden sich im Startmenü prominent die Einträge SQL Central und Interactive SQL. Wer etwas tiefer gräbt, sieht auch noch den Link zur Onlinedokumentation von SQL Anywhere (sog. DocCommentXchange) sowie den Ordner mit diversen Tools.

Weitere Informationen (folgen noch)

• iSQL starten und verbinden
• SQL Central starten und verbinden
• Installationspfad von SQL Anywhere

#Admin

Datenbanken über dbinit erstellen

Es gibt mehrere Möglichkeiten, eine SQL Anywhere-Datenbank zu erstellen:

1. über einen grafischen Assistenten im Datenbank-Browser SQL Central
2. auf der Kommandozeile über das Dienstprogramm dbinit
3. über eine CREATE DATABASE-Anweisung im iSQL-Tool

In diesem Artikel gehe ich nur auf die Erstellung über das Dienstprogramm dbinit ein.

Dienstprogramm dbinit

Mit Hilfe des Dienstprogrammes dbinit kann über eine Kommandozeile ganz schnell eine Datenbank erstellt werden. Der Vorteil dieses Programmes ist, dass sich der Aufruf auch einfach in ein Skript integrieren lässt.

Folgende Angaben sind zwingend oder sinnvollerweise notwendig:

• Name (und ggf. Pfad) der Datenbank
• Name und Passwort des Datenbank-Admin-Benutzers
• Seitengröße
• optional: Name und Pfad des Transaktionslogs
• optional: Name und Pfad des Transaktionslogspiegels

Bei der Eingabe dieses Befehls in einer Kommandozeile (z.B. Eingabeaufforderung unter Windows) empfiehlt es sich, dass gewünschte Zielverzeichnis für die Anlage der Datenbank bereits erzeugt zu haben und in der Eingabeaufforderung dann in dieses Verzeichnis zu wechseln.

cd C:\Temp\Irgendwohinmkdir DbDircd DbDir

Hat man das Verzeichnis mit den SQL Anywhere-Dienstprogrammen nicht über die Pfad-Umgebungsvariable bekannt gemacht, dann muss man das Dienstprogramm über den vollen Pfad aufrufen. Im Fall meiner SQL Anywhere 17-Installation wäre das:

“C:\Program Files\SQL Anywhere 17\Bin64\dbinit.exe”

Wichtig sind die Anführungszeichen, da der Pfad Leerzeichen beinhaltet!

Jetzt rufen wir das Dienstprogramm auf und erzeugen die Datenbank:

“C:\Program Files\SQL Anywhere 17\Bin64\dbinit.exe”-dba NameDesDbAdminUsers,ganzSchwierigesPasswort-p 4kdatenbankname.db

Im aktuellen Verzeichnis (DbDir) entsteht jetzt die Datenbankdatei datenbankname.db. Sie hat eine Seitengröße von 4 kB und der Adminuser heißt NameDesDbAdminUsers.

Da wir keine Angaben zum Transaktionslog gemacht haben, heißt das Transaktionslog datenbankname.log und befindet sich im gleichen Verzeichnis. Es gibt keinen Transaktionslogspiegel.

Während der Erstellung zeigt das Dienstprogramm eine Reihe von Ausgaben:

SQL Anywhere-Dienstprogramm Initialisierung Version 17.0.4.2053CHAR-Kollatierungssequenz:  1252LATIN1(CaseSensitivity=Ignore)CHAR-Zeichensatzkodierung:  windows-1252NCHAR-Kollatierungssequenz:  UCA(CaseSensitivity=Ignore;AccentSensitivity=Ignore;PunctuationSensitivity=Primary)NCHAR-Zeichensatzkodierung:  UTF-8Datenbank ist nicht verschlüsseltSystemtabellen werden erstelltSystemansichten werden erstelltOptionswerte werden gesetztDatenbank “datenbankname.db” erfolgreich erstellt

Datenbank starten

Die neu angelegte Datenbank existiert jetzt, aber der Server hat sie nicht gestartet.

Über die gleiche Kommandozeile kann man diese jetzt einfach mal testweise starten. Ich verwende dazu das Programm dbeng17.exe - den sog. Personal Server. Das ist ein Datenbankserver, der nur zum lokalen Test (z.B. für Entwickler) gedacht ist.

Diesem Programm übergibt man einfach den Namen der zu startenden Datenbank:

“C:\Program Files\SQL Anywhere 17\Bin64\dbeng17.exe” datenbankname.db

Rechts unten im Tray (unter Windows) sieht man dann ein kleines Blitz-Symbol. Über das Kontextmenü lässt sich Wiederherstellen aufrufen. Dann öffnet sich ein Datenbankfenster, das die jeweils aktuellen Ausgaben des Servers anzeigt.

Die Datenbank ist also vom Server gestartet worden. Im Verzeichnis ist jetzt eine weitere Datei enstanden, datenbankname.log. Das ist das Transaktionslog.

$ dirVerzeichnis von D:\DEV\SQLA\Datenbank-anlegen\DbDir11.03.2019  08:49              .11.03.2019  08:49              ..11.03.2019  08:49         2.613.248 datenbankname.db11.03.2019  08:49             4.096 datenbankname.log2 Datei(en),      2.617.344 Bytes

Über Herunterfahren kann jetzt die Datenbank wieder gestoppt werden.

#Admin

In einem Netzwerk möchte man bisweilen testen, ob man von einem speziellen Rechner den Datenbankserver erreichen kann. Dabei kann es sich auch um Berechtigungen innerhalb des Netzwerks handeln, z.B. Einstellungen an der Firewall. Dafür bringt SQL Anywhere das Dienstprogramm dbping mit. Mit diesem lässt sich ein entfernter SQL Anywhere-Server anpingen und prüfen, ob er antwortet.

Das Dienstprogramm dbping.exe findet sich im jeweiligen Programmverzeichnis sowohl unter Bin32 als auch Bin64.

Das Dienstprogramm nimmt als wichtigsten Parameter eine Verbindungszeichenfolge (mit -c) an, z.B.:

• c "Host=Hostname;ServerName=SQLAnywhereServerName"

Das Ping-Tool versucht jetzt:

1. den angegebenen Host Hostname zu kontaktieren
2. dort einen SQL Anywhere-Server auf Port 2638 zu erreichen
3. der auf den logischen Servernamen SQLAnywhereServerName hört

Antwortet dieser, wird Ping des Servers erfolgreich angezeigt.

    C:\Program Files\SQL Anywhere 17\Bin64>dbping.exe
        -c "Host=Hostname;ServerName=SQLAnywhereServerName"
    SQL Anywhere-Dienstprogramm Server-Ping Version 17.0.4.2053
    Ping des Servers erfolgreich.

Bei einem Fehlschlag bekommt man

Ping des Servers fehlgeschlagen - Datenbankserver nicht gefunden.

zu sehen. Das bedeutet:

• es gibt keinen SQL Anywhere-Datenbankserver auf dem angesprochenen Server
• oder es gibt dort einen SQL Anywhere-Datenbankserver, aber der logische Servername lautet anders

#Admin

Auf diesem Blog finden Sie Informationen über die Nutzung des Datenbank-Servers SAP SQL Anywhere (früher: Sybase SQL Anywhere).

Sie finden Informationen über klassische Administrationstätigkeiten (#Admin) als auch über die Entwicklung von Datenbank-Anwendungen (#SQL).

Impressum

Oliver Jakoubek Maria-Lanz-Straße 20 88677 Markdorf www.jakoubek.net

Informationen über neue Posts

Newsfeed (RSS) abonnieren

Per E-Mail abonnieren: