Tablespace bei kurzlebiger Speicherung


7

Aus Leistungsgründen haben Sie in einigen Szenarien, z. B. bei Amazon EC2, Zugriff auf ein schnelleres und billigeres Speichergerät, das beim Neustart alle Daten verliert und daher als "kurzlebig" bezeichnet wird.

Bei dieser Frage geht es darum, diese Art von Speicher in Installationen der Oracle-Datenbank zu nutzen. Was zerfällt in:

  1. Was ist eine Möglichkeit, die Datendateien eines Tabellenbereichs im kurzlebigen Speicher zu halten und Oracle diese beim Booten erstellen zu lassen (und möglicherweise einige Skripte auszuführen, um einige Tabellen zu erstellen / zu füllen) und in Ordnung zu sein, wenn sie verloren gehen.
  2. Was wären die Auswirkungen auf Sicherungen (es sollte keine Sicherung der kurzlebigen Daten geben).
  3. Jede andere mögliche Überlegung für Tabellen und andere Objekte darüber

    • Mögliche Optimierungen: zB Protokollierung deaktivieren.
    • Was geht bei einem Neustart verloren (Daten oder Daten + Metadaten)

Der TEMP-Tablespace ist ein perfekter Kandidat für diese Optimierung, und tatsächlich gibt es für das Äquivalent von MS SQLServer im Web Howtos, um genau dies zu tun.

Betrachten wir ein Data Warehouse als Referenzanwendungsfall mit einem wiederkehrenden Job, der viele Gigabyte Daten (aus CSVs oder Datenpumpen) in ein Staging-Schema "STG" und einen nachfolgenden ETL-Prozess importiert, der die Ergebnisse im Produktionsschema speichert.

Diese Arbeitslast würde sehr davon profitieren, wenn der Lese- und Schreibzugriff auf das Staging-Schema sehr schnell erfolgt und die Volatilität seiner Daten leicht toleriert wird.


Gute Frage! Man kann einen Tablespace sicherlich offline schalten, siehe docs.oracle.com/cd/B28359_01/server.111/b28310/tspaces005.htm. Ich vermute jedoch, dass der einfachste Weg, dies zu automatisieren, darin besteht, die Tablespaces vor dem Herunterfahren der Oracle-Instanz zu löschen. Dann gibt es die Frage, was bei einem Maschinenabsturz passieren würde. Ich bin eher ein "logischer DBA", daher überlasse ich es einem "physischen DBA", diese Frage zu beantworten.
Colin 't Hart

Können Sie hierfür einen Anwendungsfall angeben?
David Aldridge

@DavidAldridge: Jede Oracle-Bereitstellung in der Amazon Cloud ist ein Anwendungsfall.
Andrea Ratto

Antworten:


2

Oracle zeichnet keine Prüfpunktinformationen in tempfile auf. Also, für das tempfile:

  1. Oracle kann auch dann gestartet werden, wenn tempfile fehlt. Sie erhalten eine Nachricht im Änderungsprotokoll und sollten tempfile neu erstellen.

  2. Tempfile wird nicht gesichert, daher ist es sicher, es zu verlieren

  3. Es ist nicht erforderlich, mit einem Speicherparameter für tempfile zu tricksen, wenn sich dieser in einem kurzlebigen Speicher befindet.

Über physische Datenstruktur sind keine temporären Dateien, es ist nicht sicher, sie in den kurzlebigen Speicher zu legen. Oracle verfolgt Änderungen in der Datendatei, auch wenn Sie die Protokollierung deaktiviert haben. Das Deaktivieren der Protokollierung wirkt sich nur auf die Wiederherstellbarkeit der Datenbank, das Wiederherstellen und die Gesamtleistung aus. Erlaubt Ihnen nicht, Datendateien kurzlebig zu speichern. Das Öffnen der Datenbank mit einer fehlenden Datenbank (die Datenbank kümmert sich nicht darum, wie wichtig Daten darauf waren) wird ausgelöst.

ORA-01116: error in opening database file %s
ORA-27041: unable to open file
ORA-01157: cannot identify/lock data file %s - see DBWR trace file
ORA-01119: error in creating database file '%s'

Und Sie müssen das Problem manuell behandeln. Daher muss die Verwendung von kurzlebigem Speicher mit normaler Datendatei vermieden werden.


Vielen Dank. Denken Sie also, dass es ausreicht, nur einen temporären Tabellenbereich auf obersten Tempfiles im kurzlebigen Speicher zu erstellen? Nach einem Neustart hat es nur alle leeren Tabellen oder verliert es auch das Schema?
Andrea Ratto

@AndreaRatto Temporärer Tabellenbereich enthält keine Tabelle, sondern nur vorübergehende (temporäre) Objekte wie GTT (Global Temporary Table), und Daten müssen beispielsweise in einem DML-Prozess sortiert werden. Es gibt kein SCHEMA in temporären Tabellen oder anderen Standardobjekten.
Ste

2

Wie Ste in seiner Antwort sagt, sollten temporäre Tablespaces dafür in Ordnung sein, daher wären globale temporäre Tabellen und andere vorübergehende Speicher gut.

Wenn Sie permanente Tablespaces verwenden möchten, können Sie DROP TABLESPACE my_tablespace INCLUDING CONTENTS AND DATAFILES CASCADE CONSTRAINTSvor dem Herunterfahren des Systems den Speicher verlieren und beim Start neu erstellen. Sie möchten wahrscheinlich beim Start etwas haben, um den Verlust der Datendateien zu behandeln, wenn das RDBMS sie nicht selbst entfernt hätte.


Der Start nach einem Misserfolg ist der schwierige Teil, keine Zweifel ...
Andrea Ratto

Ja, ganz so - natürlich sollte ein DB-Startup konventionell ein ziemlich seltenes Ereignis sein.
David Aldridge

1

Zusätzlich zu dem, was die anderen gesagt haben, können Sie einige Daten in flachen Dateien aufbewahren und sie beim Start in den kurzlebigen Speicher kopieren. Sie können dann über externe Tabellen darauf zugreifen . Ich weiß nicht, ob dies schneller oder besser wäre, aber es ist eine andere mögliche Verwendung.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.