none
Partitionierung einer subtable RRS feed

  • Frage

  • Hallo,

    ich habe eine Frage bezüglich der Partitionierung einer SQL Server 2005 Datenbank.

    Es gibt eine Tabelle tabData mit ca. 10000000 Zeilen. Diese wird anhand einer Datumsspalte partitioniert.
    Jetzt würde ich noch gerne eine andere "Unter-Tabelle" tabDataDetail mit ca. 36000000 Zeilen partitionieren.
    Es würde sich anbieten die gleiche Funktion und das gleiche Schema zu benutzen.
    tabDataDetail hat einen Fremdschlüssel idData der auf tabData verweist. Sie besitzt selbst aber leider nicht diese Datumsspalte.
    Muss ich jetzt in tabDataDetail die gleiche Spalte erstellen und alle Daten aus tabData importieren, um im Anschluss diese Spalte als Partitionierungsspalte festlegen zu können oder gibt es eine bessere Lösung(z.B. computed Column + user-defined function)?

    LG Tim
    Montag, 22. Februar 2010 11:39

Antworten

  • Hallo Tim,

    grundsätzlich kannst Du nur über ein Feld partionieren, das sich in der Tabelle befindet.

    Du könntest die Datumswerte aus der tabData übernehmen, nur halte ich das nicht für sinnvoll.
    Zum einen weil Du dann redundant Daten hast und ggf. die immer mit Updaten muss.
    Zum anderen macht eine Partionierung nur dann Sinn, wenn Du auch über das Feld filterst. Wird nicht darüber gefiltert, müssen alle Partitionen berücksichtigt werden und das ist mit unter langsamer als bei einer Tabelle ohne Partition.

    Du müsstest dann also alle Statements so umschreiben, das auch in tabDataDetail auf das Datum gefiltert wird.

    Da solltest Du überlegen, ob eine Partitionierung über die Id nicht besser wäre.
    Olaf Helper ----------- * cogito ergo sum * errare humanum est * quote erat demonstrandum * Wenn ich denke, ist das ein Fehler und das beweise ich täglich http://olafhelper.over-blog.de
    Montag, 22. Februar 2010 20:03
  • Ich habe nur die Standard Edition im Einsatz; also ohne Partitioning.
    Meine bisherigen Erfahrung habe ich auch nur aus Test mit der Developer Edition.

    Ich kann Dir nur empfehlen, Dich vorher einzulesen; der Artikel ist z.B. ganz gut:
    Partitioned Tables and Indexes in SQL Server 2005
    Um ein gutes, performantes Design zu erhalten, sollte man es gut durchplanen, ermitteln wie am häufigsten gefiltert wird und auch einige Tests durchführen.

    Olaf Helper ----------- * cogito ergo sum * errare humanum est * quote erat demonstrandum * Wenn ich denke, ist das ein Fehler und das beweise ich täglich http://olafhelper.over-blog.de
    Dienstag, 23. Februar 2010 13:15

Alle Antworten

  • Hallo Tim,

    grundsätzlich kannst Du nur über ein Feld partionieren, das sich in der Tabelle befindet.

    Du könntest die Datumswerte aus der tabData übernehmen, nur halte ich das nicht für sinnvoll.
    Zum einen weil Du dann redundant Daten hast und ggf. die immer mit Updaten muss.
    Zum anderen macht eine Partionierung nur dann Sinn, wenn Du auch über das Feld filterst. Wird nicht darüber gefiltert, müssen alle Partitionen berücksichtigt werden und das ist mit unter langsamer als bei einer Tabelle ohne Partition.

    Du müsstest dann also alle Statements so umschreiben, das auch in tabDataDetail auf das Datum gefiltert wird.

    Da solltest Du überlegen, ob eine Partitionierung über die Id nicht besser wäre.
    Olaf Helper ----------- * cogito ergo sum * errare humanum est * quote erat demonstrandum * Wenn ich denke, ist das ein Fehler und das beweise ich täglich http://olafhelper.over-blog.de
    Montag, 22. Februar 2010 20:03
  • Hallo Olaf,

    Danke für die Antwort.  Eine Partitionierung über die ID würde mir grundsätzlich auch entgegen kommen. Weniger Änderungen am Datenmodell und keine Redundanz .Das Problem hätte ich mit einem Trigger gelöst..  Ich dachte nur es wäre sinnvoll dass die Daten von der tabData und der tabDataDetail nach dem gleichen Schema und damit zusammen gespeichert würden(Archivierung/Performance).

    EDIT: Bei der Partitionierung über den Fremdschlüssel gibt es ja keine zeitliche Zuordnung mehr. Wieviele Filegroups legt man optimalerweise an und sollten die Daten dann gleichmässig aufgeteilt werden? Gibt es eine Richtlinie ab welcher Partitionsgröße man besser feiner aufteilen sollte und wie misst man diese(Data Pages?) ?

    Angenommen ich lege 20 Dateigruppen an und möchte jeder gleichmässig viele Daten zuweisen, wäre es sinnvoll die Grenzwerte mit folgender Abfrage zu ermitteln (Prozentwert jeweils in 5 Prozent Schritten)?

    select max(fiData) from tabDataDetail
    where
    fiData in (select top 5 percent fiData from tabDataDetail order by fiData)


    Das Thema Partitionierung ist mir relativ neu, ich bedanke mich schonmal für die Tips.

    LG Tim
    Dienstag, 23. Februar 2010 09:15
  • Ich habe nur die Standard Edition im Einsatz; also ohne Partitioning.
    Meine bisherigen Erfahrung habe ich auch nur aus Test mit der Developer Edition.

    Ich kann Dir nur empfehlen, Dich vorher einzulesen; der Artikel ist z.B. ganz gut:
    Partitioned Tables and Indexes in SQL Server 2005
    Um ein gutes, performantes Design zu erhalten, sollte man es gut durchplanen, ermitteln wie am häufigsten gefiltert wird und auch einige Tests durchführen.

    Olaf Helper ----------- * cogito ergo sum * errare humanum est * quote erat demonstrandum * Wenn ich denke, ist das ein Fehler und das beweise ich täglich http://olafhelper.over-blog.de
    Dienstag, 23. Februar 2010 13:15
  • Hallo Tim,

    Ich gehe davon aus, dass die Antworten Dir weitergeholfen haben.
    Solltest Du noch "Rückfragen" dazu haben, so gib uns bitte Bescheid.

    Grüße,
    Robert

    Montag, 1. März 2010 11:33
    Moderator