## Spezielle Datenbankparameter

### Verwendung

In der folgenden Übersicht sind die speziellen Datenbankparameter beschrieben. Für Informationen zu weiteren Datenbankparametern siehe Allgemeine Datenbankparameter, Support-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

Spezielle Datenbankparameter (Extended)

Parameter | Bedeutung | Wie kann der Parameter geändert werden?
_COMMENT | Beschreibung der Datenbankinstanz | Änderung erst nach Restart wirksam
_DATA_CACHE_RGNS | Anzahl der kritischen Abschnitte, in die der Data-Cache unterteilt ist Diese Unterteilung erlaubt ein paralleles Schreiben in den Data-Cache. Der Parameter wird vom Datenbanksystem berechnet und ist nicht änderbar. Sie können den Parameter jedoch für Testzwecke mit dem Support-Datenbankparameter XP_DATA_CACHE_RGNS übersteuern. | kann nicht geändert werden
_MAX_MESSAGE_FILES | maximale Anzahl von Trace-Dateien, die parallel geöffnet werden können | Änderung erst nach Restart wirksam
_MAXEVENTS | maximale Anzahl der vom Kern im Arbeitsspeicher abgelegten Events, die vom Database Manager verarbeitet werden sollen | Änderung erst nach Restart wirksam
_ROW_RGNS | Anzahl der kritischen Abschnitte, in die die Menge aller Zeilen in der Sperrliste unterteilt ist Diese Unterteilung ermöglicht einen parallelen Zugriff auf die Sperrliste. | Änderung erst nach Restart wirksam
_TAB_RGNS | Anzahl der kritischen Abschnitte, in die die Menge aller Tabellen in der Sperrliste unterteilt ist Diese Unterteilung ermöglicht einen parallelen Zugriff auf die Sperrliste. | Änderung erst nach Restart wirksam
_TRANS_RGNS | Anzahl der kritischen Abschnitte, in die die Menge aller Transaktionen in der Sperrliste unterteilt ist Diese Unterteilung ermöglicht einen parallelen Zugriff auf die Sperrliste. | Änderung erst nach Restart wirksam
_UNICODE | legt fest, ob das Datenbanksystem für die Namen von Datenbankobjekten im Datenbankkatalog als Zeichensatz Unicode verwendet | Sie legen den Datenbankparameter beim Anlegen der Datenbankinstanz fest. Nachträglich können Sie den Datenbankparameter nur ändern, indem Sie die Datenbankinstanz neu initialisieren. Dabei gehen jedoch alle Anwendungsdaten verloren.
AUTO_RECREATE_BAD_INDEXES | als BAD markierte Indizes werden nach einem Wiederherstellen automatisch neu erzeugt | Änderung erst nach Restart wirksam
BACKUP_BLOCK_CNT | Blockgröße, die das Datenbanksystem beim Sichern für das Beschreiben der Datenträger verwendet nur für Bänder sinnvoll, die über eine optimale Blockgröße verfügen | Änderung erst nach Restart wirksam
CAT_CACHE_SUPPLY | Speichergröße des Catalog-Cache für alle User-Tasks (in Seiten) | Änderung erst nach Restart wirksam
CLUSTERED_LOBS | gibt an, ob das Datenbanksystem LONG-Werte (LOBs) im Datenbereich als Cluster speichert | kann im laufenden Betrieb geändert werden
CLUSTER_WRITE_THRESHOLD | minimale Anzahl von Blöcken, die das Datenbanksystem noch als Cluster im Datenbereich speichert | kann im laufenden Betrieb geändert werden
CONVERTER_REGIONS | Anzahl der kritischen Abschnitte, in die der Converter unterteilt ist Diese Unterteilung erlaubt ein paralleles Schreiben in den Converter. Der Parameter wird vom Datenbanksystem berechnet und ist nicht änderbar. Sie können den Parameter jedoch für Testzwecke mit dem Support-Datenbankparameter XP_CONVERTER_REGIONS übersteuern. | Änderung erst nach Restart wirksam
DATE_TIME_FORMAT | Systemvorschlag für das Datums- und Zeitformat Sie können das Datums- und Zeitformat mit Datenbankwerkzeugen (z. B. im Loader über standard_date_mask) oder durch entsprechende Angaben in SQL-Anweisungen (datetimeformat) übersteuern. Siehe Datums- und Zeitformat. | kann im laufenden Betrieb geändert werden
DEADLOCK_DETECTION | maximale Suchtiefe bei der Deadlock-Erkennung Deadlocks, die das Datenbanksystem bis zur vorgegebenen Suchtiefe nicht entdeckt hat, werden nur durch einen Timeout aufgelöst (siehe REQUEST_TIMEOUT). | Änderung erst nach Restart wirksam
DEFAULT_CODE | Systemvorschlag für das Codeattribut, gilt nur für Spaltenwerte der Datentypen CHAR[ACTER], VARCHAR und LONG[VARCHAR] | kann im laufenden Betrieb geändert werden
DIAG_HISTORY_NUM | Anzahl der Historien im Verzeichnis <diag_history_path> | Änderung erst nach Restart wirksam
DIAG_HISTORY_PATH | Verzeichnis <diag_history_path>, in dem das Datenbanksystem nach einem Datenbankfehler Diagnosedateien (Sicherungen der wichtigsten Protokolldateien und Speicherauszüge) speichert | Änderung erst nach Restart wirksam
FILEDIR_SPINLOCKPOOL_SIZE | Anzahl der Spinlocks, die für Reader-Writer-Locks für das interne Dateiverzeichnis zur Verfügung stehen | Änderung erst nach Restart wirksam
FORMAT_DATAVOLUME | unterdrückt die Formatierung der Data-Volumes beim Anlegen einer neuen Datenbankinstanz; nur für Testzwecke sinnvoll | Änderung erst nach Restart wirksam
FORMATTING_MODE | Das Datenbanksystem formatiert beim Anlegen der Datenbankinstanz die Volumes. Mit diesem Parameter legen Sie die Art der Formatierung fest. Eine parallele Formatierung ist nur für solche Data-Volumes vom Typ Datei sinnvoll, die auf unterschiedlichen Festplatten liegen. | Änderung erst nach Restart wirksam
HASHED_RESULTSET | gibt an, ob das Datenbanksystem Ergebnismengen, die beim Ausführen von Joins entstehen, mit einem Hash-Verfahren optimiert | kann im laufenden Betrieb geändert werden
HASHED_RESULTSET_CACHESIZE | maximale Größe des Arbeitsspeichers, den das Datenbanksystem für Ergebnismengen verwenden kann, die mit einem Hash-Verfahren optimiert werden (in kB) | kann im laufenden Betrieb geändert werden
HIRES_TIMER_TYPE | Art der Zeitmessung, die vom Kern für interne Operationen verwendet wird; nur sinnvoll für Mehrprozessorenrechner, bei denen es zu Synchronisationsproblemen zwischen den CPUs kommt | Änderung erst nach Restart wirksam
HS_DELAY_TIME_<NNN> | nur für Hot-Standby-Systeme Zeitverzögerung in Sekunden, mit der die Standby-Instanz NNN Datenänderungen der Master-Instanz nachvollzieht | Änderung erst nach Restart wirksam
HS_NODE_<NNN> | nur für Hot-Standby-Systeme Rechnername / IP-Adresse der Hot Standby-Instanz NNN Der Vorschlagswert für die Master-Instanz ist HSS_NODE_001. | Änderung erst nach Restart wirksam
HS_STORAGE_DLL | nur für Hot-Standby-Systeme Name der Bibliothek, über die das das Hot-Standby-System das Speicherverwaltungssystem anspricht Der Vorschlagswert ist libhsscopy. | Änderung erst nach Restart wirksam
HS_SYNC_INTERVAL | nur für Hot-Standby-Systeme minimale Zeitspanne, die zwischen zwei Befehlen der Master-Instanz zum Synchronisieren der Standby-Instanzen liegt (in s) | Änderung erst nach Restart wirksam
JOIN_MAXTAB_LEVEL4 | Parameter des SQL-Optimierers; siehe JOIN_SEARCH_LEVEL | kann im laufenden Betrieb geändert werden
JOIN_MAXTAB_LEVEL9 | Parameter des SQL-Optimierers; siehe JOIN_SEARCH_LEVEL | kann im laufenden Betrieb geändert werden
JOIN_SEARCH_LEVEL | Algorithmus, den der SQL-Optimierer für die Join-Sequenz-Suche verwendet; siehe Datenbankparameter JOIN_SEARCH_LEVEL | kann im laufenden Betrieb geändert werden
JOIN_TABLEBUFFER | Größe des Puffers, den der SQL-Optimierer pro Join-Schritt für eine Leseoperation nutzen kann | Änderung erst nach Restart wirksam
KERNELDIAGSIZE | Größe der Protokolldatei knldiag (in KB) | Änderung erst nach Restart wirksam
LOAD_BALANCING_CHK | Zeitabstand, in dem das Datenbanksystem überprüft, ob ein Load-Balancing sinnvoll ist (in s) | Änderung erst nach Restart wirksam
LOG_BACKUP_TO_PIPE | NO: Nachdem eine Log-Sicherung in eine Pipe ausgelesen wurde, wird anschließend die Verbindung zur Pipe geschlossen, ohne dass das Datenbanksystem eine Information darüber hat, ob das die Log-Sicherung erfolgreich war. Der Log-Bereich wird deswegen nicht wieder freigegeben und kann nicht erneut beschrieben werden, so dass er unter Umständen voll wird und keine weiteren Datenänderungen mehr möglich sind. YES: Das Datenbanksystem kann bereits in die Pipe geschriebene Log-Einträge im Log-Bereich wieder überschreiben. Beachten Sie, dass das System nicht prüft, ob die Log-Sicherung über die Pipe erfolgreich war. | Änderung erst nach Restart wirksam
LOG_IO_QUEUE | Größe der einzelnen Log-Warteschlangen (in Seiten) | Änderung erst nach Restart wirksam
LRU_FOR_SCAN | gibt an, ob der gesamte Data-Cache für Scans verwendet wird | kann im laufenden Betrieb geändert werden
MAX_HASHTABLE_MEMORY | maximale Größe des Arbeitsspeichers, den das Datenbanksystem für das Zwischenspeichern aller Tabellen beim Ausführen von Joins verwenden kann (in kB) | kann im laufenden Betrieb geändert werden
MAX_SINGLE_HASHTABLE_SIZE | maximale Größe des Arbeitsspeichers, den das Datenbanksystem für das Zwischenspeichern einer einzelnen Tabelle beim Ausführen eines Joins verwenden kann (in kB) | kann im laufenden Betrieb geändert werden
MAXRGN_REQUEST | maximale Anzahl von Zugriffsversuchen einer Task auf einen kritischen Abschnitt Wenn diese Zahl überschritten wird, gibt die Task den Zugriff auf die CPU für eine andere Task des gleichen User-Kernel-Thread frei. | kann im laufenden Betrieb geändert werden
MAXSERVERTASKS | Anzahl von Server-Tasks | Änderung erst nach Restart wirksam
MEM_ENHANCE_LIMIT | maximal zusätzlich zu verwendender Speicher, der durch ein Memory Scalability Enhancement wie z. B. möglich wird (in MB) | Änderung erst nach Restart wirksam
MEMORY_ALLOCATION_LIMIT | maximal von der Datenbankinstanz zu verwendender Speicher (in KB) | Änderung erst nach Restart wirksam
MP_RGN_LOOP | maximale Anzahl von Zugriffsversuchen einer Task auf einen kritischen Abschnitt, der durch eine andere Task gesperrt ist Wenn diese Zahl überschritten wird, ändert die zugreifende Task ihren Zustand in "wartend". | kann im laufenden Betrieb geändert werden
OFFICIAL_NODE | nur für Hot-Standby-Systeme Virtual Server Name, über den der Cluster von außen angesprochen wird Der Systemadministrator weist den Virtual Server Name initial dem Rechner zu, auf dem die Master-Instanz des Hot-Standby-Systems läuft. Wenn die Master-Instanz ausfällt, dann geht der Name auf jene Standby-Instanz über, die die Master-Rolle übernimmt. | Änderung erst nach Restart wirksam
OPTIM_INV_ONLY | legt fest, ob der SQL-Optimierer für Joins die Index-Only-Strategie verwendet | kann im laufenden Betrieb geändert werden
OPTIM_MAX_MERGE | beeinflusst die Entscheidung, ob der SQL-Optimierer eine Index-Merge-Strategie verwendet Wenn die Anzahl der zusammenzuführenden Seiten eines Index den Wert von OPTIM_MAX_MERGE übersteigt, dann verwendet der SQL-Optimierer diesen Index nicht für eine Index-Merge-Strategie. | kann im laufenden Betrieb geändert werden
OPTIMIZE_QUERYREWRITE | Automatisches Umformen von SQL-Anweisungen Vorschlagswert für Softwareversionen >= 7.6: OPERATOR (das Datenbanksystem formt SQL-Anweisungen um). Um das alte Umformungsverhalten (Versionen < 7.6) zu aktivieren, wählen Sie STATEMENT. | kann im laufenden Betrieb geändert werden
REQUEST_TIMEOUT | maximale Wartezeit auf Freigabe einer Sperre (in s); begrenzt für alle Datenbanksitzungen das Warten auf die Freigabe einer Sperre durch andere Benutzer Wenn eine Sperranforderung in der hier definierten Zeit nicht erfüllt werden kann, erfolgt eine Rückmeldung an die wartende Datenbanksitzung. Das Datenbanksystem macht die gegebenenfalls vorher durchgeführten Änderungen innerhalb der Transaktionen rückgängig (ROLLBACK). | Änderung erst nach Restart wirksam
SEQUENCE_CACHE | Größe des Sequence-Cache (in Seiten) | Änderung erst nach Restart wirksam
SESSION_TIMEOUT | Timeout-Wert für Datenbanksitzungen (in s) | kann im laufenden Betrieb geändert werden
SHAREDSQL | Aktivieren von Shared-SQL | kann im laufenden Betrieb geändert werden
SHAREDSQL_COMMANDCACHESIZE | maximale Größe des Shared-SQL-Cache (in KB) | Änderung erst nach Restart wirksam
SHAREDSQL_EXPECTEDSTATEMENTCOUNT | erwartete Anzahl der SQL-Anweisungen, die im Shared-SQL-Cache abgelegt werden | Änderung erst nach Restart wirksam
TRACE_PAGES_<task> | maximale Anzahl Seiten, die den einzelnen Task-Typen pro User-Kernel-Thread zur Verfügung stehen Jeder User-Kernel-Thread hat einen eigenen Trace-Bereich im Arbeitsspeicher. <task> kann folgende Werte haben: BUP (Backup-Task, noch nicht implementiert), EV (Event-Task), GC (Garbage-Collector), LW (Log-Writer), PG (Pager), SV (Server-Task), TI (Timer-Task), US (User-Task), UT (Utility-Task) | Änderung erst nach Restart wirksam
UPDATESTAT_SAMPLE_ALGO | legt den Algorithmus fest, den das Datenbanksystem für das Aktualisieren der SQL-Optimiererstatistiken verwendet | kann im laufenden Betrieb geändert werden
USED_LOG_QUEUE_COUNT | siehe LOG_QUEUE_COUNT | Änderung erst nach Restart wirksam
VOLUMENO_BIT_COUNT | Anzahl der Bits in der Converter-Blockadresse, die für die logische Volume-Nummer eines Data-Volume reserviert ist Erlaubte Werte: 6 ≤ VOLUMENO_BIT_COUNT ≤ 12 (siehe Technische Restriktionen) Wir empfehlen, den beim Anlegen der Datenbankinstanz gewählten Wert nicht mehr zu ändern. Wenn Sie den Datenbankparameter im laufenden Datenbankbetrieb ändern, dann müssen Sie anschließend eine Wiederherstellung der Datenbankinstanz durchführen, um die Nummerierung der Data-Volumes zu aktualisieren. | Änderung erst nach Restart wirksam
XP_CONVERTER_REGIONS | Übersteuern des Parameters CONVERTER_REGIONS | Änderung erst nach Restart wirksam
XP_DATA_CACHE_RGNS | Übersteuern des Parameters _DATA_CACHE_RGNS | Änderung erst nach Restart wirksam
XP_MAXPAGER | Übersteuern des Parameters MAXPAGER | Änderung erst nach Restart wirksam