Nachträglich Primärschlüssel in Tabelle anlegen

[Irmgard 0]

Hallo

 

ich sitze hier vor einer MS-SQL Datenbank mit einer Tabelle ohne PK.

Da das eine größere Sache wird, wollte ich mal um Rat fragen, in welche Fallen ich möglichst nicht tappen sollte.

 

SQL Server 2008 R2, läuft in einer VM

 

Datenbank: 11GB

Tabelle, um die es geht: 10GB

Es ist eine Protokoll-Tabelle, d.h. es wird immer nur angefügt, nichts gelöscht oder geändert.

 

Mein Plan wäre, ein AUTOINCREMENT-Feld hinzuzufügen.

FILLFACTOR auf 100 setzen oder etwas geringer?

 

Wieviel freier Festplattenplatz sollte zur Verfügung stehen? Und hat jemand Erfahrung, wie lange man die Füße (Finger) stillhalten soll und ab wann man sich anfangen muss, Sorgen zu machen, wenn der Server nicht mehr mit einem redet?

Es wird ja ein clustered index werden, da hat der SQL-Server schon ein bissl zu schreiben.

 

Den Wert für die Dateivergrößerung von Data würde ich dabei auch gleich hochsetzen, Der steht momentan auf 1MB. Was wäre sinnvoll - 50MB?

Hab geschaut: aktuell gibt es so 1-5 Vergrößerungen aller 2-3 Tage. Aber es muss auch Zeiten mit mehr Bewegung geben, sonst wäre die Tabelle nicht so groß.

 

Wiederherstellungsmodell ist einfach. Vollsicherung + Differential-Sicherung. Wird das log dann trotzdem erst einmal volllaufen bei der Index-Erstellung?

 

Solche Sachen wie: Wie sind die INSERTS in die Tabelle aufgebaut? Mit feld-Liste oder nur mit values in der entsprechenden Reihenfolge? hab ich schon an die Leute weitergegeben.

 

An was müsste ich sonst noch denken? Oder braucht  ihr noch irgendwelche Infos?

 

für Hinweise wäre ich echt dankbar.

 

Gruß

Irmgard

 

 

[wiri 10]

Hi

Den Fillfactor setze ich immer auf 90. Daneben habe ich eine Procedur die mir pro Tabelle einbezogen Wachstumsfaktor, Keylänge den passenden Factor einträgt inkl Padindex.

Mit dem Wert Dateivergrößerung  nimm 10% als festen Wert, also keine 10% sondern den berechneten Wert.

Wird die Tabelle auch ausgelesen?

[Irmgard 0]

Moin

 

10% - auch wenn die Datenbank 11GB groß ist? Um das file ggf. um 1GB zu vergrößern, braucht der Server bestimmt eine ganze Weile.

 

Und ja, die Tabelle wird auch gelesen. Eventuell kommt da noch ein zusätzlicher Index drauf, muss mir dann mal die Abfragen anschauen.

Von den bisherigen Feldern ist aber nix dabei, was in Kombination von 2 oder 3 etwas eindeutiges ergeben würde.

 

Danke und Gruß

Irmgard

[Sunny61 806]

Nein, keine prozentuale Erhöhung, sondern immer nur feste Werte nehmen. Um wieviel MB wächst denn die DB pro Tag/Woche? Wie ist die Vergrößerung des LOG eingestellt? Wieviele Temp-DBs hast Du? Wie ist bei den Temp-DBs die Vergrößerung eingestellt? IMHO sollte die DB vielleicht nur einmal in der Woche vergrößert werden müssen, deshalb lieber etwas mehr eintragen als täglich mehrmals die DB vergrößern lassen.

[Irmgard 0]

Moin

 

die letzten Wochen waren es ca 3-5 MB / Woche. Aber wie schon gesagt, es muss auch mal mehr sein, denn sonst wäre die Tabelle nicht so groß. Gelegentlich gibt es mass-Updates, die landen dann auch in dieser Protokoll-Tabelle. Aber soweit reicht der Bericht über die automatischen Dateivergrößerungen nicht zurück.

 

Das log ist aktuell 685 MB groß, der größte Teil davon nicht verwendet. Dateivergrößerung ist beim log auf 10% eingestellt.

 

Es gibt eine tempDB,  ist aktuell 109 MB groß, Dateivergrößerung dort steht jeweils auf 10%.

Anfangsgröße 8MB.

Gelegentlich wird der SQL-Server mal neu gestartet, dann landet das ja wieder auf dem Anfangswert - oder?

 

 

lg

Irmgard

[Sunny61 806]

Die 10% Regel ist die schlechteste Variante von allen, konfigurier die Größe auf feste Werte. Die eingestellten Werte überleben natürlich den Serverneustart.

 

In der model-Datenbank kannst Du die 'harten' Werte vorgeben, das hilft bei Datenbanken die neu angelegt werden, durch ein Restore angelegte oder kopierte Datenbanken greift das nicht.

[Irmgard 0]

Joar, die 10% kommen weg.

neue Datenbanken wird es dort vorerst nicht geben.

 

Sorry, nochmal zur ersten frage: wieviel Festplatten-Platz werd ich brauchen, um in die 10-GB-tabelle noch ein Feld einzufügen + clustered index?

und dauert das eher Stunden oder Minuten?

 

Gruß

Irmgard

[ukulele 11]

Darf ich fragen warum du INT mit auto_increment einsetzen willst und nicht GUID?

 

Was soll der PK auf der Tabelle bewirken, wofür ist er da?

[Irmgard 0]

Warum sollte man ohne Not eine GUID als PK einsetzen?

Da die Datensätze fortlaufend reinkommen, ist eine aufsteigende ID der beste Plan.

 

Gruß

Irmgard

[Sunny61 806]

Warum sollte man ohne Not eine GUID als PK einsetzen?

Da die Datensätze fortlaufend reinkommen, ist eine aufsteigende ID der beste Plan.

Lies doch mal diesen Artikel: http://db-berater.blogspot.de/2015/04/guid-vs-intidentity-als-clustered-key.html

Und ja, ich hab das aus dem Artikel schon live gesehen. ;)

[Irmgard 0]

ah ok. Guter Hinweis.

In meinem Fall sind es eher 20 als 200 gleichzeitige Zugriffe. Also mehr als 20 dürfte eher sehr selten vorkommen. Checke ich aber nochmal.

Aber in dem Fall wäre IDENTITY mit Länge  INT dann doch vorzuziehen, wegen geringerer Schlüssel-Länge, wenn ich es richtig verstanden habe.

 

An Datenbank-Wartung läuft da bis jetzt noch gar nix. Das muss ich mir auch noch ansehen.

 

Gruß

Irmgard

[Sunny61 806]

Und wenn es irgendwann mal 200 oder mehr gleichzeitige Zugriffe sind? Lieber gleich auf Zukunft aufbauen als in 2 Jahren wieder anfangen. ;)

[ukulele 11]

Es sind ja nicht nur Faktoren Speicherplatz und Index Performance (die ich tatsächlich nicht gut selbst einschätzen kann) sondern auch Dinge wie Datenimport / Export. Daher erstmal die Eingangsfrage, was soll dein PK tun? Deine Wahl halte ich nicht für schlecht und mir fehlt selbst etwas das Gefühl für so große Tabellen aber es geht nichts gegen eine vernünftige Zielsetzung und die interessiert mich einfach :-) Vieleicht ist auch kein PK die schnellste Lösung...

[Irmgard 0]

Mehr als 200 gleichzeitige Zugiffe zum Schreiben wird es in absehbarer Zeit definitiv nicht geben.

Mit hoher Wahrscheinlichkeit auch noch nicht einmal mehr als 20.

Sollte der Fall tatsächlich einmal in 5 oder 10 Jahren eintreten, dann nicht mehr mit diesem System und dieser Serverkonfiguration.

 

Gruß

Irmgard

Was soll der PK tun:

irgendann in den kommenden 3 Jahren sind zB die Speicherfristen von 10 Jahren abgelaufen.

Dann müssen die ersten Datensätze gelöscht werden.

Das kann man nach Datum selektieren, klar.

Ich habe aber keine Vorstellung davon, wie lange das dann bei einer vermutlich 20-30 GB großen Tabelle ohne PK dauern wird und habe das Gefühl, dass das kein guter Plan sein wird.

 

Es wird passieren, dass doch einmal ein paar einzelne Datensätze zwischendurch gelöscht werden müssen.

Es gibt keine Kombination von Feldern, die eine eindeutige Identifikation eines Datensatzes ermöglichen. Also wenn, dann vielleicht alle. Oder rowindex() ermitteln. full tablescan bei momentan ~10 mio Datensätzen dauert schon eine Weile.

 

Um ein paar Abfragen zu beschleunigen, sollten noch 1 oder 2 vernünftige indexe erstellt werden. Dazu brauche ich auch einen PK.

 

Gruß

Irmgard

[zahni 554]

Ein PK ist sicher aus Design-Gründen immer zu empfehlen. Mit der Performance hat er aber nur indirekt etwas zu tun. Auf einem PK wird immer vom System ein Index angelegt.

Wenn Du aber z.B. gefiltert nach einem Datum einen Datensatz löschen willst, nützt Dir dieser Index überhaupt nichts. Der würde nur helfen, wenn DU z.B.

delete from mytable where PK=12345; ausführen willst.

 

Besser ist es, die Queries zu analysieren und dazu passende Indizes zu erstellen. Das macht der Entwickler. Wenn der es nicht kann, bleibt es am DBA hängen ;)

Bei MS SQL hilft Dir der "Database Engine Tuning Advisor"