## Support-Datenbankparameter

### Verwendung

Die meisten Support-Datenbankparameter dienen zur Fehlersuche. Im normalen Betrieb müssen Sie die Support-Datenbankparameter nicht ändern. Das Ändern von Support-Datenbankparametern erfordert sehr detaillierte Kenntnisse des Datenbanksystems. Für Informationen zu weiteren Datenbankparametern siehe Allgemeine Datenbankparameter, Spezielle Datenbankparameter und liveCache-Datenbankparameter.

Änderungen von Datenbankparametern werden erst nach einem Restart der Datenbankinstanz wirksam.

Einige Datenbankparameter können Sie auch im laufenden Betrieb ändern. Für diese Datenbankparameter können Sie außerdem wählen, wie lange die Änderung wirksam ist:

■ nur bis zum nächsten Restart

■ erst nach dem nächsten Restart

■ sofort und dauerhaft

Support-Datenbankparameter

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