Parameter für das Oracle DB-Setup
WinCC OA greift direkt auf die Tabellen in Oracle zu. Für diesen Zugriff kann ein Anwendungsbenutzer (Application User) angelegt werden. Das Anlegen dieses Benutzers erfolgt automatisch beim späteren RDB-Setup. Für den Zugriff kann ebenso Schema-Benutzer eingesetzt werden.
Alle Setup-Parameter müssen vor dem Start des Setups in der Datei "RDB_config.sql" angepasst bzw. ergänzt werden. Die Zeilen haben z.B. den folgenden Aufbau:
define connect_identifier = 'MYDB'
”define
” - definiert die Oracle-Variable.
"connect_identifier
" - der Name der Oracle-Variable.
"'MYDB'
" - der Beispielwert, der durch den reellen Wert ersetzt werden
soll.
Die Vorlagendatei "RDB_config_template.sql" beinhaltet zusätzlich Kommentare (durch 2 Bindestriche gekennzeichnet), die Hinweise zu dem jeweiligen Parameter enthalten.
In der folgenden Tabelle werden die Setup-Parameter der Datei "RDB_config.sql" beschrieben. Beachten Sie, dass die Werte immer ausgeschrieben werden müssen - z.B. "yes" statt "y". Unter Linux muss auf Groß- und Kleinschreibung geachtet werden.
Die Kombination von den Parametern use_occi = no + sys_partitions = yes wird nicht unterstützt. Beachten Sie zudem, dass Pfade, die in der Datei angeführt werden, manuell erstellt werden müssen. Sowohl die Standardpfade (vorgegebenen Pfade von Oracle) als auch neu eingegebene Pfade müssen existieren – von der Datei werden keine Ordnerpfade erstellt. Unterhalb finden Sie ein Beispiel wie die Pfade aussehen könnten: define path_dbfile = 'D:\app\oracle\oradata\DBSYNC1\datafile\' define path_tempdbfile = 'D:\app\oracle\oradata\DBSYNC1\datafile\' define path_oraclebin = 'D:\app\oracle\product\19.3.0.0\db1\bin\' define path_backup = 'C:\WINCCOABackup\' define path_alert = 'D:\app\oracle\oradata\DBSYNC1\datafile\' define path_event = 'D:\app\oracle\oradata\DBSYNC1\datafile\' define path_asm_bin = 'D:\app\oracle\product\19.3.0.0\db1\bin\'
Parameter | Beschreibung |
---|---|
connect_identifier | Connect Identifier der Datenbank (Name für die Verbindung zur Datenbank-Instanz, wie z.B. in "tnsnames.ora" definiert), steht z.B. bei sqlplus hinter dem Klammeraffen ”@”. Kann ebenso mittels tnsping ermittelt werden. |
sysdba_user |
Name eines Benutzers mit System-Datenbank- Administrationsrechten. Dieser Eintrag kann, falls OS-Authentication möglich ist, auch leer gelassen werden. Dieser Parameter wird nicht benötigt, wenn yesno_newuser auf 'no' gesetzt ist. |
yesno_newuser |
Abfrage, ob ein neuer ”RDB-Benutzer” angelegt werden soll oder ein vorhandener Benutzer als RDB-Schema-Benutzer eingesetzt werden soll. Wenn RMAN verwendet wird, sollte yesno_newuser 'yes' sein, da es zu Problemen beim Auslagern kommen kann. |
schema_user |
Name des bestehenden oder des neu zu erzeugenden RDB-Schema-Benutzers. Dieser Benutzername darf maximal 13 Zeichen enthalten. Hinweis: Die Namen für den Schema-Benutzer und den Applikation-Benutzers müssen unterschiedlich sein. |
app_user |
Name des neu zu erzeugenden Applikation-Benutzers (App-User). Dieser Benutzername wird von WinCC OA verwendet, um auf die Datenbank zugreifen zu können. Der Name des Applikation-Benutzers darf maximal 30 Zeichen enthalten. Hinweis: Die Namen für den Schema-Benutzer und den Applikation-Benutzers müssen unterschiedlich sein. |
upgrade_sizeparams_override |
Entscheidet im Falle eines Upgrades, ob die bestehende Konfiguration überschrieben werden soll. 'yes' -> Daten aus "RDB_config.sql" werden übernommen, d.h. die bestehende Konfiguration wird überschrieben. 'no' -> Inhalte aus ARC_CONFIG werden übernommen, d.h. die bestehende Konfiguration bleibt erhalten.
Wenn ein Parameter in ARC_CONFIG noch nicht enthalten ist, werden unabhängig von der Eingabe die Daten aus "RDB_config.sql" übernommen.
Dieser Parameter wird nur bei Upgrades verwendet, bei der Erstinstallation wird er nicht benötigt. |
use_rman |
Entscheidet, ob das Backup über die Kommandos des Betriebssystems (Option ”os“ oder ”std”) oder über RMAN (Defaultoption ”rman”) erfolgt.
Für die Oracle Standard Edition sollte "std" oder "rman" verwendet werden.
‘rman’ = Aus-/Einlagerung über RMAN: "Backup and Recovery Manager" - Oracle-Kommandozeilenprogramm für Backup und Recovery. Backup und Recovery entspricht der Aus- und (Wieder-) Einlagerung.
Im Falle eines RAC oder wenn die installierte Datenbank ASM verwendet, muss die Option ‘rman’ gewählt werden. ASM: Automated Storage Management - Oracle verwaltet die Datendateien selbst auf RAW-Platten, die Verwaltung geschieht also nicht über das Betriebssystem.
Hinweis : Wenn die Auslagerung unter Windows über RMAN erfolgt, muss sich das Backup-Verzeichnis auf der lokalen Festplatte des Datenbankservers befinden. Das Backup in ein Netzwerkverzeichnis wird nicht unterstützt. Der Grund dafür ist ein Oracle Rechteproblem. Der Benutzer, für den Oracle unter Windows läuft, hat nicht genügend Rechte. Wenn dem Benutzer zusätzliche Rechte erteilt, ist es nicht mehr möglich sich als SYSDBA einzuloggen, was für das Backup über RMAN erforderlich ist.
‘std’ = „Auslagerung der Standard-Edition“ - die Archivdaten werden beim Auslagern auf den Backuppfad verschoben, beim Einlagern werden sie vom Backuppfad wieder zurückkopiert. Mit der std- Option kann auch für die Enterprise-Edition die Standard-Edition-Auslagerung gewählt werden.
‘os’ = nur für Oracle Enterprise Edition und wenn ausgelagerte Archive in eine andere Datenbank eingespielt werden sollen (diese kann dann auch eine Standard Edition sein). s-/Einlagerung durch Datapump-Export/Import. Jedes Backupset besteht aus zwei Dateien: den Datapump-Dump und der kopierten Datendatei - in dieser Zweierkombination sind die Daten theoretisch in jede kompatible Datenbank einspielbar. Für Standard-Edition: gleiche Vorgangsweise wie bei ’std’.
Hinweis: Wenn use_java und use_rman gleichzeitig verwendet werden, muss auch path_oraclebin eingetragen werden. |
os_sys | Abfrage nach dem Betriebssystem – bitte geben Sie 'win' für Windows oder 'unix' für Linux ein. |
zip_backup |
Entscheidet, ob die ausgelagerten Datenbankdateien komprimiert werden sollen. Wenn ja, dann geben Sie 'yes' ein und wenn nein, dann 'no'. Falls Backup über das Betriebssystem (use_rman = ’os’ oder use_rman = ’std’) gewählt wurde, werden die Oracle-Daten-Dateien nach der Auslagerung mit dem Zip-Tool komprimiert und erhalten die Endung *.zip. Vor der Einlagerung werden sie automatisch wieder dekomprimiert. Bei Backup über RMAN (use_rman = ’rman’) wird beim Backup die RMAN-Backup-Option ”compress” verwendet. Bei der Einlagerung dekomprimiert RMAN sie wieder automatisch. Hinweis: Ab der WinCC OA Version 3.8 ist darauf zu achten, dass ausgelagerte Datenbankdateien, die komprimiert werden sollen, die Größe von 4GB nicht überschreiten. |
sequence_start |
Anfangswert für die Archivnummerierung. Die niedrigste mögliche Zahl ist 0. Jedes neu erstellte Archiv erhöht die aktuelle Zahl um 1. Wenn es mehrere RDB-Schemen nebeneinander gibt, sollten sich die Bereiche, die sich aus sequence_start und sequence_maxvalue ergeben, nicht überschneiden. Ansonsten könnte es sein, dass Log-Dateien überschrieben werden, wenn die gewählten Verzeichnisse gleich sind. Einschränkungen für die Archivierung ergeben sich daraus keine. |
sequence_maxvalue |
Höchstwert für die Archivnummerierung. Die höchstmögliche Zahl ist '99999999'.
Es ist darauf zu achten, den Bereich zwischen sequence_start und sequence_maxvalue ausreichend groß zu definieren, damit genügend Nummern für die Lebensdauer einer Archivgruppe vorhanden sind. Für durchschnittliche bis größere Anwendungen sollte man in der Regel mit einem Bereich von ca. 100000 (z.B. von 100000 bis 199999) auskommen.
Beachten Sie: Der definierte Höchstwert darf nicht überschritten werden. Bei einer Überschreitung wird der folgende Fehler ausgegeben: ORA-08004: sequence SEQ_ARC_ARCHIVE.NEXTVAL exceeds MAXVALUE and cannot be instantiated" Das Anlegen neuer Archive wäre dann nicht mehr möglich. |
path_dbfile |
Wenn ein neuer Benutzer angelegt wird, wird mit ihm auch ein neuer Tablespace angelegt (Name = ”TS_”+Name des Benutzers). Geben Sie den Speicherort des neuen Tablespace an, der sich auf dem Oracle-Server befindet.
Wird hier nichts eingegeben, dann wird das Oracle-Default-Verzeichnis genommen (in der Regel %ORACLE_HOME%/DATABASE/).
Falls Sie den Pfad manuell eingeben, müssen Slash oder Backslash am Ende des Pfades angegeben werden! Andernfalls werden der letzte Verzeichnisname und der Tablespacename zu einem Namen zusammengefügt. Dieses Verzeichnis muss über ausreichende Lese-/Schreibrechte verfügen. Dies kann mit den Befehl chmod –R 777 <Verzeichnis> überprüft werden. |
path_tempdbfile |
Speicherort des temporären Tablespace. Bitte beachten Sie auch hier die Anmerkungen zu ”path_dbfile”. Zusätzlich wird an den Namen des temporären Tablespace „_TEMP“ angehängt. Parameter wird nur verwendet, wenn extra_TempTS = 'yes' gesetzt ist. |
extra_TempTS |
extra_TempTS = 'yes' - für das Schema wird ein eigener Temp-Tablespace verwendet. Das macht z.B. Sinn, wenn man den temporären Tablespace zur Lastenverteilung auf einer anderen Platte speichern möchte.
extra_TempTS = 'no' - für das Schema wird kein eigener Temp-Tablespace, sondern der Oracle-Default, verwendet. |
path_oraclebin | Pfadangabe des ORACLE_HOME/bin Verzeichnisses auf dem DB-Server. Der Pfad wird zum Auffinden von externen Programmen benötigt. |
instance_name | Name der Datenbankinstanz, in welcher die RDB- Installation durchgeführt wird. |
host_name | Hostname des Rechners, auf dem die Datenbankinstanz läuft. Bei Clustersystemen ist hier der Cluster-Hostname anzugeben. |
path_backup |
Verzeichnis am Oracle-Server, in dem die ausgelagerten Datenbank Datenfiles abgelegt werden. Beenden Sie die Pfadangabe immer mit einem Slash bzw. Backslash! Beachten Sie, dass dieser Parameter bereits beim ersten Setup vorhanden sein muss. |
path_alert |
Verzeichnis am Oracle-Server, in dem die Datenbank Datenfiles für die historischen Alarmdaten abgelegt werden. Beenden Sie die Pfadangabe immer mit einem Slash bzw. Backslash! Dieses Verzeichnis muss über ausreichende Lese-/Schreibrechte verfügen. Dies kann mit den Befehl chmod –R 777 <Verzeichnis> überprüft werden. Beachten Sie, dass dieser Parameter bereits beim ersten Setup vorhanden sein muss. |
path_event |
Verzeichnis am Oracle-Server, in dem die Datenbank Datenfiles für die historischen Ereignisdaten abgelegt werden. Beenden Sie die Pfadangabe immer mit einem Slash bzw. Backslash! Dieses Verzeichnis muss über ausreichende Lese-/Schreibrechte verfügen. Dies kann mit den Befehl chmod –R 777 <Verzeichnis> überprüft werden. Beachten Sie, dass dieser Parameter bereits beim ersten Setup vorhanden sein muss. |
mytimezone |
Zeitzonendefinition. Hier soll die Zeitzone angegeben werden, in der die Datenbank läuft (entspricht der Regel der lokalen Zeitzone: ”systimestamp”) Gültige Strings für Zeitzonen findet man in der Oracle-View ”v$timezone_names”. Mithilfe des sqlplus Befehls SQL> select * from v$timezone_names; wird die Zeitzone ermittelt. |
asm_instance | Connect Identifier für die ASM-Instanz (z.B. +ASM), Wert ist nur erforderlich, wenn die Datenbankdaten über ASM gespeichert und verwaltet werden. |
service_name |
Datenbank SID bzw. Datenbank SERVICE_NAME wie er in "tnsnames.ora" steht. Bei Clustern steht hier der gemeinsame Name, z.B. bei 2 geclusterten Instanzen DB1 und DB2, ist der gemeinsame Service-Name DB. |
number_db_storage
|
Wenn Sie Data Guard für die Synchronisation zwei oder mehrerer DB-Storages haben oder wenn Sie aus irgendeinem Grund mehr als einen DB-Storage haben, geben Sie 2 oder mehr ein.
"Oracle Data Guard ist die Management-, Monitoring- und Automatisierungssoftware-Infrastruktur, die eine oder mehrere Standby-Datenbanken erstellt, instand hält und überwacht, um die Daten vor Fehlern und Störungen zu schützen." -Oracle technology network-
Beachten Sie: DataGuard legt die Datendatei für den temporären Tablespace am passiven Knoten nicht an. Deswegen muss dies im Zuge des Setups für alle passiven Knoten erfolgen - folgende Schritte sind dabei erforderlich:
1. Data Guard-Wechsel auf die passive Seite damit diese aktiv wird.
2. Führen Sie das Skript "RDB_DGextra.sql" auf beiden Seiten aus. Dieses erstellt die Datendatei für den temporären Tablespace. |
upgrade_alertlastval |
Definiert, ob die Alarmletztwerttabellen bei einem Upgrade der RDB-Version neu angelegt werden oder nicht.
'yes' = Die Alarmletztwerttabellen werden gelöscht und neu angelegt. Zu beachten ist, dass es dabei zu geringen Datenverlusten kommen kann.
'no' = Die Alarmletztwerttabellen werden nicht neu angelegt. Die Folge können Unterschiede in der Tabellenstruktur sein. |
upgrade_eventlastval |
Definiert, ob die Event-Letztwerttabellen bei einem Upgrade der RDB-Version neu angelegt werden oder nicht.
'yes' = Die Event-Letztwerttabellen werden gelöscht und neu angelegt. Zu beachten ist, dass es dabei zu geringen Datenverlusten kommen kann.
'no' = Die Event-Letztwerttabellen werden nicht neu angelegt. Die Folge können Unterschiede in der Tabellenstruktur sein. |
reset_cs |
Definiert, ob die CS-Tabellen (siehe Beschreibung der Tabellen und Views der RDB-Verdichtung) bei einem Upgrade der RDB-Version neu angelegt werden oder nicht.
'yes' = Die CS-Tabellen werden gelöscht und neu angelegt (Zurücksetzen der kompletten RDB-Verdichtung).
'no' = Die CS-Tabellen werden nicht neu angelegt. Die Folge können Unterschiede in der Tabellenstruktur sein.
Hinweis: Beim Schema-Upgrade der Version 8.1 auf 8.5 muss dieser Parameter auf 'yes' gesetzt werden, damit die CS-Tabellen angelegt werden können. |
public_grants |
Im RDB gibt es für die Zugriffe auf die Objekte in der Datenbank einen eigenen Benutzer mit eingeschränkten Rechten - den Anwendungsbenutzer (Application User). Es gibt die Möglichkeit, diese Rechte publik zu machen. Das ist z.B. dann sinnvoll, wenn gewährleistet ist, dass nur vertrauenswürdige Benutzer sich einloggen können und sich jeder mit seinem eigenen Account anmelden möchte und nicht als Anwendungsbenutzer. Um die Rechte publik zu machen, geben Sie 'yes' ein.
Dieser Eintrag darf nur dann auf 'yes' gesetzt werden, wenn sichergestellt ist, dass es systemweit nur genau ein RDB-Schema gibt! Anderenfalls würde die gesamte Archivierung nicht mehr funktionieren. Defaultmäßig ist der Eintrag auf 'no'. |
compression_init_value |
Wenn Sie den Eintrag "compression_init_value" in der "RDB_config.sql"-Datei auf "yes" setzen: Für ein Verdichtungsintervall wird der letzte Wert des letzten Intervalls vor dem aktuellen Intervall berücksichtigt. Wenn z.B. der kleinste Wert des Intervalls von 08:00 Uhr bis 08:05 der Wert 2 ist aber im Intervall davor der letzte Wert des Intervalls der Wert 1 war, ist der kleinste Wert für das Intervall von 08:00 bis 08:05 Uhr der Wert 1. Der letzte Wert des vorigen Intervalls wurde für die 5-Minuten-Berechnung berücksichtigt. |
longTermStatCalcInt |
Mittels diesem Parameter kann eine RDBCompression, mit einer Intervalllänge von mehr als 24 Stunden, mehrmals täglich gestartet werden.
Wert -> Beschreibung 24 -> Die Kompression startet einmal täglich. [default] 12 -> Die Kompression startet zweimal täglich 1 -> Die Kompression startet stündlich.
Spätere Änderungen für diesen Parameter können nur mittels des RDParametrieren Panels (oder der ARC_CONFIG Tabelle) gemacht werden. |
define use_extended_oracle_types |
Multibyte-Strings mit mehr als 4000 Bytes konnten nicht in der Oracle-Datenbank gespeichert werden. Oracle unterstützt ab der Version 12c Spaltengrößen von mehr als 4000 Bytes (Extended Data Types). Dieses Feature kann vorerst nur für neue DBschemen verwendet werden! Um die Extended Data Types verwenden zu können, sind drei Schritte notwendig: 1) Konfigurieren Sie die Oracle Datenbank richtig. Damit die Extended Data Types verwendet werden können, sind einige Anpassungen in Oracle durchzuführen - Siehe https://docs.oracle.com/database/121/REFRN/GUID-D424D23B-0933-425F-BC69-9C0E6724693C.htm#REFRN10321 2) Legen Sie ein neues DBSchema an. 3) Setzen Sie den Parameter define use_extended_oracle_types der RDB_config.sql-Datei auf 'yes'. Damit wird die Byte-Anzahl für die betreffenden Strings auf 12500 erweitert. ACHTUNG! IOT (index organized tables) und Extended Datatypes können nicht gleichzeitig verwendet werden. Eine Sicherheitsabfrage wird bei der Schema-Installation ausgeführt. Die Installation prüft auch ob die Extended Datatypes in Oracle selbst aktiviert sind (max_string_size = EXTENDED). Für die Extended Datatypes wird eine Fehlermeldung in der Logdatei während des Setups angezeigt. |
define IOT_enabled |
Setzen Sie define IOT_enabled auf 'yes', um IOT (index organized tables) zu verwenden. IOT (index organized tables) und Extended Datatypes können nicht gleichzeitig verwendet werden - siehe define use_extended_oracle_types oberhalb. Wenn Extended Data Types verwendet werden, setzen Sie den Parameter define IOT_enabled auf 'no'. |
Config-Einträge für die zweite Site (bei Cluster-Lösungen). Wenn es sich um keine Cluster-Lösung handelt, sind diese Einträge nicht notwendig. Wenn es mehr als zwei Sites gibt, verwenden Sie das Site-Config-Panel um die Daten einzugeben. | |
connect_identifier2 | connect_identifier2 = ' '. Connect-Bezeichner für die zweite Site. |
instance_name2 | instance_name2 = ' '. Instanzname für die zweite Site. |
host_name2 | host_name2 = ' '. Host-Name für die zweite Site. |
asm_instance2 | asm_instance2 = ' '. Connect-Bezeichner für die ASM-Instanz für die zweite Site. |
service_name2 | service_name2 = ' '. Service-Name (Oracle SID) für die zweite Site (üblicherweise der gleiche Name wie für die erste Site). |
Config-Einträge, die auf sinnvolle und empfohlene Defaults gesetzt werden: | |
use_occi (yes/no): |
use_occi = 'yes'
Definiert ob die OCCI-Schnittstelle verwendet werden soll.
'yes' = RDB Manager schreibt Daten in das RDB-Archiv über die OCI Oracle Call-Schnittstelle (OCCI). OCI Bulk-Writing ist per default aktiviert und führt zu einer verbesserten Performance.
'no' = OCCI wird nicht verwendet. RDB-Manager schreibt Daten in das Archiv über SQL API. Fügen Sie den Config-Eintrag writeWithBulk = 0 zu der [ValueArchiveRDB]-Sektion der Config-Datei hinzu.
Beachten Sie, dass benutzerdefinierte Archivgruppen nur verwendet werden können, wenn die Daten über Oracle Call Interface (OCCI = 'yes') geschrieben werden.
Wenn Sie OCCI verwenden und das Schema für OCCI eingerichtet wird, kann nur writeWithBulk = 1 verwendet werden. Das Datenbankschema und der Config-Eintrag müssen zusammenpassen. Wenn Sie wieder das SQL-API verwenden wollen, muss auch das Datenbankschema gewechselt werden. Wenn der Config-Eintrag und das Datenbankschema nicht zusammenpassen, kann die RDB nicht gestartet werden und es wird eine Fehlermeldung angezeigt.
Beachten Sie: Es wird die Oracle-Version 11.2.0.2.0 sowie höhere Versionen unterstützt.
Hinweis: Die Fehlermeldung error ORA-00932: inconsistent datatypes: expected TESTER.LANGSTRING got CHAR erscheint, wenn das Datenbankschema nicht für OCCI aktualisiert wurde, aber der Config-Eintrag writeWithBulk = 1 in der Config-Datei gesetzt wurde. |
use_java |
Auslagerung über die C-DLL oder das in Oracle eingebettete Java:
use_java = 'yes' - verwendet wird die in Oracle eingebettete Java-Source. Die Java-Installation und die Wartung sind einfacher (es ist keine Oracle-Library zu definieren, keine zusätzlichen Einträge in "tnsnames.ora" und "listener.ora", usw.).
use_java = 'no' - verwendet wird die C-DLL zur Ein- und Auslagerung.
Im Setup wird entschieden, welche Variante eingesetzt wird. Eine nachträgliche Änderung ist nur durch eine erneute Ausführung des Setups oder durch ein Upgrade möglich.
Beachten Sie: Wenn use_java und use_rman gleichzeitig unter Linux verwendet werden, muss path_oraclebin eingetragen werden.
Beachten Sie: Wenn Sie Java für den Export unter Linux verwenden, können Sie über die DB-Konfiguration Pfade für die verwendeten Linux-Befehle eingeben (alle Einträge mit "prog_*". Das ist erforderlich, weil die Oracle-RDB-Datenbank für manche Operationen Betriebssystemkommandos benötigt und diese in einer Java-OS Shell aufruft. Allerdings kennt die Java-OS Shell keine Pfade. Deshalb müssen Sie mit dem Befehl den gesamten Pfad angeben. Das gleiche gilt unter Windows ab der Oracle Version 11g. |
sys_partitions |
sys_partitions = 'no'
Partitionierung kann die Leistung erhöhen sowie die Administrationsaufgaben vereinfachen. Partitionierung verbessert die Handhabbarkeit, Leistung und Verfügbarkeit der Datenbank. Die Tabellen, Indices und indexorientierten Tabellen können in kleinere Teile - Partitionen - unterteilt werden. Auf ein partitioniertes Objekt kann normal über SQL zugegriffen werden. |
Einträge für fortgeschrittene Oracle-Anwender. Die Einträge müssen nicht geändert werden. Diese werden auf Defaultwerte gesetzt. | |
type_float |
define type_float = 'NUMBER'
Typ durch den Float-Werte dargestellt werden, z.B. NUMBER oder BINARY_DOUBLE. |
initial_size |
Anfangsgröße der Dateien für die Tablespaces: ein Schema-Tablespace, max. ein temporärer Tablespace, viele Archiv-Tablespaces.
Die Größenangabe erfolgt mit <Wert>+<Größenkürzel>, zulässige Größenkürzel sind 'K' (Kilobytes), 'M' (Megabytes), 'G' (Gigabytes) oder 'T' (Terabytes). initial_size darf nicht leer sein.
Beispiel: define initial_size= '50M' -> die Anfangsgröße der Datei für den neu erzeugten Tablespace beträgt 50 MB.
Während des Setups wird der angegebene Wert als Default-Wert in die Tabelle ARC_CONFIG geschrieben. Für einzelne Archivgruppen kann dieser Wert später überparametriert werden (Tabelle ARC_GROUP). |
next_size |
Erweiterungsgröße der Dateien für die Tablespaces.
Wenn die bestehende Größe der Datei, in welcher der Tablespace gespeichert wird, nicht mehr ausreicht, dann wird die Datei um next_size vergrößert. Wenn der Wert leer gelassen wird, dann errechnet Oracle den passenden Wert selbst (je größer die Datei ist, desto mehr wird erweitert). Ansonsten wird immer fix um die angegebene Größe erweitert.
Die Größenangabe erfolgt mit <Wert>+<Größenkürzel>, zulässige Größenkürzel sind 'K' (Kilobytes), 'M' (Megabytes), 'G' (Gigabytes) oder 'T' (Terabytes). next_size darf leer sein.
Beispiele: define next_size = '' -> Oracle bestimmt die Autoextension der TS-Datei. define next_size = '10M’ -> Datei wird im Bedarfsfall fix um 10 MB erweitert.
Während des Setups wird der angegebene Wert als Defaultwert in die Tabelle ARC_CONFIG geschrieben, für einzelne Archivgruppen kann dieser Wert später überparametriert werden (Tabelle ARC_GROUP). |
uniform_size |
Größe neu zu allokierender Extents im Tablespace.
Wenn der Tablespace zu klein wird, wird ein neuer Extent allokiert. Dabei bestimmt uniform_size, auf welche Weise erweitert wird: Wenn der Wert leer gelassen wird, dann werden die Extents automatisch von Oracle berechnet (je größer der Tablespace bereits ist, desto größer wird der neu allokierte Extent sein), ansonsten wird immer ein Extent mit der angegebenen Größe geladen.
Die Größenangabe erfolgt mit <Wert>+<Größenkürzel>. Zulässige Größenkürzel sind 'K' (Kilobytes), 'M' (Megabytes), 'G' (Gigabytes) oder 'T' (Terabytes). Der Parameter uniform_size darf auch leer sein.
Beispiele: define uniform_size = '5M' -> Tablespace wird immer konstant um einen Extent von 5 MB erweitert.
define uniform_size = '' -> Oracle bestimmt die Größe der allokierten Extents.
Während des Setups wird der angegebene Wert als Defaultwert in die Tabelle ARC_CONFIG geschrieben. Für einzelne Archivgruppen kann dieser Wert später überparametriert werden (Tabelle ARC_GROUP).
Anmerkungen:
|
physical_attributes |
Physische Speicherparameter für die Archivtabellen.
Der einzutragende Wert entspricht 1:1 der Oracle <physical_attributes_clause>, kann aber auch leer bleiben. Die Syntax ist in der Oracle SQL Referenz unter „Common SQL DDL Clauses / physical_attributes_clause“ genau beschrieben. In den meisten Fällen genügt es diesen Wert leer zu lassen (’’).
Folgende drei Parameter können unter anderem in physical_attributes spezifiziert werden (wenn einzelne Parameter fehlen, dann verwendet Oracle die Default-Werte oder ermittelt die Werte dynamisch):
STORAGE_CLAUSE: Speicheroptionen zum Anlegen von Tabellen. Wichtig sind dabei die minimale Anfangsgröße des Objekts ("INITIAL“) und die Zahl der am Anfang allokierten Extents (MINEXTENTS) – der höhere Wert der beiden bestimmt die Anfangsgröße der Tabelle. Die Extent-Größe ergibt sich aus dem Parameter next_size.
PCTFREE: Prozentsatz. Ein Block gilt als voll, wenn weniger als der angebene Prozentsatz frei ist. Der so bewusst freigehaltene Speicher wird dann für Updates verwendet. Je häufiger Updates stattfinden, desto höher ist dieser Wert zu wählen – Oracle Default ist 10 Prozent.
INITRANS: Anzahl der am Anfang verfügbaren Transaktionsslots in einem Datenblock. Oracle Default ist, je nach Anwendung, 1 oder 2. Wenn in einer Tabelle viele Updates gleichzeitig stattfinden werden, kann der Wert erhöht werden. Oracle kann die Zahl der Slots zwar bei Bedarf dynamisch erhöhen, die Prozesse müssten dann aber eine Zeit lang auf freie Slots warten. In der Regel muss dieser Wert jedoch nicht extra spezifiziert werden.
Anmerkung: Es wird AUTO SEGMENT SPACE MANAGEMENT verwendet. Deswegen machen andere Parameter, wie z.B. PCTUSED hier keinen Sinn. Weiterführende Infos oder die genaue Syntax finden Sie in der Oracle SQL Referenz unter „Common SQL DDL Clauses / storage_clause“.
Beispiele: define physical_attributes = '' -> Oracle bestimmt das Verhalten und den Speicher der Tabelle (empfohlen).
define physical_attributes = 'PCTFREE 20 INITRANS 10 STORAGE (INITIAL 10M MINEXTENTS 2)' -> Beispiel mit allen Optionen: Blöcke werden als "voll“ definiert, wenn mehr als 80% belegt sind. Die Anfangsgröße einer Tabelle ist 10M und sie hat mindestens zwei Extents allokiert – wenn diese beiden Extents zusammen mehr als 10MB haben, dann würden sie die Anfangsgröße der Tabelle bestimmen.
Wichtige Anmerkung für Anwender früherer Versionen von RDB: Die Parameter "physical_attributes" und "physical_attrib_idx" ersetzen die Parameter "storage_clause" und "storage_clause_idx“. Wenn Sie bereits eine storage_clause definiert haben und diese beibehalten wollen, fügen Sie das Schlüsselwort STORAGE vor der Klausel ein. Ändern Sie z.B. '(INITIAL 10M MINEXTENTS 1 MAXEXTENTS UNLIMITED)' auf 'STORAGE (INITIAL 10M MINEXTENTS 1 MAXEXTENTS UNLIMITED)' um. Da die neue Klausel allgemeiner ist, ist nun das Schlüsselwort STORAGE erforderlich. Beachten Sie, dass diese Änderungen auch die Templates für die Archivgruppen in den Tabellen ARC_STATEMENT und ARC_TEMPLATE beeinflussen und die Inhalte entsprechend aktualisiert werden müssen. Dafür gibt es ein Update-Script für die RDB-Version. |
physical_attrib_idx |
Physische Speicherparameter für die Archivindizes. Für diesen Indexparameter gelten sinngemäß alle Einstellungen und Anmerkungen, die bereits beim Tabellenparameter physical_attributes beschrieben wurden. Beachten Sie bitte besonders die obige Anmerkung für Anwender früherer Versionen. |
threshold_append |
Parameter zur Steuerung des Einfügens von Archvidaten in die Oracle-Datenbank. Die Größe gibt die Anzahl der Datensätze pro Block an. Bei Blöcken, welche die angegebene Anzahl von Archiv-Datensätzen oder mehr enthalten, wird beim Einfügen von Archivdaten in die Oracle-Datenbank der Append-Hint /* +APPEND */ verwendet. Wenn 0 angegeben ist, dann wird der Append-Hint nicht verwendet. Der Append-Hint beschleunigt das Einfügen auf Kosten des Platzverbrauchs. Er sorgt dafür, dass Oracle nicht überprüft, ob noch Platz in einem bestehenden Block vorhanden ist, sondern es wird ein neuer Block erstellt, in dem alle Zeilen des Blocks hineingeschrieben werden. Der empfohlene Wert ist 100. Erfahrungsgemäß wird dabei der vorhandene Platz gut ausgenutzt und es wird ausreichend schnell geschrieben |
use_arc_idx_ts |
define use_arc_idx_ts = 'yes'
Aktivieren oder deaktivieren Sie den Index des Zeitstempels. Normalerweise ist der Index aktiviert. Die Verwendung von einem Index macht eine Abfrage grundsätzlich schneller. |
Einträge für das Disaster Recovery System (DRS) und/oder Historische Synchronisation. | |
whatpackage |
Angabe des Pakets, welches installiert wird.
define whatpackage = '2x2' -> die Einträge werden für das DRS gesetzt.
define whatpackage = 'fwd' -> die Einträge werden für die historische Synchronisation gesetzt. |
connect_first |
Erster Connect Identifier der lokalen Datenbank (Name für die Verbindung zur Datenbank-Instanz, wie z.B. in "tnsnames.ora" definiert), steht z.B. bei sqlplus hinter dem Klammeraffen ”@”. Kann ebenso mittels tnsping ermittelt werden.
define connect_first = '&connect_identifier' -> der Connect Identifier wird vom Eintrag connect_identifier übernommen. |
connect_second | Zweiter Connect Identifier der entfernten Datenbank. |
whatinstall |
Definiert, wo das Packet installiert wird. 1 -> auf der ersten Site 2 -> auf der zweiten Site 3 -> auf beiden Sites |
syncjob_intval | Dauer in Minuten zwischen den einzelnen Starts der Abgleichjobs (neue Änderungen werden abgeglichen und vorher gescheiterte Änderungsabgleiche werden erneut versucht abgeglichen zu werden). |
maxintval_len |
Nur für DRS. Maximale Abgleichsintervalllänge (Angabe in Sekunden; Default ist 60) zur Stückelung einer Abgleichsaufgabe in kleine Pakete. Dadurch wird z.B. ein Abgleich auch über eine langsame Datenleitungen möglich. Beispiel: Es soll über einen Zeitraum von 3 Stunden abgeglichen werden und die Intervalllänge wurde auf 600 eingestellt. Das bedeutet, dass die 3 Stunden auf 18 Pakete aufgeteilt werden. |
system_first |
Nur für DRS. System-ID des ersten oder lokalen Systems (PSS), um eine Übereinstimmung mit der System-ID des zweiten oder entfernten Systems zu erhalten. Die System-ID des zweiten Systems ist system_second (siehe unterhalb). |
system_second |
Nur für DRS. System-ID des zweiten oder entfernten Systems (SSS), um eine Übereinstimmung mit der System-ID des ersten oder lokalen Systems zu erhalten. Die System-ID des ersten Systems ist system_first (siehe oberhalb). |
system_first2 |
Optional und nur für DRS. Wenn es ein zweites DRS-System gibt, werden die Optionen system_first2 und system_second2 verwendet. Diese sind die Optionen für das erste (PSS) und zweite (SSS) System des zweiten DRS-Systems. System-ID des ersten oder lokalen Systems, um eine Übereinstimmung mit der System-ID des zweiten oder entfernten Systems zu erhalten. Die System-ID des zweiten Systems ist system_second2 (siehe unterhalb). |
system_second2 |
Optional und nur für DRS. Wenn es ein zweites DRS-System gibt, werden die Optionen system_first2 und system_second2 verwendet. Diese sind die Optionen für das erste (PSS) und zweite (SSS) System des zweiten DRS-Systems. System-ID des zweiten oder entfernten Systems, um eine Übereinstimmung mit der System-ID des ersten oder lokalen Systems zu erhalten. Die System-ID des ersten Systems ist system_first2 (siehe oberhalb). |
IOT_enabled |
Legt fest ob Index Organized Tables (IOTs) in der Oracle Datenbank verwendet werden dürfen. Mögliche Parameter sind:
|