MSSQL: Datensatz nicht sichtbar

[haentschman]

Hallöle...8-)

Gegeben:
Der User sagte "ein Datensatz ist weg". :?
(Es müßten eigentlich 2 sein)

Analyse mit Management Studio:
1. Backup von Mitternacht in den Entwicklungs-MSSQL eingelesen. (Test1)
-> 2 Datensätze vorhanden
2. Backup der Server Datenbank gemacht. (Test2)
3. Backup lokal in den Entwicklungs-MSSQL eingelesen. (Test2)
-> 2 Datensätze vorhanden
4. MSSQL Studio auf Server
-> nur 1 Datensätz vorhanden
5. Backup Server-MSSQL eingelesen. (Test2 , neue DB)
-> nur 1 Datensätz vorhanden
6. das gleiche Backup von 5. in den Entwicklungs-MSSQL eingelesen. (Test2)
-> 2 Datensätze vorhanden

offene Transaktionen:

Zitat:

Keine aktiven geöffneten Transaktionen.
Die DBCC-Ausführung wurde abgeschlossen. Falls DBCC Fehlermeldungen ausgegeben hat, wenden Sie sich an den Systemadministrator.

Abschlusszeit: 2021-06-28T11:41:09.4735222+02:00

...und nun kommt ihr. :gruebel:

Danke

[Blup]

Lass mal raten welche Möglichkeiten existieren:
- die Einstellungen beim Restore unterscheiden sich (Server/Entwicklungsserver)
- die MSSQL-Versionen beider Server stimmmen nicht 100% überein
- die eingelesene Datei unterscheidet sich (z.B. Betriebsystem sieht eine andere Datei als der Benutzer im Explorer)

[haentschman]

:P

Zitat:

die Einstellungen beim Restore unterscheiden sich (Server/Entwicklungsserver)

nein...bis auf den Servernamen und ggf. für den Test den Database Namen

Zitat:

die MSSQL-Versionen beider Server stimmmen nicht 100% überein

Ja...sind aber alle beide 2017. Einmal Vollversion, einmal Entwicklerversion.

Zitat:

die eingelesene Datei unterscheidet sich (z.B. Betriebsystem sieht eine andere Datei als der Benutzer im Explorer)

1:1 Kopie vom Server (Hash noch nicht geprüft)

Solche Probleme hatte ich noch nie!


Danke...:wink: Ich werde jetzt den Server neu starten...die anderen 80% der User haben Feierabend. :wink:

[jobo]

Ich kenne Eure Workflows und Spielregeln nicht.
Datensätze können eingegeben werden.
Datensätze können gelöscht werden.
Datensätze können erneut eingegeben werden.

Ich kenne Eure "Technik" nicht.
Es gibt Dinge, die einem in die Hacken laufen können. Read uncommited, clientseitige Transaktionen, .. vielleicht noch mehr bei MSSQL, das benutze ich schon ewig nicht mehr.

Aus Deinen Angaben ist mir auch nicht klar, welche Art Backups das sind, bzw. wie sie zurückgespielt werden. Mit einem JustInTime recovery könnte man ja genau sehen, wann was da und wieder weg ist.
Wenn man einfache Backups macht, kann es auch passieren, dass
Beim "Nachschauen" noch kein oder schein ein neuer Datensatz da ist.
Beim anschließenden Backupbefehl aber bereits eine andere Datenlage entstanden ist.

[haentschman]

Moin...:P

Gestern Datenbankserver MSSQL Dienst beendet / Neustart -> Datensatz fehlt. :evil:

Zitat:

Ich kenne Eure Workflows und Spielregeln nicht.

Ich verstehe nicht, was das mit dem fehlenden Datensatz zu tun hat? :gruebel: Wenn du damit meinst...ausschließlich "Read Commited".
Datensätze können eingegeben werden-> Ja
Datensätze können gelöscht werden-> Ja
Datensätze können erneut eingegeben werden-> Ja

Zitat:

Aus Deinen Angaben ist mir auch nicht klar, welche Art Backups das sind, bzw. wie sie zurückgespielt werden

MSSQL ManagmentStudio:
Backup: DB->Task->Sichern
Einspielen: DB->Task->Wiederherstellen->Datenbank

PS nochmal:
Es geht um einen Datensatz der im Live System nicht sichtbar ist, aber im Backup, welches in der Entwickler Datenbank eingespielt wurde, zu sehen ist. :evil:

[TigerLilly]

Wie stellst du fest, dass ein bzw zwei Datensätze vorhanden sind?

[haentschman]

Zitat:

Wie stellst du fest, dass ein bzw zwei Datensätze vorhanden sind?

Gleiches SQL im Live System und in der Entwicker DB (Backup aus Live DB)
-> siehe Bilder

[TigerLilly]

Poste mal das SQL-Statement.

[haentschman]

Bitteschön...:P

2. Versuch:

Code:

SELECT TOP (1000)[idBelKopf]
      ,[ixBelArt]
      ,[BELNummer]
      ,[DatumLeistung]
      ,[DatumBeleg]
      ,[ixSTAdr]
      ,[STName1]
      ,[STName2]
      ,[STPLZ]
      ,[STOrt]
      ,[STStrasse]
      ,ixRecName
      ,RecDate
  FROM [dbo].[BELKopf]where ixSTAdr = '8922' and ixBelArt  = 'STÖRUNG'
  order by idBelKopf desc

[Uwe Raabe]

Hmmm :gruebel:. Im Screenshot kommt aber auch eine Spalte idBelKopf vor...

[haentschman]

:oops: Sorry, diese Spalte ist die ID Spalte der Tabelle. Wegen Vereinfachung weggelassen...:oops:
Die Spalten im where sind wichtig.

Geändert.

[TigerLilly]

Hmm. Ich hätte auf unterschiedliche Sortiereinstellungen oder Zeichensätze getippt. Aber das scheint es nicht zu sein.
Ich hatte sowas mal mit einem defekten Index. Aber das wäre in jedem Backup drin.

[dbo].[BELKopf] ist eine Tabelle und kein View?

Du kannst den Datensatz auch gar nicht (mit anderem WHERE) zur Anzeige bringen?
Die Zahl der Datensätze nach dem RESTORE ist überall gleich?
Die spielst die Daten via RESTORE ein?

[Blup]

Der Index wird doch beim Restore neu aufgebaut? Dann sollte das eigentlich nicht das Problem sein.

Vieleicht ein Backup vom Entwicklungsserver(mit dem Datensatz) erstellen und auf dem Anwenderserver zurückspielen.

[haentschman]

Danke für eure Anregungen...:thumb:

Ich konnte den Datensatz aus dem Backup, mit der gleichen ID :shock:, wieder herstellen. *schwitz*

Trotzdem verstehe ich das nicht. :roll: Bei uns ist "öfter...2x im Jahr" mal ein Datensatz verlustig. Ich hatte mal für ein halbes Jahr einen Trigger in der Tabelle, der einen Fehler geworfen hätte, wenn ein Datensatz gelöscht worden wäre. Der Trigger hat nie angeschlagen...weil die User keine Löschrechte haben. :roll:

Danke...

[Papaschlumpf73]

Hast du eigentlich bei dem Restore immer unter Optionen den Haken "Vorhandene Datenbank überschreiben (WITH REPLACE)" gesetzt? Wenn der Haken nicht gesetzt wird und die Datenbank schon vorhanden ist, kann da bei einem Restore alles Mögliche rauskommen :-)

[TigerLilly]

Zitat:

Zitat von Papaschlumpf73 (Beitrag 1491700)

Hast du eigentlich bei dem Restore immer unter Optionen den Haken "Vorhandene Datenbank überschreiben (WITH REPLACE)" gesetzt? Wenn der Haken nicht gesetzt wird und die Datenbank schon vorhanden ist, kann da bei einem Restore alles Mögliche rauskommen :-)

Davon habe ich noch nie gehört. Wenn es die Datenbank gibt + überschreiben nicht angewählt ist, bekommst du eine Fehlermeldung + sonst nichts.

[Papaschlumpf73]

Zitat:

Zitat von TigerLilly (Beitrag 1491701)

Zitat:

Zitat von Papaschlumpf73 (Beitrag 1491700)

Hast du eigentlich bei dem Restore immer unter Optionen den Haken "Vorhandene Datenbank überschreiben (WITH REPLACE)" gesetzt? Wenn der Haken nicht gesetzt wird und die Datenbank schon vorhanden ist, kann da bei einem Restore alles Mögliche rauskommen :-)

Davon habe ich noch nie gehört. Wenn es die Datenbank gibt + überschreiben nicht angewählt ist, bekommst du eine Fehlermeldung + sonst nichts.

Dieser Fehler sollte aber nur kommen, du du Datenbank A durch ein Backup von Datenbank B wiederherstellen willst. Wenn du aber Datenbank A mit einem Backup von Datenbank A wiederherstellen willst, kannst du den Haken auch weglassen.

[jobo]

Zitat:

Ich kenne Eure Workflows und Spielregeln nicht.

Zitat:

Ich verstehe nicht, was das mit dem fehlenden Datensatz zu tun hat?

Naheliegend ist bei gegebener Eingabe- und Löschfunktion, dass der Datensatz (versehentlich) gelöscht wurde. Du bestätigst die technische Möglichkeit zum Löschen (und verneinst sie später?). Je nach Backup Zeitpunkt entdeckt man ihn beim Restore wieder oder nicht.
Abhängig von Workflows, DB Contraints, Privileges, Frontendlogik könnte das eben (durchgängig) verboten sein, das kenne ich nicht.

Ein Server, der definierte DB Constraints und Rechte nicht einhält, hätte ein ernstes Problem. Das wäre ein schwerwiegendes Problem, weil es genau das aushebelt, was ein DB Server bietet, garantierte Spielregeln.

Index:
Wenn der Index defekt ist, dann sollte es neu eingespielt funktionieren (Backup) und würde eben genau im Produktivsystem nicht funktionieren. Dies wäre allerdings nur der Fall, wenn zum Aufsuchen des DS eine where Clause verwendet wird, die den Index auch nutzt. Prinzipiell ist ein Index funktional für eine DB nicht notwendig, er beschleunigt nur. Zur Prüfung dieser Problematik, würde also bereits das gezielte Löschen des fraglichen Index ausreichen. (Abhängig vom Hersteller, Indexart und Nutzung des Index ist diese Pauschalaussage nicht immer haltbar, sie soll das Funktionsprinzip eines Index verdeutlichen, wichtig ist die Unterscheidung zwischen Index an sich und Constraint, dem der Index dient)
Andersrum, eine Query, die in irgendeiner Form DS abfragt, ohne defekte Indizes zu benutzen, also andere Felder zur Einschränkung nutzt, sollte den DS dennoch anzeigen.

DS neu eingegeben mit gleicher ID:
Das ist normalerweise überhaupt kein Problem, es gibt zwar DB Typen/Spalten Deklarationen, die einen generierten Schlüsselwert erzwingen, selbst wenn ein anderer Wert rein kommt. Der Normalfall ist aber, dass Trigger Werte oder typgenerierte Schlüsselwerte durch das Insert einfach überschrieben werden, wenn es die Schlüsselspalte enthält.
(Ich weiß nicht, ob MSSQL solche Spaltenkonstrukte kennt, die generierte ID Werte erzwingen.)
Wenn es also geht, den Datensatz manuell nachzutragen, bedeutet es
a) Der Datensatz war schlicht weg.
b) der PK für die Tabelle ist nicht wasserdicht (vlt. durch mehre Spalten) oder defekt

Man könnte also sicherstellen, dass er nicht doch irgendwo rumfliegt. (Nach Neueingabe nun doppelt):
Die Indizes checken und ggf. neu bauen.
Das System prüfen (DB und EXE), ob es Lücken in der Rechteverwaltung o.ä. gibt, wegen des Widerspruchs zwischen "Löschen möglich: ja" und "Userrechte dazu vorhanden:nein". Wichtig ist hierbei die Frage, ob die Userrechte auf DB Ebene realisiert sind (und für welche User) oder woanders. Nur im ersten Fall sollte man sich darauf verlassen können.

Solche Probleme sind eigentlich nur sauber nachvollziehbar, wenn man eine Trigger basierte Bearbeitungshistorie führt (wie bereits von Dir mal angelegt), Probleme fallweise nachvollzieht und die Ursache abstellt.
Dies am besten per File Log, nicht in weitere Tabellen. File Logging funktioniert immer am durchgängigsten (bis Platz fehlt), auch bei DB Fehlern, Transaktions- Rollback usw.. zielt das Logging wiederum auf Logtabellen, ist es den Gesetzmäßigkeiten der DB (Transaktionen,..) unterworfen und oft wertlos. (Eine Abschwächung davon wären autonome Transaktionen, sofern vom Hersteller unterstützt)

Nach meiner eigenen Erfahrung sind >99% solcher Probleme keine DB Fehler, wäre es anders, würde die Nutzung einer DB kaum Sinn machen, denn die garantierte Funktionalität (ACID) wäre nicht gegeben.

Das gilt so pauschal erst mal für klassische, relationale RDBMS, nicht für noSQL / Dokument DB.

[haentschman]

Hallo...8-)

Zitat:

Du bestätigst die technische Möglichkeit zum Löschen (und verneinst sie später?).

Technisch besteht die Möglichkeit des Löschens, aber der "Knopf" ist über ein Rechtesystem "disabled". Nuch der Admin hat die Rechte.

Zitat:

Ich hatte mal für ein halbes Jahr einen Trigger in der Tabelle, der einen Fehler geworfen hätte

Über den Trigger konnte ich selbst (Admin) keinen DS löschen! Deshalb wieder ausgebaut. :wink:

Zitat:

DS neu eingegeben mit gleicher ID:

Mit

Code:

SET IDENTITY_INSERT ON/OFF

konnte ich die originale ID wieder herstellen. Keine Fehler.

Danke für deine Zeit...:P