Tabelle entlasten - kreativer Ansatz gesucht

Hallo,

wir haben eine eigene Tabelle geschaffen, die den aktuellen Produktionsstatus eines Auftrags beherbergt.
Sie besteht aus einer Aggregierung der Arbeitsgänge = kritischer Pfad, den aktuellen Status (offen, in Arbeit, abgeschlossen), sowie einiger weiterer Informationen wie Vorgabezeiten usw.

Diese Tabelle stellt ein zentrales Element unserer Fertigung da und wird über ein in NAV umgesetztes BDE aktualisiert.

Zusätzlich benötigen wir die Daten in einem Produktionsplanungssystem zur Feinterminierung, d.h. es werden zusätzlich Exporte (Dataports) und Imports (Dataports) mit den Daten generiert.

Das Problem liegt jetzt in der Last, die die Tabelle zu bewerkstelligen hat. Durch die zentrale Funktion werden die Daten immer wieder aktualisiert, ergänzt, bereinigt, exportiert. Es kommt demnach immer wieder zu Sperrungen, insbesondere beim Exportieren der Daten (Dauer ca. 3 Min).
Den Code der Exports haben wir schon entsprechend beschleunigen können (von 10Min auf 3Min) aber jetzt ist kein wirkliches Potential mehr übrig.

Hat jemand eine Idee was wir tun können, gibt es z.B. eine Möglichkeit die Tabelle vor dem Export zu kopieren o.Ä.?

Hi,

je nach dem wie ihr auf die Daten zugreifen müsst gibt es vermutlich schon noch einiges.
Wovon ich abraten würde ist das vorherige kopieren der Daten in eine zweite Tabelle. Das kostet auch Zeit, führt zur Redundanz und muss ja später auch noch bereinigt werden.
Nutzt ihr eine SQL-Datenbank?
Wenn ja könnt ihr mal mit dem SQL-Profiler so einen Standardexport beobachten und anschliessend nach Schlüssel-Optimierungen suchen (evtl. auch nur auf SQL-Seite den Schlüssel anlegen).
Dann kannst du auch prüfen ob der Export eventuell durch die hohen Zugriffszeiten beim speichern verursacht wird und die Wahl eines anderen Speichermediums bzw einer anderen Festplatte hilft.

Hallo,

von der Idee her haben wir das schon gemacht, der Export ist recht aufwendig, da die Daten aufbereitet werden müssen. Schlüssel haben wir schon entsprechend optimiert.
Export wird auf eine zweite Festplatte direkt auf dem SQL/NAV-Server erstellt.

Weitere Ideen? :-/

Also ich werde aus der Beschreibung noch nicht so ganz schlau.

Wo wird die Abfrage ausgeführt? NAV oder SQL?
Wer führt die Abfrage aus? Client oder NAS oder sonst wie?
Was dauert 3 Minuten? Die Abfrage oder der Export?

Ganz blöd finde ich das mit der Kopie einer Tabelle ja u. U. gar nicht. Evtl. macht es Sinn bei Ausführung innerhalb NAVs mit einer temporären Tabelle zu arbeiten.
Alternativ könnte ich mir den hier nicht gerne gehörten Vorschlag der direkten SQL-Programmierung vorstellen: In allen notwendigen Tabellen im SQL-Server Datenbanktrigger für Insert und Update anlegen und genau diese Daten in eine separate Tabelle schreiben lassen. Damit ergibt sich eine Kopie der Tabelle auf der nun die Berechnungen und Exports durchgeführt werden. Währendessen bleiben die NAV-Tabellen für die User verfügbar, da hierfür keine Sperren gesetzt werden.

Volker

Der Export läuft vollständig in NAV. Wärend des Exports werden aber diverse Abfragen durchgeführt, bzw. Daten auch mehrfach ausgegeben.
Auf dem Server läuft ein Client mit "pseudo"-NAS-Funktionalität - der den Export/Import regelmäßig anstößt - auf Grund der Begrenzung des NAS = keine Dataports.

Die Dauer des Exports inkl. eingebeteter Abfragen (eigentlich sind es 3 Dataports nacheinander) dauert vom Aufruf bis zur Freigabe der Tabelle ca. 3 Min.

SQL-Programmierung wollen wir eigentlich vermeiden, diese Diskussion gibt es hier im Forum ja schon des Öfteren.

Die Temporäre-Tabellen-Idee hatten wir auch schon, jedoch haben wir bisher noch nicht damit gearbeitet bzw. in Verbindung mit Dataports ist uns die Sache nicht ganz klar was die Umsetzung angeht.

Es kommt demnach immer wieder zu Sperrungen, insbesondere beim Exportieren der Daten (Dauer ca. 3 Min).
Den Code der Exports haben wir schon entsprechend beschleunigen können (von 10Min auf 3Min) aber jetzt ist kein wirkliches Potential mehr übrig.

Also wenn es ein reiner Export ist, dann können ja keine Locks auftreten (EDIT also nicht bei Standardeinstellungen; mit dem Transaction Type "Snapshot" werden auch Sperren gesetzt). Und da liegt das Optimierungspotential. Entweder den Code der Daten ändert auslagern (damit eine Tabelle nicht für die gesamte Exportzeit gesperrt wird) oder COMMITs setzen, damit das Locking zwischendurch aufgehoben werden kann.

Aufbau Tabelle, Primärschlüssel, Alle zusätzlichen Schlüssel wären nette Angaben um zu helfen.

Mich beschleicht so das Gefühl, dass die Tabelle gar keine ist, sondern eher eine View. Außerdem stellt sich die Frage, ob die notwendigen Daten nicht auf anderem Wege übergeben werden können bzw. gar nicht übergeben werden, beispielsweise ODBC, NAS mit entsprechenden Funktionen, MSMQ oder Rohdaten-Übergbabe an eine kleines Programm, das die Daten dann extern als Datei erstellt.

Volker

Frage wäre auch, ob ein SSIS-Package in Frage käme. So rein performance-technisch.

Aber erstmal wäre es nicht schlecht konkrete Informationen zur aktuellen Implementierung zu haben. (siehe mein vorheriger Post)