Parameter

Bedeutung

Wie kann der Parameter geändert werden?

_BACKUP_HISTFILE

Name der History-Datei für Daten- und Log-Sicherungen

kann nicht geändert werden

_BACKUP_MED_DEF

Name der Datei, in der die Definitionen der Sicherungsvorlagen gespeichert sind

kann nicht geändert werden

_EVENTFILE

Name der Datei, in der das Datenbanksystem interne Events protokolliert

Änderung erst nach Restart wirksam

_EVENTSIZE

Größe der Datei, in der das Datenbanksystem interne Events protokolliert

Änderung erst nach Restart wirksam

_IDXFILE_LIST_SIZE

Anzahl der temporären Zwischenergebnisdateien bei einer parallelen Indizierung

Große Tabellen indiziert das Datenbanksystem mit mehreren Server-Tasks. Diese Server-Tasks schreiben ihre Ergebnisse in temporäre Dateien. Wenn die Anzahl dieser Dateien den Wert dieses Parameters erreicht, dann muss das Datenbanksystem die Dateien abmischen (Merge), bevor es den eigentlichen Index erzeugen kann. Das hat zur Folge, dass die Performance sinkt.

kann im laufenden Betrieb geändert werden

_IOPROCS_PER_DEV

Anzahl Threads, die das Datenbanksystem für asynchrone I/O-Operationen verwenden kann (pro Data-Volume und System)

Änderung erst nach Restart wirksam

_KERNELDIAGFILE

Name der Protokolldatei des Kerns

Änderung erst nach Restart wirksam

_KERNELDUMPFILE

Name der Dump-Datei, die bei einem Systemabsturz vom Kern geschrieben wird

In diese Datei schreibt das Datenbanksystem u. a. den Inhalt des Data-Cache und des Converters. Dimensionieren Sie Ihr System so, dass genügend Speicherplatz für diese Datei zur Verfügung steht (ungefähr CACHE_SIZE + 10%). Beachten Sie hierbei auch den Parameter DIAG_HIST_NUM.

Änderung erst nach Restart wirksam

_KERNELTRACEFILE

Datei, in die der Kern die Trace-Einträge schreibt

Der Kern schreibt nur dann Trace-Einträge, wenn Sie zuvor den Datenbank-Trace eingeschaltet haben.

Änderung erst nach Restart wirksam

_MAXEVENTTASKS

maximale Anzahl von Event-Tasks

Das Datenbanksystem verwendet Event-Tasks sowohl für Event-Dispatcher als auch für die DBM-Kommandos event_wait, event_receive, event_available, auto_extend und auto_update_statistics, die für diese Datenbankinstanz gleichzeitig aktiv sein können.

Vorschlagswert des Database Manager für diesen Parameter ist 2.

Änderung erst nach Restart wirksam

_MAXTASK_STACK

Größe des Stacks, der von den User-Tasks verwendet wird

Änderung erst nach Restart wirksam

_MINREPLY_SIZE

minimale Größe des Speichers, der in einem Paket (Shared Memory-Segment) für die Antwort zur Verfügung steht

0: Sowohl der Anwendung als auch dem Kern steht das gesamte Paket für die Anfrage/die Antwort zur Verfügung.

Änderung erst nach Restart wirksam

_MULT_IO_BLOCK_CNT

siehe DATA_IO_BLOCK_COUNT und LOG_IO_BLOCK_COUNT

_PACKET_SIZE

Größe der Pakete (Shared Memory-Segmente), in denen SQL-Anweisungen und Daten übertragen werden

Ein Paket besteht aus einem Anfrage- und einem Antwortteil.

Änderung erst nach Restart wirksam

_READAHEAD_BLOBS

Anzahl Seiten, ab denen große LONG-Werte im Voraus von zusätzlichen Server-Tasks eingelesen werden

Wenn ein LONG-Wert zu groß ist, um in einem einzigen Auftragspaket an den Client übermittelt zu werden, dann verteilt das Datenbanksystem ihn auf mehrere Auftragspakete. Um die Performance zu steigern, können Server-Tasks bereits während des Sendens des ersten Auftragspakets weitere Teile des LONG-Werts einlesen.

kann im laufenden Betrieb geändert werden

_RESTART_TIME

minimale Zeit zwischen zwei Savepoints (in Sekunden), entspricht der Zeit, die für einen Restart nach einem Systemabsturz benötigt wird

Unabhängig hiervon schreibt das Datenbanksystem in folgenden Fällen immer einen Savepoint:

●     nachdem Sie einen Index erstellt haben

●     wenn die Anzahl der durch einen Savepoint freigegebenen Seiten größer als die Anzahl der freien Blöcke in den Data-Volumes ist

Änderung erst nach Restart wirksam

_RTEDUMPFILE

Datei, in die der Kern bei einem Systemabsturz Informationen zur Laufzeitumgebung schreibt

Änderung erst nach Restart wirksam

_SERVERDB_FOR_SAP

gibt an, ob die Datenbankinstanz in einem SAP-System verwendet wird

kann im laufenden Betrieb geändert werden

_TASKCLUSTER_01 bis _03

Diese Parameter beschreiben, wie das Datenbanksystem die User-Tasks auf die Threads verteilt. Ändern Sie diese Parameter nur nach Rücksprache mit dem Support.

Änderung erst nach Restart wirksam

_USE_ASYNC_IO

gibt an, ob für asynchrone I/O-Operationen Funktionen des Betriebssystems oder spezielle I/O-Threads verwendet werden

Änderung erst nach Restart wirksam

_USE_IOPROCS_ONLY

YES: I/O-Operationen werden ausschließlich von speziellen I/O-Threads durchgeführt

NO: der Kern entscheidet, ob eine Task eine I/O-Operation selbst ausführt oder ob sie die I/O-Operation an einen speziellen I/O-Thread übergibt

kann im laufenden Betrieb geändert werden

ALLOW_MULTIPLE_SERVERTASK_UKTS

gibt an, ob das Datenbanksystem die Server-Tasks auf die verfügbaren User-Kernel-Threads verteilt oder ob alle Server-Tasks im selben User-Kernel-Thread laufen

Änderung erst nach Restart wirksam

COLUMNCOMPRESSION

legt fest, ob die Spaltenwerte mit variabler Länge abgelegt werden können oder nicht

Vorschlagswert: YES (Spalten haben variable Länge, d.h. Werte können gegebenenfalls komprimiert werden)

nur für Spalten, die keine Primärschlüsselspalten sind

kann im laufenden Betrieb geändert werden

DATA_IO_BLOCK_COUNT

Blockgröße, die das Datenbanksystem beim Schreiben von Datenseiten aus dem Data-Cache in den Datenbereich verwendet

Die optimale Blockgröße ist abhängig von der verwendeten Hard- und Software.

Änderung erst nach Restart wirksam

ENABLE_SYSTEM_TRIGGERS

gibt an, ob beim Restart der Datenbankinstanz System-Trigger aufgerufen werden

Änderung erst nach Restart wirksam

EXPAND_COM_TRACE

gibt an, ob beim Erzeugen von COM-Trace-Dateien Plattenplatz reserviert wird

Änderung erst nach Restart wirksam

INIT_ALLOCATORSIZE

initiale Größe des Arbeitsspeichers, der am Anfang einer Datenbanksitzung reserviert wird

Änderung erst nach Restart wirksam

LOAD_BALANCING_DIF

nur für Load-Balancing; gibt an, um wieviel eine zu verschiebende Task in ihrem User-Kernel-Thread länger gewartet haben muss, als die Task, die im Ziel-User-Kernel-Thread am längsten gewartet hat (in Prozent)

Änderung erst nach Restart wirksam

LOAD_BALANCING_EQ

für Load-Balancing; gibt an, welche Zeitspanne beim Vergleich wartender Tasks noch als gleich anzusehen ist (in Prozent)

Änderung erst nach Restart wirksam

LOG_IO_BLOCK_COUNT

Blockgröße, die das Datenbanksystem beim Schreiben von Log-Seiten aus den Log-Warteschlangen in den Log-Bereich verwendet

Die optimale Blockgröße ist abhängig von der verwendeten Hard- und Software.

Änderung erst nach Restart wirksam

LOG_QUEUE_COUNT

Anzahl der Log-Warteschlangen

=0: Anzahl wird aus dem Parameter MAXCPU berechnet

>0: Wert des Parameters USED_LOG-QUEUE_COUNT wird übernommen

Änderung erst nach Restart wirksam

MAX_SERVERTASK_STACK

maximale Größe des Stack, der von den Server-Tasks verwendet wird

Änderung erst nach Restart wirksam

MAX_SPECIALTASK_STACK

maximale Größe des Stack, der von den Spezial-Tasks (alle außer User-Tasks und Server-Tasks) verwendet wird

Änderung erst nach Restart wirksam

MAXPAGER

maximale Anzahl der Pager, wird vom Datenbanksystem unter anderem aus MAXDATAVOLUMES berechnet

nicht änderbar

Sie können diesen Parameter mit XP_MAXPAGER übersteuern.

MAXVOLUMES

maximale Anzahl von Data- und Log-Volumes inklusive gespiegelter Volumes, wird vom System berechnet

Änderung erst nach Restart wirksam

MINI_DUMP

legt fest, ob das System die Speicherauszüge knlmini.dmp und srvmini.dmp (für das Postmortem-Debugging) schreibt, und wie viele Informationen diese Speicherauszüge enthalten

DISABLED: das System schreibt keine Speicherauszüge

NORMAL (Vorschlagswert): Das System schreibt alle Stacks und System-Handle-Informationen in den Speicherauszug

FULL: Das System schreibt alle Stacks und Datensegmente in den Speicherauszug

Änderung erst nach Restart wirksam

OMS_STREAM_TIMEOUT

maximale Wartezeit für alle Datenbanksitzungen, die bis zur Antwort einer OMS-Stream-Anfrage an einen Client vergehen darf (in Sekunden)

kann im laufenden Betrieb geändert werden

OPTIM_CACHE

gibt an, ob das Datenbanksystem die Suchstrategie nur einmal oder bei jeder Ausführung einer geparseten SQL-Anweisung ermittelt

Für Prepared Statements mit Parametern reicht es unter Umständen aus, die Suchstrategie nur einmal zu ermitteln.

kann im laufenden Betrieb geändert werden

OPTIMIZE_OPERATOR_JOIN

gibt an, ob das Datenbanksystem die verbesserte Join-Implementierung verwendet (spart Ressourcen)

kann im laufenden Betrieb geändert werden

SET_VOLUME_LOCK

gibt an, ob das Datenbanksystem beim Hinzufügen eines Volume eine Sperre setzt, die ein späteres erneutes Hinzufügen desselben Volume verhindert

In folgenden Fällen kann es sinnvoll sein, diesen Parameter auf NO zu setzen:

●     NFS-gemountetes Volume

●     Hot-Standby-System

Änderung erst nach Restart wirksam

SHOW_MAX_STACK_USE

protokolliert den maximalen Stack-Verbrauch jeder Task im Kernprotokoll

Setzen Sie den Parameter nur für Diagnosezwecke auf YES, weil er im Produktivbetrieb die Performance verschlechtert.

Änderung erst nach Restart wirksam

SUPPRESS_CORE

gibt an, ob das Datenbanksystem Core-Dumps des Kerns unterdrückt

Änderung erst nach Restart wirksam

SYMBOL_DEMANGLING

gibt an, ob das Datenbanksystem ein C/C++-Demangling durchführt

Änderung erst nach Restart wirksam

UPDATESTAT_PARALLEL_SERVERS

gibt an, wie viele parallele Server-Tasks das Datenbanksystem für das Aktualisieren der Statistiken des SQL-Optimierers verwendet

Wert -1: Aktualisieren der Statistiken erfolgt sequentiell
Wert 0: Datenbanksystem entscheidet, wie viele parallele Server-Tasks verwendet werden sollen

Wert n>0: Datenbanksystem verwendet maximal n parallele Server-Tasks

kann im laufenden Betrieb geändert werden

USE_OPEN_DIRECT

YES: Das Datenbanksystem verwendet beim Öffnen von Volumes das O_DIRECT-Flag (wenn dieses Flag vom Dateisystem unterstützt wird). Mit diesem Flag konfigurieren Sie, dass das Betriebssystem keinen eigenen Cache für I/O-Operationen verwendet.

Beachten Sie, dass dieses Flag für Linux-Kernel < 2.4.18 ignoriert wird.

Änderung erst nach Restart wirksam

USE_SYSTEM_PAGE_CACHE

gibt an, ob die Datenbankinstanz den System-Page-Cache für die Pufferung nicht mehr benötigter Speicherseiten verwendet

Änderung erst nach Restart wirksam