PL/SQL Verwendung von Variablen

[ten13]

Hallo zusammen,

ich habe folgendes Problem:

Regelmäßig muss ich eine Statistiktabelle erstellen. Diese heißt <tabelle>_<JAHR>_<MONAT> also z.B. Statistik_2009_2

Auf diese Tabelle setze ich verschiedene Indize und Berechtigungen.

Ist es möglich, JAHR und MONAT in Variablen zu speichern um sie in allen Statements zu verwenden?

Beispiel:

DECLARE

VAR1 number(4) := 2009;

VAR2 number(2) := 2;

BEGIN

CREATE TABLE STATISTIK_%VAR1_%VAR2 FROM (SELECT .... WHERE JAHR = %VAR1 AND MONAT = %VAR2);

CREATE UNIQUE INDEX PK_STATISTIK_%VAR1_%VAR2 ON STATISTIK_%VAR1_%VAR2;

...

...

...

GRANT SELECT ON STATISTIK_%VAR1_%VAR2 TO USER_READ_ONLY

END

Gibt es dafür irgendwelche Möglichkeiten?

Ich hoffe mir kann jemand weiterhelfen!

MfG, ten13

[dbwizard]

Hallo zusammen,

Gibt es dafür irgendwelche Möglichkeiten?

Ich hoffe mir kann jemand weiterhelfen!

MfG, ten13

- Darf ich Fragen, warum du für jeden Monat eine neue Tabelle erstellen willst ? Dies führt zu einigen Komplikationen bei den nachfolgenden Abfragen und verkompliziert die Sache nur. In solch eine Fall würde sich eine Range-Partitionierung (pro Monat) "Einer" Tabelle anbieten, welche die kompletten Daten enthält.

Gruss

[ten13]

Die Basistabelle hat ein paar Millionen Datensätze und wird stetig erweitert, weshalb die Performance darauf recht bescheiden ist.

Die monatlichen Tabellen, beinhalten nur die Datensätze (auch ein paar Millionen), die für den jeweiligen Monat von Bedeutung ist.

Deshalb handelt es sich jeden Monat um eine Copy-Paste-Angelegenheit wo nur der Monat aktualisiert werden muss.

[dbwizard]

Die Basistabelle hat ein paar Millionen Datensätze und wird stetig erweitert, weshalb die Performance darauf recht bescheiden ist.

Die monatlichen Tabellen, beinhalten nur die Datensätze (auch ein paar Millionen), die für den jeweiligen Monat von Bedeutung ist.

Deshalb handelt es sich jeden Monat um eine Copy-Paste-Angelegenheit wo nur der Monat aktualisiert werden muss.

- Eben deshalb würde ich die Tabelle pro Monat Range-Partitionieren. Wenn du den entsprechenden Monat abfragst, wird nur die betreffende Partition abgefrgt. Dies ist transparent gegenüber der Appliaktion, d.h. du musst dir Appliaktion nicht abändern. Die Lösung, für jeden Monat eine separate Tabelle zu erstellen , ist

- aufwändig

- Kostet unnötig Ressourcen

- Kompliziert das Abfragen (was machst du, wenn du einmal mehrere Monate /Ein Jahr abfragen willst ?)

- Bringt mehr Verwaltungsaufwand

Für das grundsätzliche Konzept :

Partitioned Tables and Indexes

...Basistabelle hat ein paar Millionen Datensätze und wird stetig erweitert, weshalb die Performance darauf recht bescheiden ist....

- Da würde ich mal meine Querys anschauen, "ein paar" Millionen Row's sind "nicht viel"

- na ja, wenn du es trotzdem auf "die harte" Tour machen willst :-) : Du musst für dein Problem Dynamic SQL verwenden :

http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14261/dynamic.htm#LNPLS011

Gruss

Bearbeitet 2. März 2009 von dbwizard

[ten13]

Benötige ich besondere Berechtigungen für die Partitionen? Denn falls ja, werde ich die wohl nicht haben, da unsere IT-Zentrale ziemlich kleinlich bei der Vergabe derartiger Zulassungen ist.

[dbwizard]

Benötige ich besondere Berechtigungen für die Partitionen? Denn falls ja, werde ich die wohl nicht haben, da unsere IT-Zentrale ziemlich kleinlich bei der Vergabe derartiger Zulassungen ist.

- Nein. Dies ist ja der Vorteil dieser Lösung. Wenn du die "normale" Tabelle selektieren kannst, so geht dies auch ohne einer Änderung mit einer partitionierten Tabelle. Aus Sicht Applikation verhält sich eine part. Tabelle gleich wie ein unpartitionierte Tabelle. Der Oracle Optimizer enscheidet anhand der Where Clause (Welche natürlich den Partitionig Key, hier z.b. das Datum enthalten muss), welche Partition der Tabelle gefragt ist und liest anschliessend nur aus dieser. Der Rest der Daten wird nicht einbezogen und damit hast du denselben Effekt wie deine monatlichen Tabellen, aber ohne den ganzen Overhead.

Gruss

[ten13]

Aber diese Methode würde den Zugriff auf den "unpartitionierten", sich stetig erweiternden Bereich der Tabelle, welche ohne z.B. Datum stattfindet, extrem verlangsamen, da ja die Tabelle immer größer wird?

[dbwizard]

Aber diese Methode würde den Zugriff auf den "unpartitionierten", sich stetig erweiternden Bereich der Tabelle, welche ohne z.B. Datum stattfindet, extrem verlangsamen, da ja die Tabelle immer größer wird?

- Nein. Warum sollte dies so sein ? Jeder Monat liegt in einer eigenen Partition, es gibt nicht so etwas wie einen "unpartitionierten" Bereich (Mit einer Ausnahme). Wenn du mehrere Monate in dei Abfrage einbeziehen musst, so "schaut" die DB auf die entsprechenden Partitionen, aber dies wäre ja bei der von dir ins Auge gefasste Lösung auch so, du mpsstes da die entsprechenden tabellen per Union zusammenfassen. Die Gesamtanzahl der Datensätze bleicvht ja dieselbe

Gruss

[dr.dimitri]

Hi,

also mir ist da schon was aufgefallen:

WHERE JAHR = %VAR1 AND MONAT = %VAR2

In Oracle gibt es den Datentyp DATE, den man dafür verwenden soll.

weshalb die Performance darauf recht bescheiden ist.

Die Anzahl der Datensätze ist nicht unbedingt verantwortlich für die Laufzeit. Wichtig wäre zu sehen, welche Statements denn Probleme macht und natürlich auch den richtigen Datentyp verwenden.

Wieviel Daten selektiert denn ein typisches SQL aus dieser Tabelle?

Dim

[ten13]

Hi,

also mir ist da schon was aufgefallen:

WHERE JAHR = %VAR1 AND MONAT = %VAR2

In Oracle gibt es den Datentyp DATE, den man dafür verwenden soll.

Macht es denn einen Unterschied, wenn ich nach Monaten suche, ob ich ein Monatsfeld (NUMBER) habe oder aus einem DATE ein CHAR mache? Normalerweise ist der Zugriff auf NUMBER doch wesentlich schneller, oder nicht?

[dr.dimitri]

Normalerweise ist der Zugriff auf NUMBER doch wesentlich schneller, oder nicht?

Also auf den Beweis bin ich jetzt mal gespannt aber Du darfst mich gern überraschen.

Bevor Du anfängst, solltest Du jedoch wissen, dass Oracle das Datum als 7 Byte langen Binärwert speichert - man könnte also sagen, dass das einer Zahl gar nicht mal so unähnlich wäre:D

Daher speichere ein Datum als Datum und eine Zahl als Zahl ab. Warum denkst Du gibts den Datentyp? Weil er langsamer ist? :cool:

habe oder aus einem DATE ein CHAR mache?

Genau falsch rum. Wenn das Feld ein DATE ist, dann suchst Du auch nach einem DATE. Etwa so:

WHERE datum between to_date('01.01.2009','DD.MM.YYYY') and to_date('31.01.2009','DD.MM.YYYY')

Damit hat der Optimizer eine viel genauere Vorstellung was Du denn eigentlich haben möchtest und kann dies in seine Berechnungen für den Zugriffsplan mit einbeziehen.

Keinesfalls solltest Du das Datumsfeld mit to_char in einen String umwandeln!

Dim

[ten13]

Leider sind wir etwas vom eigentlichen Thema abgekommen.

Meine Frage ist leider noch nicht beantwortet. Ist es möglich mit SQL/ORACLE

vor dem Ausführen mehrerer durch ";" getrennte Abfragen Variablen zu deklarieren und diese dann zu benutzen?

Beispiel:


var1 = blubs;

var2 = bla;

select * from a where b = var1;

select * from c where d = var2;

Vielen Dank schonmal