Benutzer mit den meisten Antworten
SQL Server 2016: Räumliche Indizes funktionieren nicht in einer Datenbank mit Latin1_General_CS_AS

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.
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ß,
DimitarBitte 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.
- Als Antwort vorgeschlagen Christoph Muthmann Donnerstag, 30. März 2017 08:33
- Als Antwort markiert Hartmut Kühne Donnerstag, 30. März 2017 09:25
-
Ein kleines Update:
Nach der Installation des SQL Server 2016 SP1 CU3 ist das Problem behoben. Jetzt funktioniert unsere Datenbank wieder wie gehabt.
Hartmut.
- Als Antwort markiert Dimitar DenkovMicrosoft contingent staff, Administrator Dienstag, 30. Mai 2017 06:41
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ß,
DimitarBitte 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.
- Als Antwort vorgeschlagen Christoph Muthmann Donnerstag, 30. März 2017 08:33
- Als Antwort markiert Hartmut Kühne Donnerstag, 30. März 2017 09:25
-
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.
-
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
-
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.
-
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
-
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
-
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.
-
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
-
Ein kleines Update:
Nach der Installation des SQL Server 2016 SP1 CU3 ist das Problem behoben. Jetzt funktioniert unsere Datenbank wieder wie gehabt.
Hartmut.
- Als Antwort markiert Dimitar DenkovMicrosoft contingent staff, Administrator Dienstag, 30. Mai 2017 06:41