In diesem Abschnitt werden die Richtlinien zur Datenbankkonfiguration beschrieben, die von Datenbankadministratoren angewendet werden, um eine DB2-Datenbank für WebSphere Product Center zu erstellen und zu konfigurieren.
Voraussetzungen erfüllen
- Installieren Sie IBM DB2 II Version 8.1 Advanced Edition oder IBM DB2 UDB 8.1 Enterprise Server Edition unter AIX Version 5L v5.1.
- Wenden Sie DB2 Fixpack 5 auf den Datenbankserver an.
Wenn die oben genannten Voraussetzungen erfüllt sind, müssen Sie die in diesem Abschnitt beschriebenen Richtlinien anwenden, um die Datenbank für WebSphere Product Center zu erstellen und zu definieren.
Exemplar für WebSphere Product Center-Datenbank erstellen
Erstellen Sie ein Exemplar mit dem Namen db2inst1 für die WebSphere Product Center-Datenbank. Falls gewünscht, erstellen Sie ein 64-Bit-Exemplar für die Datenbank. Es steht eine Option zur Verfügung, mit der ein Exemplar zum Zeitpunkt der DB2-Softwareinstallation erstellt werden kann.
Neue Datenbank erstellen
Die gemeinsame Nutzung einer bestehenden Datenbank auf einer Maschine mit einer Datenbank der WebSphere Product Center-Middleware wird nicht empfohlen. Erstellen Sie eine neue Datenbank für das WebSphere Product Center-Schema. Sie können die erforderliche Datenbank sowie die erforderlichen Pufferpools und Tabellenbereiche zum Zeitpunkt der DB2-Softwareinstallation erstellen.
Hinweis: Die Datenbank muss unbedingt unter Verwendung des codierten Zeichensatzes UTF-8 erstellt werden. Der in den Beispielen dieses Handbuchs verwendete Datenbankname lautet WPCDB.
Neue Pufferpools erstellen
Da die Tabellen in WebSphere Product Center sehr groß sind, liegt die Seitengröße für die Erstellung der Pufferpools bei 16 KB.
Die folgenden Pufferpools sind für die Verwendung durch Tabellenbereiche erforderlich:
- USERSBP – Zur Verwendung durch den Tabellenbereich USERS
- INDXBP – Zur Verwendung durch den Tabellenbereich INDX
- BLOBBP – Zur Verwendung durch den Tabellenbereich BLOB_TBL_DATA
- TEMPUSRBP – Zur Verwendung durch den Tabellenbereich für temporäre Tabellen des Benutzers
- TEMPSYSBP – Zur Verwendung durch den Tabellenbereich für temporäre Tabellen des Systems
Die folgende Tabelle enthält eine Liste der für die einzelnen Pufferpools jeweils empfohlenen Größe.
Pufferpool Größe (16-KB-Seiten)* USERSBP 30.000 INDXBP 30.000 BLOBBP 1.000 TEMPUSRBP 10.000 TEMPSYSBP 10.000
* Diese Zahlen wurden für einen Server mit 4 GB Hauptspeicher kalibriert. Die Größen können unter Verwendung des Faktors 0,25 pro GB Zunahme des Hauptspeichers des Datenbankservers erhöht werden.
* Vor dem Erstellen der neuen Tabellenbereiche müssen Sie das Exemplar unter Verwendung der Befehle 'db2stop' und 'db2start' erneut starten, um die Pufferpools zu aktivieren.
Von der Steuerzentrale erstellter Beispiel-SQL-Code:
db2 CONNECT TO wpcdb
db2 CREATE BUFFERPOOL USERSBP SIZE 30000 PAGESIZE 16384
db2 CREATE BUFFERPOOL INDXBP SIZE 30000 PAGESIZE 16384
db2 CREATE BUFFERPOOL BLOBBP SIZE 1000 PAGESIZE 16384
db2 CREATE BUFFERPOOL TEMPUSRBP SIZE 10000 PAGESIZE 16384
db2 CREATE BUFFERPOOL TEMPSYSBP SIZE 10000 PAGESIZE 16384Neue Tabellenbereiche erstellen
Da die Tabellen in WebSphere Product Center sehr groß sind, liegt die Seitengröße für die Erstellung der Pufferpools bei 16 KB.
Für WebSphere Product Center sind die folgenden Tabellenbereiche erforderlich:
- USERS
- INDX
- BLOB_TBL_DATA
- TEMP_USER
- TEMP_SYSTEM
Die folgende Tabelle enthält eine Liste der Zuordnungen von Typen, Pufferpools und Knotengruppen zu den jeweiligen Tabellenbereichen.
Tabellenbereich
Typ
Verwaltung
Pufferpool
USERS
REGULAR
Datenbank
USERSBP
INDX
REGULAR
Datenbank
INDXBP
BLOB_TBL_DATA
REGULAR
Datenbank
BLOBBP
TEMP_USER
USER TEMPORARY
System
TEMPUSRBP
TEMP_SYSTEM
SYSTEM TEMPORARY
System
TEMPSYSBP
Hinweis: Wenn DMS-Tabellenbereiche (von der Datenbank verwaltete Tabellenbereiche) eingesetzt werden, müssen Sie sicherstellen, dass genügend Container erstellt und den einzelnen Tabellenbereichen jeweils zugeordnet werden. Stellen Sie sicher, dass TEMP_USER als Tabellenbereich USER TEMPORARY und TEMP_SYSTEM als Tabellenbereich SYSTEM TEMPORARY erstellt wird und beide vom System verwaltet werden.
Von der Steuerzentrale erstellter Beispiel-SQL-Code:
Hinweis: In den folgenden Beispielen wird zum Erstellen von Tabellenbereichen der Verzeichnispfad '/u01/db2data/wpcdb/' verwendet.
db2 CONNECT TO wpcdb;
db2 CREATE REGULAR TABLESPACE USERS PAGESIZE 16K MANAGED BY DATABASE
USING (file '/u01/db2data/wpcdb/users01' 90000)
EXTENTSIZE 32 PREFETCHSIZE 64 BUFFERPOOL USERSBP
OVERHEAD 24.100000 TRANSFERRATE 0.900000 DROPPED TABLE RECOVERY ON;db2 CREATE REGULAR TABLESPACE INDX PAGESIZE 16K MANAGED BY DATABASE
USING (file '/u01/db2data/wpcdb/indx01' 190000)
EXTENTSIZE 32 PREFETCHSIZE 64 BUFFERPOOL INDXBP
OVERHEAD 24.100000 TRANSFERRATE 0.900000 DROPPED TABLE RECOVERY ON;db2 CREATE REGULAR TABLESPACE BLOB_TBL_DATA PAGESIZE 16K MANAGED BY DATABASE
USING (file '/u01/db2data/wpcdb/blob01' 60000)
EXTENTSIZE 32 PREFETCHSIZE 64 BUFFERPOOL BLOBBP
OVERHEAD 24.100000 TRANSFERRATE 0.900000 DROPPED TABLE RECOVERY ON;db2 CREATE USER TEMPORARY TABLESPACE TEMP_USER PAGESIZE 16K MANAGED BY SYSTEM
USING ('/u01/db2data/wpcdb/usertemp01')
EXTENTSIZE 32 PREFETCHSIZE 64 BUFFERPOOL TEMPUSRBP
OVERHEAD 24.100000 TRANSFERRATE 0.900000;db2 CREATE SYSTEM TEMPORARY TABLESPACE TEMP_SYSTEM PAGESIZE 16K MANAGED BY SYSTEM
USING ('/u01/db2data/wpcdb/systemtemp01')
EXTENTSIZE 32 PREFETCHSIZE 64 BUFFERPOOL TEMPSYSBP
OVERHEAD 24.100000 TRANSFERRATE 0.900000;AIX-Benutzer erstellen
Für das Datenbankschema von WebSphere Product Center ist ein Datenbankbenutzer erforderlich, und die Benutzerauthentifizierung muss auf Serverebene erfolgen.
- Erstellen Sie den Betriebssystembenutzer mit dem Namen WPC auf der Betriebssystemebene für die Verwendung durch das WebSphere Product Center-Datenbankschema.
- Richten Sie das Kennwort des Benutzers auf Betriebssystemebene ein und versuchen Sie, eine Verbindung zum Benutzer auf Betriebssystemebene herzustellen, um zu prüfen, ob der Benutzer eine Verbindung zum Server herstellen kann.
- Legen Sie die Primärgruppe je nach Erstellung in AIX entweder auf db2iadm1 oder auf db2grp1 fest.
Hinweis: Es empfiehlt sich, das Verwaltungsdienstprogramm SMIT von AIX 5L zu verwenden, um einen neuen AIX-Benutzer zu erstellen.
Datenbankbenutzer hinzufügen und Berechtigungen erteilen
Nachdem Sie den Benutzer auf Betriebssystemebene erstellt haben, erstellen Sie den Datenbankbenutzer WPC und erteilen Sie diesem Benutzer die nachstehenden Berechtigungen. Verwenden Sie dabei die Exemplareigneranmeldung (die standardmäßige Exemplareigneranmeldung lautet db2inst1).
- DBADM
- CREATETAB
- BINDADD
- CONNECT
- CREATE_NOT_FENCED
- IMPLICIT_SCHEMA
- LOAD ON DATABASE
Von der Steuerzentrale erstellter Beispiel-SQL-Code:
db2 CONNECT TO wpcdb
GRANT DBADM, CREATETAB, BINDADD, CONNECT, CREATE_NOT_FENCED, IMPLICIT_SCHEMA, LOAD ON DATABASE TO USER WPC;
Erteilen Sie darüber hinaus die Berechtigung zur Verwendung von Speicherplatz in allen für WebSphere Product Center spezifischen Tabellenbereichen.
Von der Steuerzentrale erstellter Beispiel-SQL-Code:
GRANT USE OF TABLESPACE USERS TO WPC;
GRANT USE OF TABLESPACE INDX TO WPC;
GRANT USE OF TABLESPACE BLOB_TBL_DATA TO WPC;
GRANT USE OF TABLESPACE TEMP_USER TO WPC;Neues Schema erstellen
Erstellen Sie ein neues Schema WPC für den Benutzer WPC.
Von der Steuerzentrale erstellter Beispiel-SQL-Code:
CREATE SCHEMA WPC AUTHORIZATION WPC;
Hinweis: Wiederholen Sie die Schritte ab "AIX-Benutzer erstellen" im vorstehenden Abschnitt bis "Neues Schema erstellen", wenn Sie einen zusätzlichen Datenbankschemabenutzer für ein weiteres Exemplar von WebSphere Product Center wünschen. Wenn beispielsweise ein weiteres Testexemplar von WebSphere Product Center auf dem Anwendungsserver ausgeführt werden soll, der ein Datenbankschema in derselben Datenbank benötigt, müssen Sie in der Datenbank einen Datenbankbenutzer und ein Datenbankschema mit dem Namen WPCTEST erstellen. Hierfür ist ein Betriebssystembenutzer mit dem Namen WPCTEST erforderlich.
Knoten und Datenbank auf Anwendungsserver katalogisieren
Bei Ausführung von WebSphere Product Center und der Datenbank auf unterschiedlichen Servern
Wenn WebSphere Product Center auf einem anderen Server ausgeführt wird, müssen Sie die Datenbank katalogisieren, um über WebSphere Product Center auf sie zugreifen zu können. Führen Sie hierzu die folgenden Befehle auf dem Anwendungsserver aus:
db2 "catalog tcpip node <knotenname> remote <dbhostname> server <sname/port#>"
db2 terminate
db2 "catalog database <dbname> as <dbname> at node <knotenname>"
db2 terminateHierbei gilt:
- knotenname - Beliebiger Namen für das ferne Exemplar
- dbhostname - Hostname oder IP-Adresse des Datenbankservers
- sname/port# - Servicename oder Portnummer für den Verbindungsport des lokalen DB2-Exemplars in der Datei '/etc/services'
- dbname – Datenbankname
Hinweis: Um den korrekten Verbindungsport zu ermitteln, rufen Sie mit Hilfe des folgenden Befehls den Wert des Parameters SVCNAME des Datenbankmanagers (DBM) ab:
Db2 get dbm cfg|grep “SVCNAME”Beispiel:
db2 "catalog tcpip node NODE0001 remote trigprd server 50000/tcp"
db2 terminate
db2 "catalog database wpcdb as wpcdb at node NODE0001"
db2 terminateBei Ausführung von WebSphere Product Center und der Datenbank auf demselben Server
Bei der Ausführung von WebSphere Product Center auf derselben Maschine mit DB2 unter AIX besteht ein Problem. Die folgenden beiden Korrekturen sind erforderlich, damit WebSphere Product Center funktioniert:
1. Exportieren Sie EXTSHM=ON in die Datei '.profile' und '.bashrc' des DB2-Datenbankexemplareigners und des Benutzers, der für die Installation der WebSphere Product Center-Anwendung verwendet wurde:
export EXTSHM=ON
2. Legen Sie DB2ENVLIST mit Hilfe des Befehls 'db2set' als DB2-Exemplareigner fest, der die Datenbank erstellt hat:
db2set DB2ENVLIST=EXTSHM
Geben Sie die Befehle 'db2stop force' und 'db2start' aus.
Aktualisierungen für das Profilregister der DB2-Datenbank
Die folgenden Variablen des Profilregisters sind für die Verwendung durch WebSphere Product Center erforderlich:
- DB2_RR_TO_RS
- DB2CODEPAGE
- DB2COMM
Andere Variablen des Profilregisters sind nicht erforderlich, können aber festgelegt werden, wenn dazu eine spezifische Anforderung besteht.
DB2_RR_TO_RS
Beschreibung: Das Sperren des nächsten Schlüssels garantiert die Isolationsstufe 'Wiederholbares Lesen' (Repeatable Read, RR), indem automatisch der nächste Schlüssel für alle INSERT- und DELETE-Anweisungen sowie der nächsthöhere Schlüsselwert über der Ergebnismenge für SELECT-Anweisungen gesperrt werden.
Für UPDATE-Anweisungen, die Schlüsselteile eines Indexes ändern, wird der ursprüngliche Indexschlüssel gelöscht und der neue Schlüsselwert wird eingefügt. Das Sperren des nächsten Schlüssels erfolgt bei Schlüsseleinfügung und auch bei Schlüssellöschung. Der Überspringverhalten wirkt sich auf die Isolationsstufen 'Wiederholbares Lesen' (RR), 'Lesestabilität' (Read Stability, RS) und 'Cursorstabilität' (Cursor Stability, CS) aus. (Für die Isolationsstufe 'Lesen ohne Bestätigung' - Uncommitted Read, UR - gibt es keine Zeilensperrung.) Wenn DB2_RR_TO_RS auf den Wert ON festgelegt wird, kann das Verhalten von RR nicht für Überprüfungen von Benutzertabellen garantiert werden, weil das Sperren des nächsten Schlüssels nicht während des Einfügens und Löschens von Indexschlüsseln erfolgt.
Katalogtabellen sind von dieser Option nicht betroffen. Die andere Änderung im Verhalten besteht darin, dass bei Festlegung von DB2_RR_TO_RS auf den Wert ON Prüfungen Zeilen überspringen, die gelöscht, aber nicht festgeschrieben wurden, selbst wenn die betreffende Zeile sich für die Überprüfung qualifiziert hat.
Wert: Auf ON festlegen
Beispiel:
db2set db2_rr_to_rs=ON
DB2CODEPAGE
Beschreibung: Die Codepage wird zum Angeben des Zeichensatzes eingesetzt, der während des Exports und Imports von Daten in DB2 verwendet wird. Legen Sie diesen Wert auf 1208 fest.
Wert: Auf 1208 festlegen
Beispiel:
db2set db2codepage=1208
DB2COMM
Beschreibung: Mit der Registervariablen 'db2comm' wird das Protokoll festgelegt, dessen Verbindungsmanager aktiviert werden sollen, wenn der Datenbankmanager gestartet wird. Sie können für diese Variable mehrere Kommunikationsprotokolle angeben, indem Sie die Schlüsselwörter durch Kommata trennen.
Wert: Auf 'tcpip' festlegen
Beispiel:
db2set db2comm=tcpip
DB2-Datenbankmanager konfigurieren
Die folgenden Konfigurationsparameter des Datenbankmanagers müssen zur Verwendung mit WebSphere Product Center festgelegt werden:
- MON_HEAP_SZ - Größe des Zwischenspeichers des Datenbanksystemmonitors
- SHEAPTHRES - Schwellenwert des Sortierspeichers
- ASLHEAPSZ - Größe des Zwischenspeichers der Anwendungsunterstützungsschicht
- QUERY_HEAP_SZ - Größe des Abfragezwischenspeichers
- MAXAGENTS - Maximale Anzahl der Agenten
Beschreibung Wert Beispiel MON_HEAP_SZ Der Speicher, der für die Pflege privater Ansichten der Datenbanksystemmonitordaten erforderlich ist, wird vom Monitorzwischenspeicher zugeordnet. Seine Größe wird von dem Konfigurationsparameter 'mon_heap_sz' gesteuert. Auf 30000 festlegen SHEAPTHRES Private und gemeinsam genutzte Sortiervorgänge verwenden Speicher aus zwei unterschiedlichen Speicherquellen. Die Größe des gemeinsam genutzten Sortierspeicherbereichs wird auf der Basis des Werts des Parameters 'sheapthres' zu dem Zeitpunkt statisch vordefiniert, an dem die erste Verbindung zu einer Datenbank hergestellt wird. Dieser Wert muss mindestens die doppelte Größe des Parameters 'sortheap' aller Datenbanken aufweisen, für die das DB2-Exemplar als Host dient. Auf 20000 festlegen ASLHEAPSZ Der Zwischenspeicher der Anwendungsunterstützungsschicht stellt einen Kommunikationspuffer zwischen der lokalen Anwendung und dem dieser Anwendung zugeordneten Agenten dar. Dieser Puffer wird von jedem gestarteten Datenbankmanageragenten als gemeinsam genutzter Speicher zugeordnet. Auf 4200 festlegen QUERY_HEAP_SZ Dieser Parameter gibt an, welche Speichermenge dem Abfragezwischenspeicher maximal zugeordnet werden kann. Ein Abfragezwischenspeicher wird zum Speichern aller Abfragen im privaten Speicher des Agenten verwendet. Sie sollten den Parameter 'query_heap_sz' mindestens auf einen Wert festlegen, der fünf Mal größer als der des Parameters 'aslheapsz' ist. Auf 524280 festlegen MAXAGENTS Dieser Parameter gibt die maximale Anzahl von Datenbankmanageragenten (sowohl koordinierende Agenten als auch Subagenten) an, die zu einem beliebigen Zeitpunkt verfügbar sind, um WebSphere Product Center-Anforderungen zu empfangen. Der Wert des Parameters 'maxagents' sollte mindestens der Summe der Werte des Parameters 'maxappls' in allen Datenbanken entsprechen, auf die gleichzeitig zugegriffen werden kann. Wenn die Anzahl der Datenbanken größer ist als der Wert des Parameters 'numdb', besteht die sicherste Vorgehensweise darin, den Wert von 'numdb' mit dem größten Wert für den Parameter 'maxappls' zu multiplizieren und das Ergebnis dieser Operation zu verwenden. Auf 400 festlegen Beispielscript:
update dbm cfg using MON_HEAP_SZ 30000;
update dbm cfg using SHEAPTHRES 20000;
update dbm cfg using ASLHEAPSZ 4200;
update dbm cfg using QUERY_HEAP_SZ 524280;
update dbm cfg using MAXAGENTS 400;
Konfigurationsparameter für die DB2-Datenbank
Die folgenden Konfigurationsparameter der Datenbank müssen zur Verwendung mit WebSphere Product Center festgelegt werden:
- DFT_QUERYOPT - Standardmäßige Abfrageoptimierungsklasse
- DBHEAP - Datenbankzwischenspeicher
- CATALOGCACHE_SZ - Cachegröße des Katalogs
- LOGBUFSZ - Protokollpuffergröße
- UTIL_HEAP_SZ - Größe des Zwischenspeichers für Dienstprogramme
- BUFFPAGE - Pufferpoolgröße
- LOCKLIST - Maximaler Speicher für Sperrenliste
- APP_CTL_HEAP_SZ - Maximale Größe des Zwischenspeichers für die Anwendungssteuerung
- SORTHEAP - Zwischenspeicher für die Sortierliste
- STMTHEAP - Zwischenspeicher für SQL-Anweisungen
- APPLHEAPSZ - Standardmäßiger Anwendungszwischenspeicher
- STAT_HEAP_SZ - Größe des Statistikzwischenspeichers
- MAXLOCKS - Prozentsatz der Sperrenlisten pro Anwendung
- LOCKTIMEOUT - Zeitlimit für Sperre
- NUM_IOCLEANERS - Anzahl der asynchronen Seitenlöschfunktionen
- NUM_IOSERVERS - Anzahl der E/A-Server
- MAXAPPLS - Maximale Anzahl aktiver Anwendungen
- AVG_APPLS - Durchschnittliche Anzahl aktiver Anwendungen
- MAXFILOP - Maximale Anzahl geöffneter Datenbankdateien pro Anwendung
- NEWLOGPATH - Neuer Pfad zum Erstellen der Protokolldateien
- LOGFILSIZ - Protokolldateigröße
- LOGPRIMARY - Anzahl primärer Protokolldateien
- LOGSECOND - Anzahl sekundärer Protokolldateien
Beschreibung Wert DFT_QUERYOPT Die Abfrageoptimierungsklasse wird verwendet, um das Optimierungsprogramm anzuweisen, beim Kompilieren von SQL-Abfragen unterschiedliche Optimierungsgrade zu verwenden. Dieser Parameter stellt zusätzliche Flexibilität bereit, indem die Standardabfragenoptimierungsklasse festgelegt wird. Auf 9 festlegen DBHEAP Es gibt einen Datenbankzwischenspeicher pro Datenbank; der Datenbankmanager verwendet diesen Zwischenspeicher für alle Exemplare von WebSphere Product Center, die mit der Datenbank verbunden sind. Er enthält Steuerblockdaten für Tabellen, Indizes, Tabellenbereiche und Pufferpools. Darüber hinaus enthält er auch Speicherplatz für den Protokollpuffer (logbufsz) und den Katalogcachespeicher (catalogcache_sz). Daher hängt die Größe des Zwischenspeichers von der Anzahl der Steuerblöcke ab, die jeweils gleichzeitig im Zwischenspeicher gespeichert sind. Die Steuerblockdaten werden im Zwischenspeicher belassen, bis alle Exemplare von WebSphere Product Center die Verbindung zur Datenbank trennen.
Der Mindestbetrag, den der Datenbankmanager für den Anfang benötigt, wird bei der ersten Verbindung zugeordnet. Der Datenbereich wird je nach Bedarf bis zu der Maximalgröße erweitert, die im Parameter 'dbheap' angegeben wurde.
Auf 65448 festlegen CATALOGCACHE_SZ Dieser Parameter gibt an, welchen Speicherbereich der Katalogcachespeicher aus dem Datenbankzwischenspeicher (dbheap) maximal verwenden kann. Auf 6000 festlegen LOGBUFSZ Mit diesem Parameter können Sie die Menge des Datenbankzwischenspeichers (der über den Parameter 'dbheap' definiert ist) angeben, die als Puffer für Protokollsätze verwendet werden soll, bevor diese Sätze auf Platte geschrieben werden. Dieser Parameter muss ebenfalls kleiner-gleich dem Wert des Parameters 'dbheap' sein. Auf 4096 festlegen UTIL_HEAP_SZ
Dieser Parameter gibt die maximale Speichermenge an, die gleichzeitig von BACKUP, RESTORE, LOAD und den Wiederherstellungsprogrammen verwendet werden kann. Auf 5000 festlegen BUFFPAGE Der Parameter 'buffpage' steuert die Größe eines Pufferpools, wenn die Anweisung CREATE BUFFERPOOL oder ALTER BUFFERPOOL mit der Angabe NPAGES -1 ausgeführt wurde. Andernfalls wird der Parameter 'buffpage' ignoriert, und der Pufferpool wird mit der Anzahl der Seiten erstellt, die im Parameter NPAGES angegeben ist. Auf 22000 festlegen LOCKLIST Dieser Parameter gibt die Speichermenge an, die der Sperrenliste zugeordnet wird. Pro Datenbank gibt es eine einzige Sperrenliste, die alle Sperren enthält, die momentan von allen gleichzeitig mit der Datenbank verbundenen Exemplaren von WebSphere Product Center gehalten werden. Je nach der Größe der Datenbank muss diesem Parameter möglicherweise ein größer Wert zugewiesen werden. Auf 6000 festlegen APP_CTL_HEAP_SZ Dieser Parameter legt die Maximalgröße des gemeinsam genutzten Speichers für die Anwendungssteuerung in 4-KB-Seiten fest. Zwischenspeicher für die Anwendungssteuerung werden aus diesem gemeinsam genutzten Speicher zugeordnet. Auf 4500 festlegen SORTHEAP Dieser Parameter definiert die maximale Anzahl privater Speicherseiten für private Sortiervorgänge oder die maximale Anzahl von Seiten des gemeinsam genutzten Speichers für gemeinsam genutzte Sortiervorgänge. Auf 2650 festlegen STMTHEAP Der Anweisungszwischenspeicher wird vom SQL-Compiler während der Kompilierung einer SQL-Anweisung als Arbeitsbereich verwendet. Dieser Parameter gibt die Größe dieses Arbeitsbereichs an. Auf 30000 festlegen APPLHEAPSZ Dieser Parameter definiert die Anzahl der privaten Speicherseiten, die dem Datenbankmanager für einen bestimmten Agenten oder Subagenten zur Verfügung stehen. Auf 45000 festlegen STAT_HEAP_SZ Dieser Parameter gibt die Maximalgröße des Zwischenspeichers an, der bei der Erfassung von Statistiken mit dem Befehl RUNSTATS verwendet wird. Auf 22000 festlegen MAXLOCKS Sperreneskalation ist der Prozess, bei dem Zeilensperren durch Tabellensperren ersetzt werden, wodurch die Anzahl der Sperren in der Liste reduziert wird. Dieser Parameter definiert den Prozentsatz der Sperren in der Sperrenliste, die von einer Anwendung gehalten werden müssen, bevor der Datenbankmanager eine Sperreneskalation durchführt. Auf 30 festlegen LOCKTIMEOUT Dieser Parameter gibt die Anzahl der Sekunden an, die WebSphere Product Center auf den Abruf einer Sperre wartet. Auf 8 festlegen NUM_IOCLEANERS Dieser Parameter ermöglicht die Angabe der Anzahl asynchroner Seitenlöschfunktionen für eine Datenbank. Diese Seitenlöschfunktionen schreiben geänderte Seiten aus dem Pufferpool auf Platte, bevor der Speicher im Pufferpool von einem Datenbankagenten angefordert wird. Auf 7 festlegen NUM_IOSERVERS Ein-/Ausgabeserver werden für die Datenbankagenten verwendet, um Ein-/Ausgabeoperationen mit Vorablesezugriff und asynchrone Ein-/Ausgabeoperationen durch Dienstprogramme (z. B. zum Sichern und Wiederherstellen) durchzuführen. Dieser Parameter gibt die Anzahl der E/A-Server für eine Datenbank an. Auf 8 festlegen MAXAPPLS Dieser Parameter gibt die maximale Anzahl an Exemplaren von WebSphere Product Center an, die gleichzeitig (lokal und fern) mit einer Datenbank verbunden sein können. Auf 400 festlegen AVG_APPLS Dieser Parameter wird vom SQL-Optimierungsprogramm verwendet, um zu schätzen, welche Menge des Pufferpools während der Laufzeit für den ausgewählten Zugriffsplan verfügbar sein wird. Auf 2 festlegen MAXFILOP Dieser Parameter gibt die maximale Anzahl von Dateikennungen an, die für die einzelnen Datenbankagenten jeweils geöffnet sein können. Auf 640 festlegen Beispielscript: (Name der verwendeten Datenbank ist WPCDB)
db2 connect to wpcdb
update db cfg for wpcdb using DFT_QUERYOPT 9;
update db cfg for wpcdb using DBHEAP 65448;
update db cfg for wpcdb using CATALOGCACHE_SZ 6000;
update db cfg for wpcdb using LOGBUFSZ 4096;
update db cfg for wpcdb using UTIL_HEAP_SZ 5000;
update db cfg for wpcdb using BUFFPAGE 22000;
update db cfg for wpcdb using LOCKLIST 6000;
update db cfg for wpcdb using APP_CTL_HEAP_SZ 4500;
update db cfg for wpcdb using SORTHEAP 2650;
update db cfg for wpcdb using STMTHEAP 30000;
update db cfg for wpcdb using APPLHEAPSZ 45000;
update db cfg for wpcdb using STAT_HEAP_SZ 22000;
update db cfg for wpcdb using MAXLOCKS 30;
update db cfg for wpcdb using LOCKTIMEOUT 8;
update db cfg for wpcdb using NUM_IOCLEANERS 7;
update db cfg for wpcdb using NUM_IOSERVERS 8;
update db cfg for wpcdb using MAXAPPLS 400;
update db cfg for wpcdb using AVG_APPLS 2;
update db cfg for wpcdb using MAXFILOP 640;
Einrichten der Transaktionsprotokolldateien für die WebSphere Product Center-Datenbank
Mit Hilfe der Protokolldateien sind Sie in der Lage, Ihre Umgebung auf einen konsistenten Status wiederherzustellen und die Integrität Ihrer Daten zu bewahren. Der Protokolldateispeicher muss optimiert werden, da der Datenbankmanager die Protokolldateien während der Datenbankwiederherstellung lesen muss.
Es wird empfohlen, die Protokolle in ein Dateisystem zu stellen und jeweils stets getrennt von den Tabellenbereichen der Datenbank und der Datenbanksoftware auf einer eigenen physischen Platte zu speichern. Die Platten sollten im Idealfall ausschließlich für die DB2-Protokollierung verwendet werden, um zu verhindern, dass möglicherweise andere Prozesse auf diese Platten zugreifen oder auf diesen Platten schreiben. Eine ideale Position für die Protokolle ist der äußere Rand der Platte, wo pro Spur mehr Datenblöcke zur Verfügung stehen. Es wird dringend empfohlen, die Protokolle vor Störungen einzelner Platten zu schützen, indem ein RAID 10- oder RAID 5-Plattenstapel verwendet wird.
Beschreibung Beispiel NEWLOGPATH Mit diesem Parameter wird der Protokollpfad geändert, um die Transaktionsprotokolldateien auf einer eigenen Partition/einem eigenen Datenträger zu erstellen und nicht auf dem Standarddatenträger oder dem Datenträger, der für die Container der Datenbanktabellenbereiche verwendet wird.
Legen Sie den Pfad auf ein Verzeichnis fest, bei dem es sich um die Zieladresse für Protokolldateien handelt. Um dieses Verzeichnis festzulegen, muss es zunächst erstellt werden. Stellen Sie sicher, dass die Zieladresse über ausreichend Speicherplatz verfügt, bevor Sie den neuen Protokollpfad festlegen.
update db cfg for wpcdb using NEWLOGPATH /u02/db2data/logs
LOGFILSIZ Dieser Parameter definiert die Größe jeder primären und sekundären Protokolldatei. Die Größe dieser Protokolldateien begrenzt die Anzahl von Protokollsätzen, die in sie geschrieben werden können, bevor sie voll werden und eine neue Protokolldatei erforderlich wird. Legen Sie den Wert auf 30000 fest, wenn es sich um eine Entwicklungs-/ Testdatenbank handelt. Ansonsten legen Sie den Wert auf 60000 fest. Die Größe bezieht sich auf die Anzahl von Seiten mit jeweils 4 KB. update db cfg for wpcdb using LOGFILSIZ 30000 LOGPRIMARY Die primären Protokolldateien reservieren eine feste Speichermenge, die den Protokolldateien für die Wiederherstellung zugeordnet wird. Dieser Parameter ermöglicht die Angabe der Anzahl primärer Protokolldateien, die vorab zugeordnet werden sollen. Legen Sie den Wert auf 20 fest, wenn es sich um eine Entwicklungsdatenbank handelt. Ansonsten legen Sie den Wert auf 40 fest. update db cfg for wpcdb using LOGPRIMARY 20
LOGSECOND Dieser Parameter gibt die Anzahl sekundärer Protokolldateien an, die (je nach Bedarf) für Wiederherstellungsprotokolldateien erstellt und verwendet werden. Wenn die primären Protokolldateien voll sind, werden die sekundären Protokolldateien (mit der Größe logfilsiz) nach Bedarf jeweils einzeln zugeordnet. Dies geschieht bis zu einer maximalen Anzahl, die von diesem Parameter gesteuert wird. Legen Sie den Wert auf 10 fest, wenn es sich um eine Entwicklungs-/ Testdatenbank handelt. Ansonsten legen Sie den Wert auf 20 fest. update db cfg for wpcdb using LOGSECOND 10
Nachdem Sie die Änderungen an der Datenbankkonfiguration vorgenommen haben, müssen Sie die Datenbank erneut starten. Verwenden Sie hierzu die Befehle 'db2stop' und 'db2start'.
db2stop force
db2startDB2 Admin/Developer/Run-Time Client auf dem Anwendungsserver installieren
- Installieren Sie DB2 Admin/Developer/Run-Time Client auf WebSphere Application Server.
- Erstellen Sie einen der verfügbaren Clienttypen.
DB2-Exemplar auf WAS erstellen
Erstellen Sie auf dem WAS (WebSphere Application Server) ein DB2-Exemplar. Der Benutzer 'db2inst1' oder der Benutzer der WebSphere Product Center-Middleware kann der Eigner des Exemplars sein. Sie müssen auf dem Anwendungsserver ein 32-Bit-Exemplar für die WebSphere Product Center-Anwendung erstellen, um eine Verbindung zur Datenbank herzustellen. Ein 32-Bit-Exemplar auf dem Anwendungsserver kann eine Verbindung zum 64-Bit-Exemplar auf dem Datenbankserver herstellen.
Hinweis: Wenn der Exemplareigner der Benutzer 'db2inst1' ist (oder ein anderer Benutzer außer dem Benutzer der WebSphere Product Center-Middleware), müssen Sie für den Benutzer der WebSphere Product Center-Middleware unter '$HOME/sqllib' eine bedingte Verbindung (Softlink) zu demselben Verzeichnis des Exemplareigners erstellen.
Beispiel:
Führen Sie den folgenden Befehl im Ausgangsverzeichnis des Benutzers der WebSphere Product Center-Middleware aus:
ln -s /home/db2inst1/sqllib/ sqllib
Checkliste für DB2-Datenbank-Setup
Verwenden Sie die folgende Checkliste, um sicherzustellen, dass die erforderliche DB2-Datenbank korrekt für die Verwendung mit WebSphere Product Center konfiguriert wurde.
X
Checkliste für DB2-Setup
Release des DB2-Servers überprüfen Stellen Sie sicher, dass das Release des DB2-Servers den in diesem Dokument aufgeführten Installationsvoraussetzungen entspricht. Codierten Zeichensatz der Datenbank überprüfen Der Zeichensatz und der Satz nationaler Sonderzeichen sollte UTF8 sein. Stellen Sie als Systembenutzer eine Verbindung her, und überprüfen Sie den Zeichensatz der Datenbank.
(Auf dem Datenbankserver als Exemplareigner angemeldet)
$db2 get db cfg for <datenbankname>
Dabei sollte der codierte Zeichensatz der Datenbank ("Database code set") auf UTF-8 festgelegt sein.
Einträge der Parameterdatei überprüfen Führen Sie die Schritte in den Abschnitten zur DB2-Konfiguration in diesem Kapitel aus, um sicherzustellen, dass Sie die erforderlichen Parameteränderungen an den Variablen des DB2-Registers, am Datenbankmanager und an der Datenbank vorgenommen haben. Setup der Tabellenbereiche überprüfen Stellen Sie sicher, dass die erforderlichen Tabellenbereiche in der Datenbank definiert sind. Setup der Transaktionsprotokolle überprüfen Stellen Sie sicher, dass die Transaktionsprotokolle auf einer eigenen Partition erstellt werden.
Setup des Datenbankbenutzers überprüfen Zeigen Sie den Datenbankbenutzernamen und das zugehörige Kennwort in der Datei '$TOP/etc/default/common.properties' an, und stellen Sie sicher, dass der Datenbankbenutzer erstellt wurde und ihm alle erforderlichen Berechtigungen erteilt wurden. Konnektivität zum Datenbankserver überprüfen Der Datenbankserver und der Datenbankserverknoten müssen auf dem Anwendungsserver katalogisiert sein, und vom Anwendungsserver aus muss auf die Datenbank zugegriffen werden können.
- Überprüfen Sie die Datenbankkonnektivität mit '$TOP/bin/ test_db.sh'.
- Überprüfen Sie die JDBC-Konnektivität mit '$TOP/bin/ test_java_db.sh'.
Vom Anwendungsserver aus muss auf die Datenbank zugegriffen werden können.
Betriebssystemeinstellungen für Oracle
Es gibt mehrere, von Oracle empfohlene Einstellungen für System V-Semaphoren und gemeinsam genutzten Speicher. Diese Einstellungen können je nach Plattform und Größe der Datenbank unterschiedlich sein. Die korrekten Einstellungen entnehmen Sie bitte den entsprechenden Oracle-Handbüchern oder fragen Sie Ihren Datenbankadministrator.
In den folgenden Abschnitten werden die empfohlenen Parameter für das Betriebssystem der Oracle-Datenbank definiert:
Oracle unter Linux
Bearbeiten Sie die folgende Datei:
/etc/sysctl.conf
Festgelegte Parameter:
fs/file-max=16384
kernel/msgmni=1024
kernel/shmmax=3221225472Hinweis: Der für 'kernal/shmmax' festgelegte Wert wird empfohlen, wenn 4 GB Hauptspeicher verfügbar sind. Die Größe hängt von der Menge des verfügbaren Hauptspeichers ab.
Oracle 9i-Konfiguration
In diesem Abschnitt werden die Richtlinien für die Oracle-Datenbankkonfiguration erörtert, die angewendet werden, um WebSphere Product Center ordnungsgemäß zu installieren.
Voraussetzungen erfüllen
- Stellen Sie sicher, dass das lokale System die Voraussetzungen hinsichtlich Hardware, Software, Hauptspeicher und Plattenspeicherplatz für den Oracle-Server erfüllt (siehe Checkliste am Ende dieses Abschnitts).
- Installieren Sie Oracle 9.2.0.5 Enterprise Edition.
Gehen Sie beim Erstellen und Einrichten der WebSphere Product Center-Datenbank anhand der nachstehenden Richtlinien vor.
Neue Datenbank erstellen
Es wird empfohlen, eine separate Datenbank für die WebSphere Product Center-Anwendung einzurichten. Ein wichtiger Grund hierfür ist, dass die WebSphere Product Center-Datenbank nicht unbedingt von der Verfügbarkeit und vorhandenen Konfiguration (Aspekt der Leistungsoptimierung) anderer verwendeter Datenbanken abhängen muss.
Bereits vorhandene Oracle-Datenbankexemplare können zum Speichern von WebSphere Product Center-Daten verwendet werden. Aufgrund der Länge bestimmter Primärschlüssel im WebSphere-Schema muss die Blockgröße jedoch mindestens 8.192 KB betragen.
Zeichensatz und Satz nationaler Sonderzeichen
Für WebSphere Product Center wird der Zeichensatz UTF8 verwendet. Daher müssen der Zeichensatz der Datenbank und der Satz nationaler Sonderzeichen beim Erstellen der WebSphere Product Center-Datenbank auf UTF8 festgelegt werden.
Für WebSphere Product Center spezifische Einträge in der Oracle-Parameterdatei (init.ora)
Oracle verwendet Konfigurationsparameter, um Dateien zu suchen und Laufzeitparameter anzugeben, die für alle Oracle-Produkte gleich sind.Wenn ein Oracle-Programm oder eine Oracle-Anwendung die Umsetzung einer bestimmten Konfigurationsvariablen erfordert, verwendet Oracle hierfür den jeweils zugeordneten Parameter. Alle Oracle-Parameter werden in dem Register gespeichert.
Die folgenden Parameter sind zur Verwendung mit WebSphere Product Center festgelegt:
- DB_BLOCK_SIZE
- QUERY_REWRITE_ENABLED
- COMPATIBLE
- PROCESSES
- OPEN_CURSORS
- MAX_ENABLED_ROLES
- DB_CACHE_SIZE
- SHARED_POOL_SIZE
- LOG_BUFFER
- SORT_AREA_SIZE
- OPTIMIZER_INDEX_CACHING
- OPTIMIZER_INDEX_COST_ADJ
- OPTIMIZER_FEATURES_ENABLE
Beschreibung Wert DB_BLOCK_SIZE Dieser Parameter legt die Größe (in Byte) eines Oracle-Datenbankblocks fest. Dieser Wert wird bei Datenbankerstellung festgelegt und kann anschließend nicht mehr geändert werden. DB BLOCK SIZE ist für das Trio-Schema von kritischer Bedeutung und muss mindestens den Wert 8192 haben. Ist die Datenbankblockgröße (db_block_size) nicht ausreichend, schlägt die Erstellung des Schemas fehl. Legen Sie diesen Parameter für die WebSphere Product Center-Datenbank auf 8192 fest. Beispiel:
db_block_size = 8192
QUERY_REWRITE_ENABLED Dieser Parameter wird verwendet, um das erneute Schreiben von Abfragen für gespeicherte Ansichten zu aktivieren oder zu inaktivieren. Dieser Parameter muss auf 'true' (wahr) festgelegt werden. Beispiel:
query_rewrite_enabled = true
COMPATIBLE Dieser Parameter ermöglicht Ihnen die Verwendung eines neuen Release, während gleichzeitig die Abwärtskompatibilität mit einem vorherigen Release gewährleistet bleibt. Legen Sie diesen Parameter auf 9.2.0.0.0 oder höher fest. Beispiel:
Compatible = 9.2.0.0.0
PROCESSES Dieser Parameter gibt die maximale Anzahl an Benutzerprozessen vom Betriebssystem an, die gleichzeitig eine Verbindung zu einem Oracle-Server herstellen können. Legen Sie diesen Parameter auf mindestens 500 fest. Beispiel:
Processes = 500
OPEN_CURSORS Dieser Parameter gibt die maximale Anzahl an Cursorn an, die in einer Sitzung gleichzeitig geöffnet sein können, und beschränkt die PL/SQL-Cursor-Cachegröße, die PL/SQL verwendet, um eine erneute Syntaxanalyse (Parsing) von Anweisungen zu vermeiden, die von einem Benutzer erneut ausgeführt werden. Legen Sie diesen Parameter auf 600 fest. Beispiel:
Open_cursors = 600
MAX_ENABLED_ROLES Dieser Parameter gibt die maximale Anzahl an Datenbankaufgabenbereichen (einschließlich untergeordneter Aufgabenbereiche) an, die ein Benutzer aktivieren kann. Legen Sie diesen Parameter auf 60 fest. Beispiel:
Max_enabled_roles = 60
DB_CACHE_SIZE Dieser Parameter gibt die Anzahl der Oracle-Blöcke im Puffercache an. Der Wert dieses Parameters hat einen signifikanten Einfluss auf die SGA-Gesamtgröße eines Exemplars. Legen Sie für diesen Parameter einen Wert fest, der sich nach der Gesamtgröße des verfügbaren Speichers richtet. Der Wert muss mindestens 1048576000 betragen. Beispiel:
Db_cache_size = 1048576000
SHARED_POOL_SIZE Dieser Parameter gibt die Größe des gemeinsamen Pools in Byte an. Der gemeinsame Pool enthält Objekte wie beispielsweise gemeinsam genutzte Cursor, gespeicherte Prozeduren, Steuerstrukturen und Nachrichtenpuffer für parallele Ausführung. Legen Sie für diesen Parameter einen Wert fest, der sich nach der Speicherkapazität des Datenbankservers richtet. Beispiel:
Shared_pool_size = 209715200 (200 MB, wenn der Datenbankserver über 2 GB Hauptspeicher verfügt)
LOG_BUFFER Dieser Parameter gibt die Speicherkapazität in Byte an, die verwendet wird, um Einträge für die Rücknahme des Widerrufs zu puffern, bevor sie von LGWR in eine Protokolldatei für entsprechende Einträge geschrieben werden. Mit Hilfe von Einträgen für die Rücknahme des Widerrufs werden Änderungen an Datenbankblöcken verfolgt und protokolliert. Legen Sie diesen Parameter auf 5242880 fest. Beispiel:
Log_buffer = 5242880
SORT_AREA_SIZE Dieser Parameter gibt die maximale Speicherkapazität in Byte an, die für Sortiervorgänge verwendet werden kann. Nach Abschluss eines Sortiervorgangs werden Zeilen zurückgegeben, und der Speicher wird wieder freigegeben. Sie können den Wert erhöhen, um die Effizienz umfangreicher Sortiervorgänge zu verbessern. Bei Überschreitung der Speicherkapazität werden temporäre Plattensegmente im Tabellenbereich für temporäre Tabellen des Benutzers verwendet. Legen Sie diesen Parameter je nach Größe des verfügbaren Hauptspeichers auf einen Wert zwischen 5 MB und 10 MB fest. Ist der festgelegte Wert für 'sort_area_size' zu hoch, kann dies zu Auslagerungen führen, wenn zu wenig Speicher für andere Prozesse verbleibt. Beispiel:
Sort_area_size = 5242880
OPTIMIZER_INDEX_CACHING Dieser Parameter passt die auf dem Systemaufwand basierenden Annahmen des Optimierungsprogramms hinsichtlich des erwarteten Prozentsatzes an Indexblöcken im Puffercache für Verknüpfungen verschachtelter Schleifen an. Der Wert dieses Parameters hat Auswirkungen auf den Systemaufwand für die Ausführung von Verknüpfungen verschachtelter Schleifen, bei denen ein Index verwendet wird. Wird dieser Parameter auf einen höheren Wert festgelegt, geht das Optimierungsprogramm davon aus, dass Verknüpfungen verschachtelter Schleifen weniger Systemaufwand verursachen. Der Wertebereich liegt zwischen 0 und 100 Prozent. Wert: Auf 90 festlegen. Beispiel:
Optimizer_index_caching = 90
OPTIMIZER_INDEX_COST_ADJ Dieser Parameter wird verwendet, um die Leistung des Optimierungsprogramms zu optimieren, wenn zu wenige oder zu viele Indexzugriffspfade berücksichtigt werden. Bei einem niedrigeren Wert ist die Wahrscheinlichkeit größer, dass das Optimierungsprogramm einen Index auswählt. Der Wertebereich liegt zwischen 1 und 10000. Legen Sie diesen Parameter auf 50 fest. Beispiel:
optimizer_index_cost_adj=50
OPTIMIZER_FEATURES_ENABLE Mit diesem Parameter können die Parameter in der Datei 'init.ora', die das Verhalten des Optimierungsprogramms steuern, geändert werden. Legen Sie diesen Parameter auf 8.1.7 fest. Beispiel:
optimizer_features_enable=8.1.7
Tabellenbereiche einrichten
Die folgenden Tabellenbereiche müssen in der WebSphere Product Center-Datenbank erstellt werden:
- SYSTEM
- USERS
- INDX
- BLOB_TBL_DATA
- UNDOTBS1
- TEMP
Hinweis: Stellen Sie sicher, dass keine Datendatei größer als 1.500 MB ist. Um den Tabellenbereichen mehr Speicherplatz zuzuordnen, können Sie ihnen jeweils eine größere Anzahl an Datendateien hinzufügen.
Tabellenbereich Beschreibung SYSTEM Hierbei handelt es sich um den Standardtabellenbereich, der in der Oracle-Datenbank automatisch erstellt wird. Im Tabellenbereich SYSTEM werden das Datenverzeichnis und die Objekte gespeichert, die vom Systembenutzer erstellt werden. Dieser Tabellenbereich ist permanent. Empfehlung: Die Größe des Tabellenbereichs SYSTEM sollte mindestens 400 MB betragen.
USERS In diesem Tabellenbereich werden alle Tabellen der WebSphere Product Center-Datenbank gespeichert, mit Ausnahme von Tabellen, in denen große Objekte (LOBs) gespeichert werden. Dieser Tabellenbereich wird beim Erstellen der Datenbank mit Hilfe des Oracle-Datenbankkonfigurationsassistenten (Oracle Database Configuration Assistant, ODCA) automatisch erstellt. Es handelt sich um einen permanenten, lokal verwalteten Tabellenbereich. Empfehlung: Die Größe des Tabellenbereichs USERS sollte mindestens 15 GB betragen.
INDX
In diesem Tabellenbereich werden alle Indizes der WebSphere Product Center-Datenbank gespeichert. Dieser Tabellenbereich wird beim Erstellen der Datenbank mit Hilfe von ODCA automatisch erstellt. Es handelt sich um einen permanenten, lokal verwalteten Tabellenbereich. Empfehlung: Die Größe des Tabellenbereichs INDX sollte mindestens 40 GB betragen.
BLOB_TBL_DATA In diesem Tabellenbereich werden alle Tabellen der WebSphere Product Center-Datenbank gespeichert, die große Objekte (LOBs) wie beispielsweise Kataloge enthalten. Der Oracle-Datenbankkonfigurationsassistent (ODCA) erstellt diesen Tabellenbereich beim Erstellen der Datenbank nicht automatisch. Daher müssen Sie diesen Tabellenbereich nach Erstellung der Datenbank unbedingt manuell erstellen. Es handelt sich um einen permanenten, lokal verwalteten Tabellenbereich. Empfehlung: Die Größe des Tabellenbereichs BLOB_TBL_DATA sollte mindestens 5 GB betragen.
UNDOTBS1 In diesem Tabellenbereich werden alle ROLLBACK-Segmente in einer Oracle-Datenbank gespeichert. Dieser Tabellenbereich wird von ODCA automatisch in der Datenbank erstellt. Empfehlung: Die Größe des Tabellenbereichs UNDOTBS1 sollte mindestens 15 GB betragen.
TEMP In diesem Tabellenbereich werden Objekte temporär in Datenbankoperationen wie Sortierungen und Gruppierungen gespeichert. Dieser Tabellenbereich wird von ODCA ebenfalls automatisch erstellt. Es handelt sich um einen temporären Tabellenbereich. Empfehlung: Die Größe des Tabellenbereichs TEMP sollte mindestens 6 GB betragen.
Informationen zu Oracle-Tabellenbereichen
Tabellenbereich
Mindestgröße
Empfohlene Speicherparameter
SYSTEM 400 MB Standard USERS 5 GB EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO
INDX 20 GB EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO
BLOB_TBL_DATA 2 GB EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO
UNDOTBS1 10 GB UNDO TABLESPACE LEAVE DEFAULT VALUES
TEMP 5 GB TEMPORARY TABLESPACE LEAVE DEFAULT VALUES
Protokolldateien für die Rücknahme des Widerrufs einrichten
Für das Aufzeichnen von Transaktionen verwendet Oracle Online-Protokolldateien für die Rücknahme des Widerrufs. Für jede Transaktion, die in der Datenbank stattfindet, wird den Protokolldateien für die Rücknahme des Widerrufs jeweils ein Eintrag hinzugefügt. Durch Optimierung der Größe der Protokolldateien für die Rücknahme des Widerrufs kann die Datenbankleistung gesteigert werden. Für nicht festgeschriebene Transaktionen werden ebenfalls Protokolleinträge für die Rücknahme des Widerrufs generiert. Sie müssen sechs Protokolldateien für die Rücknahme des Widerrufs mit einer Größe von jeweils 300 MB erstellen.
Empfangsprogramm (Listener) für diese Datenbank auf dem Datenbankserver einrichten
Die Herstellung einer Verbindung zwischen WebSphere Product Center und der Datenbank erfolgt über den JDBC-Thin Client auf dem Anwendungsserver. Einige SQL-Prozeduren von WebSphere Product Center werden ebenfalls auf dem Anwendungsserver verwendet, um bestimmte Tasks auszuführen, wie beispielsweise das Erstellen eines WebSphere Product Center-Schemas etc. Richten Sie den Listener auf dem Datenbankserver ein, damit der Client mit Hilfe von JDBC oder SQL Plus eine Verbindung zur Datenbank herstellen kann.
Datenbankschemabenutzer erstellen
Erstellen Sie einen Datenbankbenutzer für WebSphere Product Center, auf den in der Datei common.properties verwiesen wird.
Die folgenden Benutzerdaten sind erforderlich:
- Standardtabellenbereich (default tablespace): users
- Temporärer Tabellenbereich (temporary tablespace): temp
- Authentifizierung (authentication): Kennwort (password)
- Status: Entsperrt (unlocked)
- Zu erteilende Aufgabenbereiche: connect (Verbinden) und resource (Ressource)
- Zu erteilende Systemberechtigungen: unlimited tablespace (uneingeschränkter Tabellenbereich), select any dictionary (Auswahl eines beliebigen Wörterbuchs) und query rewrite (erneutes Schreiben von Abfragen)
Führen Sie beispielsweise die folgenden SQL-Befehle an der SQL-Eingabeaufforderung aus:
SQL> Create user WPC identified by WPC default tablespace users temporary tablespace temp;
SQL> Grant connect, resource, unlimited tablespace, select any dictionary, query rewrite to WPCOracle 9i-Client auf dem Anwendungsserver installieren
Installieren Sie den Oracle 9i-Client auf dem Anwendungsserver und stellen Sie sicher, dass ein Eintrag für die Datenbank in der Datei 'tnsnames.ora' auf dem Anwendungsserver vorhanden ist, auf dem der Oracle-Client installiert ist. Die Datei 'tnsnames.ora' befindet sich im Verzeichnis "$ORACLE_HOME/network/admin". Überprüfen Sie die Konnektivität zwischen dem Anwendungsserver und dem Datenbankserver mit Hilfe von 'tnsping' und/oder SQLPlus auf dem Anwendungsserver.
X
Checkliste für Oracle-Setup
Release des Oracle 9i-Servers überprüfen Bei dem Oracle-Server sollte es sich um Oracle 9.2.0.5 Standard/Enterprise Edition Database Server handeln. Zeichensatz der Datenbank überprüfen Der Zeichensatz und der Satz nationaler Sonderzeichen sollte UTF8 sein. Stellen Sie als Systembenutzer eine Verbindung her, und überprüfen Sie den Zeichensatz der Datenbank. SQL>select * from nls_database_parameters where PARAMETER in ('NLS_CHARACTERSET',’ NLS_NCHAR_CHARACTERSET’);
Einträge der Parameterdatei 'init' überprüfen Bitte lesen Sie den Abschnitt zur Oracle-Konfiguration in diesem Kapitel und stellen Sie sicher, dass die erforderlichen Einträge in der Parameterdatei vorgenommen wurden. Setup der Tabellenbereiche überprüfen Stellen Sie sicher, dass die erforderlichen Tabellenbereiche in der Datenbank definiert sind. Status der ROLLBACK-Segmente überprüfen Stellen Sie sicher, dass alle ROLLBACK-Segmente online sind. Stellen Sie als Systembenutzer eine Verbindung her und überprüfen Sie den Status der ROLLBACK-Segmente. SQL> select SEGMENT_NAME, STATUS from dba_rollback_segs;
Protokolldateien für die Rücknahme des Widerrufs überprüfen Stellen Sie sicher, dass in der Datenbank eine ausreichende Anzahl an Protokolldateien für die Rücknahme des Widerrufs erstellt wurden. Um Informationen über vorhandene Protokolldateien für die Rücknahme des Widerrufs in der Datenbank abzurufen, stellen Sie als Systembenutzer eine Verbindung her und setzen Sie die folgende Abfrage ab: SQL> select * from v$log;
Setup des Datenbankbenutzers überprüfen Zeigen Sie den Datenbankbenutzernamen und das zugehörige Kennwort in der Datei '$TOP/etc/default/common.properties' an, und stellen Sie sicher, dass der Datenbankbenutzer erstellt wurde und ihm alle erforderlichen Berechtigungen erteilt wurden. Eintrag der Datenbank in der Datei 'tnsnames.ora' überprüfen Stellen Sie sicher, dass sich für die Datenbank ein Eintrag in der Datei 'tnsnames.ora' auf dem Anwendungsserver befindet, auf dem der Oracle-Client installiert ist. Die Datei 'tnsnames.ora' befindet sich in folgendem Verzeichnis: $ORACLE_HOME/network/admin Hinweis: Aufgrund einer Einschränkung in der Schemainstallation muss der Servicename in der Datei 'tnsnames.ora' der SID der Datenbank entsprechen. Mit anderen Worten: OCI-Dienstprogramme wie beispielsweise 'sqlplus' müssen in der Lage sein, unter Verwendung eines Servicenamens, der mit der SID identisch ist, eine Verbindung herzustellen.
Listener auf dem Datenbankserver überprüfen Vom Anwendungsserver aus muss auf die Datenbank zugegriffen werden können.