Partition erstellen mit Hindernissen

B

Benutzer0000

Benutzer
Beiträge
13
[MS SQL Server 2012]

Hallo Community,

ich habe ein mehr oder weniger großes Problem...
Wenn ich nun versuche Partitionen mit dem SQL Server 2012 von einer Tabell zu erstellen, teilt er anhand der Boundary's die Daten nicht richtig auf. (Aufteilung der Datensätze: Date Column)
Suche bereits seit Tagen nach einer Lösung, werde aber nicht fündig...

Wenn ich z.B. nun 500.000 Datensätze mit dem Datum 2008 habe und dann weitere Datensätze mit dem Datum von 2009 hinzufüge, dann Packt er die Datensätze trozdem in das Feld "<= 12-31-2008"

Ich verstehe die Logik hier hinter nicht ... hat jemand von euch eine Idee, woran dies liegen könnte?
Laut Bild sollte das Feld 2012 vier Datensätze haben, das Feld 2010 sollte sieben Datensätze haben und 2009 sollte 18 Datensätze und nicht ¿13? Datensätze haben ...

fcyh5ixe.png


MFG Benutzer0000
 
Werbung:
Benutzer0000 schrieb:
[MS SQL Server 2012]

Hallo Community,

ich habe ein mehr oder weniger großes Problem...
Wenn ich nun versuche Partitionen mit dem SQL Server 2012 von einer Tabell zu erstellen, teilt er anhand der Boundary's die Daten nicht richtig auf. (Aufteilung der Datensätze: Date Column)
Suche bereits seit Tagen nach einer Lösung, werde aber nicht fündig...
Zum Vergrößern anklicken....

Ich nix M$SQL, aber vielleicht hilft Dir ja http://www.mssqltips.com/sqlservertip/2888/how-to-partition-an-existing-sql-server-table/ weiter.
 
Ich hab noch nie ne Tabelle partitioniert, soviel Daten hab ich gar nicht :)

Sieht auch erstmal richtig aus nur wunder ich mich etwas über die Schreibweisen. Ist der Boundary Wert wirklich mit DATE vergleichbar? Wenn ich in einem WHERE lastdat >= 12/31/2010 prüfe bekomme ich auch Datumswerte vor dem 31.12.2010. Wenn ich aber WHERE lastdat >= '2010-31-12 00:00:000' prüfe funktioniert es. Ist jetzt DATETIME, wird sich aber vermutlich ähnlich verhalten.
 
Bei der Partitionierung, bzw. beim Datumsformat Date, DateTime und DateTime2 ist es egal ob ich '2010-31-12' mit Uhrzeit eingebe oder ohne, dies ist in meinem Fall auch egal, da ich nur "Date" verwende.
Die Boundary wurde automatisch generiert(über die Schaltfläche 'Set Boundaries...' (nicht oben abgebildet)), wenn man die range eingegeben hat, weswegen ich erwarte, das die Eingabe Richtig ist

MFG Benutzer0000
 
Good point. Vieleicht hilft es sich mal den TSQL Code für die Partitionierung anzuschauen, müsste im Managementstudio möglich sein.
 
Hier ist der TCode der entsteht, doch wird dieser Code das richtige tun oder wird er die Daten auch nur so aufteilen, wie es auch die Anzeige wiedergibt? Ich bin mir da nicht wirklich sicher ....

Code: 
USE [HISTORIE]
    GO
    BEGIN TRANSACTION
 
        CREATE PARTITION FUNCTION [function1](date) AS RANGE LEFT FOR VALUES (N'2008-12-31', N'2009-12-31', N'2010-12-31', N'2011-12-31', N'2012-12-31')
 
        CREATE PARTITION SCHEME [scheme1] AS PARTITION [function1] TO ([Historie_2008], [Historie_2009], [Historie_2010], [Historie_2011], [Historie_2012], [PRIMARY])
 
        ALTER TABLE [dbo].[Tabelle] DROP CONSTRAINT [PK_Tabelle]
 
        ALTER TABLE [dbo].[Tabelle] ADD  CONSTRAINT [PK_Tabelle] PRIMARY KEY NONCLUSTERED
        (
            [ID] ASC
        )WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
 
        CREATE CLUSTERED INDEX [ClusteredIndex_on_scheme1_635113970066053750] ON [dbo].[Tabelle]
        (
            [DATUM]
        )WITH (SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF) ON [scheme1]([DATUM])
 
        DROP INDEX [ClusteredIndex_on_scheme1_635113970066053750] ON [dbo].[Tabelle]
 
    COMMIT TRANSACTION
 
Hallo zusammen,

nach ein paar Wochen Urlaub kanns dann wieder losgehen :D.
Zu den Angabe im Thread ist mir nur folgenden aufgefallen: nach meinem Wissen muss der Primary-Key der zu partitionirenden Tabelle auch die Spalte enthalten, über die patitioniert werden soll. (In diesem Falle also nicht nur die ID, sondern auch das Datum). Der PKey wird im SQL-Server als geclusterter Index gesehen und behandelt. Die Partitionierungs-Aufteilung nur über einen zusätzlichen Index über das Datum reicht für eine korrekte Verteilung in die Dateigruppen (bei bestehenden Tabellen) wol nicht aus.

Dazu muss ich jedoch sagen, dass ich dies in dieser Form ebenfalls noch nicht genutzt habe und ich somit keine echten Erfahrungswerte habe. Aber vielleicht hilfts ja trotzdem.

Hierzu auch noch ein paar Links:
http://technet.microsoft.com/de-de/library/ms190787.aspx
http://technet.microsoft.com/de-de/library/ms187802.aspx
http://technet.microsoft.com/de-de/library/ms179854.aspx
http://www.flip-design.de/?p=129


Viele Grüße,
Tommi
 
Ich bin auf die Lösung des Problems gekommen, bzw. mein Kollege hat zufälligerweise einen Satz gelesen der auf der MS Seite stand. Die Werte die der Wizard anzeigt, werden nicht berechnet sondern geschätzt ... sprich, diese Werte sind einfach erdacht.
Das MS dies nicht in Rot beim Wizard schreiben kann ~.~

Ich habe jedenfalls, testweise 2 Tabellen Partitioniert und mit einem Kollegen eine kleine Funktion schnell erarbeitet, die uns die Anzahl der Rows von jeder einzelnen Partition ausgibt.
Und diese Werte stimmen mit der Ausgabe meiner kleinen Funktion überein.

Vielen danke für eure Hilfe und euer nettes entgegenkommen =)

MFG
 
Werbung:
Wie es aussieht schon, den nach der Partitionierung sind genau die Anzahl Daten vorhanden, die ich mit meinen Abfragen angegeben sind und das auf den Zähler genau.
Das hat mich die Tage auch ganz schön verwirrt und hat mir auch viel Zeit gekostet.
Wären meine Englischkenntnisse besser gewesen, wäre es glaube ich nicht passiert ^-^ (wegen dem Wort: "estimate")

MFG
 

Ähnliche Themen

M
Umsatzstatistik
Antworten
1
Aufrufe
5K
akretschmer
akretschmer
R
Sicht erstellen CAST
Antworten
4
Aufrufe
5K
Ramon
R
Zurück
Oben