1              Themenübersicht

Die Datenbank-Propertys erlauben die manuelle Anpassung des physischen Layouts der Business-Object-Tabellen und -Indexe, der Datenbankanweisungen sowie der Initialisierung von neuen Datenbankverbindungen.

2              Zielgruppe

• Administratoren
• Technische Berater

3              Beschreibung

Mit den Datenbank-Propertys können Sie die Eigenschaften des Datenbankzugriffs und von Datenmodelländerungen verändern.

Hinweis:

Beachten Sie unbedingt, dass bei der fehlerhaften Verwendung der Datenbank-Propertys die Konsistenz der Daten des ERP-Systems ernsthaft gefährdet ist. Testen Sie daher jede Änderung an den Datenbank-Propertys auf einem Testsystem bevor Sie diese im Produktivsystem einsetzen. Erstellen Sie vor der Verwendung der Datenbank-Propertys immer eine Sicherung des Systems.

Die Datenbank-Propertys werden in einer XML-Datei gespeichert.

Beispiel:

<?xml version=”1.0″ encoding=”UTF-8″?>

<database>

< lobsBuffered/>

</database>

Die Datenbank-Propertys müssen im classes-Verzeichnis des ERP-Systems abgelegt werden. Für jede Datenbank werden die Datenbank-Propertys in jeweils einer eigenen Datei gespeichert. Der Dateiname lautet:

properties-<Datenbankname>.xml

Die Datenbank-Propertys werden beim ersten Zugriff auf die jeweilige Datenbank, d. h. beim Start des Application-Servers, einmalig gelesen. Wenn die Datenbank-Propertys verwendet werden, dann wird eine Meldung im Log des Application-Servers ausgegeben.

Beispiel:

Das ERP-System ist im Verzeichnis C:\ABC\semiramis installiert. Die Datenbank-Propertys für die Datenbank „ABC00“ müssen in folgendes Verzeichnis und in folgender Datei abgelegt werden:

C:\ABC\semiramis\classes\properties-ABC00.xml

Mit dem folgenden Befehl können Sie zusätzliche Debug-Ausgaben für die Datenbank-Propertys ausgeben:

dbgcls -class:com.cisag.sys.kernel.sql.CisDatabaseProperties

Beachten Sie, dass diese Debug-Ausgaben die Leistungsfähigkeit des Application-Servers spürbar beeinträchtigen können. Verwenden Sie diesen Befehl daher nur auf Testsystemen.

3.1        Tabellen und Indexe

Das ERP-System ist datenbankunabhängig. Deshalb existieren für Business Objects im Installationssystem keine datenbankabhängigen Metadaten. Das ERP-System erzeugt die Tabellen und Indexe der Business Objects aufgrund der existierenden Metadaten für jedes Datenbanksystem für die meisten Anwendungsfälle passend.

3.1.1          Physische Eigenschaften anpassen

Bei Installationen mit sehr großem Datenvolumen kann eine manuelle Anpassung der physischen Parameter der Tabellen und Indexe die Leistungsfähigkeit des ERP-Systems verbessern.

Die Datenbank-Propertys erlauben, für jede Tabelle oder jeden Index an das CREATE TABLE- oder CREATE INDEX-Statement eine beliebige Zeichenkette anzuhängen. Wenn die Tabelle oder der Index neu erzeugt wird, so wird das modifizierte Statement ausgeführt.

Beispiel:

Die Tabelle „ABC“ hat bis auf den Primärschlüssel keinen weiteren Index. Die Tabelle „ABC“ wird nur über den Primärschlüssel abgefragt. Die Tabelle „ABC“ kann für die Datenbank „XYZ00“ mithilfe der Datenbank-Propertys als Index-Organized-Table erzeugt werden:

<table>

<name>ABC<name/>

<physical>ORGANIZATION INDEX</physical>

</table>

Bei dem Index I123 sollen 20 % des Platzes in den Blöcken für zukünftige Updates reserviert werden:

<index>

<name>I123<name/>

<physical>PCTFREE 20</physical>

</index>

Die Datenbank-Propertys für eine Tabelle oder einen Index werden also erst beim Erzeugen der Tabelle oder des Indexes wirksam, d. h. erst wenn das Tool „Business Object reorganisieren“ (rgzbo) mit der Option -force aufgerufen wird oder aber wenn das Business Object durch Softwareaktualisierungen oder im Entwicklungssystem verändert wird.

Hinweis:

Beachten Sie, dass Sie das Tool „Business Object reorganisieren“ (rgzbo) nicht verwenden dürfen, solange beliebige Anwendungen aus den zu erzeugenden Tabellen lesen oder schreiben. Das bedeutet insbesondere, dass Sie es nicht im Produktivsystem verwenden dürfen, solange Benutzer angemeldet sind und Verarbeitungsaufträge ausgeführt werden.

Das Tool „Datenbanktabellen anzeigen“ (dspdbt) gibt den Tabellen und die Indexnamen eines Business Objects aus.

3.1.2          Spaltenreihenfolge anpassen

Das Datenbank-Management-System Oracle verteilt die Spalten einer Tabelle gemäß der Spaltenreihenfolge unter Umständen auf mehrere Blöcke. Durch diese Verteilung müssen zum Lesen einer Zeile mehrere Blöcke gelesen werden. Spalten, die besonders häufig verwendet werden, sollten daher gemeinsam in einem Block stehen, damit z. B. bei Abfragen nur ein Block gelesen werden muss.

Beispiel:

Die Spalten „GUID“, „CODE“ und „DESCRIPTION“ der Tabelle „ABC“ sollen die ersten Spalten sein:

<table>

<name>ABC<name/>

<columnSequence>

GUID

CODE

DESCRIPTION

</columnSequence>

</table>

Verwenden Sie das Tool „Spaltenreihenfolge optimieren“ (optclmsqn), um eine gute Spaltenreihenfolge auf Basis der Monitoring-Daten zu berechnen. Das Tool kann auch die Spaltenreihenfolge einer Tabelle auf der Datenbank ändern.

Hinweis:

Beachten Sie, dass neue Spalten am Ende der Tabelle hinzugefügt werden, wenn ALTER TABLE verwendet wird. Verwenden Sie entweder CREATE TABLE AS SELECT oder prüfen Sie nach einem Release-Wechsel, ob die Spaltenreihenfolge noch optimal ist.

3.2        Verbindungsaufbau

Durch die Datenbank-Propertys können Sie zusätzliche Anweisungen beim Aufbau jeder Datenbankverbindung ausführen. Mit den zusätzlichen Anweisungen können Sie die Eigenschaften der vom ERP-System verwendeten Datenbankverbindungen modifizieren. Die Anweisungen werden in der Reihenfolge ausgeführt, in der diese in der XML-Datei angegeben wurden.

Beispiel:

Sie können direkt nach dem Öffnen einer neuen Datenbankverbindung zu der Datenbank „XYZ00“ die Anweisung „ALTER SESSION SET NLS_COMP=’ANSI’“ ausführen.

<connectStatement>

ALTER SESSION SET NLS_COMP=’ANSI’

</connectStatement>

3.3        Datenbankanweisungen ersetzen

Mithilfe der Datenbank-Propertys können Sie ausgewählte Datenbankanweisungen vor deren Ausführung durch andere Datenbankanweisungen ersetzen. Dadurch können Sie beispielsweise Hinweise für den Optimierer einfügen oder aber die Join-Reihenfolge der Datenbankanweisung ändern. Sie können durch die Datenbank-Propertys diese Optimierungen vornehmen, ohne den Programmcode des ERP-Systems ändern zu müssen.

Hinweis:

Stellen Sie unbedingt sicher, dass die Ersetzung das Ergebnis der Datenbankanweisung nicht verändert.

Beachten Sie unbedingt, dass eine fehlerhafte Verwendung dieser Funktion die Konsistenz der Datenbank irreparabel beschädigen kann. Testen Sie jede Ersetzung von Datenbankanweisungen gründlich.

Die Ersetzung von Datenbankanweisungen sollte ein Ausnahmefall sein. Übernehmen Sie alle Ersetzungen, bei denen dieses möglich ist, sobald als möglich z. B. als Adaptierung in Ihr Entwicklungssystem.

Beispiel:

Sie wollen die Datenbankanweisung
SELECT * FROM “ITEM001” WHERE “GUID”=?

auf der Datenbank „XYZ00“ ersetzen durch:
SELECT * FROM XYZ00.”ITEM001” WHERE “GUID”=?

Das folgende XML führt die Ersetzung durch:

<replacement>

<original>

SELECT * FROM “ITEM001” WHERE “GUID”=?

</original>

<replaced>

SELECT * FROM XYZ00.”ITEM001” WHERE “GUID”=?

</replaced>

</replacement>

3.4        Datenbank-Failover

Die unterstützten Datenbank-Management-Systeme (DBMS) bieten unterschiedliche Mechanismen zum Datenbank-Failover an. Die vom DBMS angebotene Funktionalität bietet jedoch in einigen Fällen nicht die vom Kunden gewünschte Ausfallsicherheit. Das ERP-System bietet optional aktivierbare Funktionen, die die Ausfallsicherheit beim Datenbank-Failover verbessern können.

3.4.1    Transaktionsmonitor

Der Transaktionsmonitor erhöht die Ausfallsicherheit bei schreibenden Zugriffen durch das ERP-System. Durch den Transaktionsmonitor kann im Fehlerfall erkannt werden, ob die Schreibtransaktion erfolgreich war oder fehlgeschlagen ist. Falls die Transaktion fehlgeschlagen ist, wird die Schreibtransaktion wiederholt.

Beispiel:

Das folgende XML aktiviert den Transaktionsmonitor:

<transactionMonitor/>

3.4.2    LOB-Pufferung

Einige Datenbank-Management-Systeme (z. B. Oracle 10 und 11) können bei Anfragen mit großen Binär- oder Textobjekten (BLOB oder CLOB kurz LOB) die Ausfallsicherheit beim Datenbank-Failover nicht gewährleisten. Das ERP-System kann beim Zugriff auf LOB-Spalten durch das Puffern der LOB-Inhalte die Ausfallsicherheit beim Datenbank-Failover erhöhen.

Hinweis:

Das Puffern der LOBs betrifft den Lesezugriff über Business Objects und den Lesezugriff auf den Knowledge Store. Der Lesezugriff über ODBC-SQL oder OQL kann durch das ERP-System nicht abgesichert werden. Das bedeutet, dass die meisten interaktiven Anwendungen und Hintergrundanwendungen mit der LOB-Pufferung ausfallsicher werden, selbst dann, wenn das DBMS das Datenbank-Failover bei den LOBs nicht leistet. Beleg- und Berichtsausgaben sowie Cockpit-Anwendungen können jedoch trotz der LOB-Pufferung beim Datenbank-Failover abbrechen.

Die LOB-Pufferung erhöht den Speicherbedarf des Application-Servers und erzeugt ggf. zusätzliche Zugriffe auf das Dateisystem des Application-Servers.

Beispiel:

Das folgende XML aktiviert die LOB-Pufferung:

< lobsBuffered/>

3.4.3    Failover-Timeout

Das Datenbank-Management-System (DBMS) kann auch im Produktivbetrieb temporär nicht verfügbar sein. In diesem Fall ist für eine bestimmte Zeit der Verbindungsaufbau zum Datenbank-Management-System nicht möglich. Sie können einstellen, wie lange der Application-Server versuchen soll, eine Verbindung zum DBMS aufzubauen. Wenn diese Zeit abgelaufen ist, dann wird im Allgemeinen die Anwendung, die die Datenbankverbindung angefordert hat, mit einer Fehlermeldung abgebrochen.

Sie geben die Zeitdauer als Zahl in Minuten an. Wenn Sie keine Zahl angeben, versucht der Application-Server unbegrenzt lange eine Verbindung aufzubauen.

Beispiel:

Failover-Timeout von 5 Minuten:

<failoverTimeout>5</failoverTimeout>

Failover-Timeout unendlich:

<failoverTimeout/>

3.4.4    Datenbankfehlererkennung

Das ERP-System wertet die Datenbankfehlermeldungen aus. So erkennt das ERP-System aufgrund der Fehlernummer beispielsweise, ob ein Datenbank-Failover eingeleitet werden soll. Die Datenbankfehlermeldungen sind mit der zugehörigen Bedeutung fest im ERP-System kodiert. Sie können sofern erforderlich zusätzliche Fehlermeldungen dem ERP-System bekannt machen.

Die folgenden Typen von Fehlermeldungen werden unterstützt:

Eine Fehlermeldung wird durch den SQL-State und die Fehlernummer identifiziert. Das System gibt bei einem Datenbankfehler den SQL-State und die Fehlernummer aus. Zur Fehlererkennung müssen Sie mindestens einen der Werte angeben. Wenn ein Datenbankfehler auftritt passiert Folgendes:

1. Liegt ein vom ERP-System erkannter Fehler vor? Wenn ja, dann diesen Fehlertyp verwenden.
2. Prüfen, ob der Fehler in den Datenbank-Propertys angeben wurde. Wenn alle angegebenen Eigenschaften auf den Fehler zutreffen, wird der entsprechende Fehlertyp verwendet.
3. Der Fehler wird als unbekannter Fehler behandelt.

Beispiel:

Erkenne den Fehler mit dem SQL-State „42000“ und der Fehlernummer 937 als Verbindungsabbruch:

<exception>

<type>CONNECTION_LOST</type>

<errorCode>937</errorCode>

<sqlState>42000</sqlState>

</exception>

3.4.5    Optimierung von Datenmodelländerungen

Datenmodelländerungen können bei Release-Wechseln viel Zeit benötigen. Mit den Datenbank-Propertys können Sie diese Zeit verkürzen, wenn Sie auf die Transaktionssicherheit bei Teilen des Release-Wechsels verzichten.

Hinweis:

Prüfen Sie sehr genau, ob die verwendete Datenbank-Property die Konsistenz Ihres Systems gefährdet.

Bei einer falschen Verwendung wird keine Gewährleistung übernommen.

3.4.5.1      Oracle: ALTER TABLE vs. CREATE TABLE AS SELECT

Das Erzeugen neuer Spalten mit einem konstanten Initialwert, das Löschen von Spalten und das Verlängern von String-Attributen wird normalerweise durch ALTER TABLE abgebildet.

Bei Oracle-Datenbanken können Sie statt mit ALTER TABLE die Datenmodelländerung mit CREATE TABLE AS SELECT und durch eine temporäre Tabelle durchführen. Diese temporäre Tabelle benötigt mehr Speicherplatz in der Datenbank, kann aber zu einer geringeren Plattenbelastung führen und zwar insbesondere, wenn Sie die Propertys <updateOracleNoLogging> oder <updateOracleParallel> einsetzen.

Beispiel:

Wähle CREATE_TABLE_AS statt ALTER_TABLE:

<updateTable>

CREATE_TABLE_AS

</updateTable>

3.4.5.2      Oracle: NOLOGGING

Beim Erzeugen von Indexen und bei CREATE TABLE AS SELECT kann mit der Option NOLOGGING das Schreiben des Archive-Logs abgeschaltet werden. Diese Operationen werden durch das Abschalten des Archive-Logs deutlich beschleunigt. Wenn Ihre Datenbank normalerweise das Archive-Log schreibt, so wird das Archive-Log durch diese Option inkonsistent. Ein inkonsistentes Archive-Log kann zu Inkonsistenzen beispielsweise bei Standby-Datenbanken oder beim Wiederherstellen aus einem Backup führen.

Hinweis:

Prüfen Sie sehr genau, ob Sie das Archive-Log für eine Datenmodelländerung abschalten dürfen.

Beispiel:

Abschalten des Archive-Logs bei Datenmodelländerungen:

<updateOracleNoLogging/>

3.4.5.3      Oracle: PARALLEL

Das Erzeugen von Indexen und bei CREATE TABLE AS SELECT kann mit der Option PARALLEL parallelisiert und damit beschleunigt werden. Die Parallelisierung wird bei Oracle mit der Enterprise Edition unterstützt.

Hinweis:

Prüfen Sie, ob in Ihrer Datenbankinstallation die Parallelisierung lizenziert ist.

Beispiel:

Parallelisierung der Datenmodelländerungen:

<updateOracleParallel>PARALLEL 4</updateOracleParallel>

3.4.5.4      iSeries: ALTER TABLE no commit

Bei Datenmodelländerungen mit ALTER TABLE kann bei der iSeries mit der Property <updateAlterTableNoCommit/> das Journaling abgeschaltet werden. Die Datenmodelländerungen werden dadurch deutlich beschleunigt.

Hinweis:

Prüfen Sie genau, welche Konsequenzen das Abschalten des Journalings in Ihrem System hat.

Beispiel:

Journaling bei Datenmodelländerungen abschalten:

<updateAlterTableNoCommit/>

3.5        Datenbankverbindungen anpassen

In der Regel verwenden Sie zur Installation des Test- oder Produktivsystems beim Kunden eine Kopie des Entwicklungs- oder Entwicklungstestsystems. Die Konfigurations-Datenbank, die durch eine solche Installation importiert wird, enthält meist keine zum Kundensystem passenden Verbindungsdaten. Mithilfe der folgenden System-Propertys können Sie die Verbindungsdaten anpassen.

Die Propertys enthalten jeweils den Namen des Business Objects, den Namen der Datenbank und den Attributpfad des anzupassenden Attributs:

com.cisag.sys.configuration.obj.Database.<Datenbankname>.<Attributpfad>

com.cisag.sys.configuration.obj.SVMDBConnection.<Datenbankname>.<Attributpfad>

Ersetzen Sie den Wert <Datenbankname> durch den Namen der Datenbank in der zugehörigen Konfigurations-Datenbank. Ersetzen Sie den Wert <Attributpfad> durch den technischen Namen des anzupassenden Attributs. Geben Sie den gewünschten Wert des Attributs als Zeichenkette an.

Beispiel:

Sie können eine Datenbankverbindung für die Datenbank „ABC123RP“ wie folgt ändern:

Benutzer:

com.cisag.sys.configuration.obj.Database.ABC123RP.user=XYZ456RP

Schema:

com.cisag.sys.configuration.obj.Database.ABC123RP.schema=XYZ456RP

Kennwort:

com.cisag.sys.configuration.obj.Database.ABC123RP.password=XYZ456RP

JDBC-Treiber

com.cisag.sys.configuration.obj.SVMDBConnection.ABC123RP.driver=12

Zugriffspfad:

com.cisag.sys.configuration.obj.SVMDBConnection.ABC123RP.driverAccessPath=jdbc:jtds:sqlserver://sql.xyz.com:1433

Hinweis:

Beachten Sie, dass Sie die Propertys in die Datei system.properties eintragen müssen und nicht in die Datenbank-Property-Datei.

Nachdem das System mit einer durch die genannten Propertys angepassten Datenbankverbindung gestartet wurde, können Sie diese Einstellungen mit dem folgenden Befehl in die Konfigurations-Datenbank übernehmen:

wrksysprp –update

Hinweis:

Beachten Sie, dass das Tool „Mit System-Propertys arbeiten“ (wrksysprp, Parameter ‑update) die Systemkonfiguration mit dem Inhalt der Propertys anpasst. Sie sollten das Tool nur bei der Installation eines neuen Systems verwenden.

Mit dem folgenden Befehl können Sie die Propertys eines Systems in eine Datei exportieren. Sie können die Datenbankverbindungen eines Systems in dieser Datei komfortabel überarbeiten.

wrksysprp –export:C:\temp\my.properties

Hinweis:

Beachten Sie, dass statt des Datenbankkennworts der Datenbankname ausgegeben wird. Ersetzen Sie die Datenbanknamen durch die richtigen Kennwörter, damit ein System mit diesen Propertys starten kann.

Bei der Installation eines neuen Systems aus der Kopie eines anderen Systems, sollten Sie die Datenbanken mit den Namen des neuen Systems importieren.

Beispiel:

Wenn Sie die Datenbanken „C4711DVCF“, „C4711DVRP“ und „C4711DV01“ exportieren, dann importieren Sie diese in das Datenbank-System des Kunden mit den Namen „C4711CF“, „C4711TRP“ und „C4711T01“. Damit das Kundensystem „C4711T“ starten kann, passen Sie die System-Propertys so an, dass das System auf die neuen Datenbanken zugreifen kann. Nach dem Systemstart wird die Repository-Datenbank mit den folgenden Daten angesprochen:

Datenbankname: C4711DVRP

Datenbankschema: C4711TRP

Mit dem folgenden Befehl können Sie die Datenbanknamen in der Konfigurationsdatenbank auf den Namen des Datenbankschemas ändern:

wrksysprp –renameDatabases

Beispiel:

Der Befehl „wrksysprp –renameDatabases“ ändert im obigen Beispiel den Datenbanknamen auf „C4711TRP“.

Hinweis:

Beachten Sie, dass Sie die Datenbanken erst nach dem Aufruf des Tools „Mit System-Propertys arbeiten“, Parameter –update, („wrksysprp –update“) umbenennen sollten, da ansonsten die System-Propertys aufgrund der geänderten Datenbanknamen nicht mehr wirksam sind. Entfernen Sie nach dem Aufruf des Tools „Mit System-Propertys arbeiten“, Parameter ‑renameDatabases, („wrksysprp –renameDatabases“) die Propertys zum Anpassen der Datenbankverbindungen aus den System-Propertys.

4              Vorgehensweise: Tabellen und Indexe erzeugen

Voraussetzungen

Wenn Sie die Datenbank-Propertys für die Tabellen- oder Index-Erzeugung erfassen oder verändern, sollten Sie alle betroffenen Tabellen mit dem Tool „Business Object reorganisieren“ (rgzbo) neu erzeugen. Beachten Sie dabei unbedingt die folgenden Hinweise:

• Testen Sie alle Änderungen auf dem Testsystem bevor Sie diese im Produktivsystem einsetzen.
• Sichern Sie die Datenbank.

Anleitung

1. Legen Sie die Datenbank-Propertys-Datei für die Datenbank „db“mit dem Namen „properties-<db>.xml“ im classes-Verzeichnis des Systems ab.
2. Beenden Sie alle Application-Server außer dem Message-Server.
3. Stellen Sie sicher, dass keine Benutzer auf dem Message-Server angemeldet sind und dass keine Verarbeitungsaufträge laufen.
4. Führen Sie für alle Business Objects „x1, …, xn“ und die Datenbank „db“ die folgenden Toolshell-Befehle aus:

rgzbo -force -db:<db> -o:<x1>

…

rgzbo -force -db:<db> -o:<xn>

5. Starten Sie den Message-Server und alle Application-Server neu.
6. Prüfen Sie, ob die Tabellen erfolgreich erzeugt wurden.