Kompilieren mit Force von Tabelle 113

Hi zusammen, wir haben aktuell das Problem auf dem Testsystem, dass wir die Tabelle Sales Invoice Line nicht kompiliert kriegen. Es dauert ewig (der aktuelle Versuch läuft gerade über 30 Minuten) und irgendwann sieht man im SQL Activity Montior nur noch den Hinweis "Killed / Rollback" zu der Session.

Was bisher geschah:
Wir haben auf dem DEV-System in der Tabelle ein neues Code-Feld erstellt, Code 20.
Das haben wir dann geändert in Text 20. Dazu haben wir in NAV programmiert, dass wir den Inhalt erst wegsichern in einer Wegsicherungs-Tabelle, die wir nur dafür erstellt haben, dann den Feldinhalt in der Originaltabelle leeren und der Plan war, die Daten aus der Wegsicherungstabelle wieder in die Originaltabelle zu bekommen. (Man könnte dafür natürlich auch Extras - Datenupgrade verwenden, aber die Funktion ist bei uns gerade nicht gut verwendbar, da sie in der Vergangenheit etwas sehr intensiv genutzt wurde und wir jetzt in verschiedenen Objekten Funktionen haben, die darüber ausgeführt würden, die man mal bereinigen müsste. Ich weiß, das ist blöd, aber technisch sehe ich im vorgenannten Vorgehen mit der selbst erstellten Tabelle und den Skripten zum Hin- und Herschaufeln aber auch keinen Fehler.)
Auf dem DEV-System war das Feld in der Tabelle noch nie gefüllt und das kompilieren ist dort kein Problem. Allerdings hatten wir da in der Vergangenheit (nur auf DEV!) auch schonmal Probleme beim Kompilieren, weswegen wir dort einmal alle Datensätze heraus gelöscht hatten, sodass wir aktuell nur 5 Datensätze dort haben. Auf dem Testsystem haben wir über 40 Millionen Datensätze.
Wenn man die Tabelle jetzt jedenfalls versucht, normal zu kompilieren, nachdem man die Anpassung mit Text 20 eingespielt hat, erscheint der Fehler, dass deleted data gefunden worden ist und man möge doch die Datenupgrade-Funktion nutzen. Wir kompilieren anschließend stattdessen mit Force; die Daten haben wir ja manuell weggesichert.
Das Kompilieren mit Force dauert dann allerdings ewig und irgendwann sieht man wie oben erwähnt, dass die Session bei Killed/Rollback steht. Im Entwicklungsclient kommt dabei die Meldung "A connection to SQL Server is no longer usable".

Wir haben in der Tabelle keine zusätzlichen SQL-Trigger. Wir haben allerdings neben 19 NAV-Schlüsseln auch 5 SQL-Indizes. Wenn man im SQL Activity Monitor mal schaut, was getan wird, wenn der so lange hängt, ist das folgender CreateIndex-Befehl:

Code:

IF (SELECT INDEXPROPERTY(OBJECT_ID(N'"dbo"."UnsereFirma$Sales Invoice Line"'), N'$1', 'IndexId')) IS NOT NULL DROP INDEX "$1" ON "dbo"."UnsereFirma$Sales Invoice Line"; CREATE UNIQUE NONCLUSTERED INDEX "$1" ON dbo."UnsereFirma$Sales Invoice Line" ("Blanket Order No_","Blanket Order Line No_","Document No_","Line No_"); IF (SELECT INDEXPROPERTY(OBJECT_ID(N'"dbo"."UnsereFirma$Sales Invoice Line"'), N'$3', 'IndexId')) IS NOT NULL DROP INDEX "$3" ON "dbo"."UnsereFirma$Sales Invoice Line"; CREATE UNIQUE NONCLUSTERED INDEX "$3" ON dbo."UnsereFirma$Sales Invoice Line" ("Sell-to Customer No_","Type","Document No_","Line No_");

(nur ein Auszug, das geht dann noch bis $15)

Das neue Feld kommt in keinem der Indizes vor. Ich weiß auch nicht, warum es unbedingt nötig ist, die Tabelle mit Force zu kompilieren und dabei alle Indizes neu aufzubauen. Eigentlich könnten theoretisch ja auch alle Code-Werte so in dem Feld, das in Text geändert wird, stehen bleiben, aber da ist NAV scheinbar etwas kleinlich.

Wir hatten jetzt auch schon die Stage einmal komplett neu aufgebaut auf der Backup-Basis vom Produktivsystem, weil ich zunächst das Feld nicht geleert hatte, sondern gedacht hab, dass ich das einfach über das Force mache, aber auch mit vorherigem Leeren des Feldes und erst anschließendem Force (von dem ich mir gehofft hatte, dass ich es mir hätte sparen können) klappt es immer noch nicht.

Zum Abbruchzeitpunkt habe ich noch folgende Meldung im Eventlog vom Server, auf dem das beim Kompilieren genutzte ServiceTier läuft, gefunden:

Code:

Server: BMSQLI03\SQLI03
State: 0
Source: .Net SqlClient Data Provider
ErrorCode: -2146232060
Message: Execution Timeout Expired.  The timeout period elapsed prior to completion of the operation or the server is not responding.
StackTrace:
     at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
     at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
     at System.Data.SqlClient.TdsParserStateObject.ReadSniError(TdsParserStateObject stateObj, UInt32 error)
     at System.Data.SqlClient.TdsParserStateObject.ReadSniSyncOverAsync()
     at System.Data.SqlClient.TdsParserStateObject.TryReadNetworkPacket()
     at System.Data.SqlClient.TdsParserStateObject.TryPrepareBuffer()
     at System.Data.SqlClient.TdsParserStateObject.TryReadByte(Byte& value)
     at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)
     at System.Data.SqlClient.SqlCommand.RunExecuteNonQueryTds(String methodName, Boolean async, Int32 timeout, Boolean asyncWrite)
     at System.Data.SqlClient.SqlCommand.InternalExecuteNonQuery(TaskCompletionSource`1 completion, String methodName, Boolean sendToPipe, Int32 timeout, Boolean& usedCache, Boolean asyncWrite, Boolean inRetry)
     at System.Data.SqlClient.SqlCommand.ExecuteNonQuery()
     at Microsoft.Dynamics.Nav.Runtime.NavSqlConnection.<>c__DisplayClass12`1.<ExecuteFunction>b__11()
HResult: -2146232060
----------------------------------
Type: System.ComponentModel.Win32Exception
NativeErrorCode: 258
ErrorCode: -2147467259
Message: The wait operation timed out
HResult: -2147467259

Hab ich das richtig verstanden, vor dem Einspielen des geänderten Tabellenobjekts und Kompilieren mit Force habt ihr den Feldinhalt auch gelöscht? Wenn ihr nur durch "Force" löscht dann würde ich das mal versuchen. Wenn es die Schlüssel sind, dann könntest du auch vor dem Kompilieren mit Force mal alle Schlüssel außer dem Primärschlüssel deaktivieren.

Ja genau, erster Versuch war Feldinhalt löschen durch Force, zweiter Versuch war Feldinhalt vorher löschen direkt anschließend an das Skript, das auch die Datensätze wegsichert. Schlüssel deaktivieren würdest du in NAV machen oder auf SQL-Ebene?

Schlüssel deaktivieren würdest du in NAV machen oder auf SQL-Ebene?

Ich bin NAV'ler und habe keine Ahnung von SQL, also immer NAV
Wäre halt ein Versuch, weil das timeout beim CreateIndex kommt. Es sind ja auch viele Millionen Datensätze.

Da steht die Ursache:

Code:

Message: Execution Timeout Expired.  The timeout period elapsed prior to completion of the operation

Auf dem NST ist das SQL-Timeout zu gering.

Wir haben bei uns auch sehr sehr viele Daten in einigen Tabellen, so dass wir selber schon vor dem Problem standen.
Aus dem Grund haben wir spezielle DEV-NSTs für die Datenbanken aufgesetzt, bei denen das SQL-Timeout auf 3 Stunden gesetzt ist.
Wenn wir also nach einem Update die Schema-Synchronisation starten müssen, machen wir das immer nur
a) per Remote-Desktop direkt auf der Maschine des DEV-NST
b) per PowerShell-Command auf dem speziellen DEV-NST

Seit dem haben wir keine Probleme mehr mit Timeouts.

(Die "normalen" Anwender gehen immer über die "normalen" NSTs.)

Ok, danke, wir haben das Timeout hoch gestellt und dann ging es.

Wie macht ihr das denn bei Updates? Die Anwender können, während das läuft, NAV nicht benutzen, oder? Das heißt, man hätte eine lange Downtime? Wir haben nur gar kein Zeitfenster mehr, zu dem nicht mit NAV gearbeitet wird, wir können es deswgen auch nicht einfach Nachts anstoßen o.ä.

Wie macht ihr das denn bei Updates?

Wir haben bei uns ein festes Zeitfenster definiert, in welchem die Anwender nicht mit dem ERP-System arbeiten können/dürfen.
Da die Anwender sich ja die Anpassungen gewünscht haben und diese auch in der Produktiv-Datenbank haben möchten, ist die Akzeptanz für diese regelmäßige Downtime sehr hoch.

Bei uns ist dieses Zeitfenster "jeden Dienstag ab 17:00 Uhr".
Ich persönlich könnte mir auch vorstellen, dass man nur einmal monatlich ein Update in die Produktiv-Datenbank spielt, aber unsere Anwender sind dafür zu ungeduldig und nehmen daher lieber die wöchentliche Downtime am Dienstag Abend in Kauf.

Wenn ihr rund um den Globus Niederlassungen habt, die auf dieselbe(!) Datenbank zugreifen müssen, dann empfiehlt es sich, nur einmal monatlich ein planmäßiges Update durchzuführen.
Als Zeitfenster solltet ihr dann einen Zeitraum wählen, in dem die wenigsten Anwender betroffen sind.
(Extremste Variante: Die Nacht von Samstag auf Sonntag, da arbeiten - global betrachtet - die wenigsten Personen.)

[Edit]
Wenn ihr verschiedene Datenbanken für verschiedene Länder bzw. Regionen habt, vereinfacht sich die Ermittlung eines für die Region/das Land passendem Zeitfensters natürlich.
Dann könntet ihr die Updates der Datenbanken auch an unterschiedlichen Tagen/Uhrzeiten durchführen.
In unserem Fall dauert das wöchentliche Update ca. eine Stunde. Bei umfangreichen Updates (z. B. mit Schema-Änderungen in Tabellen mit extrem vielen Datensätzen) kann es auch schonmal zwei Stunden dauern.

Ok danke, dann suchen wir mal ein Zeitfenster. Wir machen auch wöchentliche Updates, aber die dauern meist nur wenige Minuten bis max. 30 Minuten.

Wir machen auch wöchentliche Updates, aber die dauern meist nur wenige Minuten bis max. 30 Minuten.

Anfangs dauerten unsere Updates auch nur 10-20 Minuten, bis irgendwann einmal nach einem Update von der Test- in die Live-Datenbank am nächsten Morgen keiner mehr in NAV arbeiten konnte, obwohl jede einzelne Anpassung von den jeweiligen Key-Usern in der Test-Datenbank getestet und explizit für den Transport (mittels "Object Manager Advanced") freigegeben wurde.

Es stellte sich heraus, dass durch einen Bedienungsfehler im OMA-Transport nicht alle Objekte der auszuliefernden Projekte exportiert wurden, so dass Funktionen aufgerufen wurden, die gar nicht existierten.
Das wäre alles nicht so schlimm gewesen, wenn es an dem Abend des Updates aufgefallen wäre, denn dann hätte man es ja noch lösen können.

Seit diesem Vorfall machen wir nach dem Update in die Live-Datenbank immer einen Szenarientest, bei dem die unternehmensnotwendigen Prozesse auf Funktionsfähigkeit und Richtigkeit (mit einem Testkunden sowie Testartikeln) getestet werden.
Daher dauert ein Update bei uns in der Regel 45-60 Minuten. Wir haben es aber auch mal (inkl. vollständigem Szenarientest) in unglaublichen 20 Minuten geschafft.

Es stellte sich heraus, dass durch einen Bedienungsfehler im OMA-Transport nicht alle Objekte der auszuliefernden Projekte exportiert wurden, so dass Funktionen aufgerufen wurden, die gar nicht existierten.
Das wäre alles nicht so schlimm gewesen, wenn es an dem Abend des Updates aufgefallen wäre, denn dann hätte man es ja noch lösen können.

Kompiliert ihr die Objekte nach dem Import in der Ziel-DB nicht? Denn beim Kompilieren wären die Objektunstimmigkeiten sofort aufgefallen. Was noch dem Import der Objekte noch machen sollte: die Subscriber kontrollieren, ob diese den Haken "Aktiv" haben und wenn diese keinen Haken haben dann nachforschen warum nicht (es kann sein dass es bereits "alte" nicht als aktiv markierte Suscriber in der DB drin waren aber wenn nach dem Objektimport neue nicht aktive hinzukommen -> müßte man nachforschen).

Kompiliert ihr die Objekte nach dem Import in der Ziel-DB nicht? Denn beim Kompilieren wären die Objektunstimmigkeiten sofort aufgefallen.

In den alten NAV-Versionen (<= NAV 5.0 bzw. NAV 2009 ohne RTC/NST) war das nicht nötig, da es ja noch keine Object Metadata gab.
Die zwingende Erforderlichkeit zum Kompilieren nach dem Objektimport entstand ja erst mit den Metadata.
Seit der Umstellung von NAV 5.00 auf NAV 2017 werden selbstverständlich alle importierten Objekte nochmals kompiliert und sollte bei dem Import mindestens ein MenuSuite-Objekt enthalten sein, werden anschließend nochmal alle MenuSuites kompiliert.

Was noch dem Import der Objekte noch machen sollte: die Subscriber kontrollieren, ob diese den Haken "Aktiv" haben und wenn diese keinen Haken haben dann nachforschen warum nicht

Danke für den wertvollen Hinweis, das hatten wir bisher noch nicht auf dem Radar und werden es in Zukunft im Auge behalten.

In den alten NAV-Versionen (<= NAV 5.0 bzw. NAV 2009 ohne RTC/NST) war das nicht nötig, da es ja noch keine Object Metadata gab.
Die zwingende Erforderlichkeit zum Kompilieren nach dem Objektimport entstand ja erst mit den Metadata.

Object Metadata hin oder her: ich meine primär folgendes (und was auch Euch passiert ist): wenn ich ein Objekt importiert habe, in welchem irgendwas angesprochen wird, was gar nicht da ist (z.B. ein Feld in der Tabelle welches noch fehlt, weil die Tabelle nicht mitimportiert wurde), dann sieht man beim F11 doch sofort was noch fehlt / sich nicht kompilieren läßt ==> und genau deshalb sollte man immer kompilieren, egal in welcher NAV-Version, also auch <=5.0

Hallo,

und genau deshalb sollte man immer kompilieren, egal in welcher NAV-Version, also auch <=5.0

Das sehe ich eigentlich genauso.

Alles andere führt zu Leichen im Keller, die irgendwann mal wieder zu einem ganz ungünstigen Zeitpunkt wieder auftauchen.

Gruß Fiddi