Neu JTL Wawi Update von 1.6.44.2 auf 1.7.13.1 Datenbank Fehler

[wo0dle]

Hallo,

wir wollten heute das Update von JTL Wawi Version 1.6.44.2 auf 1.7.13.1 durchführen. Leider erstellt die JTL kein DB Backup, weil es zu einem Fehler kommt (siehe unten).
Daher kann das Update auch nicht durchgeführt werden. Wir erstellen aber tägliche Backups mit SQLBackupAndFTP.

Wir nutzen den SQL Server 2019 Express. Kann zufällig einer beschreiben was zu tun ist, damit wir den Fehler wegbekommen und das Update durchführen können.

Von CHECKDB wurden 1 Zuordnungsfehler und 0 Konsistenzfehler in der tGlobalsQueue-Tabelle (Objekt-ID 1758432763) gefunden.

Unbehandelte Ausnahme #959190594F6282F vom Typ System.Exception in
System.Exception: Die Prüfung der Datenbank ist fehlgeschlagen
Tabellenfehler: Mehrere IAM-Seiten für Objekt-ID 1758432763, Index-ID 0, Partitions-ID 72057595040169984, Zuordnungseinheits-ID 72057595161739264 (In-row data-Typ) enthalten Zuordnungen für dasselbe Intervall. IAM-Seiten (1:19426) und (1:9675).
Von CHECKDB wurden 1 Zuordnungsfehler und 0 Konsistenzfehler in der tGlobalsQueue-Tabelle (Objekt-ID 1758432763) gefunden.
Von CHECKDB wurden 1 Zuordnungsfehler und 0 Konsistenzfehler in der eazybusiness-Datenbank gefunden.

2023-08-28T13:52:50 DEBUG - Dauer: 1ms, 1 Zeilen
2023-08-28T13:53:05 DEBUG - SELECT * FROM [tversion]
2023-08-28T13:53:05 DEBUG - Dauer: 0ms, (bis zum Reader)
2023-08-28T13:53:05 DEBUG - Dauer: 0ms, 1 Zeilen
2023-08-28T13:53:07 DEBUG - SELECT [cVersion] FROM [dbo].[tVersion]
2023-08-28T13:53:07 DEBUG - Dauer: 0ms, Result: 1.6.44.2
2023-08-28T13:53:07 DEBUG - SELECT COUNT(*) FROM [eazybusiness].[dbo].[tMandant]
JOIN [eazybusiness].[dbo].[tBenutzerFirma] ON [eazybusiness].[dbo].[tBenutzerFirma].kMandant = [eazybusiness].[dbo].[tMandant].kMandant
WHERE [eazybusiness].[dbo].[tBenutzerFirma].kBenutzer = @kBenutzer AND [eazybusiness].[dbo].[tMandant].cDB = @cDatenbank;
@kBenutzer = 2
@cDatenbank = 'eazybusiness'
2023-08-28T13:53:07 DEBUG - Dauer: 3ms, Result: 1
2023-08-28T13:53:07 DEBUG - SELECT TOP 1 tRechtBenutzerGruppenZuordnung.kRechtBenutzerGruppe
        FROM eazybusiness.dbo.tRechtBenutzerGruppenZuordnung tRechtBenutzerGruppenZuordnung
        JOIN eazybusiness.dbo.tRechtBenutzerGruppe tRechtBenutzerGruppe ON tRechtBenutzerGruppe.kRechtBenutzerGruppe = tRechtBenutzerGruppenZuordnung.kRechtBenutzerGruppe
        WHERE    tRechtBenutzerGruppenZuordnung.kBenutzer = @kBenutzer
                AND tRechtBenutzerGruppe.nIsAdmin = 1
@kBenutzer = 2
2023-08-28T13:53:07 DEBUG - Dauer: 0ms, (bis zum Reader)
2023-08-28T13:53:07 DEBUG - Dauer: 0ms, 1 Zeilen
2023-08-28T13:53:07 DEBUG - IF(OBJECT_ID('tempdb..#TMP_DRIVES') IS NOT NULL)
BEGIN
    DROP TABLE #TMP_DRIVES
END
CREATE TABLE #TMP_DRIVES
(
    DRIVE NCHAR(1) NOT NULL,
    MBFREE INT NOT NULL
)
INSERT INTO #TMP_DRIVES
EXEC xp_fixeddrives
SELECT * FROM #TMP_DRIVES
2023-08-28T13:53:07 DEBUG - Dauer: 3ms, (bis zum Reader)
2023-08-28T13:53:07 DEBUG - Dauer: 6 ms, 1 Zeilen
2023-08-28T13:53:08 DEBUG - SELECT [size] FROM [eazybusiness].[sys].[database_files] WHERE type = 0
2023-08-28T13:53:08 DEBUG - Dauer: 3ms, Result: 232896
2023-08-28T13:53:08 DEBUG - SELECT cValue FROM [eazybusiness].[dbo].[tOptions] WHERE cKey='BackupErzwingen'
2023-08-28T13:53:08 DEBUG - Dauer: 0ms, Result:
2023-08-28T13:53:08 DEBUG - SELECT cValue FROM [eazybusiness].[dbo].[tOptions] WHERE cKey='BackupErzwingen'
2023-08-28T13:53:08 DEBUG - Dauer: 0ms, Result:
2023-08-28T13:53:08 DEBUG - DBCC CHECKDB (eazybusiness) WITH NO_INFOMSGS, TABLERESULTS, EXTENDED_LOGICAL_CHECKS
2023-08-28T13:53:28 DEBUG - Dauer: 20321ms, (bis zum Reader)
2023-08-28T13:53:28 DEBUG - Dauer: 20325 ms, 3 Zeilen
2023-08-28T13:53:28 DEBUG - SELECT (CASE WHEN SERVERPROPERTY('MACHINENAME') = HOST_NAME() THEN 'local' ELSE 'remote' END) AS instance
2023-08-28T13:53:28 DEBUG - Dauer: 0ms, Result: local
Zeitstempel: 2023-08-28T13:53:46
Locale: German (Germany)
Locale: German (Germany)
Version: 1.7.13.1
Plattform: Wawi
WawiSeed: 1.0.73077.45301
Prozessname: JTL-Wawi
Physikalischer Speicher: 409337856 / Peak: 411443200
Basispriorität: 8
Prioritätsklasse: Normal
CPU-Zeit (User): 0:00:08,40625
CPU-Zeit (System): 0:00:01,90625
Page-Size (Sytem): 2378552 / Peak: 420491264
Page-Size: 417218560 / Peak: 420491264
Offene Handles: 1634
Database:
Build: 2307311407 3cbad2a54d787432166d751eb69277d485a99ded

 

[mh1]

Wir nutzen den SQL Server 2019 Express. Kann zufällig einer beschreiben was zu tun ist, damit wir den Fehler wegbekommen und das Update durchführen können.

Du musst deine Datenbank reparieren lassen.
Dazu musst du

• sie erstmal in den Emergency Modus versetzen: ALTER DATABASE [eazybusiness] SET EMERGENCY
• Dann lass mal den CHECKDB drüber: DBCC CHECKDB (eazybusiness)
• Um die Datenbank jetzt zu reparieren musst du sie in den Single User Modus versetzen: ALTER DATABASE eazybusiness SET SINGLE_USER
• Jetzt startest du die Reparatur: DBCC CHECKDB (N ’eazybusiness’, REPAIR_REBUILD) WITH ALL_ERRORMSGS, NO_INFOMSGS;
  Wenn das nicht zum Erfolg führt kannst du stat REPAIR_REBUILD mal REPAIR_ALLOW_DATA_LOSS versuchen. Das kann aber zu Datenverlust führen, ist also eher als "die letzte Chance" anzusehen...
• Nach erfolgreicher Reparatur wieder in den Mehrbenutzermodus: ALTER DATABASE eazybusiness SET MULTI_USER

 

[wo0dle]

Du musst deine Datenbank reparieren lassen.
Dazu musst du

• sie erstmal in den Emergency Modus versetzen: ALTER DATABASE [eazybusiness] SET EMERGENCY
• Dann lass mal den CHECKDB drüber: DBCC CHECKDB (eazybusiness)
• Um die Datenbank jetzt zu reparieren musst du sie in den Single User Modus versetzen: ALTER DATABASE eazybusiness SET SINGLE_USER
• Jetzt startest du die Reparatur: DBCC CHECKDB (N ’eazybusiness’, REPAIR_REBUILD) WITH ALL_ERRORMSGS, NO_INFOMSGS;
  Wenn das nicht zum Erfolg führt kannst du stat REPAIR_REBUILD mal REPAIR_ALLOW_DATA_LOSS versuchen. Das kann aber zu Datenverlust führen, ist also eher als "die letzte Chance" anzusehen...
• Nach erfolgreicher Reparatur wieder in den Mehrbenutzermodus: ALTER DATABASE eazybusiness SET MULTI_USER

Das war tatsächlich die Lösung
REPAIR_REBUILD) danach REPAIR_ALLOW_DATA_LOSS hat den Fehler beseitigt und ich konnte das Update auf die neueste Wawi Version durchführen.
Daten technisch sieht auch alles gut aus, es kann evtl. sein das vor Monaten mal die Datenbank abgestürzt ist, weil wir einen Stromausfall hatten bei uns.

Vielen Dank mh1

 

[mh1]

Das war tatsächlich die Lösung
REPAIR_REBUILD) danach REPAIR_ALLOW_DATA_LOSS hat den Fehler beseitigt und ich konnte das Update auf die neueste Wawi Version durchführen.
Daten technisch sieht auch alles gut aus, es kann evtl. sein das vor Monaten mal die Datenbank abgestürzt ist, weil wir einen Stromausfall hatten bei uns.

Vielen Dank mh1

Super dass es funktioniert hat.
Ein Tipp wäre noch, mit dem CHECKDB nicht zu sparsam umzugehen
Es bringt ja nichts, wenn man täglich eine kaputte Datenbank sichert....