MSSQL/ADO + 3 Mio Datensätze , Thread Error

[bernhard_LA]

unser fatales Problem hat folgende technische Kennwerte

1. DB Server : MSSQL, Prof. Version
2. Delphi : XE2, ADO, x64
3. Datenbank : 10 Tabellen
4. Dateivolumen 800 Mbyte
5. Index Volumen 200 Mbyte
6. Anzahl der Datensätze in der Größten Tabelle ~ 3 Mio

Unsere Anwendung liefert ein Thread Fehler beim Einfügen von weiteren Datensätzen in die DB. Mit dem MS Datenbank Tool kann man die DB öffnen und manuelle Abfragen durchführen.
Client Hardware : WIN7 Prof, x64 , Speicher 16 Gbyte RAM (hier sollte kein Problem vorliegen)

[arnof]

die Größe stellt kein Problem dar und geht sogar mit MSSQL Express .....

Das Problem ist hier woanders zu suchen.

Wie lautet denn der Fehler genau ? ADO Meldung oder eine von Delphi ?

[p80286]

Zitat:

Zitat von bernhard_LA (Beitrag 1261918)

Unsere Anwendung liefert ein Thread Fehler beim Einfügen von weiteren Datensätzen in die DB.

Nur so aus Neugierde, welchen Fehler denn?

Gruß
K-H

[jensw_2000]

Zitat:

... liefert ein Thread Fehler beim Einfügen von weiteren Datensätzen in die DB

Daten Abfragen geht also? Performance OK oder läuft die Abfrage ggf. ins Query Timeout?
Ist ein Insert über das SQL-Managementstudio oder andere DB Tools möglich oder kommt dort auch ein Fehler?
Wie sieht das Zeitverhalten aus, wenn eure Anwendung versucht Datensätze einzufügen?

[bernhard_LA]

mit diesem kleinen Testprogramm können wir den Fehler aus der richtigen Anwendung nachbilden :

Delphi-Quellcode:

unit Unit_openADOTable;

interface

uses
  Winapi.Windows, Winapi.Messages, System.SysUtils, System.Variants, System.Classes, Vcl.Graphics,
  Vcl.Controls, Vcl.Forms, Vcl.Dialogs, Vcl.StdCtrls, Data.DB, Vcl.ExtCtrls,
  Vcl.Grids, Vcl.DBGrids, Data.Win.ADODB;

type
  TForm1 = class(TForm)
    ADOTable1: TADOTable;
    ADOConnection1: TADOConnection;
    DBGrid1: TDBGrid;
    Panel1: TPanel;
    DataSource1: TDataSource;
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

procedure TForm1.Button1Click(Sender: TObject);
var  Servername, Databasename, TableName : String;
    DatabaseStr: String;
begin

  Servername := 'mssql_server';
  Databasename := 'databasename';


  ADOConnection1.Connected := False;

  ADOConnection1.LoginPrompt := false;

  DatabaseStr :=
    'Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Data Source='
    + Servername + ';Initial Catalog=' + Databasename + ';';
  ADOConnection1.ConnectionString := DatabaseStr;

  ADOConnection1.Connected := True;

  ADOTable1.Active := true;
end;

end.

[baumina]

Ich würde mal Serverseitig nachschauen ob es eine Fehlermeldung gab. (Logdateien o.ä.)

[Sir Rufo]

Hast du da ein nvarchar Feld in der Tabelle mit mehr als 127 Zeichen?

http://stackoverflow.com/questions/1...22561#14222561

Kannst du nicht per ADO mit dem Native Client zugreifen?
siehe auch hier: http://msdn.microsoft.com/de-de/library/ms130978.aspx

[p80286]

Wie wäre es mit

Delphi-Quellcode:

ADOConnection1.Connected := True;
ADOTable1.Active := false;
ADOTable1.Active := true;

@Sir Rufo
dieser Multistep-murks wird auch durch Abfragen verursacht:

Code:

Select 'Ich habe '||count(Database5.Tablell234.id_vondengeschlossenendatensaetzen)||' Datensätze in meiner DB und noch ein paar Zeichen mehr'

Wenn man den Feldnamen verkürzen kann, hat man eine chance, daß es funktioniert.


Gruß
K-H

[jobo]

Zitat:

Zitat von bernhard_LA (Beitrag 1261946)

Delphi-Quellcode:

  ADOTable1.Active := true;

Muss man denn unbedingt eine Table-Komponente mit 3 Mio Datensätzen öffnen können?
Wie wärs mit einer Query?
MaxRecords steht auf 0?
Filter gesetzt?

Gerade für Insert eher keine Table-Komponente nehmen?
Am besten nie eine Table-Komponente nehmen.

[p80286]

Zitat:

Zitat von jobo (Beitrag 1261963)

Zitat:

Zitat von bernhard_LA (Beitrag 1261946)

Delphi-Quellcode:

  ADOTable1.Active := true;

Muss man denn unbedingt eine Table-Komponente mit 3 Mio Datensätzen öffnen können?
Wie wärs mit einer Query?
MaxRecords steht auf 0?
Filter gesetzt?

Gerade für Insert eher keine Table-Komponente nehmen?
Am besten nie eine Table-Komponente nehmen.

Recht hast Du,
aber in allen Beispielen, die ich gesehen habe, wird fröhlich mit Tables und Datasets herum gespielt.
wahrscheinlich wissen die wenigsten welche Möglichkeiten eine Query beinhalted.

Aber das Nutzen einer Query wird sein Problem ja nicht lösen sondern nur umgehen.

Gruß
K-H

[jobo]

Zitat:

Zitat von p80286 (Beitrag 1261965)

Aber das Nutzen einer Query wird sein Problem ja nicht lösen sondern nur umgehen.

Je nach Settings der anderen Properties hat er vlt. gar keine Chance, die Table zu öffnen bzw. sie dadurch vollständig einzulesen.

Wenn ich mit dem Sportwagen immer aus der Kurve fliege, weil ich immer die Höchstgeschwindigkeit nutzen will, muss ich mich wohl zwangsläufig mit einem Workaround anfreunden.

Vielleicht muss er mindestens für die Fehlersuche eine Query verwenden. Wenn z.B. es nicht um die Datenmenge, sondern um die Inhalte geht (z.B. schrottige Datumswerte, .. was ADO eben so nicht mag).
Man kann natürlich auch im Management Studio oder anderen Tools nach Range Verletzungen suchen.

[Dejan Vu]

Die DFM wäre noch interessant. Ist die Tabelle bereits geöffnet? Und ist sie überhaupt mit der Connection verbunden, oder hat sie einen eigenen ConnectionString?

Welche ADO-Version ist installiert? Das mag eine antiquierte Frage sein, aber man weiss ja nie.

Hier wird beschrieben, das das Problem behoben wurde, als die Datenmenge eingeschränkt wurde. Vielleicht also mal nicht alle 3 mio recs laden. Was soll das eigentlich?

[arnof]

Tadotable ist nicht direkt für große Datenmengen geeignet!

Benutze hie mal das maxrecords property!



1. schaue mal im taskmanager ob deine Anwendung nicht die 2 Gb grenze erreicht !

2. benutze mal tadoquery mit Top in der selectanweisung

Select Top 1000 * from wasauchimmer

Dann gibt es die coursortypen mit denen Spielen kann....

[bernhard_LA]

unser rowcount steht auf 2598000 records ..... dann kippt die Anwendung, hat diese Zahl eine Bedeutung ?

[mkinzler]

Der Speicherbedarf wird höchstwahrscheinlich sinken. Den eine T<xx>Table auf eine Tabelle in einem DBMS ist ein Query mit

SQL-Code:

select * from <Tabelle>;

[jobo]

Zitat:

Zitat von bernhard_LA (Beitrag 1261982)

unser rowcount steht auf 2598000 records ..... dann kippt die Anwendung, hat diese Zahl eine Bedeutung ?

Das ist nicht ernst jetzt?
a) 2598000 ist 1 mehr als 2597999
b) die Zahl, die geteilt durch den Speicherbedarf pro Datensatz maximal in Deinem System/Programm verarbeitet werden kann.
c) der Record, in dem Schrott steht und dadurch den Treiber ins Nirvana schickt.

Solche und ähnliche Antworten hast Du jeweils schon mehrfach erhalten.
Du könntest Dich mal damit auseinander setzen und negative oder positive Ergebnisse zurückmelden oder nach Testmöglichkeiten fragen, wenn Dir nicht klar ist, wie es gemacht wird. Oder die diversen Fragen nach den verwendeten Einstellungen beantworten.

[bernhard_LA]

sorry, habe die letzte Antwort nicht verstanden :

Zitat:

die Zahl, die geteilt durch den Speicherbedarf pro Datensatz maximal in Deinem System/Programm verarbeitet werden kann

a) welches System , der Client oder der MSSQL Server ??
b) wo bekomme ich weitere Infos her ??

[mkinzler]

Nein, Du willst es nicht verstehen!

[Dejan Vu]

Der Sarkasmus hinter der Antwort war auch subtil.

Was jobo damit sagen wollte:
1. LIES DIR DIE ANTWORTEN NOCHMAL DURCH.
2. Schau Dir den Speicherplatzverbrauch auf deinem PC an
3. Verwende eine TADOQuery und lies nicht alles ein (wozu?)
4. Verwende zum Zählen der Datensätze 'select count(*) as Anzahl from Tabelle', wobei das auch etwas dauert.

5. Warum 3 Mio Datensätze einlesen?
6. Und wieso werden 3 Mio Datensätze im Client benötigt?
7. Wer schaut sich die 3 Mio Datensätze eigentlich an?
8. Gibt es keine bessere, schnellere, resourcenschonendere Möglichkeit, das, was Du mit den 3 Mio Datensätzen vorhast, zu lösen?

[arnof]

Zitat:

Zitat von bernhard_LA (Beitrag 1261995)

sorry, habe die letzte Antwort nicht verstanden :

Zitat:

die Zahl, die geteilt durch den Speicherbedarf pro Datensatz maximal in Deinem System/Programm verarbeitet werden kann

a) welches System , der Client oder der MSSQL Server ??
b) wo bekomme ich weitere Infos her ??

Dein Speicher reicht nicht aus schau in den taskmanager es ist nicht alles 64 Bit :!:

Und man läd nun mal nicht alle Daten aus der SQL Datenbank, das war zu Bde Zeiten ( die hat das nur virtuell gemacht)

[jensw_2000]

Zitat:

Zitat von Dejan Vu (Beitrag 1262013)

7. Wer schaut sich die 3 Mio Datensätze eigentlich an?
8. Gibt es keine bessere, schnellere, resourcenschonendere Möglichkeit, das, was Du mit den 3 Mio Datensätzen vorhast, zu lösen?

Genau das ist auch für mich das Punkt.
Niemand kann die Daten in einem Grid mit 3 Mio Datensätzen sinnvoll erfassen und nutzen. Es hat daher keinen Sinn, einem Menschen die komplette Datenmenge zu präsentieren. Ergo braucht man sie auch nicht aus der DB abrufen.
Mit ein wenig SQL kannst man dem Benutzer gruppierte und aggregierte Daten liefern, die den kompletten Datenhaushalt der abfragen, aber nur die "Fakten" in den Client transportieren.
Das Gruppieren und Aggregieren kann der SQL Server schnell und problemlos erledigen. Der Client jedoch nicht.

[bernhard_LA]

Die Tatsache, dass wir in unserer Anwendung einige Sachen "suboptimal" implementiert haben, war mir auch schon vor diesem Betrag bekannt und dies ist auch nicht mein Thema


Ich habe über Nacht eine Testbankenbank auf unserem MSSQL Server eingespielt mit 12 MIO Datensätzen, d.h. die Aussage Irgend eine 32 Bit Speichergröße geteilt durch die Größe eines Datensatzes ergibt die Anzahl der max. Records kann ich so nicht nachvollziehen.

[mkinzler]

Zitat:

Die Tatsache, dass wir in unserer Anwendung einige Sachen "suboptimal" implementiert haben, war mir auch schon vor diesem Betrag bekannt und dies ist auch nicht mein Thema

Warum wird das dann nicht geändert?

Zitat:

Ich habe über Nacht eine Testbankenbank auf unserem MSSQL Server eingespielt mit 12 MIO Datensätzen, d.h. die Aussage Irgend eine 32 Bit Speichergröße geteilt durch die Größe eines Datensatzes ergibt die Anzahl der max. Records kann ich so nicht nachvollziehen.

Für das DBMS ist das kein Problem, es ist aber eines wenn man versucht, die 3 (oder 12) MIO Datensätze in ein Grid anzuzeigen.
Dadurch werden die Daten dann (teilweise) redundant im Arbeitsspeicher des Clients gehalten. Vorher verstopfen diese das Netzwerk, da sie ja auch übertragen werden müssen.
Wieviel Hauptspeicher hast du?

[bernhard_LA]

der Client hat aktuell 32 GByte Arbeitsspeicher, Win 7 x64 ..... ; Für ~ 1000 Euro könnte ich kurzfristig weiter 64 GByte auf unserem Client nachrüsten und hätte mein Problem für einige Zeit gelöst / nach hinten geschoben;


Kann ich mir mit dieser Strategie "Zeit verschaffen" oder muss ich sofort den Code anpacken?

[himitsu]

Das ist egal. Wenn der Client nur 32 Bit ist, dann kann der nunmal standardmäßig nur 2 GB (optional 3, bzw fast 4 GB) verwalten
und das auch, wenn im Rechner real nun 1 GB RAM verbaut sind. (siehe Auslagerungsdatei)


Es gibt aber auch DB-Komponenten und Grids, welche die Daten nicht alle sofort laden müssen, sondern nur einen (relevanten) verschiebbaren Teil,
so daß man in dem Grid dann auch 300 Mio. Datensätze anzeigen könnte, wenn es unbedingt sein muß.
Gut, sowas wie Sortierung und Filterung geht dann im Grid natürlich nicht mehr, da ja nicht alle Daten "aktuell" verfügbar sind.
(Das ist wie beim HxD, welcher, bei Anzeige der des RAM- oder HDD-Inhalts, auch nicht alles lädt, sondern nur den aktuell sichtbaren Bereich)

[Bernhard Geyer]

Zitat:

Zitat von bernhard_LA (Beitrag 1262037)

der Client hat aktuell 32 GByte Arbeitsspeicher, Win 7 x64 ..... ; Für ~ 1000 Euro könnte ich kurzfristig weiter 64 GByte auf unserem Client nachrüsten und hätte mein Problem für einige Zeit gelöst / nach hinten geschoben;

Du hast das Problem nicht gelöst. Du versucht es durch unpassende Mittel zu umgehen.
Und solange deine erstellte Exe nicht 64-Bittig ist bringt dir das ehe nix.

Zitat:

Zitat von bernhard_LA (Beitrag 1262037)

Kann ich mir mit dieser Strategie "Zeit verschaffen" oder muss ich sofort den Code anpacken?

Das ist keine Strategie. Das ist planloses handeln.
Mit 32 GB RAM kann man heutzutage problemlos ein ganze Automodell im CAD-System laden. Und du schafft es nicht damit ein popelige Tabllendarstellung zu realisieren.

Ein Workaround wäre u.U. den Curser den Table-Komponente auf clUseServer zu stellen um ein paar Tage zeit zu haben. das so anzupassen das du nicht alle Datensätze in den Clientspeicher list. Man muss aber bedenken das dieser SErverseitige Curser Last auf den Server erzeugt.

[p80286]

Zitat:

Zitat von bernhard_LA (Beitrag 1261918)

unser fatales Problem hat folgende technische Kennwerte

1. DB Server : MSSQL, Prof. Version
2. Delphi : XE2, ADO, x64
3. Datenbank : 10 Tabellen
4. Dateivolumen 800 Mbyte
5. Index Volumen 200 Mbyte
6. Anzahl der Datensätze in der Größten Tabelle ~ 3 Mio

Unsere Anwendung liefert ein Thread Fehler beim Einfügen von weiteren Datensätzen in die DB.

Hallooooo,
das Problem taucht beim Einfügen auf!

Eigentlich ist hier nur ein

Code:

input into Mytable (Fld1...Fldx) values(....)

vonnöten (TAdoQuery .Execute). Da muß keine Tabelle geladen werden!


Gruß
K-H

[bernhard_LA]

Zitat:

Und solange deine erstellte Exe nicht 64-Bittig ist bringt dir das ehe nix.

unsere *.exe ist x64 !


Unsere Analyse zeigt : Das Programm kippt bereits beim Versuch eine TADOTable zu aktivieren (

Delphi-Quellcode:

MyAdoTable.active := true

) , bis zur Anzeige der Daten im Grid kommen wir erst gar nicht.
Damit bin ich auch nicht in der Lage in einer Query einen Befehl "select * from MyTable" abzuschicken, damit ist ein Lösungsweg absolut nicht klar

[mkinzler]

Du sollst auch auf die Table verzichten und per Query, die Daten holen, welche Du benötigst! Und nur die!!! Das für Deinen Anwendungsfall falsche Verhalten selber nachzubilden ist ja auch nicht besser!

[bernhard_LA]

Zitat:

Du sollst auch auf die Table verzichten und per Query, die Daten holen, welche Du benötigst! Und nur die!!! Das für Deinen Anwendungsfall falsche Verhalten selber nachzubilden ist ja auch nicht besser!

Eurer Idee habe ich schon verstanden , nur führt die leider nicht zum Ziel.
:cry:


Meine Anwendung ist ganz gut vergleichbar mit einem CAD Programm, wenn der Anwender auf den "Male Gegenstand auf Bildschirm, z.b. einen Pkw "
Button drückt dann läuft intern "select * from Tabelle"; soll ich beim Zeichnen des Autos die Reifen dann weglassen ????

[p80286]

Zitat:

Zitat von bernhard_LA (Beitrag 1262069)

Meine Anwendung ist ganz gut vergleichbar mit einem CAD Programm, wenn der Anwender auf den "Male Gegenstand auf Bildschirm, z.b. einen Pkw "
Button drückt dann läuft intern "select * from Tabelle"; soll ich beim Zeichnen des Autos die Reifen dann weglassen ????

Nein sollst Du nicht, aber wenn Du nur die Reifen ändern willst, dann interessiert sich niemand für die Kabelbäume.
Du solltest ggf. mal etwas weiter ausholen was Du erreichen willst, und welche Daten Du hast. Solange Du darauf bestehst 3Mio Datensätze einzulesen, woher kommen die überhaupt?, drehen wir uns nur im Kreis.

Gruß
K-H

[Mikkey]

Zitat:

Zitat von bernhard_LA (Beitrag 1262069)

Meine Anwendung ist ganz gut vergleichbar mit einem CAD Programm, wenn der Anwender auf den "Male Gegenstand auf Bildschirm, z.b. einen Pkw "
Button drückt dann läuft intern "select * from Tabelle"; soll ich beim Zeichnen des Autos die Reifen dann weglassen ????

Nein, aber das Motorrad...

Warum lässt Du in "intern" nicht 'Select * from Tabelle Where <gehört zum Gegenstand>" ablaufen. Es ist kaum vorstellbar, dass wirklich 3 Millionen Bestandteile zu einer Zeichnung gehören.

[bernhard_LA]

sorry Jungs : das Hinterfragen ob ich wirklich 3 Mio Datensätze brauche ist sinnlos, es sind heute in unserem Problem-Projekt 3 Mio records - können aber auch mal deutlich mehr werden;

Delphi-Quellcode:

   //  von ~ 10 Records   bis zu 10 Mio ....  alles ist technisch möglich
   ///    
   aquery.sql.add ('select* from database where material = 'Alu'');


   aquery.open; 

   LoopIndex := aquery.recordCount  
  for i:= 0 to LoopIndex do
      begin

         ReadSinglerecordFromTable; 

         CopySingleRecordIntoObjectList;
      
         aquery.next;   //  ist natürlich auch enthalten :-)  
     end; 

   //  die ObjectList darf nur durch den verfügbaren Hauptspeicher am Computer begrenzt sein
   //  ich brauche alle Daten in der Liste !!!!!!!
   
   MachwasMitderObjectList;

   
   SchreibeObjectListInTabelleZurück,

[mkinzler]

Das ist nicht dein Ernst, Du liest 3+ Mio Datensätze ein, nur zu ermitteln wieviel es sind?

:shock:

Delphi-Quellcode:

aQuery.Sql.Text := 'select count(*) from database where material = :material;';
aQuery.Paramters.Params[0].asString := 'Alu';
aQuery.Open;
LoopIndex := aquery.Fields[0].asInteger;

sollte das Selbe machen nur halt schenller und mit minimalen Speicherverbrauch!!!

[himitsu]

Delphi-Quellcode:

   //LoopIndex := aquery.recordCount
  //for i:= 0 to LoopIndex do
  while not aquery.EOF do
      begin

         ReadSinglerecordFromTable;

         CopySingleRecordIntoObjectList;

         aquery.Next;

     end;

Für das Query ist das kein Problem, denn dem kann man ja sagen, daß es die Daten noch im Datenbankserver belassen soll und nur nach und nach die "benötigten" Records nachladen soll.
Aber mit deiner Liste kannst du dennoch an die Grenzen des lokalen Arbeitsspeichers stoßen.

Und nee, im Grunde braucht man die Liste nicht, wenn man die RecNo's der Datensätze nimmt und dann auf das Query zugreift.

[mkinzler]

Wobei ja auc h interessant wäre, was ReadSinglerecordFromTable() genau macht

[bernhard_LA]

Zitat:

Aber mit deiner Liste kannst du dennoch an die Grenzen des lokalen Arbeitsspeichers stoßen.

ist schon klar , darum bin ich auch bereits 32, 64 oder wenn denn sein muss 128 GByte RAM zu spendieren, ich bekomme halt die Krise wenn der ADOTable, ADOQuery .... mir ohne "Workaround" Optionen einen Strich durch die Rechnung machen.

Zitat:

Wobei ja auch interessant wäre, was ReadSinglerecordFromTable() genau macht

ganz einfach :


procedure ReadSinglerecordFromTable()
begin

aClass := TDatabaseClassContent.create;

CopyDBRecord (aClass ); // die meisten Felder der Klasse werden hier 1:1 aus der DB gefüllt

BerechneWas; // ein paar Sachen muss ich aber noch separat berechnen

end;

[-=ZGD=-]

Ich würde das ja mit

Code:

LIMIT

lösen.

Du kannst dir den Count() der Daten holen und dann den Index immer weiter verschieben. Das ist um einiges besser als x-Millionen Datensätze zur gleichen Zeit..

Edit: MSSQL hat keinen Limit-Befehl wie MySQL, richtig? :-(

Das könnte dir weiterhelfen: http://stackoverflow.com/questions/9...0-in-sqlserver


Schlagt mich nicht, wenn ich auf der falschen Fährte bin..

[Jumpy]

Zitat:

Zitat von bernhard_LA (Beitrag 1262085)

Zitat:

Aber mit deiner Liste kannst du dennoch an die Grenzen des lokalen Arbeitsspeichers stoßen.

ist schon klar , darum bin ich auch bereits 32, 64 oder wenn denn sein muss 128 GByte RAM zu spendieren, ich bekomme halt die Krise wenn der ADOTable, ADOQuery .... mir ohne "Workaround" Optionen einen Strich durch die Rechnung machen.

Zitat:

Wobei ja auch interessant wäre, was ReadSinglerecordFromTable() genau macht

ganz einfach :


procedure ReadSinglerecordFromTable()
begin

aClass := TDatabaseClassContent.create;

CopyDBRecord (aClass ); // die meisten Felder der Klasse werden hier 1:1 aus der DB gefüllt

BerechneWas; // ein paar Sachen muss ich aber noch separat berechnen

end;

Das klingt aber nun auch so, das die Daten zeitweilig doppelt im Speicher des Clients liegen, einmal in der Query und dann noch in den 3 Mio. daraus erstellten Objekten.

Wäre es da nicht einfacher sich mit der ursprünglichen Query nur die IDs zu holen und die CopyDBRecord Prozedur entsprechend anzupassen, dass die sich nur den jeweils einen Datensatz mit der aktuellen ID aus der DB holt?

[pertzschc]

Zitat:

Zitat von mkinzler (Beitrag 1262082)

Wobei ja auch interessant wäre, was ReadSinglerecordFromTable() genau macht

Das lesen eines Datensatzes wahrsscheinlich. Bei 3 Mio. würde ich die Laufzeit der Schleife gerne mal sehen.

Wobei dann weiterhin interessant wäre, was MachwasMitderObjectList(); genau macht...:)