Update von 99894 auf aktuellste Wawi

[maydo]

Hi,

auf unserem Testsystem wollten nur nun auch die neue Wawi testen.

Allerdings bricht das Update nach Fehlern ab.

Hier die Fehler:

Das Index-Objekt '_dta_index_tartikel_6_1765581328__K1_K58_K10_K57_K2_K48_3_5_6_7_9_12_13_14_15_16_19_22_23_24_25_26_27_28_29_30_31_32_33_36_37_' ist vom Spalte-Objekt 'nPuffer' abhängig.
Fehler bei ALTER TABLE ALTER COLUMN nPuffer, da mindestens ein Objekt auf diese Spalte zugreift.
Das Statistik-Objekt '_dta_stat_1803153469_2_1' ist vom Spalte-Objekt 'cKey' abhängig.
Fehler bei ALTER TABLE ALTER COLUMN cKey, da mindestens ein Objekt auf diese Spalte zugreift.
Eine PRIMARY KEY-Einschränkung kann für eine Spalte in der tOptions-Tabelle, die NULL zulässt, nicht definiert werden.
Die Einschränkung konnte nicht erstellt werden. Siehe vorherige Fehler.

Das Index-Objekt '_dta_index_tartikel_6_1765581328__K1_K58_K10_K57_K2_K48_3_5_6_7_9_12_13_14_15_16_19_22_23_24_25_26_27_28_29_30_31_32_33_36_37_' ist vom Spalte-Objekt 'nPuffer' abhängig.
Fehler bei ALTER TABLE ALTER COLUMN nPuffer, da mindestens ein Objekt auf diese Spalte zugreift.
Das Statistik-Objekt '_dta_stat_1803153469_2_1' ist vom Spalte-Objekt 'cKey' abhängig.
Fehler bei ALTER TABLE ALTER COLUMN cKey, da mindestens ein Objekt auf diese Spalte zugreift.
Eine PRIMARY KEY-Einschränkung kann für eine Spalte in der tOptions-Tabelle, die NULL zulässt, nicht definiert werden.
Die Einschränkung konnte nicht erstellt werden. Siehe vorherige Fehler.

Das Index-Objekt '_dta_index_tartikel_6_1765581328__K1_K58_K10_K57_K2_K48_3_5_6_7_9_12_13_14_15_16_19_22_23_24_25_26_27_28_29_30_31_32_33_36_37_' ist vom Spalte-Objekt 'nPuffer' abhängig.
Fehler bei ALTER TABLE ALTER COLUMN nPuffer, da mindestens ein Objekt auf diese Spalte zugreift.
Das Statistik-Objekt '_dta_stat_1803153469_2_1' ist vom Spalte-Objekt 'cKey' abhängig.
Fehler bei ALTER TABLE ALTER COLUMN cKey, da mindestens ein Objekt auf diese Spalte zugreift.
Eine PRIMARY KEY-Einschränkung kann für eine Spalte in der tOptions-Tabelle, die NULL zulässt, nicht definiert werden.
Die Einschränkung konnte nicht erstellt werden. Siehe vorherige Fehler.

Bis jetzt hatten wir noch nie Probleme mit Updates. Alle waren bisher immer erfolgreich.
Was ist zu tun ?

Übrigens hatte DITH Shop in irgendeinem Thread den Vorschlag gemacht einen Button einzubauen um das Zwangsbackup zu überpsringen.
Dies würde ich auch begrüssen.

Gerade bei solchen Updatefehlern, ist es wirklich sehr mühsam jedesmal das stundenlange Backup abzuwarten.

 

[SebastianB]

AW: Update von 99894 auf aktuellste Wawi

Hi,

das Problem wird durch einen _dta_stat - Index erzeugt. Der kommt nicht von der Wawi. Das ganze sieht so aus, als wäre das Tool "dta" (Database Tuning Advisor) eingesetzt worden um die Performance des SQL-Servers zu "optimieren". Dadurch ergeben sich jetzt Fehler im Update. Die Datenbank kann von unserem Support kostenpflichtig wieder in den Standardzustand gebracht werden - alternativ kann man selber versuchen, die Auswirkungen dieses Tools wieder rückgängig zu machen.

Das Zwangs-Backup wurde exakt für solche Fälle geschaffen: Wäre vor dem Update kein Backup gemacht worden, wäre die Datenbank jetzt in einem undefinierten Zustand und ggf. nur mit großem finanziellen Aufwand wieder herzustellen. Wer auf eigenes Risiko arbeiten möchte kann das gerne tun (wie im anderen Thread schon geschrieben hilt der Support da gerne weiter), aber die Erfahrungen der letzten Jahre haben und letztlich zu dem Zwangs-Backups bewogen.

Gruß,
Sebastian

 

[DITH-Shop]

AW: Update von 99894 auf aktuellste Wawi

_dta_index_

Das sind selbst (vermutlich durch Datenbankadvisor) angelegte indize die von JTL natürlich nicht berücksichtigt werden können, müssen daher VOR dem Update-Versuch gelöscht sein, andernfalls Felder in Tabellen nicht korrekt angepasst/geändert/gelöscht werden können. (s. Fehlermeldung)

Einen Button "Zwangsupdate überspringen" wird es aller Voraussicht nach nicht geben, aber man kann beim Support einen SQL-Befehl (per Ticket) erhalten der das übernimmt.

Ich habe mir für die Entfernung, automatisch durch den Advisor angelegter Indize und Statistiken, ein entsprechendes Script erstellt welches das übernimmt.

--- ab hier gehts nur noch für sehr erfahrene SQL Administratoren weiter ---

Das nachfolgende Script sucht in den Systemtabellen nach vorkommen des von Datenbank-Advisor vergebenen Index Namen und löscht diese dann einzeln.

DECLARE @indexName VARCHAR(128)
DECLARE @tableName VARCHAR(128)

DECLARE [indexes] CURSOR FOR

        SELECT          [sysindexes].[name] AS [Index],
                        [sysobjects].[name] AS [Table]

        FROM            [sysindexes]

        INNER JOIN      [sysobjects]
        ON              [sysindexes].[id] = [sysobjects].[id]

        WHERE           [sysindexes].[name] like '%_dta_i%' 


OPEN [indexes]

FETCH NEXT FROM [indexes] INTO @indexName, @tableName

WHILE @@FETCH_STATUS = 0
BEGIN
        --PRINT 'DROP INDEX [' + @indexName + '] ON [' + @tableName + ']'
        Exec ('DROP INDEX [' + @indexName + '] ON [' + @tableName + ']')

        FETCH NEXT FROM [indexes] INTO @indexName, @tableName
END

CLOSE           [indexes]
DEALLOCATE      [indexes]

GO

Unnötig zu erwähnen dass das Script bei mir zwar getestet ist, aber ausschließlich auf eigene Gefahr verwendet wird, ein AKTUELLES Backup ist ebenfalls Voraussetzung

 

[DITH-Shop]

AW: Update von 99894 auf aktuellste Wawi

Das Zwangs-Backup wurde exakt für solche Fälle geschaffen:
Wäre vor dem Update kein Backup gemacht worden, wäre die Datenbank jetzt in einem undefinierten Zustand

Sorry, aber "Quark"

Wenn jemand die "Fähigkeit" hat solche Änderungen zu bewerkstelligen, hat er ebenfalls die Fähigkeit die Version in der DB zurück zu setzen, die angezeigten Fehler fix zu beheben und das Update neu zu starten. Das einzige was dabei enorm behindert ist das Zwangsupdate.

Jemand der an den Indize "herum fummelt", weil die Wawi damit zur Turbo-Wawi wird, hat auch jederzeit ein aktuelles Backup welches vollautomatisch durch die "zum fummeln" verwendeten Tools erzeugt wird. Gell?

Das Zwangsbackup ist aber vermutlich für die 0815/User die wirklich NUR User sind von klar von Vorteil. Ich könnte mir vorstellen dass DIE tatsächlich auch unbedacht den Haken weg nehmen würden um ein paar Minuten zu sparen und dann dumm da stehen wenn nichts mehr geht.
Die Idee mit dem SQL für erfahrenen SQL-Administratoren finde ich gar nicht schlecht.

So kann JTL im Falle des Falles darauf hinweisen
"Ey Du Nase, Du hast das Abschalten explizit angefragt, nu sieh zu wie Du klar kommst oder wir reparieren das gerne für Dich auf Deine Kosten"

 

[Thomas Lisson]

AW: Update von 99894 auf aktuellste Wawi

So kann JTL im Falle des Falles darauf hinweisen
"Ey Du Nase, Du hast das Abschalten explizit angefragt, nu sieh zu wie Du klar kommst oder wir reparieren das gerne für Dich auf Deine Kosten"

Es ist aber besser, diesen Fall nie eintreten zu lassen, indem man einfach das Zwangsbackup bei einem Update beibehält. Das spart Im Fall der Fälle viel Ärger - wohl aber nicht Zeit.

 

[DITH-Shop]

AW: Update von 99894 auf aktuellste Wawi

Es ist aber besser, diesen Fall nie eintreten zu lassen, indem man einfach das Zwangsbackup bei einem Update beibehält. Das spart Im Fall der Fälle viel Ärger - wohl aber nicht Zeit.

- Rischtisch

 

[maydo]

AW: Update von 99894 auf aktuellste Wawi

hi,

@dith- shop, danke für den code.

er findet die einträge und möchte diese löschen allerdings erhalte ich folgende fehlermeldung

Löschen des Index-Objekts 'tkategorie._dta_stat_1874105717_4_8_2_6' ist nicht möglich, weil das Objekt nicht vorhanden ist oder Sie nicht die erforderliche Berechtigung haben.

das ganze bei 370 verschiedenen objekten.

ne idee ?

berechtigungen passen.

 

[DITH-Shop]

AW: Update von 99894 auf aktuellste Wawi

hi,

@dith- shop, danke für den code.

er findet die einträge und möchte diese löschen allerdings erhalte ich folgende fehlermeldung

Löschen des Index-Objekts 'tkategorie._dta_stat_1874105717_4_8_2_6' ist nicht möglich, weil das Objekt nicht vorhanden ist oder Sie nicht die erforderliche Berechtigung haben.

das ganze bei 370 verschiedenen objekten.

ne idee ?

berechtigungen passen.

Na wenn Du Änderungen vornimmst, dann auch richtig

Gesucht wird in meinem Script nach "_dta_i" - da kann Dein "_dta_stat_" eigentlich nicht vorkommen.
Zudem Du das für Statistiken etwas umschreiben musst, da ja nicht INDEX gelöscht werden soll, sondern STATISTIKEN.

 

[maydo]

AW: Update von 99894 auf aktuellste Wawi

danke für alle tips.

das problem konnte ich lösen.

hier ist der query um auch die statistiken zu säubern (falls noch einer auf das problem stossen sollte):

DECLARE @Sql        NVARCHAR(MAX)       SET @Sql       = ''
DECLARE @TableName  sysname             SET @TableName = ''
DECLARE @StatsName  sysname             SET @StatsName = ''

DECLARE cur CURSOR LOCAL FOR
SELECT OBJECT_NAME(s.object_id)   AS 'TableName'
     , s.name                     AS 'StatsName'
  FROM sys.stats     s 
  JOIN sys.tables    t
    ON s.object_id = t.object_id
 WHERE s.object_id > 100
 AND s.name like '%_dta_s%'
   --AND s.name NOT IN 
        -- (SELECT name FROM sys.indexes WHERE object_id = s.object_id)

OPEN cur
FETCH NEXT FROM cur INTO @TableName, @StatsName

WHILE @@FETCH_STATUS = 0
BEGIN
    SET @Sql = 'DROP STATISTICS ' + QUOTENAME(@TableName) + '.' + QUOTENAME(@StatsName)
    PRINT @Sql
    EXEC sp_executesql @Sql
    FETCH NEXT FROM cur INTO @TableName, @StatsName
END

CLOSE cur 
DEALLOCATE cur

 

[DITH-Shop]

AW: Update von 99894 auf aktuellste Wawi

Und zur Sicherheit nochmals der dringende Hinweis - obige Scripts gehen tief in die Datenbank und können bei unsachgemäßer Verwendung dazu führen, das die Wawi nicht mehr funktioniert.

Es kann sogar so weit gehen, dass der gesamte SQL-Server komplett neu installiert werden muss, da ggf auch Server eigene Tabellen (master, model, msdb uvm.) zerstört werden könnten!