Löschen großer Datenbanken

[bernhard_LA]

mit diesem Code

Delphi-Quellcode:

    with MyQuery do
    begin
      Close;
      SQL.Clear;
      SQL.Add('delete from ');
      SQL.Add(TableName);
      TADODataSet(MyQuery).CommandTimeout := TimeOut;
      ExecSQL;
      result := true;
    end;
  except
    result := false;
  end;

komme ich bei großen Datenbanken nicht immer zum Erfolg. Gibt es eine Lösung in n-Abfragen immer nur einen kleinern Teil zu löschen, geht vielleicht sogar dann insgesamt schneller ?

[franktron]

Stored Proc ?

[bra]

Wenn du eine Datenbank löschen willst, kannst du das mit drop database machen. Wenn du dagegen Tabellen in einer Datenbank löschen willst, solltest du die Überschrift anpassen.

[Bambini]

beim MS SQL kannst du die Tabellen - ohne Prüfungen - mit TRUNCATE löschen
https://msdn.microsoft.com/de-de/lib...=sql.120).aspx

[himitsu]

Zitat:

Löschen großer Datenbanken Tabellen

Trigger, Indize usw. deaktivieren?

Parameter?
https://xkcd.com/327/

[nahpets]

Definiere bitte, was Du unter dem Löschen einer Datenbank verstehst.

Die Datenbank löschen - also alles: drop database

Tabellen löschen: drop table

Inhalte von Tabellen löschen: delete from tabelle

Inhalte von Tabellen unwiderruflich löschen: truncate table

Bei Delete werden die Löschungen erstmal ins Rollbacksegment geschrieben, da die Datenbank ja nicht weiß, ob am Ende statt des Commit doch ein Rollback kommen könnte.

Truncate macht das nicht: Was weg ist ist weg.

[jobo]

moderne RDBMS sind per default sehr darauf getrimmt, den Tagesbedarf zu erledigen. Insert, Update, Select
Delete gehört nicht dazu.
Sie bieten u.U. konfigurationsprofile an, die das Löschen im großen Stil beschleunigen.
Die Standardbremse sind aber idR wie schon tw. geschrieben:
Indizes nachpflegen, aufräumen
Das Logging der Löschung für Rollback.
ref.Konstraints prüfen, verfolgen, u.u. noch mehr Löschen in abhängigen Tabellen.
Trigger, die irgendwas harmloses machen (wenn nur alle 3 Tage ein Satz gelöscht wird, z.B. "lieber noch mal in Datei schreiben, bevors ganz gelöscht wird und noch gebraucht wird")

Dann gibt's noch exotischere Sachen, die vielleicht im Rauschen untergehen.
Locks, die im Löschprozess verwickelt sind. Entweder von fremden Zugriffen oder sogar von eigenen (Selbstreferenz).

Was davon zutreffen könnte, kannst Du sicher am besten selbst beurteilen.

[Sir Rufo]

Um eine Datenbank in den Auslieferungszustand zu bringen lösche ich die ganz einfach, erstelle diese wieder und lasse dann die Scripts drüber laufen, bis ich auf der Zielversion der Datenbank bin.

Das geht ganz unkompliziert und auch schnell.

[nahpets]

Zitat von Sir Rufo:

Um eine Datenbank in den Auslieferungszustand zu bringen lösche ich die ganz einfach, erstelle diese wieder und lasse dann die Scripts drüber laufen, bis ich auf der Zielversion der Datenbank bin.

Das geht ganz unkompliziert und auch schnell.

Und das Schöne daran ist: Man hat einen klar definierten Zustand und nicht nur hoffentlich alles korrekt aufgeräumt und damit dann den erhofften Zustand.

[jobo]

Naja, was der TE zu Anfang postet ist nicht die Löschung einer DB, sondern einer Tabelle.
Da er hier noch irgendwo einen Thread rumfliegen hat, wo es um irgendwas mit großen Tabellen geht (50 Mio), kann ich mir gut vorstellen, dass er hier beim Testen auf die Problematik des Löschens von Testdaten gestoßen ist. Oder verwechsele ich das?
Und zum Thema Legendenbildung:
Wenn ich eine DB habe und 5 Tabellen reintu mit Daten und die später lösche, habe ich auch einen klar definierten Zustand. Zumindest bei halbwegs ernst zu nehmenden Systemen. Daran ändert sich auch nichts, wenn noch Trigger, Views, SP dabei sind und die auch wieder gelöscht werden.
Ich schalte ja auch nicht meinen Rechner aus, wenn ich ein Programm beendet habe, um die RAM Riegel in einen definierten Zustand zu bringen.
Und wie gesagt, falls ich die Threads bzw. den Ersteller nicht verwechsele: Wenn wirklich größere Tabellen im Spiel sind, dann ist immerhin schon mal das/die File/s angelegt. Das kann auch etwas Zeit sparen, wenn im Rahmen der Tests sowieso wieder Millionen von DS da reingeblasen werden. Das gilt besonders, wenn man sich mangels Bedarf oder Kenntnis noch nicht mit den physikalischen Einstellmöglichketen für Tabellen auseinandergesetzt hat.
Was da konkret bei MS SQL Server 2014 geht, kann ich allerdings mangels Erfahrung nicht sagen.