[GELÖST]Sperrung Tabelle Artikelposten immer Dienstags...

Guten Morgen,

wir haben hier ein Phänomen was ich mir nicht erklären kann. Immer Dienstags zwischen 08:00Uhr und 09:00Uhr wird die Tabelle Artikelposten durch einen anderen Benutzer gesperrt.
Wir können in NAV nichts mehr buchen. Keine Warenausgänge, keine Lagerbewegungen oder Wareneingänge.

Es läuft um die Zeit keine SQL Sicherung, kein Bestell- oder Planungsvorschlag, auch kein Mahnlauf.
Habe sogar den Vertrieb dazu gebracht in der Zeit Dienstags nie einen VK Auftrag anzulegen oder unser Einkauf Bestellungen.

Dennoch kommt diese Meldung mit der Artikelpostentabelle.

Habt ihr eventuell eine Idee wie ich eingrenzen kann und herausfinden wodurch das verursacht wird?

Ich wollte diese Sache mal ausprobieren. Habe auf Mibuso bzw. Google Suche gefunden

Decisions 2010 - NAV/SQL - Blocks & Deadlocks

https://mibuso.com/downloads/decisions- ... -deadlocks

https://dynamicsuser.net/nav/b/stryk/po ... sql-server

Habe die Skripte 1 bis 3 erfolgreich ausgeführt.

Bei dem Skript 4 kommt als Meldung (0 Zeilen(n) betroffen)
Ist ein Zeichen dafür, dass der Code nicht richtig ausgeführt wurde, oder?

Code:

USE msdb
GO

declare @instance varchar(128), @perfcon varchar(256)
if @@servicename = 'MSSQLSERVER' -- Standard-Instance
  set @instance = 'SQLServer'
else -- Named Instance
  set @instance = 'MSSQL$' + @@servicename
set @perfcon = @instance + N':General Statistics|Processes blocked||>|0'

EXEC sp_add_alert @name=N'SSI: Block Detection',
  @message_id=0,
  @severity=0,
  @enabled=1,
  @delay_between_responses=10,  -- 10 seconds; requires Registry change
  @include_event_description_in=0,
  @performance_condition= @perfcon,
  @job_name=N'SSI: Block Detection'
GO

USE master
GO

Der Navisiondienst läuft als Dienstname als: MSSQL$NAV15

Muss im Skript eventuell etwas angepasst werden?

Wie geschrieben, bin sonst für Anregungen offen wie man den "Übeltäter" herausfinden kann.
Danke
Beste Grüße
Robert

Zuletzt geändert von Raban am 4. Juni 2019 09:06, insgesamt 2-mal geändert.

Es läuft um die Zeit keine SQL Sicherung, kein Bestell- oder Planungsvorschlag, auch kein Mahnlauf.

Auch nicht über die Projekt- bzw. Aufgabenwarteschlange (oder wie die noch in NAV 2015 hieß)?
Dort müsste sich doch bestimmt eine wiederkehrende Aufgabe für Dienstags 8 Uhr finden lassen?

Hallo,

ist der SQL-Server eine virtuelle Maschine?
Falls ja, könnte eine Sicherung der VM's das System blockieren.

Nicht richtig eingerichtete Virenscanner werden auch immer wieder gerne für solche Blockaden genommen.

Gruß Fiddi

Was sagt denn der SQL-Aktivitätenmonitor in der Zeit. Da gibt es eine Spalte mit "Blockiert durch..." (o.ä.)

Guten Morgen,

im SQL Aktivitätsmonitor war alles im Leerlauf. Aufgabenwarteschlangen standen auch alle auf Bereit.
Der NAV Server ist eine VM. Eine Sicherung zu diesem Zeitpunkt erfolgte nicht.

Mit "Decisions 2010 - NAV/SQL - Blocks & Deadlocks" wie im ersten Beitrag geschrieben habe ich den Übeltäter gefunden.

Wir verwenden für Auswertungen JetReports 2019. Immer Dienstags um 08:00Uhr startet (jetzt nicht mehr ) ein Report was uns den Mengenumsatz der letzten 2 Geschäftsjahren Monatsweise aus der Tabelle Artikelposten rausholt.
Da wir Daten aus 6 Mandanten auswerten dauerte der Report eben ca. 50min.

Man greift mit JetReport nur lesend auf die Datenbank zu. Warum die Tabelle so lange der Report läuft, gesperrt wird muss ich jetzt mit dem Hersteller klären. Meiner Meinung nach ist das ein Bug.
Man verändert mit dem lesenden Zugriff ja keine Daten.

Ich hätte aber wirklich nicht dran gedacht, dass JetReports der Übeltäter ist.

Vielen Dank für eure Anregungen.

Beste Grüße
Robert

Ich hätte aber wirklich nicht dran gedacht, dass JetReports der Übeltäter ist.

Nicht zufällig ersetzen manche Konzerne aus dem D-A-CH Raum das "gute" Jet Reports step by step durch PowerBI oder durch Qlick View.
Mehr Infos nur per personal message

...Meiner Meinung nach ist das ein Bug.
Man verändert mit dem lesenden Zugriff ja keine Daten.

Das kommt auf das sogenannte Isolation Level an.
Wenn man "Read Committed" verwendet, sperrt ein SELECT auf dem SQL Server standardmäßig die Tabelle während des Lesevorgangs.