Local Temporary Tablespaces im RAC

3. März 2020 Aus Von Markus Flechtner

„Temporary Tablespaces“ gibt es schon länger und ihre Funktionalität sollte bekannt sein: wenn z.B. beim Anlegen von Indizes oder beim Sortieren mittels ORDER BY der Platz in der PGA nicht reicht, dann dienen sie als „Überlauf“, als temporärer Zwischenspeicher. Außerdem werden die Daten von „global temporary tables“ dort abgelegt. Natürlich gibt es derartige temporäre Tablespaces auch in RAC-Datenbanken; sie werden gemeinsam von allen RAC-Instanzen genutzt und die Dateien (TEMPFILES) dieser Tablespaces liegen in einem für alle zugänglichen Plattenbereich („shared“). Seit Oracle 12.2 gibt es aber auch zusätzlich „local temporary tablespaces“.

„Local temporary tablespaces“ sind instanzspezifische temporäre Tablespaces, deren Dateien in einem lokalen Dateisystem auf dem jeweiligen Server liegen. Der primäre Einsatzzweck sind die „RAC Reader Nodes“, d.h. RAC-Instanzen, die keine Datenbankänderungen durchführen können. RAC Reader Nodes werden in Verbindung mit den mit Oracle 12.2 eingeführten „Flex Clustern“ genannt, d.h. Clustern die aus „Hub-Nodes“ (mit Verbindung zum „Shared Storage“) und „Leaf Nodes“, d.h. Knoten ohne Verbindung zum Shared Storage, bestehen. Sie laufen üblicherweise auf den „Leaf-Nodes“, während die Read-/Write-Operationen auf den „normalen RAC-Instanzen“ auf den Hub-Nodes laufen. Aber natürlich können diese Read-Only-Instanzen auch auf den Hub-Nodes laufen.

Anmerkungen:

  • Interessanterweise sind die „Leaf Nodes“ lt. Oracle 19c-Upgrade-Guide mit Oracle 19c „desupported“ (genauer: mit 19.5) , d.h. das Konzept der „Flex Cluster“ hat sich auf dem Markt anscheinend nicht durchgesetzt.
  • „RAC Reader Nodes“ bieten aus Lizenzsicht auch keine Vorteile; sie sind müssen voll wie normale RAC-Knoten lizenziert werden.

Aber zurück zu den „local temporary tablespaces“:

Anlegen eines local temporary tablespaces

SQL> create local temporary tablespace for all LOC_TEMP 
  2   tempfile '/u01/oradata/SOURCE/loc_temp' size 100M;

Tablespace created.

„FOR ALL“ bedeutet, dass für alle Instanzen (Reader-Nodes und read/write-Instanzen) ein derartiger Tablespace angelegt wird.

:-(

Mit „FOR LEAF“ wird nur auf den Reader-Nodes ein derartiger Tablespace angelegt. Interessanterweise gibt es hier einen Widerspruch in der Oracle 19c-Dokumentation: lt. SQL-Reference ist es „FOR LEAF“, lt. RAC-Deployment-Guide „FOR RIM“. Letzteres funktioniert aber nicht: „ORA-00901: invalid CREATE command).

Wenn man keine Reader-Nodes in seinem Cluster hat, dann wird bei der Verwendung von „FOR LEAF“ auch kein Tablespace angelegt. Stattdessen gibt es einen ORA-32778.

Hinweis 1: Das Verzeichnis, in dem die Dateien des Tablespaces abgelegt werden, muss auf allen Knoten vorhanden sein bzw. vor dem Anlegen des Tablespaces angelegt werden.

SQL> select tablespace_name,contents,bigfile,shared 
 2   from dba_tablespaces order by tablespace_name;

TABLESPACE_NAME 	       CONTENTS 	     BIG SHARED
------------------------------ --------------------- --- -------------
LOC_TEMP		       TEMPORARY	     YES LOCAL_ON_ALL
SYSAUX			       PERMANENT	     NO  SHARED
SYSTEM			       PERMANENT	     NO  SHARED
TEMP			       TEMPORARY	     NO  SHARED
UNDOTBS1		       UNDO		     NO  SHARED
UNDOTBS2		       UNDO		     NO  SHARED
USERS			       PERMANENT	     NO  SHARED

7 rows selected.

Hinweis 2: Local temporary tablespaces sind immer Bigfile-Tablespaces

Die Dateien der lokalen temporären Tablespaces werden aufsteigend nummeriert; der Dateiname den man beim Anlegen angibt ist nur ein „Prefix“:

SQL> select inst_id,file_id,file_name from dba_temp_files;

   INST_ID    FILE_ID FILE_NAME
---------- ---------- ------------------------------------------
		    1 +DATA/SOURCE/TEMPFILE/temp.261.1033595189
	 1	    2 /u01/oradata/SOURCE/loc_temp_1
	 2	    2 /u01/oradata/SOURCE/loc_temp_2

SQL>

Zuweisen von lokalen temporären Tablespaces

Wenn es mehrere lokale temporäre Tablespaces gibt, dann kann ein Default auf Datenbank-Ebene gesetzt werden oder einem Benutzer kann gezielt ein Tablespace zugewisen werden. Darin unterscheidet sich dieser Tablespace-Typ also nicht von den „normalen“ temporären Tablespaces.

SQL> alter database default local temporary tablespace LOC_TEMP;
Database altered.

SQL> alter user system local temporary tablespace loc_temp;
User altered.

SQL> column default_tablespace format a20
SQL> column temporary_tablespace format a20
SQL> column local_temp_tablespace format a21
SQL> select default_tablespace,temporary_tablespace,local_temp_tablespace
  2  from dba_users
  3  where username='SYSTEM';

DEFAULT_TABLESPACE   TEMPORARY_TABLESPACE LOCAL_TEMP_TABLESPACE
-------------------- -------------------- ---------------------
SYSTEM		     TEMP		  LOC_TEMP

Wie nutzt Oracle diese lokalen temporären Tablespaces?

Da es jetzt zwei Typen von lokalen Tablespaces gibt, gibt es lt. Oracle-Dokumentation eine Hierarchie der temporären Tablespaces. Diese unterscheidet sich, je nachdem ob die Instanz „read-only“ oder „read-write“ ist.

Für Read-Only-Instanzen gilt folgende Hierarchie:

  1. Allocate from a user’s local temporary tablespace.
  2. Allocate from the database default local temporary tablespace.
  3. Allocate from a user’s temporary tablespace.
  4. Allocate from the database default temporary tablespace.

Für Read-Write-Instanzen gilt:

  1. Allocate from a user’s shared temporary tablespace.
  2. Allocate from a user’s local temporary tablespace.
  3. Allocate from the database default shared temporary tablespace.
  4. Allocate from the database default local temporary tablespace.

Dabei ist zu beachten, dass Oracle bei den Sortieroperationen etc. immer nur einen temporären Tablespace nutzt und nicht – für den Fall, dass der Platz nicht reicht – einen zweiten heranzieht. Für Read-Write-Instanzen wird somit ein lokaler temporärer Tablespace – meiner Meinung nach – in den meisten Fällen nicht genutzt werden. Das passt dann auch zu dem Haupteinsatzgebiet „RAC Reader Nodes“.

Droppen von local temporary Tablespaces

Wenn man einmal einem User eine Tablespace als „local temporary tablepace“ zugewiesen hat („alter user <User> local temporary tablespace <TS“) oder sogar einen datenbankweiten Default gesetzt hat („alter database default local temporary tablespace <TS>“) ist es schwer, die lokalen temporären Tablespaces wieder loszuwerden. Denn man kann diesen Tablespace nur „ersetzen“, nicht aber die Einstellung komplett zurücknehmen,

Weitere Informationen:

 

Amazon Partner Link