SQL Reads

Hallo

Ich habe mich heute wieder einmal mit dem Thema SQL und Performance beschäftigt.
Dabei bin ich nach den Empfehlungen von J. Stryk vorgegangen und habe einmal alle grösseren Reads analysiert.
Dabei habe ich gesehen, dass auf eine Einrichtungstabelle (Branchenlösung) sehr oft zugegriffen wird.
Die Anzahl Reads ist dort z.T. 16000, 14000, 15000 etc. . Die Duration aber nur so 40, 60, 50 etc.
Diese Tabelle beinhaltet etliche Blobs mit Bitmaps etc. (Ich weiss schlecht für SQL).
- Ist der Wert bei Reads deshalb so gross?
- Die Dauer sollte doch aber vernachlässigt werden können?
- Oder verstehe ich da was falsch?

Gruss

Hi!

Freut mich wenn ich "Gehör" finde

"Reads" gibt die Anzahl der Seiten (= kleinste logische SQL Zugriffseinheit = 8KB) wieder, die für eine Operation gelesen werden. Zu viele "Reads" bedeuten also einen hohen logischen I/O, damit auch erhöhte "CPU" Zeit, ggf. höhern physikalischen I/O und damit läneger "Duration".
Hohe "Reads" sind i.d.R. Anzeichen für "Index Scans" (= vollständiges/partielles Lesen der Blattebene eines Index), können aber auch andere Ursachen haben ... wie z.B. die Verwendung von BLOBS ...

Wenn man sich die "Verbrauchsdaten" von SQL Operationen ansieht, dann wird man Feststellen, dass korrekte "Index Seeks" meist nur 1-5 "Reads" benötigen, bei suboptimalen Filtern vielleicht mal ein paar Dutzend. Alles ab 1000 "Reads" ist m.E. einziemlich sicheres Zeichen für Index Probleme (und anderes).
Auch kann man alles was mehr als 20 msec CPU Zeit verbraucht als langsam definieren ...
Aber wie gesagt, meist steht eine hohe "CPU"/"Duration" immer im Beszug zu den "Reads".

Diese Artikel beschreiben weiteres:
Indexes/Profiling: http://dynamicsuser.net/blogs/stryk/archive/2010/05/20/directions-emea-2010-nav-sql-performance-indexes.aspx
Indexes/Profiling: http://dynamicsuser.net/blogs/stryk/archive/2010/02/10/technical-airlift-2009-munich-nav-sql-performance-optimization-indexes.aspx
BLOBs: http://dynamicsuser.net/blogs/stryk/archive/2009/02/12/blob-fields-with-nav-amp-sql.aspx
BLOBs: http://msdynamicsworld.com/story/business-process-mgmt/way-around-binary-hell-sql-server

Hoffe das hilft ...

Hallo Vielen Dank

In meinem Fall sind das also die BLOBS, die das Problem verursachen. In der Tabelle ist ja nur ein Datensatz.
Muss mir mal überlegen, wie ich das anders aufbauen könnte.

Gruss

In meinem Fall sind das also die BLOBS, die das Problem verursachen. In der Tabelle ist ja nur ein Datensatz.
Muss mir mal überlegen, wie ich das anders aufbauen könnte.

Eine denkbare Lösung wäre, die BLOBs in eine eigenständige Tabelle zu packen, welche ausschließlich BLOBs verwaltet.
Tabellenstruktur könnte sein:
- Code[10] (Primärschlüssel)
- BLOB
- Text[250] (für Dateiname)
- Text[30] (für kurze Anmerkung)

In der betroffenen Setup-Tabelle würde man dann anstelle der BLOB-Felder nur noch die Referenz zu dem Eintrag in der "BLOB-Tabelle" verwalten.
Somit liest der SQL-Server keine BLOB-Felder mehr, nur weil er den Datensatz in der Einrichtungstabelle benötigt.

Folge: Sämtliche Verweise auf ein BLOB-Feld dieser Einrichtungstabelle müssen dann natürlich auf die "BLOB-Tabelle" umgelenkt werden.

Also anstatt:

Code:

Setup.GET;
Setup.CALCFIELD(MeinBlob1);
// In irgendeiner PictureBox: SourceExpr: Setup.MeinBlob1

müsste dann

Code:

Setup.GET;
CLEAR(BlobRec);
IF Setup.MeinBlobCode1 <> '' THEN
  IF BlobRec.GET(Setup.MeinBlobCode1) THEN
    BlobRec.CALCFIELD(BlobFeld);
// In irgendeiner PictureBox: SourceExpr: BlobRec.BlobFeld

Dies hätte sogar den Vorteil, dass ein und dasselbe Bild mehrmals in der Datenbank referenziert werden kann, ohne es doppelt abzuspeichern.

Hallo Timo

Werde ich wohl machen müssen.
Als die Tabelle seinerzeit entwickelt worden ist, hatten wir es ausschliesslich mit NATIV-DB's zu tun. Da war das eingentlich nie ein Problem.

Aber bisher ist dies der einzige Nachteil den SQL mit sich gebracht hat.
Ansonsten ist die Performance wirklich sehr beindruckend.

Gruss

Hallo Timo

Werde ich wohl machen müssen.
Als die Tabelle seinerzeit entwickelt worden ist, hatten wir es ausschliesslich mit NATIV-DB's zu tun. Da war das eingentlich nie ein Problem.

Aber bisher ist dies der einzige Nachteil den SQL mit sich gebracht hat.
Ansonsten ist die Performance wirklich sehr beindruckend.

Gruss

Soviel ich weiß, kann der SQL-Server auch keine SIFT-Indizes mehr?

Soviel ich weiß, kann der SQL-Server auch keine SIFT-Indizes mehr?

Können schon, nur verwendet NAV diese Indizes ab 5.00 SP1 nicht mehr.
Stattdessen setzt man auf Indexed Views, welche zu demselben Ergebnis führen, jedoch performanter sind.
(Wobei ich mich ganz schwach daran erinnere, dass J. Stryk diese Aussage auch schon relativiert (jedoch nicht explizit widerlegt) hat.)

In meinem Fall sind das also die BLOBS, die das Problem verursachen. In der Tabelle ist ja nur ein Datensatz.
Muss mir mal überlegen, wie ich das anders aufbauen könnte.

Eine denkbare Lösung wäre, die BLOBs in eine eigenständige Tabelle zu packen, welche ausschließlich BLOBs verwaltet.
Tabellenstruktur könnte sein:
- Code[10] (Primärschlüssel)
- BLOB
- Text[250] (für Dateiname)
- Text[30] (für kurze Anmerkung)

In der betroffenen Setup-Tabelle würde man dann anstelle der BLOB-Felder nur noch die Referenz zu dem Eintrag in der "BLOB-Tabelle" verwalten.
Somit liest der SQL-Server keine BLOB-Felder mehr, nur weil er den Datensatz in der Einrichtungstabelle benötigt.

...

Dies hätte sogar den Vorteil, dass ein und dasselbe Bild mehrmals in der Datenbank referenziert werden kann, ohne es doppelt abzuspeichern.

Hi,
ich habe genau ein solches "Problem" ebenfalls gehabt und habe mich fuer EINE Tabelle entschieden in der X BlobFelder existieren.
Mein Gedanke war folgender:
"weniger GET und nur Calcfield, wenn ichs brauche"

Ist das den total in die Falsche Richtung gedacht?

Mein Gedanke war folgender:
"weniger GET und nur Calcfield, wenn ichs brauche"

War auch mein Gedanke.

Ist das den total in die Falsche Richtung gedacht?

Ich fürchte ja.

Gruss

Soviel ich weiß, kann der SQL-Server auch keine SIFT-Indizes mehr?

Können schon, nur verwendet NAV diese Indizes ab 5.00 SP1 nicht mehr.
Stattdessen setzt man auf Indexed Views, welche zu demselben Ergebnis führen, jedoch performanter sind.
(Wobei ich mich ganz schwach daran erinnere, dass J. Stryk diese Aussage auch schon relativiert (jedoch nicht explizit widerlegt) hat.)

Also wenn's um "SIFT vs. VSIFT" geht, dann gibt es für beide Seiten Für & Wider ... letztendlich ist aber VSIFT die aktuelle Technologie die gut & performant funktioniert (in den aktuellen Releases). Natürlich gibt's auch da ein paar Tücken, die bekommt man aber auch in den Griff.

Siehe dazu: http://dynamicsuser.net/blogs/stryk/archive/2010/05/29/optimizing-sift-and-vsift.aspx

Hi,
ich habe genau ein solches "Problem" ebenfalls gehabt und habe mich fuer EINE Tabelle entschieden in der X BlobFelder existieren.
Mein Gedanke war folgender:
"weniger GET und nur Calcfield, wenn ichs brauche"

Ist das den total in die Falsche Richtung gedacht?

Ja, denn dann muss der SQL-Server immer alle BLOBs lesen, egal welches Bild du benötigst.
(NAV sendet ja - vereinfacht gesprochen - immer einen SELECT * FROM Table...)
Verteilst du die BLOBs auf mehrere Datensätze (also pro Datensatz immer nur ein BLOB-Feld), so braucht der SQL-Server die anderen BLOB-Felder nicht lesen.

Hi,
ich habe genau ein solches "Problem" ebenfalls gehabt und habe mich fuer EINE Tabelle entschieden in der X BlobFelder existieren.
Mein Gedanke war folgender:
"weniger GET und nur Calcfield, wenn ichs brauche"

Ist das den total in die Falsche Richtung gedacht?

Ja, denn dann muss der SQL-Server immer alle BLOBs lesen, egal welches Bild du benötigst.
(NAV sendet ja - vereinfacht gesprochen - immer einen SELECT * FROM Table...)
Verteilst du die BLOBs auf mehrere Datensätze (also pro Datensatz immer nur ein BLOB-Feld), so braucht der SQL-Server die anderen BLOB-Felder nicht lesen.

danke!, dann werd ichs wohl nochmal umstellen muessen.

Hi,
ich habe genau ein solches "Problem" ebenfalls gehabt und habe mich fuer EINE Tabelle entschieden in der X BlobFelder existieren.
Mein Gedanke war folgender:
"weniger GET und nur Calcfield, wenn ichs brauche"

Ist das den total in die Falsche Richtung gedacht?

Ja, denn dann muss der SQL-Server immer alle BLOBs lesen, egal welches Bild du benötigst.
(NAV sendet ja - vereinfacht gesprochen - immer einen SELECT * FROM Table...)
Verteilst du die BLOBs auf mehrere Datensätze (also pro Datensatz immer nur ein BLOB-Feld), so braucht der SQL-Server die anderen BLOB-Felder nicht lesen.

danke!, dann werd ichs wohl nochmal umstellen muessen.

Ich denke die grundsätzliche Frage sollte sein:
"Wie oft wird auf die Tabelle zugegriffen und wie oft davon werden die BLOB's benötigt?"
Werden die BLOBs eher (relativ) selten benötigt, dann lohnt sich eine Auslagerung wohl schon. Werden die BLOBs eh permanent benötigt, dann wäre der Zugriff über einen zweiten GET wohl unsinnig ...

Der Kunde hat pro report MINDESTENS 3 Bilder. Die Tabelle hat aber nun schon min. 15 genutze Bilder.
daher kam mir der Gedanke.

Hallo,

ich möchte nur sicher sein:
gilt diese Diskussion auch dann, wenn in den Blobs (z.B. Item) keine Bilder gespeichert werden ? Abgefragt werden sie ja, aber der Inhalt ist ja Null; beeinflußt dies trotzdem die Read's ?

Vielen Dank.
Ralf

Nö, wenn die BLOBs leer sind, dann wird auch kein "Pointer" in NAV gespeichert und der SQL Server muss kein BLOB suchen ... und damit also auch kein I/O Problem erzeugen ...