nach Datenbankumzug wird der sperrende Benutzer nicht mehr angezeigt

[edv-hen 0]

Wir haben noch eine alte eigenentwickelte Software im Einsatz die bald abgelöst wird. Diese greift mit langlaufenden Transaktionen und pessimistischer Sperre auf die SQL-Server 2008R2 DB zu. Jetzt habe ich eine bestehende DB auf einen neuen Server umgezogen. Alles funktioniert soweit. Allerdings wird den Anwender nach dem Umzug jetzt nicht mehr angezeigt wer einen Datensatz sperrt. Es kann eigentlich nur an den Rechten liegen. Wer kann mir helfen? Danke.

 

Die Software liest die master.db aus. Die Informationen hole ich mir wie folgt; Benutzer ist SA als db_owner und public auf die master-db.

1)

SELECT DISTINCT blocked, WAITTIME
   FROM master..sysprocesses
 WHERE nt_username={eigener NT-Username}
       AND blocked>0
ORDER BY WAITTIME DESC

2) wer sperrt eine Enitität?

SELECT nt_username,hostname
   FROM master..sysprocesses
 WHERE spid=blocked

 (aus Abfrage 1)

[edv-hen 0]

Guten Morgen,

 

hat keiner eine Idee zu meinem Problem?

Danke.

[Sunny61 772]

Darf der Benutzer denn die Stored Procedures ausführen? Fehlermeldungen im SQL Server Log? Manuell auf dem SQL Server ausgeführt bzw. im Debugger laufen lassen bringt keine Fehlermeldung?

[edv-hen 0]

Ja, Stored Procedures darf er ausführen.

Hier das LogFile. Die Letzte Abfrage bringt keine Werte für nt_username hostname zurück.

EventClass StartTime TextData RPC:Completed 09.04.2015 13:38 exec sp_executesql N'SELECT … Audit Login 09.04.2015 13:38 -- network protocol: TCP/IP set quoted_identifier on set arithabort off set numeric_roundabort off set ansi_warnings on set ansi_padding on set ansi_nulls on set concat_null_yields_null on set cursor_close_on_commit off set implicit_transactions off set l SQL:BatchStarting 09.04.2015 13:38 select USER_NAME() select usertype,type,name from systypes where usertype>=257 SQL:BatchCompleted 09.04.2015 13:38 select USER_NAME() select usertype,type,name from systypes where usertype>=257 RPC:Completed 09.04.2015 13:38 exec sp_datatype_info 1 RPC:Completed 09.04.2015 13:38 exec sp_datatype_info 12 RPC:Completed 09.04.2015 13:38 exec sp_datatype_info -2 RPC:Completed 09.04.2015 13:38 exec sp_datatype_info -3 SQL:BatchStarting 2015-04-09 13:38:32.003 SET LOCK_TIMEOUT 10000 SQL:BatchCompleted 2015-04-09 13:38:32.003 SET LOCK_TIMEOUT 10000 SQL:BatchStarting 2015-04-09 13:38:32.023 SELECT DISTINCT nt_username FROM master..sysprocesses WHERE spid=@@spid SQL:BatchCompleted 2015-04-09 13:38:32.023 SELECT DISTINCT nt_username FROM master..sysprocesses WHERE spid=@@spid RPC:Completed 2015-04-09 13:38:32.040 exec sp_executesql N'SELECT DISTINCT blocked,WAITTIME FROM master..sysprocesses WHERE nt_username=@P1  AND blocked>0 ORDER BY Waittime DESC',N'@P1 varchar(128)','TestUser' RPC:Completed 09.04.2015 13:38 exec sp_executesql N'SELECT DISTINCT blocked,WAITTIME FROM master..sysprocesses WHERE nt_username=@P1  AND blocked>0 ORDER BY Waittime DESC',N'@P1 varchar(128)','TestUser' RPC:Completed 09.04.2015 13:38 exec sp_executesql N'SELECT DISTINCT blocked,WAITTIME FROM master..sysprocesses WHERE nt_username=@P1  AND blocked>0 ORDER BY Waittime DESC',N'@P1 varchar(128)','TestUser' RPC:Completed 09.04.2015 13:38 exec sp_executesql N'SELECT DISTINCT blocked,WAITTIME FROM master..sysprocesses WHERE nt_username=@P1  AND blocked>0 ORDER BY Waittime DESC',N'@P1 varchar(128)','TestUser' RPC:Completed 09.04.2015 13:38 exec sp_executesql N'SELECT DISTINCT blocked,WAITTIME FROM master..sysprocesses WHERE nt_username=@P1  AND blocked>0 ORDER BY Waittime DESC',N'@P1 varchar(128)','TestUser' RPC:Completed 09.04.2015 13:38 exec sp_executesql N'SELECT DISTINCT blocked,WAITTIME FROM master..sysprocesses WHERE nt_username=@P1  AND blocked>0 ORDER BY Waittime DESC',N'@P1 varchar(128)','TestUser' RPC:Completed 09.04.2015 13:38 exec sp_executesql N'SELECT DISTINCT blocked,WAITTIME FROM master..sysprocesses WHERE nt_username=@P1  AND blocked>0 ORDER BY Waittime DESC',N'@P1 varchar(128)','TestUser' RPC:Completed 09.04.2015 13:38 exec sp_executesql N'SELECT DISTINCT blocked,WAITTIME FROM master..sysprocesses WHERE nt_username=@P1  AND blocked>0 ORDER BY Waittime DESC',N'@P1 varchar(128)','TestUser' RPC:Completed 09.04.2015 13:38 exec sp_executesql N'SELECT DISTINCT blocked,WAITTIME FROM master..sysprocesses WHERE nt_username=@P1  AND blocked>0 ORDER BY Waittime DESC',N'@P1 varchar(128)','TestUser' RPC:Completed 09.04.2015 13:38 exec sp_executesql N'SELECT DISTINCT blocked,WAITTIME FROM master..sysprocesses WHERE nt_username=@P1  AND blocked>0 ORDER BY Waittime DESC',N'@P1 varchar(128)','TestUser' RPC:Completed 09.04.2015 13:38 exec sp_executesql N'SELECT nt_username,hostname FROM master..sysprocesses WHERE spid=@P1 ',N'@P1 float',0

Hier nochmals das LogFile als Screenshot. :)

[Sunny61 772]

Hat die Variable @P1 in der letzten Abfrage noch Inhalt? Kannst Du das debuggen?

 

 

BTW: Wenn Du hier das Logfile in Code-Tags bringst, ist es auch formatierbar. So ist der Text des Logfile nutzlos, weil nicht lesbar. :(

[edv-hen 0]

Nein @P1 hat keinen Inhalt. Die Abfrage zuvor bringt kein Ergebnis:

SELECT DISTINCT blocked,WAITTIME
   FROM master..sysprocesses
WHERE nt_username=?cNT_Name.nt_username AND
              blocked>0
ORDER BY Waittime DESC

Auch ohne den Username in der Bedingung kommt nichts zurück:

SELECT DISTINCT blocked,WAITTIME
   FROM master..sysprocesses
WHERE blocked>0
ORDER BY Waittime DESC

D.h., der Wert für blocked wird schon nicht gesetzt beim Sperren?

[Sunny61 772]

Ich würde jetzt ganz oben anfangen und jede SP debuggen, irgendwo muss ja der Fehler auftreten.

[zahni 521]

Vergleiche mal die Einstellungen beider Instanzen (alt  und  neu). Wurde  beim Umzug die  Version des  SQL-Server  geändert?

Kommt denn bei "SELECT DISTINCT blocked, WAITTIME  FROM master..sysprocesses " überhaupt irgendein Ergebnis?

[edv-hen 0]

Guten Morgen,

 

Als Ergebnis der Abfrage "SELECT DISTINCT blocked, WAITTIME  FROM master..sysprocesses" kommt auf der neuen Instanz immer nur eine Zeile zurück mit blocked=0 und waittime=0, egal ob ein Datensatz gesperrt ist oder nicht.

 

In der anderen (alten) Instanz kommen mehrere Zeilen zurück und wenn ein Nutzer auf einen gesperrten Datensatz zugreifen möchte gibt es auch einen Wert blocked>0.

Es kann nur etwas mit der Konfig der neuen Instanz zu tun haben. Es sind zwei verschiedenen Maschinen (jeweils Windows Server 2008) und auf beiden ist SQL Server 2008 R2 installiert.

[Sunny61 772]

Und Du bist ganz sicher mit dem Frontend auch auf dem neuen Server zu arbeiten? Nicht dass du immer noch auf der alten Maschine bist.

[edv-hen 0]

Ja, du hattest recht. Ich habe es auf der "alten" Maschine laufen lassen. Ich habe es jetzt Remote auf der neuen Maschine im Mangemant Studio laufen lassen. Da wird mir jetzt mein Name angezeigt wenn ich einen Datensatz zum zweiten Mal sperren möchte. So wie es sein soll.

 

Kurz zur Erläuterung unserer Umgebung:

Wir haben zwei Standarote die über eine 10 Mbit CompanyConnect miteinander verbunden sind. In beiden Standorten arbeiten Mandaten mit der selben Software. Die Datenbanken lagen bisher alle bei einem Mandanten. Ich habe nun für einen Mandanten die Datenbank umgezogen. Damit haben jetzt alle Mandanten die DB im eigenen Hause und arbeiten nicht mehr über die Leitung. Bei diesem Mandanten besteht jetzt das beschriebene Problem.

[Sunny61 772]

Ja, du hattest recht. Ich habe es auf der "alten" Maschine laufen lassen. Ich habe es jetzt Remote auf der neuen Maschine im Mangemant Studio laufen lassen. Da wird mir jetzt mein Name angezeigt wenn ich einen Datensatz zum zweiten Mal sperren möchte. So wie es sein soll.

Schön, freut mich für dich und Danke für die Rückmeldung. ;)

 

 

 

Kurz zur Erläuterung unserer Umgebung:

Wir haben zwei Standarote die über eine 10 Mbit CompanyConnect miteinander verbunden sind. In beiden Standorten arbeiten Mandaten mit der selben Software. Die Datenbanken lagen bisher alle bei einem Mandanten. Ich habe nun für einen Mandanten die Datenbank umgezogen. Damit haben jetzt alle Mandanten die DB im eigenen Hause und arbeiten nicht mehr über die Leitung. Bei diesem Mandanten besteht jetzt das beschriebene Problem.

*Bestand* das Problem, oder doch nicht? ;)

[edv-hen 0]

Das Problem besteht noch bei dem Mandanten bei dem ich die DB umgezogen habe.

[Sunny61 772]

Das Problem besteht noch bei dem Mandanten bei dem ich die DB umgezogen habe.

Hmm, auch hier sei nochmal die Frage nach der richtigen Version erlaubt. Bist Du sicher das du mit dem Frontend auch auf dem richtigen Backend arbeitest?

[edv-hen 0]

Also das Problem besteht, wenn die Abfragen aus der Software heraus aufgerufen werden.

Im Mangemant Studio auch der neuen Umgebung nicht.