Irmgard

ok. Danke erst einmal für alle Antorten. Dass Tabellen ohne PK eine ernsthafte Alternative sind, verwirrt mich allerdings schon ein wenig :) Ich kläre weiteres mit den Server-Admins. Wartungspläne und so. Gruß Irmgard

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

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

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

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

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

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

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