none
SQL Server 2016: Räumliche Indizes funktionieren nicht in einer Datenbank mit Latin1_General_CS_AS RRS feed

  • Frage

  • Nach Migration einer Datenbank von SQL Server 2008R2 nach SQL Server 2016 ist beim Löschen von Zeilen in einer Tabelle mit Geometriespalten folgende Fehlermeldung aufgetreten:

    Meldung 596, Ebene 21, Status 1, Zeile 2
    Die Ausführung kann nicht fortgesetzt werden, weil die Sitzung den KILL-Status aufweist.
    Meldung 0, Ebene 20, Status 0, Zeile 2
    Für den aktuellen Befehl ist ein schwerwiegender Fehler aufgetreten. Löschen Sie eventuelle Ergebnisse.

    Durch intensives Testen wurde ermittelt, daß dieser Fehler mit den vorhandenen räumlichen Indizes zusammenhängt. Nach dem Entfernen der räumlichen Indizes können Datensätze gelöscht werden. Testhalber wurde versucht, neue räumliche Indizes für die vorhandenen Geometriespalten anzulegen. Dabei wurde folgende Fehlermeldung ausgegeben:

    Meldung 0, Ebene 11, Status 0, Zeile 27
    Für den aktuellen Befehl ist ein schwerwiegender Fehler aufgetreten. Löschen Sie eventuelle Ergebnisse.

    Die Sortierung der betroffenen Datenbank ist auf Latin1_General_CS_AS festgelegt.

    Nach weiteren Tests, sind wir zu folgendem Ergebnis gekommen:

    Räumliche Indizes funktionieren nicht in Microsoft SQL Server 2016, wenn die Sortierung der Datenbank zwischen Groß- und Kleinschreibung unterscheidet.

    Verwendete Version des SQL Servers (@@VERSION)
    Microsoft SQL Server 2016 (SP1-CU1) (KB3208177) - 13.0.4411.0 (X64)
     Jan  6 2017 14:24:37
     Copyright (c) Microsoft Corporation
     Developer Edition (64-bit) on Windows Server 2012 Datacenter 6.2 <X64> (Build 9200: ) (Hypervisor)

    Für einen weiteren Test wurden zwei völlig neue Datenbanken, einmal mit der Sortierung Latin1_General_CI_AS und einmal mit der Sortierung Latin1_General_CS_AS angelegt. Es wurde eine einfache Tabelle mit einer Geometriespalte erzeugt und versucht einen räumlichen Index anzulegen.

    Datenbank mit Latin1_General_CI_AS:
    Befehl(e) wurde(n) erfolgreich abgeschlossen.

    Datenbank mit Latin1_General_CS_AS:
    Meldung 0, Ebene 11, Status 0, Zeile 27
    Für den aktuellen Befehl ist ein schwerwiegender Fehler aufgetreten. Löschen Sie eventuelle Ergebnisse.

    In der betroffenen Datenbank werden geologische Bohrungen verwaltet, deren Schichtbeschreibungen nach den Regeln des Symbolschlüssel Geologie verschlüsselt sind. Da wir diese Beschreibungen auch wieder entschlüsseln müssen, können wir auf die Unterscheidung zwischen Groß- und Kleinschreibung leider nicht verzichten (z.B. "U = Schluff" ist ein anderer Schuh als "u = schluffig" ;-). Auch auf die räumlichen Indizes können wir nicht verzichten, da die Bohrungen in GIS / WebGIS-Systemen dargestellt und dafür über räumliche Abfragen selektiert werden müssen.

    Gibt es für das beschriebene Problem einen Workaround, Patch oder ähnliches? Die Rückkehr auf eine ältere Version von SQL Server, wo das Problem nicht auftritt, ist nicht unbedingt zielführend.

    Zum Nachvollziehen unseres Problems können die folgenden beiden Skripte verwendet werden.

    ------------------------------------------------------------------------
    --
    -- Datenbank _TEMP_CI mit Sortierung Latin1_General_CI_AS
    --
    ------------------------------------------------------------------------
    
    -- Create database with case-insensitive collation
    USE [master]
    GO
    
    CREATE DATABASE [_TEMP_CI]
    COLLATE Latin1_General_CI_AS
    GO
    
    ALTER DATABASE [_TEMP_CI]
    SET RECOVERY SIMPLE
    GO
    
    ALTER AUTHORIZATION ON DATABASE::[_TEMP_CI] TO [sa]
    GO
    
    -- Create table with spatial column and spatial index
    USE [_TEMP_CI]
    GO
    
    CREATE TABLE [dbo].[TEST] (
    	[ID] uniqueidentifier NOT NULL DEFAULT(NEWID())
    ,	[GK4_GEOM] geometry
    ,	CONSTRAINT [PK_TEST] PRIMARY KEY CLUSTERED ([ID])
    )
    GO
    
    CREATE SPATIAL INDEX [SX_TEST_GK4_GEOM] ON [dbo].[TEST] ([GK4_GEOM])
    USING GEOMETRY_GRID 
    WITH (
    	BOUNDING_BOX = (4375000, 5625000, 4600000, 5900000)
    ,	GRIDS = (LEVEL_1 = MEDIUM, LEVEL_2 = MEDIUM, LEVEL_3 = MEDIUM, LEVEL_4 = MEDIUM)
    ,	CELLS_PER_OBJECT = 16
    ) ON [PRIMARY]
    GO
    
    -- Meldungsfenster -----------------------------------------------------
    Befehl(e) wurde(n) erfolgreich abgeschlossen.
    
    
    
    ------------------------------------------------------------------------
    --
    -- Datenbank _TEMP_CS mit Sortierung Latin1_General_CS_AS
    --
    ------------------------------------------------------------------------
    
    -- Create database with case-sensitive collation
    USE [master]
    GO
    
    CREATE DATABASE [_TEMP_CS]
    COLLATE Latin1_General_CS_AS
    GO
    
    ALTER DATABASE [_TEMP_CS]
    SET RECOVERY SIMPLE
    GO
    
    ALTER AUTHORIZATION ON DATABASE::[_TEMP_CS] TO [sa]
    GO
    
    -- Create table with spatial column and spatial index
    USE [_TEMP_CS]
    GO
    
    CREATE TABLE [dbo].[TEST] (
    	[ID] uniqueidentifier NOT NULL DEFAULT(NEWID())
    ,	[GK4_GEOM] geometry
    ,	CONSTRAINT [PK_TEST] PRIMARY KEY CLUSTERED ([ID])
    )
    GO
    
    CREATE SPATIAL INDEX [SX_TEST_GK4_GEOM] ON [dbo].[TEST] ([GK4_GEOM])
    USING GEOMETRY_GRID 
    WITH (
    	BOUNDING_BOX = (4375000, 5625000, 4600000, 5900000)
    ,	GRIDS = (LEVEL_1 = MEDIUM, LEVEL_2 = MEDIUM, LEVEL_3 = MEDIUM, LEVEL_4 = MEDIUM)
    ,	CELLS_PER_OBJECT = 16
    ) ON [PRIMARY]
    GO
    
    -- Meldungsfenster -----------------------------------------------------
    Meldung 0, Ebene 11, Status 0, Zeile 27
    Für den aktuellen Befehl ist ein schwerwiegender Fehler aufgetreten. Löschen Sie eventuelle Ergebnisse.
    

    Mittwoch, 29. März 2017 06:46

Antworten

  • Hallo Hartmut,

    Würdest Du die migrierte Datenbank mit CHECKDB überprüfen?

    DBCC CHECKDB(migrierteDB)
    WITH EXTENDED_LOGICAL_CHECKS, DATA_PURITY, ALL_ERRORMSGS, TABLERESULTS

    Die Rückkehr auf eine ältere Version von SQL Server, wo das Problem nicht auftritt, ist nicht unbedingt zielführend.

    Da ich es gerade mit einer neuen Datenbank unter Anwendung Deines Skriptes probiert habe, wobei es auf der älteren Version (SQL Server 2012) geklappt hat, würde ich Dir empfehlen, einen Bericht mit dem Skript auf Microsoft Connect zu erstellen, so dass sich die zuständigen Personen dieses Problems annehmen können. Verlinke dann den Bericht der Übersichtlichkeit halber auch hier.

    Gruß,
    Dimitar


    Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.

    Donnerstag, 30. März 2017 06:36
    Administrator
  • Ein kleines Update:

    Nach der Installation des SQL Server 2016 SP1 CU3 ist das Problem behoben. Jetzt funktioniert unsere Datenbank wieder wie gehabt.

    Hartmut.

    Donnerstag, 18. Mai 2017 11:05

Alle Antworten

  • Hallo Hartmut,

    Würdest Du die migrierte Datenbank mit CHECKDB überprüfen?

    DBCC CHECKDB(migrierteDB)
    WITH EXTENDED_LOGICAL_CHECKS, DATA_PURITY, ALL_ERRORMSGS, TABLERESULTS

    Die Rückkehr auf eine ältere Version von SQL Server, wo das Problem nicht auftritt, ist nicht unbedingt zielführend.

    Da ich es gerade mit einer neuen Datenbank unter Anwendung Deines Skriptes probiert habe, wobei es auf der älteren Version (SQL Server 2012) geklappt hat, würde ich Dir empfehlen, einen Bericht mit dem Skript auf Microsoft Connect zu erstellen, so dass sich die zuständigen Personen dieses Problems annehmen können. Verlinke dann den Bericht der Übersichtlichkeit halber auch hier.

    Gruß,
    Dimitar


    Bitte haben Sie Verständnis dafür, dass im Rahmen dieses Forums, welches auf dem Community-Prinzip „IT-Pros helfen IT-Pros“ beruht, kein technischer Support geleistet werden kann oder sonst welche garantierten Maßnahmen seitens Microsoft zugesichert werden können.

    Donnerstag, 30. März 2017 06:36
    Administrator
  • Hallo Dimitar,

    danke für Deine Antwort.

    DBCC CHECKDB liefert freundlicherweise die erste von mir beschriebene Fehlermeldung:

    (421 Zeile(n) betroffen)
    Meldung 596, Ebene 21, Status 1, Zeile 10
    Die Ausführung kann nicht fortgesetzt werden, weil die Sitzung den KILL-Status aufweist.
    Meldung 0, Ebene 20, Status 0, Zeile 10
    Für den aktuellen Befehl ist ein schwerwiegender Fehler aufgetreten. Löschen Sie eventuelle Ergebnisse.

    Ansonsten wurden von CHECKDB 0 Zuordnungsfehler und 0 Konsistenzfehler gefunden.

    Ohne räumliche Indizes läuft CHECKDB problemlos durch.

    Danke für Deinen Hinweis auf Microsoft Connect, da hätte ich auch selber draufkommen müssen.

    Donnerstag, 30. März 2017 08:18
  • Das Skript erzeugt auch einen Stack Dump auf SQL Server 2016 SP1 CU2:

    *   Access Violation occurred reading address 0000000000000000
    *   Exception Code    = c0000005 EXCEPTION_ACCESS_VIOLATION
    *   Exception Address = 00007FFEAB1F5F5D Module(sqllang+00000000000D5F5D)

    Wende Dich entweder direkt an den Support oder verwende Connect.

    Falls Du den Eintrag erstellt hast, poste ihn hier, damit andere auch abstimmen können und die Priorität steigt. Ich kann diese Infos dann auch noch mal über andere Kanäle weitergeben.


    Einen schönen Tag noch, Christoph -- Data Platform MVP - http://www.insidesql.org/blogs/cmu

    Donnerstag, 30. März 2017 08:35
  • Dieser Fehler wurde bereits in Microsoft Connect gemeldet. Ich habe einen Kommentar dazu geschrieben.

    Siehe den Beitrag von Michelle Taylor: Severe Error on creating spatial index with USING GEOMETRY_GRID.

    Danke für eure Antworten.

    Donnerstag, 30. März 2017 09:25
  • Der Eintrag ist ja schon fast ein Jahr alt! ;-(

    Ich habe das jetzt auch noch mal per Mail weitergegeben. In der Regel sind die Kollegen dann ziemlich schnell bei der Sache.


    Einen schönen Tag noch, Christoph -- Data Platform MVP - http://www.insidesql.org/blogs/cmu

    Donnerstag, 30. März 2017 09:41
  • Hallo Hartmut,

    wäre der Workaround für Dich einsetzbar die Datenbank auf CI zu setzen und die entsprechenden Spalten mit einer CS-Collation anzulegen?

    -- Create database with case-insensitive collation
    USE [master]
    GO
    
    CREATE DATABASE [_TEMP_CI]
    COLLATE Latin1_General_CI_AS
    GO
    
    ALTER DATABASE [_TEMP_CI]
    SET RECOVERY SIMPLE
    GO
    
    ALTER AUTHORIZATION ON DATABASE::[_TEMP_CI] TO [sa]
    GO
    
    -- Create table with spatial column and spatial index
    USE [_TEMP_CI]
    GO
    
    CREATE TABLE [dbo].[TEST] (
    	[ID] uniqueidentifier NOT NULL DEFAULT(NEWID())
    ,	Feld varchar(10) Collate Latin1_General_CS_AS
    ,	[GK4_GEOM] geometry
    ,	CONSTRAINT [PK_TEST] PRIMARY KEY CLUSTERED ([ID])
    )
    GO
    
    CREATE SPATIAL INDEX [SX_TEST_GK4_GEOM] ON [dbo].[TEST] ([GK4_GEOM])
    USING GEOMETRY_GRID 
    WITH (
    	BOUNDING_BOX = (4375000, 5625000, 4600000, 5900000)
    ,	GRIDS = (LEVEL_1 = MEDIUM, LEVEL_2 = MEDIUM, LEVEL_3 = MEDIUM, LEVEL_4 = MEDIUM)
    ,	CELLS_PER_OBJECT = 16
    ) ON [PRIMARY]
    GO
    
    Insert into test(Feld) values('Auto'), ('auto'), ('AUTO');
    
    Select *
    from test
    where Feld = 'Auto';


    Einen schönen Tag noch, Christoph -- Data Platform MVP - http://www.insidesql.org/blogs/cmu

    Freitag, 31. März 2017 08:09
  • Hallo Christoph,

    das ist ein guter Vorschlag.

    Es wird aber sicherlich eine der letzten Optionen sein, die ich einsetzen werde, falls sich in absehbarer Zeit keine andere Problemlösung ergibt. Unser Kunde hat sich dafür entschieden, erst einmal auf die räumlichen Indizes zu verzichten, da das bereits vorhandene WebGIS-System dieses Jahr abgelöst werden soll. Somit werden die Bohrungen auf absehbare Zeit nicht in einem GIS dargestellt werden müssen.

    Ein einfaches ALTER DATABASE [name] COLLATE Latin1_General_CI_AS und eine Anpassung der Sortierung der betroffenen Tabellenspalten funktioniert ja leider nicht ganz so einfach ;-)

    Daher müsste natürlich die komplette Datenbank mit allen Tabellen, Views, Routinen etc. und den entsprechenden Anpassungen neu erstellt und auch der komplette Datenbestand übertragen bzw. neu importiert werden.

    Auf letzteres würde ich gerne verzichten, denn mehr als 100 Jahre geologische Forschung und Erkundung im Deutschen Reich, der DDR und der BRD haben natürlich einen entsprechenden Datenbestand hervorgebracht, der auch bei unserem Kunden seit der Wende fleißig verschlüsselt, digitalisiert und in Datenbanken abgelegt wurde und auch immer noch wird.

    Nochmal danke für den Vorschlag. Ich werde ihn auf jeden Fall im Hinterkopf behalten.

    Freitag, 31. März 2017 09:15
  • Hallo Hartmut,

    ein MVP-Kollege hatte gerade Gelegenheit den Program Manager zu treffen und hat das Thema mit ihm diskutiert. Sie wollen es sich jetzt mal anschauen! ;-)


    Einen schönen Tag noch, Christoph -- Data Platform MVP - http://www.insidesql.org/blogs/cmu

    Freitag, 7. April 2017 07:30
  • Guten Morgen,

    das klingt richtig gut. Dann hoffen wir, dass das Problem bald gelöst werden kann.

    Schöne Grüße, Hartmut.

    Freitag, 7. April 2017 07:45
  • Hallo Hartmut,

    wie ich gerade gehört habe, wird die Lösung aller Voraussicht nach im nächsten CU enthalten sein.


    Einen schönen Tag noch, Christoph -- Data Platform MVP - http://www.insidesql.org/blogs/cmu

    Donnerstag, 13. April 2017 06:30
  • Hallo Christoph,

    es freut mich, dass zu hören.

    Vielen Dank nochmal für eure Hilfe und ein schönes Osterfest.

    Hartmut.

    Donnerstag, 13. April 2017 06:50
  • Ein kleines Update:

    Nach der Installation des SQL Server 2016 SP1 CU3 ist das Problem behoben. Jetzt funktioniert unsere Datenbank wieder wie gehabt.

    Hartmut.

    Donnerstag, 18. Mai 2017 11:05